1. 项目概述为什么集群调度是K8S的“大脑”如果你已经玩过一阵子K8S部署过几个Pod用过kubectl get pods看到它们跑在某个节点上那你可能已经和集群调度打过交道了。这个“调度”过程就像一个大公司的HR部门负责把成千上万个工作任务Pod合理地分配到各个工位Node上。但它的工作远比HR复杂它不仅要考虑工位有没有空节点资源还要考虑任务之间的亲疏关系亲和性、任务对硬件的要求节点选择器、甚至要保证公司大楼集群的稳定和高效。很多人刚接触K8S觉得kubectl apply -f deployment.yaml就完事了调度是K8S自动完成的“黑盒”。但当你遇到“Pod一直Pending”、“节点负载不均”、“某些服务死活调度不到GPU机器上”这些问题时你就必须打开这个黑盒看看了。集群调度决定了你的应用性能、资源利用率和系统稳定性是线上环境避不开的核心议题。无论是k8s安装部署后第一步要调的参数还是处理k8s虚拟机cpu占用率太高这种棘手问题根源往往都在调度策略上。2. 调度器核心原理与工作流拆解K8S的调度器kube-scheduler是一个独立运行的控制器它时刻监视着那些还没被分配节点的Pod即spec.nodeName为空的Pod。它的工作是一个典型的“筛选-打分”两阶段流程我把它理解为“海选”加“决赛”。2.1 第一阶段筛选Filtering调度器会遍历集群中的所有节点用一系列叫做“预选策略Predicates”的过滤器把不符合硬性条件的节点全部淘汰。这个过程是并行的速度很快。常见的过滤器包括NodeResourcesFit检查节点的CPU、内存资源是否足够满足Pod的请求requests。这是最基本的过滤器。如果Pod请求了2核4G而节点只剩1核2G那这个节点在第一轮就会被淘汰。NodeName如果Pod的spec.nodeName已经指定了比如你用kubectl run时加了--node参数调度器就只会尝试调度到这个指定节点其他节点被过滤。PodFitsHostPorts检查节点上Pod需要使用的宿主机端口hostPort是否已被占用。MatchNodeSelector检查节点标签是否满足Pod的nodeSelector或nodeAffinity配置。PodToleratesNodeTaints检查Pod的容忍度tolerations是否能忍受节点的污点taints。这是实现“节点独占”或“特殊节点调度”的关键比如不让普通Pod调度到带有dedicatedgpu:NoSchedule污点的GPU节点上。注意很多人部署pgsql或redis这类有状态应用时Pod卡在Pending第一步就应该用kubectl describe pod pod-name查看事件里面通常会明确提示是哪个Predicate失败了比如“0/3 nodes are available: 3 Insufficient cpu.”这就直接指向了资源不足的问题。2.2 第二阶段打分Scoring通过海选的节点们进入决赛圈。调度器会为每个节点计算一个分数0-100分得分最高的节点就是最终赢家。打分策略Priorities有很多它们共同决定了调度的“偏好”。常用的打分项包括LeastRequestedPriority优先选择资源请求最少的节点。公式是(节点剩余可分配CPU / 节点CPU总量) * 10 (节点剩余可分配内存 / 节点内存总量) * 10。这个策略倾向于将Pod分散开避免节点过载是平衡节点负载的核心。BalancedResourceAllocation优先选择CPU和内存使用率更均衡的节点。它不希望看到一个节点CPU快满了但内存还很空闲或者反过来。这有助于提高资源利用率防止单一资源瓶颈。NodeAffinityPriority满足Pod的nodeAffinity节点亲和性规则的节点会获得高分。TaintTolerationPriority根据Pod容忍的污点数量和程度进行微调打分。ImageLocalityPriority如果节点上已经缓存了Pod所需的容器镜像则该节点得分更高。这能加速Pod启动。调度器会为每个策略赋予一个权重最后计算加权总分。默认配置下LeastRequestedPriority和BalancedResourceAllocation的权重较高所以K8S默认行为是追求负载均衡。2.3 调度结果绑定选出最优节点后调度器并不会直接去节点上创建容器。它只是向APIServer发送一个绑定Binding请求将Pod的spec.nodeName字段更新为这个节点名。这个写操作一旦完成该节点上的kubelet组件就会监听到这个属于它的Pod然后才开始拉取镜像、创建容器的实际工作。这个“决策与执行分离”的架构非常清晰也使得自定义调度器成为可能——你完全可以自己写一个程序按照自己的逻辑为Pod选择节点然后向APIServer发送绑定请求即可。3. 高级调度策略实战详解理解了默认调度器的工作原理我们就能利用K8S提供的丰富API来精细化控制调度过程解决复杂的业务场景问题。3.1 节点亲和性与反亲和性Node Affinity/Anti-Affinity这用于表达Pod对节点的“喜好”或“厌恶”。比古老的nodeSelector更强大、更灵活。requiredDuringSchedulingIgnoredDuringExecution硬亲和必须满足的条件不满足则不调度。常用于强制Pod运行在特定硬件或区域的节点上。preferredDuringSchedulingIgnoredDuringExecution软亲和优先满足的条件不满足也能调度但分数会低。常用于优化比如“优先部署在SSD存储的节点上”。实战案例将若依Ruoyi-Cloud的网关组件优先调度到高带宽节点假设我们给高带宽节点打上了标签network-typehigh-bandwidth。apiVersion: apps/v1 kind: Deployment metadata: name: ruoyi-gateway spec: template: spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 # 权重范围1-100 preference: matchExpressions: - key: network-type operator: In values: - high-bandwidth containers: - name: gateway反亲和性Pod Anti-Affinity则用于避免Pod扎堆提高可用性。一个经典场景是部署ZooKeeper、Etcd等有状态集群需要避免多个实例在同一节点。affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - zookeeper topologyKey: kubernetes.io/hostname # 关键确保不同主机这里topologyKey: kubernetes.io/hostname意味着“主机名”这个拓扑域要求匹配到的Pod不能在同一台主机上。你也可以用failure-domain.beta.kubernetes.io/zone来实现跨可用区部署。3.2 污点与容忍度Taints and Tolerations这是一个“节点排斥Pod”的机制。给节点打上污点Pod必须声明能容忍这个污点才能被调度上去。这实现了节点的“专用”或“预留”。核心操作给节点加污点kubectl taint nodes node1 dedicatedfoo:NoSchedulededicatedfoo键值对。NoSchedule效果表示绝不调度不容忍的Pod。还有PreferNoSchedule尽量不调度和NoExecute不仅不调度还会驱逐已有不容忍的Pod。在Pod上添加容忍度tolerations: - key: dedicated operator: Equal value: foo effect: NoSchedule实战场景GPU节点专用给所有GPU节点打上gputrue:NoSchedule污点。只有深度学习训练任务Pod才添加对应的容忍度。Master节点隔离K8S安装后Master节点默认带有node-role.kubernetes.io/master:NoSchedule污点防止业务Pod调度上去干扰控制平面。问题排查当出现k8s虚拟机cpu占用率太高时可以给过载节点临时加上一个污点node.kubernetes.io/overload:NoSchedule阻止新Pod调度上去为排查和恢复争取时间。3.3 Pod间亲和与反亲和Inter-Pod Affinity/Anti-Affinity这用于控制Pod和Pod之间的位置关系。比如让前端Pod和后端Pod尽量部署在同一节点、同一可用区以减少网络延迟或者让同一个服务的多个副本分散在不同节点以提高容灾能力。它的语法和节点亲和类似但多了一个关键的topologyKey用于定义“什么叫在一起”。这个key必须是节点标签的键比如kubernetes.io/hostname同一台机器、topology.kubernetes.io/zone同一个可用区。实战案例部署高可用Redis哨兵我们希望Redis主从实例不要放在同一台主机上。# 在Redis Deployment的Pod模板中 affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - redis-store topologyKey: kubernetes.io/hostname实操心得Pod反亲和性尤其是requiredDuringSchedulingIgnoredDuringExecution硬反亲和在使用时要非常小心。如果集群节点数少于Pod副本数且规则要求每个节点只能有一个Pod那么多出来的Pod将永远处于Pending状态。生产环境更推荐使用preferredDuringSchedulingIgnoredDuringExecution软反亲和并设置合理的weight在保证高可用的同时提供一定的调度灵活性。4. 资源请求与限制调度的基石这是调度器做决策时最重要的依据也是很多资源相关问题的根源。在Pod的容器定义中resources字段包含两个关键部分resources: requests: # 请求值调度依据 memory: 256Mi cpu: 250m limits: # 限制值运行约束 memory: 512Mi cpu: 500mrequests请求这是Pod向集群“申请”的资源量也是调度器在筛选阶段判断节点资源是否足够的唯一标准。如果一个节点剩余的可分配资源Allocatable小于Pod的请求值该节点就会被过滤掉。这个值设置是否合理直接决定了集群的调度效率和资源利用率。limits限制这是容器运行时如Docker给容器设置的上限。如果容器使用资源超过此限制会被OOM Kill内存或ThrottleCPU。这个值不影响调度只影响运行时的行为。常见问题与技巧requests设置过低Pod被调度到一个资源紧张的节点虽然能启动但运行时与其他Pod竞争资源性能极差表现为应用响应慢但节点监控看整体资源没用满。这就是“吵群架”现象。requests设置过高导致节点资源碎片化。比如节点有4核你每个Pod请求2核那么只能调度2个Pod即使它们实际只用0.5核也浪费了另外2核的调度容量。集群资源利用率低下。limits设置但requests未设置requests默认等于limits。这会导致资源浪费因为调度器按高的requests来预留资源。只设limits不设requests通过LimitRange默认设置同上不推荐。如何设置合理的值这是一个持续优化的过程。建议新应用上线参考测试环境数据设置一个保守的requests和一个稍宽松的limits。生产环境运行后必须结合监控如Prometheus来观察应用的实际资源使用量特别是P95/P99。使用kubectl top pod可以看实时数据但长期趋势分析要靠监控系统。使用VPA垂直Pod自动扩缩容对于非弹性应用可以考虑使用VPA自动分析历史负载并推荐或更新requests和limits值。注意VPA更新资源时会重建Pod对有状态服务需谨慎。排查k8s虚拟机cpu占用率太高的一个思路先看是节点整体CPU高还是某个Pod的CPU使用率远高于其requests。如果是后者可能是该Pod业务压力真的大需要调高其limits并考虑水平扩容如果是节点整体高但各个Pod的requests总和并不高那就是典型的“资源超卖”导致的资源竞争需要调整Pod的requests向真实使用量靠拢或者对节点上的Pod进行梳理和重新调度。5. 调度器性能调优与自定义默认调度器能满足大部分场景但在超大规模集群数千节点或具有复杂调度需求的场景下可能需要调优甚至自定义。5.1 调度器参数调优kube-scheduler支持很多启动参数可以通过修改其静态Pod配置文件通常是/etc/kubernetes/manifests/kube-scheduler.yaml来调整。--percentage-of-nodes-to-score默认值50。调度器不会在打分阶段评估所有节点而是先抽样一部分节点进行打分。在大集群中调低此值可以提升调度性能但可能错过最优节点。对于1000个节点以下的集群保持默认或略低即可。--kube-api-qps和--kube-api-burst调度器访问APIServer的QPS限制。如果调度队列积压严重可以适当调高比如从默认的50调到100。调整Predicates和Priorities你可以禁用一些用不到的插件或者调整打分插件的权重。例如如果你更看重资源利用率而非绝对均衡可以降低LeastRequestedPriority的权重提高BalancedResourceAllocation的权重。5.2 使用多调度器K8S支持集群中运行多个调度器。你可以开发一个自定义调度器专门负责调度某一类特定的Pod比如AI训练任务。Pod可以通过spec.schedulerName字段来指定由哪个调度器负责调度。默认调度器的名字是default-scheduler。自定义调度器场景比如一个专门调度批处理作业的调度器它可能采用“装箱”算法尽可能将任务塞满节点而不太关心负载均衡另一个调度器专门调度有状态服务它更关注Pod与持久化存储的位置关系。5.3 调度框架Scheduling Framework从K8S v1.19开始调度框架提供了一组更模块化、可扩展的插件API。它允许开发者在不重写整个调度器的前提下通过实现特定的插件接口来注入自定义的筛选、打分、绑定等逻辑。这是目前实现自定义调度需求的主流和推荐方式。例如你可以写一个插件在打分阶段根据节点上是否运行了某个特定的守护进程如你的专属安全Agent来给予加分或减分。6. 实战故障排查从Pending Pod到调度决策当Pod卡在Pending状态时kubectl describe pod是你的第一把钥匙。我们系统性地梳理一下排查流程。步骤一查看Pod事件kubectl describe pod pod-name -n namespace重点关注Events部分。0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, 2 node(s) didnt match Pods node affinity.解读清晰指出了两个原因1个节点有磁盘压力污点2个节点不满足Pod的节点亲和性规则。你需要检查Pod的亲和性配置和节点的污点/状态。0/3 nodes are available: 3 Insufficient cpu.解读所有节点CPU资源不足。检查Pod的requests.cpu是否设置过高或者集群是否需要扩容节点。0/3 nodes are available: 3 node(s) didnt have free ports for the requested pod ports.解读Pod申请的hostPort在所有节点上都被占用了。考虑换端口或改用NodePort/LoadBalancer Service。步骤二检查Pod配置资源请求kubectl get pod pod-name -o yaml | grep -A 5 -B 5 resources确认requests是否合理。节点选择器与亲和性检查nodeSelector、nodeAffinity配置是否正确对应的节点标签是否存在。污点与容忍度检查Pod的tolerations是否匹配目标节点的taints。使用kubectl describe node node-name查看节点污点。步骤三检查节点状态节点资源kubectl describe node node-name看Allocatable和Allocated资源部分。kubectl top node看实时使用量。节点状态节点是否Ready是否有MemoryPressure、DiskPressure、PIDPressure这些条件会由Node Problem Detector自动添加对应的污点阻止调度。节点标签确认节点上的标签kubectl get node --show-labels是否满足Pod的要求。步骤四检查调度器本身调度器日志如果怀疑调度器有问题查看其日志。kubectl logs -n kube-system kube-scheduler-pod-name。注意调度器可能有多副本。调度器状态检查调度器Pod是否运行正常有无重启。一个综合案例k8s configmap执行脚本 permission denied与调度的间接关系这个错误本身是权限问题通常发生在Pod内的容器尝试执行ConfigMap挂载的脚本时。但它有时会和调度产生关联你可能会为了让某个Pod能访问特定的ConfigMap而使用节点亲和性将该Pod调度到ConfigMap所在的节点如果ConfigMap内容较大出于本地性考虑。但如果该节点的安全上下文或文件系统权限与Pod要求不符就可能出现权限错误。排查时除了检查Pod的securityContext和ConfigMap文件的权限默认是644还要结合kubectl describe pod看Pod被调度到了哪个节点然后登录该节点检查挂载点的实际权限。7. 与监控的联动用Prometheus洞察调度健康度正如热词中提到的prometheus监控k8s集群状态的详细操作监控是调度优化的眼睛。我们需要关注几个关键指标调度器队列深度指标scheduler_pending_pods意义等待调度的Pod数量。如果这个值持续很高说明调度器可能成为瓶颈或者集群资源严重不足。调度尝试结果指标scheduler_schedule_attempts_total(按结果result标签过滤如unschedulable,error)意义统计调度成功和失败的次数。失败次数突增意味着出现了普遍的调度约束问题如新上了个资源请求巨大的Deployment。调度延迟指标scheduler_scheduling_duration_seconds(按阶段profile,result分桶)意义Pod从创建到被调度完成的延迟分布。P99延迟过高会影响应用启动速度。节点资源压力指标kube_node_status_condition(条件类型为MemoryPressure,DiskPressure,PIDPressure)意义节点处于资源压力状态会打上污点影响调度。监控这些指标可以提前预警及时扩容或清理节点。Pod资源使用率 vs 请求率指标使用container_cpu_usage_seconds_total/ (kube_pod_container_resource_requests* 时间) 计算CPU使用率占比。内存同理。意义这是优化requests设置、提升集群利用率的黄金指标。如果使用率持续远低于请求率说明资源浪费如果持续接近或超过请求率说明资源紧张可能影响性能。配置告警规则示例Prometheus Rulegroups: - name: k8s-scheduler rules: - alert: SchedulerPendingPodsHigh expr: scheduler_pending_pods 10 for: 5m labels: severity: warning annotations: summary: 调度队列积压 description: 等待调度的Pod数量超过10个持续5分钟。可能集群资源不足或调度器异常。通过监控这些指标你可以从“事后排查”变为“事前预警”和“持续优化”让集群调度始终处于健康、高效的状态。