2. Kubernetes 集群架构回顾：Master节点与Worker节点组件、控制平面与数据平面
在深入平台工程值班基线核验之前，必须对Kubernetes集群的物理与逻辑架构建立清晰的认知。集群由Master节点（控制平面）与Worker节点（数据平面）构成，两者通过安全的API通信协同工作。本节将分别拆解节点组件，并明确控制平面与数据平面的职责边界。
2.1 节点角色与组件全景
一个生产级Kubernetes集群通常包含多个Master节点（高可用部署，建议3或5台）和一组Worker节点。下表列出了每个节点上的核心组件及其所属平面：
| 节点角色 | 组件名称 | 所属平面 | 核心职责 |
|---|---|---|---|
| Master节点 | kube-apiserver | 控制平面 | 集群网关，所有REST请求的入口，认证/授权/准入控制 |
| etcd | 控制平面 | 分布式键值存储，保存集群全部状态数据 | |
| kube-scheduler | 控制平面 | 为新Pod选择最合适的Worker节点 | |
| kube-controller-manager | 控制平面 | 运行控制器循环（Node/ReplicaSet/Deployment/Endpoint等） | |
| Worker节点 | kubelet | 数据平面 | 节点代理，管理Pod生命周期与容器健康 |
| kube-proxy | 数据平面 | 维护节点网络规则，实现Service负载均衡 | |
| 容器运行时 | 数据平面 | 实际运行容器（containerd / CRI-O / Docker） |
值班基线核验要点： 在巡检集群时，应首先确认Master节点上kube-apiserver与etcd的健康状态，因为这两者失效将导致整个控制平面不可用。Worker节点则需重点检查kubelet证书是否过期、容器运行时是否响应正常。
2.2 控制平面（Master节点）组件详解
控制平面是集群的“大脑”，负责全局决策与状态管理。以下四个组件缺一不可：
- kube-apiserver：唯一与etcd直接交互的组件。所有组件（包括kubelet、scheduler、controller-manager）都通过它读写集群状态。它实现了水平伸缩，可通过负载均衡器对外暴露。
- etcd：采用Raft一致性算法保证数据强一致性。生产环境必须使用TLS加密通信，并定期备份数据文件。
- kube-scheduler：基于调度策略（资源需求、亲和性、污点容忍等）为未调度的Pod绑定节点。调度结果写入etcd。
- kube-controller-manager：包含多个控制器，例如Node Controller（节点健康检测）、Replication Controller（维持Pod副本数）、Endpoint Controller（维护Service与Pod映射）等。
架构提示： 控制平面组件通常以静态Pod或系统服务形式运行在Master节点上。在基线核验时，应检查kube-system命名空间下所有控制平面Pod的
READY状态是否为1/1，以及重启次数是否异常。
2.3 数据平面（Worker节点）组件详解
数据平面承载实际工作负载，负责容器的运行、网络连通与流量转发：
- kubelet：每个Worker节点上唯一的Kubernetes原生代理。它通过API Server注册节点，接收PodSpec并调用容器运行时创建/删除容器，同时定期上报节点与Pod状态。
- kube-proxy：维护节点上的iptables/IPVS规则，实现ClusterIP、NodePort、LoadBalancer类型的Service流量转发。它不直接参与Pod间通信，但决定了Service的可达性。
- 容器运行时（Container Runtime）：符合CRI（Container Runtime Interface）标准的底层引擎，负责拉取镜像、启动/停止容器、管理存储卷挂载。
2.4 控制平面与数据平面的通信机制
下图展示了两个平面之间的核心通信路径，以及组件间的依赖关系：
通信安全基线： 所有控制平面与数据平面之间的通信必须使用TLS加密。kubelet提供10250端口的HTTPS API，kube-apiserver通过客户端证书认证kubelet身份。在基线核验中，应检查
/etc/kubernetes/pki目录下的证书有效期，以及kubelet配置中的serverTLSBootstrap是否启用。
2.5 平面职责对比与故障域
理解两个平面的故障隔离边界，对值班排障至关重要：
| 对比维度 | 控制平面 | 数据平面 |
|---|---|---|
| 核心功能 | 状态管理、调度决策、API网关 | 容器运行、网络转发、存储挂载 |
| 故障影响范围 | 集群全局（无法创建/更新资源） | 仅影响所在节点上的Pod |
| 高可用策略 | 多Master + 负载均衡 + etcd集群 | Pod反亲和 + 多副本 + 节点自动修复 |
| 值班监控重点 | API Server响应延迟、etcd leader变更、控制器队列深度 | 节点状态、kubelet心跳、Pod重启次数、节点磁盘/内存压力 |
在平台工程值班基线核验中，建议使用kubectl get componentstatuses（已弃用，推荐直接检查Pod状态）或kubectl get pods -n kube-system快速验证控制平面健康度，同时使用kubectl get nodes确认所有Worker节点处于Ready状态。