3. Kubernetes 核心组件：架构与职责
Kubernetes 集群由多个核心组件协同工作，共同构成控制平面与数据平面。理解每个组件的职责、交互方式及故障模式，是进行弹性伸缩编排与故障排查的基础。本章将逐一剖析 API Server、Scheduler、Controller Manager、kubelet 和 kube-proxy 的架构与职责。
3.1 组件总览与交互关系
Kubernetes 采用主从（Master-Worker）架构。控制平面（Control Plane）负责全局决策与集群状态管理，数据平面（Data Plane）负责运行实际容器负载。下图展示了核心组件之间的通信与依赖关系。
3.2 API Server (kube-apiserver)
API Server 是 Kubernetes 控制平面的前端，所有组件与外部用户的交互均通过它进行。它是集群的“网关”与“状态权威”。
核心职责
- RESTful API 提供：暴露 Kubernetes API，接收并处理所有资源（Pod、Service、Deployment 等）的 CRUD 操作。
- 认证与授权：对请求进行身份验证（Authentication）与权限校验（Authorization），确保安全访问。
- 准入控制：通过 Admission Controller 链对请求进行变更或验证，例如资源配额校验、PodSecurityPolicy 检查。
- 状态存储：所有集群状态唯一写入 etcd，API Server 是唯一与 etcd 交互的组件。
- 事件广播：提供 Watch 机制，允许其他组件（Scheduler、Controller Manager）监听资源变化并做出响应。
故障排查要点：API Server 不可用将导致整个集群不可控。常见故障包括 etcd 连接超时、证书过期、资源泄漏（大量未关闭的 Watch 连接）。排查时优先检查 API Server Pod 日志及 etcd 健康状态。
3.3 Scheduler (kube-scheduler)
Scheduler 负责将新创建的 Pod 分配到最合适的 Worker Node 上。它通过一系列调度算法和策略，确保集群资源的高效利用。
调度流程
- 监听：通过 Watch 机制监听 API Server，获取未调度的 Pod（
spec.nodeName为空）。 - 过滤（Predicates）：筛选出满足 Pod 资源请求、节点亲和性、污点容忍等硬性条件的节点。
- 打分（Priorities）：对通过过滤的节点进行优先级评分，考虑资源利用率、Pod 分布均衡性等因素。
- 绑定（Bind）：选择最高分节点，通过 API Server 将 Pod 与节点绑定。
弹性伸缩关联：在 HPA（Horizontal Pod Autoscaler）触发扩容时，Scheduler 的调度效率直接影响 Pod 启动速度。若集群资源不足或调度策略配置不当，可能导致扩容 Pod 长时间处于 Pending 状态。
3.4 Controller Manager (kube-controller-manager)
Controller Manager 是集群的“大脑”，运行多个控制器（Controller），通过控制循环（Reconciliation Loop）确保集群实际状态与期望状态一致。
核心控制器
| 控制器名称 | 职责 | 与弹性伸缩的关系 |
|---|---|---|
| Replication Controller | 确保指定数量的 Pod 副本运行 | HPA 通过修改副本数触发其工作 |
| Node Controller | 监控节点健康，处理节点失联 | 节点故障时触发 Pod 驱逐与重新调度 |
| Endpoint Controller | 维护 Service 与 Pod 的映射关系 | Pod 扩缩容后更新 Endpoint 列表 |
| Namespace Controller | 管理命名空间的生命周期 | 资源配额管理影响扩容上限 |
| ServiceAccount Controller | 为命名空间创建默认 ServiceAccount | 间接影响 Pod 的权限配置 |
常见故障模式：Controller Manager 中的某个控制器死锁或 panic 会导致对应资源无法收敛。例如，Replication Controller 故障可能导致 HPA 扩容后 Pod 数量无法稳定。排查时需检查
kube-controller-manager 日志中的控制器循环错误。
3.5 kubelet
kubelet 是运行在每个 Worker Node 上的核心代理，负责管理节点上的 Pod 生命周期。它是控制平面与数据平面的桥梁。
核心职责
- Pod 管理：从 API Server 接收 PodSpec，通过容器运行时（如 Docker、containerd）创建、启动、停止容器。
- 健康检查：执行 Liveness、Readiness、Startup 探针，根据结果重启容器或标记 Pod 不可用。
- 资源监控：采集节点与 Pod 的 CPU、内存、磁盘、网络等资源使用数据，上报至 API Server。
- Volume 管理：挂载 Pod 声明的存储卷，支持多种存储后端。
- 节点状态上报：定期向 API Server 发送心跳及节点状态信息。
故障排查要点：kubelet 证书轮转失败、容器运行时无响应、磁盘压力（DiskPressure）是常见故障。使用
journalctl -u kubelet 或 kubectl describe node 查看节点状态与事件。
3.6 kube-proxy
kube-proxy 运行在每个 Worker Node 上，负责实现 Service 的网络代理与负载均衡。它维护节点上的网络规则，使集群内外的流量能够正确路由到后端 Pod。
工作模式
| 模式 | 原理 | 性能特点 | 适用场景 |
|---|---|---|---|
| userspace | 用户态代理，监听端口并转发 | 性能较低，存在上下文切换 | 早期版本，已弃用 |
| iptables | 利用 Linux 内核 Netfilter 规则 | 性能较好，规则更新时存在延迟 | 中小规模集群，默认模式 |
| IPVS | 利用 Linux 内核 IP Virtual Server | 高性能，支持更多调度算法 | 大规模集群，高并发场景 |
核心职责
- Service 后端维护：监听 API Server 中 Service 与 Endpoint 的变化，实时更新转发规则。
- 流量转发：将发往 Service ClusterIP 或 NodePort 的流量负载均衡到后端 Pod。
- 会话保持：支持基于源 IP 的会话亲和性（Session Affinity）。
弹性伸缩影响：当 HPA 快速扩缩容时，kube-proxy 需要及时更新 iptables/IPVS 规则。若规则更新滞后，可能导致新 Pod 无法接收流量或旧 Pod 仍在处理请求。排查时检查 kube-proxy 日志中的规则同步延迟。
3.7 组件职责对比总结
| 组件 | 部署位置 | 核心功能 | 状态存储 | 故障影响范围 |
|---|---|---|---|---|
| API Server | 控制平面 | API 网关、认证授权、状态管理 | etcd | 全局 |
| Scheduler | 控制平面 | Pod 调度与节点选择 | 无（读取 API Server） | 全局（新 Pod 无法调度） |
| Controller Manager | 控制平面 | 控制器循环、状态收敛 | 无（读取 API Server） | 全局（资源无法自愈） |
| kubelet | Worker Node | Pod 生命周期管理、健康检查 | 无（上报至 API Server） | 节点级 |
| kube-proxy | Worker Node | Service 网络代理与负载均衡 | 无（读取 API Server） | 节点级（网络连通性） |