控制平面组件详解：角色、职责与交互

AI 协助说明： 本页由 Codex 协助核验和修复站内链接；正文的技术事实和适用范围未因本次修改而改变，仍以文中来源及当前官方文档为准。

本文边界：本文从协作关系说明控制平面各组件的角色、职责与交互，不替代 API Server、集群引导和证书配置的专题说明。

推荐深读：API Server 详解、Kubeadm 详解 与 Kubernetes 证书、kubeconfig 与 API Server 的关系。

1. API Server：集群的中央神经系统#

基本角色#

API Server是Kubernetes控制平面的前端接口，是所有组件和用户的唯一官方入口。它负责：

• 验证和处理所有API请求
• 执行准入控制（Admission Control）
• 在etcd中存储和检索资源状态
• 协调集群中所有组件间的通信

交互方式#

graph LR
    A[用户/kubectl] -->|REST请求| B(API Server)
    C[Scheduler] -->|监听Pod创建| B
    D[Controller Manager] -->|监控资源变化| B
    E[Kubelet] -->|节点状态报告| B
    F[etcd] <-->|读写数据| B

• 外部交互：

  • 通过kubectl命令行工具
  • 通过REST API直接调用 (curl -k -H "Authorization: Bearer $TOKEN" https://<master-ip>/api/v1/namespaces)
  • 通过客户端库（client-go, client-python等）

• 内部交互：

  • 作为唯一能够直接与etcd通信的组件
  • 为其他控制平面组件（Scheduler、Controller Manager）提供Watcher机制
  • 为kubelet提供API端点进行节点注册和状态报告

面向对象#

• 主要用户：所有Kubernetes用户（开发者、管理员、CI/CD系统）
• 次要用户：所有Kubernetes内部组件（它们都是API Server的客户端）

开发者视角#

作为开发者，你每天与API Server交互：

• 使用kubectl apply -f deployment.yaml创建资源
• 通过kubectl get pods查询资源状态
• 在代码中使用client-go库管理资源
• 通过kubectl proxy或port-forward进行应用调试

类比理解#

API Server就像机场的中央调度塔：

• 所有飞机（请求）必须与塔台（API Server）通信
• 塔台协调所有活动但不直接控制飞机
• 塔台保存所有飞行计划和状态（通过etcd）
• 任何未经授权的通信都会被拒绝

2. etcd：集群的集体记忆#

基本角色#

etcd是一个分布式、一致性的键值存储系统，作为Kubernetes的唯一真相来源：

• 存储所有集群状态：节点、Pod、服务、配置等
• 保存每个资源的完整历史记录
• 保证数据一致性和高可用性（通常以3或5节点集群运行）

交互方式#

graph LR
    A[API Server] -->|唯一合法客户端| B(etcd集群)
    B -->|副本同步| C[etcd节点1]
    B -->|副本同步| D[etcd节点2]
    B -->|副本同步| E[etcd节点3]

• 正常交互：

  • 仅API Server可以直接读写etcd
  • 其他组件（包括管理员）必须通过API Server间接访问
  • 数据以键值对形式存储，键遵循特定命名约定

• 紧急情况：

  • 集群管理员可能直接操作etcd进行灾难恢复
  • 使用etcdctl命令行工具（需要证书和权限）

面向对象#

• 直接用户：仅API Server和集群管理员（在维护时）
• 间接用户：所有Kubernetes用户（通过API Server）

开发者视角#

作为开发者，你几乎从不直接与etcd交互，但需要理解：

• 为什么配置变更有时有延迟（数据同步需要时间）
• 为什么API Server宕机整个集群不可用（它是唯一访问etcd的途径）
• 为什么资源配额和限制是强制性的（这些规则存储在etcd中）
• 所有声明式配置最终都持久化到etcd

类比理解#

etcd就像公司的中央档案室：

• 所有重要决策和状态都记录在此
• 普通员工（开发者）不直接进入档案室
• 前台（API Server）负责接收请求并从档案室检索信息
• 档案管理员（etcd）确保记录准确、安全且可恢复

3. Scheduler：集群的资源管家#

基本角色#

Scheduler负责监视新创建的Pod并将其分配到合适的节点：

• 根据资源需求选择最佳节点
• 考虑亲和性/反亲和性规则
• 避免资源过载
• 支持自定义调度策略

交互方式#

sequenceDiagram
    API Server->>Scheduler: "新Pod已创建，未分配节点"
    Scheduler->>API Server: "获取所有节点信息"
    API Server-->>Scheduler: "返回节点列表与状态"
    Scheduler->>Scheduler: "运行调度算法"
    Scheduler->>API Server: "绑定Pod到选定节点"
    API Server->>etcd: "更新Pod的nodeName字段"
    API Server->>Kubelet: "通知节点创建Pod"

• 工作流程：
  1. 通过API Server的Watch机制监听未调度的Pod（spec.nodeName为空）
  2. 从API Server获取所有节点的状态和容量
  3. 执行两阶段调度：过滤（符合要求的节点）→ 评分（最佳节点）
  4. 通过API Server将Pod绑定到选定节点

面向对象#

• 配置者：集群管理员（设置调度策略和插件）
• 影响者：开发者（通过Pod规范影响调度决策）
• 监控者：SRE团队（观察调度性能和决策）

开发者视角#

作为开发者，你通过配置影响Scheduler：

• 设置资源请求和限制

  resources:
    requests:
      memory: "256Mi"
      cpu: "100m"
    limits:
      memory: "512Mi"
      cpu: "500m"

• 配置节点亲和性/反亲和性

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values: [zone-a, zone-b]

• 设置Pod拓扑分布约束，确保高可用

• 理解为什么Pod可能处于"Pending"状态（无法调度）

类比理解#

Scheduler就像酒店前台经理：

• 新客人（Pod）到达时，经理查看所有可用房间（节点）
• 考虑客人需求（资源请求）、偏好（亲和性）和酒店政策
• 避免将相互讨厌的客人（反亲和性Pod）安排在同一楼层
• 确保不超订房间（资源过载）

4. Controller Manager：集群的自动驾驶系统#

基本角色#

Controller Manager运行核心控制器进程，是Kubernetes的自愈引擎：

• 确保集群的实际状态与期望状态一致
• 通过控制循环（Control Loop）不断比较和调整
• 包含多个内置控制器：Node Controller, Deployment Controller, Endpoint Controller等

核心控制器详解#

交互方式#

flowchart TD
    A[Controller Manager] -->|通过API Server| B[监视资源]
    B --> C{检测到状态不一致}
    C -->|是| D[创建/更新/删除资源]
    D -->|通过API Server| E[使状态一致]
    E --> B

• 控制循环流程：
  1. 通过API Server Watch特定资源（如Deployments）
  2. 比较资源的spec（期望状态）与status（实际状态）
  3. 如有差异，创建/更新/删除相关资源（如创建新的ReplicaSet）
  4. 持续监控直到状态一致

面向对象#

• 内置控制器：面向所有Kubernetes用户
• 自定义控制器/Operators：
  • 面向高级开发者和平台工程师
  • 用于扩展Kubernetes API和自动化复杂应用管理

开发者视角#

作为开发者，你通过配置驱动控制器：

• 创建Deployment资源，由Deployment Controller管理滚动更新

• 配置liveness和readiness探针，影响Endpoint Controller行为

• 理解为什么删除Pod后会自动重建（控制器的自愈行为）

• 开发Operator时，需深入理解控制器模式：

  // 简化的控制器逻辑
  func reconcile(request reconcile.Request) (reconcile.Result, error) {
      // 1. 获取当前资源状态
      instance := &appsv1.Deployment{}
      err := r.Get(ctx, request.NamespacedName, instance)
  
      // 2. 检查期望状态与实际状态
      if instance.Status.AvailableReplicas != *instance.Spec.Replicas {
          // 3. 执行纠正措施
          r.Update(ctx, instance)
      }
  
      // 4. 返回结果，可能需要重新排队
      return reconcile.Result{RequeueAfter: time.Minute}, nil
  }

类比理解#

Controller Manager就像建筑工地的监理团队：

• 每个监理（控制器）负责特定方面（电气、管道、结构）
• 他们不断对照设计图（期望状态）检查实际建筑（实际状态）
• 发现偏差时，指令工人（API Server）进行修正
• 全天候工作，确保建筑按计划进行

整体交互流程：部署一个应用时发生了什么#

sequenceDiagram
    Developer->>+API Server: kubectl apply -f app.yaml
    API Server->>+etcd: 保存Deployment配置
    etcd-->>-API Server: 确认保存
    API Server-->>-Developer: 确认创建
    
    Controller Manager->>+API Server: Watch新Deployment
    API Server-->>-Controller Manager: 返回新Deployment
    
    Controller Manager->>+API Server: 创建ReplicaSet
    API Server->>+etcd: 保存ReplicaSet
    etcd-->>-API Server: 确认保存
    API Server-->>-Controller Manager: 确认创建
    
    Scheduler->>+API Server: Watch未调度Pod
    API Server-->>-Scheduler: 返回新Pod
    Scheduler->>+API Server: 选择节点并绑定
    API Server->>+etcd: 更新Pod分配
    etcd-->>-API Server: 确认更新
    API Server-->>-Scheduler: 确认绑定
    
    Kubelet->>+API Server: Watch分配给本节点的Pod
    API Server-->>-Kubelet: 返回Pod详情
    Kubelet->>Container Runtime: 创建容器
    Container Runtime-->>Kubelet: 容器运行中
    Kubelet->>+API Server: 更新Pod状态
    API Server->>+etcd: 保存状态
    etcd-->>-API Server: 确认更新
    API Server-->>-Kubelet: 确认状态更新

面向不同角色的核心要点#

开发者（你的角色）需要重点掌握#

1. API Server交互：

   • 精通kubectl和API资源操作
   • 理解API资源的完整生命周期
   • 能通过client-go等库程序化操作资源

2. 影响Scheduler：

   • 合理配置资源请求/限制
   • 设置适当的亲和性/反亲和性规则
   • 理解Pod拓扑分布提高可用性

3. 利用Controller模式：

   • 理解Deployment、StatefulSet等控制器行为
   • 配置正确探针确保应用健康
   • 了解滚动更新策略及其影响

4. 概念性了解etcd：

   • 理解声明式配置最终持久化到etcd
   • 了解集群状态的最终一致性保证

集群管理员需要额外掌握#

1. API Server：高可用配置、认证授权策略、准入控制器
2. etcd：备份恢复策略、性能调优、证书管理
3. Scheduler：自定义调度器、调度器性能优化
4. Controller Manager：控制器参数调优、自定义控制器部署

学习建议#

1. 动手实验：

   • 使用minikube或Kind创建本地集群
   • 故意制造资源不足场景，观察调度行为
   • 修改Deployment配置，观察控制器行为

2. 可视化工具：

   • 使用Lens或Octant观察集群内部运作
   • 通过kubectl get events -w实时监控控制平面活动

3. 关键命令：

   # 观察API Server请求
   kubectl get pods -v=8
   
   # 查看调度决策原因
   kubectl describe pod <pod-name> | grep -A 10 "Events:"
   
   # 观察控制器活动
   kubectl get events --sort-by=.metadata.creationTimestamp
   
   # 模拟控制平面组件故障
   kubectl delete pod -n kube-system kube-apiserver-<node> --force

4. 深入阅读：

   • Kubernetes官方文档的"Concepts"部分
   • 《Kubernetes Up & Running》第1-4章
   • Kubernetes源码中pkg/controller目录

理解控制平面组件不是为了成为集群管理员，而是为了设计出与Kubernetes设计理念契合的应用。当你理解这些组件如何协作，就能编写出更具弹性、自愈能力更强的云原生应用，大幅减少运维负担和故障恢复时间。

记住：Kubernetes的核心哲学是"声明式API+控制循环"，控制平面组件正是这一理念的实现者。作为开发者，你的工作是清晰地声明"是什么"，而控制平面负责实现"怎么做"。