这个循环每秒都在执行,即便某个Pod意外崩溃，控制器也会在秒级内重新创建，保证集群状态始终向期望状态收敛。
Pod：调度的最小单元
Kubernetes并不直接调度容器,而是以Pod为最小单位，一个Pod里可以有一个或多个容器，它们共享网络命名空间和存储卷，这种设计意味着调度器只需要决策”这个Pod放哪台节点”，而不必关心内部容器的具体细节。
直观理解：Pod是一套房，容器是住在这个套房里的租户，租房时你先选房子位置，租户本身跟着房子走。
Kubernetes调度器工作流程：从调度算法到节点亲和性配置
调度器（kube-scheduler）是整个编排系统的”交通指挥”，它的职责是为每个待调度的Pod寻找一台合适的节点（Node），这个过程分两步：过滤和打分。
过滤阶段：筛掉不合格的节点
调度器首先根据一系列硬性条件剔除不满足要求的节点,常见条件包括：
- 资源是否足够（CPU、内存、GPU等）
- 端口是否冲突
- 是否满足nodeSelector指定的标签
- 是否容忍节点上的污点
- 卷是否能在该节点挂载（如云盘绑定地域）
一个Pod声明需要2核CPU、4GB内存，而某节点只剩1核可用，这个节点会直接出局。
打分阶段：在合格者中选出最优解
通过过滤后的节点进入打分环节,Kubernetes内置了多种评分策略，
- 资源余量：剩余资源多的节点得分高，这有助于负载均衡
- Pod分布：尽量将同一应用的Pod分散到不同节点，避免单点故障
- 亲和性偏好：如果配置了软性节点亲和性，匹配的节点会额外加分
最终得分最高的节点被选中,整个过程通常在毫秒级完成。
实操：配置节点亲和性
如果你想让某个应用优先部署到SSD节点的机器上,可以通过nodeAffinity实现：
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 80
preference:
matchExpressions:
- key: disk-type
operator: In
values:
- ssd
配置提交后,调度器在打分阶段会给带disk-type=ssd标签的节点加80分，需要注意的是，亲和性属于”优先级”而非”必须”，如果没有匹配节点，Pod仍会被调度到其他机器上。
节点亲和性与反亲和性对比
| 功能 | 典型场景 | 配置方式 |
|---|---|---|
| 节点亲和性 | 将Pod调度到特定机型或地域 | nodeAffinity |
| Pod间亲和性 | 让两个服务靠近部署，减少网络延迟 | podAffinity |
| Pod间反亲和性 | 将同一应用副本分散到不同节点，提升容灾能力 | podAntiAffinity |
生产环境中,反亲和性的使用频率往往高于亲和性，行业共识认为，同应用多副本部署在同一节点，相当于把鸡蛋放在同一个篮子里，节点故障会直接导致整个应用中招。
Kubernetes生产环境落地：集群节点管理、资源配额与高可用
Kubernetes的编排能力远不止”把Pod放到节点上”这一步，在真实生产环境中，我们同样关注资源配额、滚动更新、自动扩缩容这些运行时行为。
用资源配额保障集群稳定性
如果没有限制,一个异常应用可能耗尽整个集群的内存，Kubernetes通过ResourceQuota和LimitRange提供两层保护：
- ResourceQuota：以命名空间为单位，限制该空间下所有Pod的资源总和
- LimitRange：为单个Pod设置默认的request和limit
对于多团队共享集群的场景,资源配额必不可少，搭建Kubernetes集群后，建议在创建命名空间时同步下发配额配置，避免后期出现”一个团队吃垮整个集群”的事故。
高可用部署：从单点到多副本
Kubernetes用Deployment管理无状态应用,滚动更新策略默认
maxUnavailable=25%、maxSurge=25%，这意味着升级过程中，同时最多有25%的副本不可用，同时最多额外创建25%的临时副本。
默认策略并不适合所有场景,跑在Kubernetes里的数据库或消息队列，通常需要配置PodDisruptionBudget（PDB），确保主动驱逐（如节点维护）时副本数量不低于指定阈值。
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: mysql-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: mysql
这段配置告诉Kubernetes：无论什么原因，保证至少2个MySQL副本在运行，否则不允许驱逐Pod。
自动扩缩容：应对流量高峰
HorizontalPodAutoscaler（HPA）让集群能根据CPU、内存或自定义指标自动调整副本数，它和调度器协同工作：HPA负责”决定改到几个副本”，调度器负责”把新副本放到哪里”。
配置一个基于CPU的HPA：
kubectl autoscale deployment web-server --cpu-percent=70 --min=3 --max=20
当CPU使用率超过70%时，系统会自动扩容，最高20个副本；低于阈值一段时间后自动缩容回最小值3个。
多集群场景下的编排调度策略
单一Kubernetes集群有规模上限,数千节点的规模对etcd的压力、网络插件的复杂度都会陡增，近年来越来越多的企业采用多集群架构，编排调度也随之延伸到集群维度。
多集群调度的核心诉求
- 隔离环境：开发、测试、生产各用独立集群，互不干扰
- 跨地域部署：将应用部署到离用户最近的区域，降低访问延迟
- 容灾切换：某一云可用区整体故障时，流量自动切换到其他集群
常见方案是Karmada或Kubernetes Federation，它们在Kubernetes之上再加一层控制面，负责将应用分发到不同成员集群，并维护每个集群的状态。
比如用Karmada将同一个Deployment下发到两个可用区：
kubectl create -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: app-demo labels: app: demo spec: replicas: 4 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - name: nginx image: nginx:1.25 EOF
配合PropagationPolicy,可以指定”这个Deployment在两个集群各分配2个副本，分别位于北京和上海可用区”，任何一边的故障，都不会影响另一边正常服务。
把编排调度玩明白的关键点
Kubernetes的统一编排调度是一套完整的闭环系统：API Server接收意图，etcd存储状态，控制器纠正偏差，调度器智能分配，Kubelet执行落地，五个组件各司其职，配合Pod、Deployment、HPA、PDB这些资源对象，形成了从部署到运维、从日常管理到故障自愈的完整能力体系。
生产环境落地的关键不只是会用kubectl命令，更要理解每一步背后的选择逻辑：为什么Pod要这样调度、资源配额怎么设、反亲和性要不要加，把这些问题想清楚，Kubernetes才能真正成为省心的编排系统，而不是另一个需要日夜维护的负担。
Kubernetes编排调度常见问题解答
Kubernetes调度器能保证最优调度结果吗？
不能,Kubernetes调度器在过滤和打分阶段使用的是启发式算法，寻找的是”足够好”的节点而非”绝对最优”的节点，集群规模越大，这种近似最优解的差距越明显，如果业务对调度结果有极致的性能要求，可以通过自定义调度器扩展Kubelet的调度策略，或使用拓扑感知调度（Topology Aware Scheduling）来优化流量走向。
为什么集群中有节点处于NotReady状态，但应用没有中断？
这正是Kubernetes编排能力的体现,当节点失联超过默认容忍时间（约40秒）后，节点上的Pod会被标记为Unknown，若Pod由Deployment管理，控制器会在其他健康节点上重新创建副本，实际影响取决于Pod的副本数和反亲和性策略的配置，要想避免单点故障，建议使用topologySpreadConstraints将副本均匀打散到不同可用区。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641265.html
