2. Kubernetes集群架构回顾：Master节点组件、Worker节点组件、控制平面与数据平面交互流程
在深入值班基线核验之前，必须对Kubernetes集群的静态拓扑与动态交互有清晰的认知。本章从Master节点组件、Worker节点组件以及控制平面与数据平面的交互流程三个维度进行回顾，为后续的配置核验提供架构层面的上下文。
2.1 Master节点组件（控制平面）
Master节点承载集群的“大脑”——控制平面。所有集群级别的决策、状态存储与调度逻辑均在此执行。以下为核心组件及其职责：
| 组件 | 进程名称 | 核心职责 | 关键端口 |
|---|---|---|---|
| kube-apiserver | kube-apiserver | 所有组件交互的唯一入口，提供RESTful API，执行认证、授权、准入控制 | 6443 (HTTPS) |
| etcd | etcd | 分布式键值存储，保存集群所有资源对象的状态（唯一有状态组件） | 2379 (客户端), 2380 (peer) |
| kube-scheduler | kube-scheduler | 监听未调度的Pod，根据调度策略将其绑定到最合适的Worker节点 | 10259 (HTTPS) |
| kube-controller-manager | kube-controller-manager | 运行多个控制器（Node、Replication、Endpoint等），确保实际状态向期望状态收敛 | 10257 (HTTPS) |
| cloud-controller-manager | cloud-controller-manager | （可选）与云厂商API交互，管理负载均衡、存储卷、节点路由等云资源 | 10258 (HTTPS) |
值班核验要点： 在基线核验中，需确认
kube-apiserver 的 --anonymous-auth 与 --enable-admission-plugins 参数是否合规；etcd 是否启用 TLS 双向认证；scheduler 与 controller-manager 的 --secure-port 是否开启。
2.2 Worker节点组件（数据平面）
Worker节点负责运行实际的应用容器。每个Worker节点必须运行以下三个核心组件：
- kubelet：节点上的“代理”，负责与API Server通信，管理Pod的生命周期（创建、监控、重启），执行健康检查（liveness/readiness probe）。
- kube-proxy：网络代理，维护节点上的网络规则（iptables/IPVS），实现Service的Cluster IP到后端Pod的负载均衡。
- 容器运行时（Container Runtime）：负责拉取镜像、启动/停止容器。常见实现包括 containerd、CRI-O、Docker Engine（已弃用）。
| 组件 | 进程名称 | 核心职责 | 关键端口 |
|---|---|---|---|
| kubelet | kubelet | Pod生命周期管理、节点状态上报、资源监控 | 10250 (HTTPS), 10255 (只读, 建议关闭) |
| kube-proxy | kube-proxy | Service流量转发、会话保持、健康检查 | 10256 (健康检查) |
| 容器运行时 | containerd / dockerd / crio | 容器镜像管理、容器执行、存储挂载 | Unix Socket (如 /run/containerd/containerd.sock) |
常见配置偏差： 值班核验中经常发现
kubelet 的 --read-only-port (10255) 未关闭，导致节点信息泄露；或 kube-proxy 的 --mode 被设置为性能较差的 userspace。基线应强制要求 --read-only-port=0 且 --mode=iptables 或 ipvs。
2.3 控制平面与数据平面交互流程
理解组件间的通信路径是诊断集群故障的基础。以下是一个典型的Pod创建流程，展示了控制平面与数据平面的完整交互：
- 用户提交：通过
kubectl或 API 调用向kube-apiserver发送创建Pod的请求。 - 认证与准入：
kube-apiserver对请求进行认证、授权，并通过准入控制器（如MutatingAdmissionWebhook、ValidatingAdmissionWebhook）进行校验与修改。 - 持久化：
kube-apiserver将Pod资源对象写入etcd。 - 调度决策：
kube-scheduler通过Watch机制监听到未调度的Pod，执行预选与优选算法，将Pod绑定到某个Worker节点，并将绑定结果写回kube-apiserver。 - 节点执行：目标Worker节点上的
kubelet通过Watch机制发现Pod被调度到本节点，调用容器运行时（CRI）拉取镜像并启动容器。 - 网络配置：
kubelet调用CNI插件配置Pod网络；kube-proxy根据Service变化更新节点上的iptables/IPVS规则。 - 状态回写：
kubelet持续监控Pod状态，并通过kube-apiserver更新Pod的status字段，最终持久化到etcd。
2.4 关键交互协议与端口矩阵
值班核验时，防火墙策略与网络策略（NetworkPolicy）的基线检查依赖于对组件间通信协议的准确理解。以下矩阵总结了核心交互：
| 源组件 | 目标组件 | 协议 | 目标端口 | 用途 |
|---|---|---|---|---|
| kubelet (Worker) | kube-apiserver | HTTPS | 6443 | 节点注册、Pod状态上报、Watch指令 |
| kube-scheduler | kube-apiserver | HTTPS | 6443 | 监听未调度Pod、写入绑定结果 |
| kube-controller-manager | kube-apiserver | HTTPS | 6443 | 监听资源变化、执行控制循环 |
| kube-apiserver | etcd | gRPC (TLS) | 2379 | 读写集群状态数据 |
| kubelet | 容器运行时 | gRPC (Unix Socket) | CRI Socket | 创建/管理容器 |
| kube-proxy | kube-apiserver | HTTPS | 6443 | 监听Service与Endpoint变化 |
| kubelet | 节点上的Pod | HTTP/HTTPS | Probe端口 | 执行liveness/readiness/startup探针 |
基线核验检查项：
- 确认所有Master组件之间的通信均使用TLS（端口6443/10257/10259）。
- 确认etcd的客户端端口（2379）仅对Master节点开放，禁止从Worker节点直接访问。
- 确认kubelet的10250端口仅对Master节点网络可达，禁止匿名访问。
- 确认kube-proxy的Cluster IP转发模式（iptables/IPVS）与集群规模匹配。
2.5 值班视角下的架构核验清单
基于上述架构回顾，值班人员在执行基线核验时，应重点检查以下项目：
- 组件进程存活检查：在Master节点上执行
systemctl status kube-apiserver kube-scheduler kube-controller-manager etcd；在Worker节点上执行systemctl status kubelet kube-proxy。 - 端口监听检查：使用
ss -tlnp确认关键端口（6443, 2379, 10250, 10257, 10259）处于监听状态，且未暴露到非预期网络接口。 - 证书有效期检查：检查
/etc/kubernetes/pki/下的apiserver.crt、etcd/server.crt等证书是否在有效期内。 - etcd健康检查：执行
etcdctl endpoint health --cluster确认etcd集群所有成员健康。 - 节点状态检查：执行
kubectl get nodes确认所有节点处于Ready状态。
快速诊断命令示例：
# 检查所有Master组件健康状态
kubectl get componentstatuses
# 检查节点状态与内核版本
kubectl get nodes -o wide
# 检查kubelet证书过期时间
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -dates
# 检查etcd集群成员列表
etcdctl member list --write-out=table