K8S（九）—— Kubernetes 集群调度全面解析

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

前言
[一、Kubernetes 集群调度](#一、Kubernetes 集群调度)
- [1.1 Kubernetes组件协作机制](#1.1 Kubernetes组件协作机制)
- - [1.1.1 关键组件及职责](#1.1.1 关键组件及职责)
  - [1.1.2 组件协作流程简述](#1.1.2 组件协作流程简述)
- [1.2 Pod创建与工作机制流程](#1.2 Pod创建与工作机制流程)
- - [1.2.1 初始化监听（List-Watch启动）](#1.2.1 初始化监听（List-Watch启动）)
  - - （1）三大组件启动监听（List-Watch）
    - [（2）用户创建 Pod 对象](#（2）用户创建 Pod 对象)
    - [（3）API Server 将 Pod 信息写入 etcd](#（3）API Server 将 Pod 信息写入 etcd)
    - [（4）etcd 通知事件（Create）](#（4）etcd 通知事件（Create）)
    - [（5）Controller Manager 监听到 Pod 创建事件](#（5）Controller Manager 监听到 Pod 创建事件)
    - [（6）Replication Controller（RC）/ ReplicaSet 保证副本数](#（6）Replication Controller（RC）/ ReplicaSet 保证副本数)
    - [（7）API Server 更新 etcd（记录详细信息）](#（7）API Server 更新 etcd（记录详细信息）)
    - [（8）etcd 触发 Pod 信息更新事件](#（8）etcd 触发 Pod 信息更新事件)
    - [（9）Scheduler 监听到待调度的 Pod](#（9）Scheduler 监听到待调度的 Pod)
    - [（10）Scheduler 更新调度结果](#（10）Scheduler 更新调度结果)
    - [（11）etcd 确认更新 & API Server 同步结果](#（11）etcd 确认更新 & API Server 同步结果)
    - [（12）kubelet 在 Node 上拉取并运行容器](#（12）kubelet 在 Node 上拉取并运行容器)
    - [（13）API Server 更新 Pod 状态](#（13）API Server 更新 Pod 状态)
二、Scheduler工作原理
- [2.1 调度器核心任务与目标](#2.1 调度器核心任务与目标)
- - [2.1.1 核心任务](#2.1.1 核心任务)
  - [2.1.2 调度目标](#2.1.2 调度目标)
- [2.2 调度流程详解](#2.2 调度流程详解)
三、指定调度节点的常用方式
- [3.1 nodeName：强制绑定节点](#3.1 nodeName：强制绑定节点)
- [3.2 nodeSelector：基于标签匹配](#3.2 nodeSelector：基于标签匹配)
四、亲和性与反亲和性调度
- [4.1 节点亲和性（NodeAffinity）](#4.1 节点亲和性（NodeAffinity）)
- [4.1.3 实践案例](#4.1.3 实践案例)
- [4.2 Pod亲和性与反亲和性](#4.2 Pod亲和性与反亲和性)
五、污点（Taint）与容忍（Toleration）
六、节点维护与Pod生命周期
七、故障排查常用命令
总结

前言

1、list-watch 组件 Controller Manager Scheduler kubelet

2、list-watch 工作机制

3、亲和性（节点亲和pod亲和）和反亲和性以及硬策略和软策略

4、污点和容忍

5、驱逐

---

一、Kubernetes 集群调度

1.1 Kubernetes组件协作机制

Kubernetes各组件通过List-Watch机制实现协同工作与数据同步，这种机制确保了组件间的解耦与集群状态的实时一致性。

1.1.1 关键组件及职责

组件	职责描述
kubectl / API客户端	向 APIServer 发起资源创建、查询、更新等管理请求
APIServer	集群控制的核心入口，负责 API 调用处理、权限校验、与 etcd 交互
etcd	分布式键值存储，保存集群所有状态信息（如 Pod、Node、配置等）
Controller Manager	运行各类控制器（如 ReplicaSet、Deployment），维持资源期望状态（如副本数、自愈逻辑）
Scheduler	调度器，为未分配节点的 Pod 选择最合适的 Node 节点
kubelet	节点代理程序，负责本节点上 Pod 的生命周期管理（创建、启停、状态上报）

1.1.2 组件协作流程简述

用户通过kubectl或其他客户端向APIServer发送请求（如创建Pod）后，APIServer会完成权限校验并将数据存入etcd。
etcd存储数据时会触发事件（如Create事件），并同步给APIServer；
其他组件（Controller Manager、Scheduler、kubelet）通过监听APIServer的事件变化，触发各自的业务逻辑（如Controller Manager维持副本数、Scheduler调度Pod、kubelet运行容器），最终完成整个资源的部署与管理。

1.2 Pod创建与工作机制流程

Pod的完整生命周期需多个组件协同完成，其核心依托于List-Watch模型实现动态响应。

以下是Pod创建的典型流程：

1.2.1 初始化监听（List-Watch启动）

（1）三大组件启动监听（List-Watch）

Controller Manager、Scheduler、kubelet

启动后会分别通过 Watch API Server（HTTPS 6443 端口）监听集群资源事件变化。

Controller Manager：监听副本控制类对象（如 ReplicaSet、Deployment）

Scheduler：监听未调度的 Pod

kubelet：监听分配到本节点的 Pod

（2）用户创建 Pod 对象

用户通过 kubectl 或其他 API 客户端发送创建 Pod 的请求给 API Server。

示例：

（3）API Server 将 Pod 信息写入 etcd

API Server 校验请求后，将 Pod 的元数据存入 etcd。

写入成功后返回确认给客户端。

（4）etcd 通知事件（Create）

etcd 接受到 Pod 信息后，触发 Create 事件。

该事件被发送给 API Server。

（5）Controller Manager 监听到 Pod 创建事件

Controller Manager 通过 Watch 机制收到 API Server 发出的 Pod 创建事件。

（6）Replication Controller（RC）/ ReplicaSet 保证副本数

）Controller Manager 在接到 Create 事件以后，如果发现副本数量不足，则由 RC/ReplicaSet

创建所需副本。

扩容、缩容操作也都由此机制控制。

（7）API Server 更新 etcd（记录详细信息）

Controller Manager 创建完 Pod 副本后，API Server 会将 Pod 的详细信息更新写入 etcd。

包括副本数量、副本模板、容器规格等。

（8）etcd 触发 Pod 信息更新事件

etcd 再次发送更新事件给 API Server。

kubectl apply -f pod.yaml

（9）Scheduler 监听到待调度的 Pod

Scheduler Watch 到新创建的 Pod 处于 "Pending" 状态（尚未分配节点）。

通过调度算法（资源、亲和性、污点等）为其选择一个合适的 Node。

（10）Scheduler 更新调度结果

Scheduler 将选定的 Node 信息写回到 API Server。

API Server 更新 etcd 中该 Pod 的 Node 绑定信息。

（11）etcd 确认更新 & API Server 同步结果

etcd 更新成功后向 API Server 返回确认。

API Server 同步 Pod 的最新状态（包括 Node 绑定结果）。

（12）kubelet 在 Node 上拉取并运行容器

kubelet 监听到分配给自己的新 Pod。

调用容器运行时（Docker/containerd）：

拉取镜像
创建容器
启动容器
启动成功后将 Pod 状态（Running、Failed 等）上报给 API Server。

（13）API Server 更新 Pod 状态

API Server 将 kubelet 上报的状态写入 etcd。

etcd 确认写入成功后，集群状态完成同步，Pod 正式进入 Running 状态

kubelet 持续监听 Pod 事件，是为了应对副本数变化、镜像更新等动态操作。

注意：在创建 Pod 的工作就已经完成了后，为什么 kubelet 还要一直监听呢？原因很简单，假设这个

时候 kubectl 发命令，要扩充 Pod 副本数量，那么上面的流程又会触发一遍，kubelet 会根据最新的

Pod 的部署情况调整 Node 的资源。又或者 Pod 副本数量没有发生变化，但是其中的镜像文件升级

了，kubelet 也会自动获取最新的镜像文件并且加载。

二、Scheduler工作原理

2.1 调度器核心任务与目标

2.1.1 核心任务

Scheduler的核心职责是为未绑定节点的Pod（spec.nodeName == ""）分配合适的Node节点，通过创建binding对象记录调度结果。

2.1.2 调度目标

公平性：确保节点间资源分配均衡，避免个别节点负载过高；
高效性：最大化集群资源利用率，减少资源浪费；
效率：快速完成大批量Pod的调度，降低调度延迟；
灵活性：支持自定义调度策略与插件，适配复杂业务场景。

2.2 调度流程详解

调度过程分为过滤（Predicate）和优选（Priorities）两个阶段，最终选择最优节点绑定Pod。

预选和优选

调度分为几个部分：首先是过滤掉不满足条件的节点，这个过程称为预算策略（predicate）；然后对

通过的节点按照优先级排序，这个是优选策略（priorities）；最后从中选择优先级最高的节点。如果中

间任何一步骤有错误，就直接返回错误

三、指定调度节点的常用方式

3.1 nodeName：强制绑定节点

pod.spec.nodeName直接将Pod调度到指定节点，跳过Scheduler的调度逻辑，属于强制绑定。

3.2 nodeSelector：基于标签匹配

pod.spec.nodeSelector通过标签选择器 label-selector 匹配节点，由Scheduler根据标签策略调度匹配 label，然后调度 Pod 到目标节点，属于强制约束。

四、亲和性与反亲和性调度

亲和性调度用于更灵活地控制Pod与节点、Pod与Pod之间的调度关系，分为节点亲和性、Pod亲和性与Pod反亲和性。

4.1 节点亲和性（NodeAffinity）

节点亲和性定义Pod对节点的"偏好"或"硬性要求"，类似"想去哪个班"（软策略）或"必须去哪个班"（硬策略）。

4.1.3 实践案例

案例1：硬策略（必须排除node02）

案例2：软策略

案例3：软硬策略

如果把硬策略和软策略合在一起使用，则要先满足硬策略之后才会满足软策略。

yaml 复制代码

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: affinity03
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:   #先满足硬策略，排除有kubernetes.io/hostname=node02标签的节点
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - node02
      preferredDuringSchedulingIgnoredDuringExecution:  #再满足软策略，优先选择有yjsc=a标签的节点
	  - weight: 1
        preference:
          matchExpressions:
          - key: yjs
            operator: In
            values:
            - a

bash 复制代码

kubectl apply -f pod3.yaml
# 先满足硬策略不在Node02上，在满足软策略yjs=a的节点上
kubectl get po -owide

4.2 Pod亲和性与反亲和性

Pod亲和性/反亲和性基于已有Pod的标签控制调度，用于实现"Pod与目标Pod同节点/同拓扑域"或"Pod与目标Pod分离"的需求。

五、污点（Taint）与容忍（Toleration）

节点亲和性，是Pod的一种属性（偏好或硬性要求），它使Pod被吸引到一类特定的节点。Taint 则相反，它使节点能够排斥一类特定的 Pod。

污点与容忍机制用于实现节点对Pod的排斥与例外，节点通过污点拒绝不匹配的Pod，而Pod通过容忍突破排斥。

5.1 污点（Taint）

六、节点维护与Pod生命周期

6.1 节点维护操作

当需要对节点进行升级、检修时，可通过以下命令暂时隔离节点并迁移Pod：

七、故障排查常用命令

操作需求	命令示例
查看Pod事件（调度失败原因）	`kubectl describe pod <pod-name>`
查看Pod日志	`kubectl logs <pod-name> [-c <container-name>]`
进入容器执行命令	`kubectl exec -it <pod-name> -- bash`
查看集群状态	`kubectl cluster-info`
查看节点状态	`kubectl get nodes`
查看kubelet日志	`journalctl -xefu kubelet`

总结

一句话总结： "调度是吸引，污点是排斥，亲和性是偏好，容忍是例外。"