2.1 kubectl 的处理#

kubectl apply 并不是简单地发送 YAML 文本。它做了以下工作：

1. 读取 YAML 文件：解析为 Kubernetes API 对象
2. 计算变更：对比当前集群中的对象和 YAML 中的对象，生成增量补丁（如果对象已存在）
3. 发送请求：通过 HTTP POST（新对象）或 PATCH（更新对象）发送到 API Server

1
# 查看 kubectl 实际发送的请求
2
kubectl apply -f deployment.yaml --v=8
3

4
# 输出（简化）：
5
# I0513 POST https://api-server:6443/apis/apps/v1/namespaces/default/deployments
6
# Request Body: {"kind":"Deployment","metadata":{"name":"nginx"},...}

2.2 API Server 认证#

API Server 首先验证请求者的身份：

2.3 API Server 鉴权（RBAC）#

认证通过后，API Server 检查请求者是否有权限执行该操作：

1
用户: admin
2
操作: POST /apis/apps/v1/namespaces/default/deployments
3
RBAC 检查: ClusterRoleBinding admin → ClusterRole cluster-admin → 允许

RBAC 的检查逻辑：遍历所有与用户关联的 RoleBinding/ClusterRoleBinding，检查对应的 Role/ClusterRole 是否包含匹配的规则。

2.4 准入控制链#

鉴权通过后，请求进入准入控制链（Admission Chain）。准入控制器可以修改（Mutating）或验证（Validating）请求对象：

常见的准入控制器：

4.1 Informer 机制#

Controller 不直接轮询 API Server，而是使用 Informer 机制：

Informer 的工作流程：

1. List：首次启动时，从 API Server 获取所有 Deployment 对象，建立本地缓存
2. Watch：之后监听 API Server 的变更事件，实时更新本地缓存
3. 回调：缓存更新后触发 OnAdd/OnUpdate/OnDelete 回调，Controller 在回调中执行业务逻辑

Informer 的优势：减少 API Server 压力（不需要反复 List），响应速度快（Watch 事件实时推送）。

4.2 Deployment Controller 的处理#

当 Deployment Controller 收到新 Deployment 的 OnAdd 回调时：

1. 检查是否已有匹配的 ReplicaSet
2. 如果没有，创建新的 ReplicaSet（初始版本 revision=1）
3. 设置 ReplicaSet 的 replicas 为 Deployment 的 replicas 值
4. 更新 Deployment 的 status 字段

1
# Deployment Controller 创建的 ReplicaSet
2
apiVersion: apps/v1
3
kind: ReplicaSet
4
metadata:
5
  name: nginx-7d6f5c4b2d         # 自动生成的名称（包含 Pod 模板哈希）
6
  labels:
7
    app: nginx
8
    pod-template-hash: 7d6f5c4b2d # Deployment 自动添加的标签
9
  ownerReferences:                 # 声明 ReplicaSet 属于 Deployment
10
    - apiVersion: apps/v1
11
      kind: Deployment
12
      name: nginx
13
      uid: a1b2c3d4-...
14
      controller: true
15
spec:
16
  replicas: 3
17
  selector:
18
    matchLabels:
19
      app: nginx
20
      pod-template-hash: 7d6f5c4b2d
21
  template: ...                    # 与 Deployment 的 Pod 模板一致

ownerReferences 是 Kubernetes 的垃圾回收机制——当 Deployment 被删除时，所有引用它的 ReplicaSet 和 Pod 都会被自动回收。

6.1 调度算法#

**预选（Filter）**阶段排除不满足硬性条件的 Node：

**优选（Score）**阶段为满足条件的 Node 打分：

6.2 绑定#

Scheduler 选择 Node 后，向 API Server 发送 Bind 请求：

1
apiVersion: v1
2
kind: Binding
3
metadata:
4
  name: nginx-7d6f5c4b2d-abc12
5
target:
6
  apiVersion: v1
7
  kind: Node
8
  name: node-2

API Server 更新 Pod 的 nodeName 字段为 node-2。

7.1 kubelet 的 Pod 处理流程#

7.2 CRI：容器创建#

kubelet 通过 CRI（Container Runtime Interface）与容器运行时通信：

1
kubelet → containerd（通过 gRPC）
2
  CreateContainer(podConfig) → 返回 containerID
3
  StartContainer(containerID) → 容器进程启动

CRI 的关键步骤：

1. 拉取镜像（image: nginx:1.25）
2. 创建 Pause 容器（持有 Pod Network Namespace）
3. 创建应用容器（加入 Pause 的 Network Namespace）
4. 启动容器进程

7.3 CNI：网络配置#

kubelet 调用 CNI 插件为 Pod 配置网络：

1
kubelet → CNI 插件（如 Calico/Cilium）
2
  ADD: 创建 veth pair、配置 IP、设置路由

CNI 插件的工作：

1. 创建 veth pair（一端在 Pod Network Namespace，一端在宿主机）
2. 为 Pod 分配 IP（从 Pod CIDR 中分配）
3. 配置 Pod 内的路由和 DNS
4. 配置宿主机的路由（将 Pod IP 路由到 veth 对）
5. 如果是跨节点通信，配置节点间的路由或封装规则

7.4 CSI：存储挂载#

如果 Pod 引用了 PVC，kubelet 调用 CSI 插件挂载存储：

1
kubelet → CSI 插件
2
  NodeStageVolume → 将存储挂载到临时目录
3
  NodePublishVolume → 将临时目录 bind-mount 到 Pod 目录

7.5 状态上报#

容器启动后，kubelet 定期向 API Server 上报 Pod 状态：

1
status:
2
  phase: Running
3
  conditions:
4
    - type: Ready
5
      status: "True"
6
  containerStatuses:
7
    - name: nginx
8
      ready: true
9
      restartCount: 0
10
      state:
11
        running:
12
          startedAt: "2026-05-13T10:01:30Z"