2. K8s集群架构基础：Master节点组件、Worker节点组件、控制平面与数据平面分离原理
Kubernetes集群采用主从架构（Master-Worker），所有组件按职责划分为控制平面（Control Plane）与数据平面（Data Plane）。理解这两层的组件构成与交互原理，是规划升级窗口、预留资源、保障Pod调度稳定性的前提。
2.1 控制平面（Master节点）核心组件
控制平面负责集群的全局决策、状态管理与事件响应。通常由3或5个Master节点组成高可用（HA）集群，每个Master运行以下组件：
| 组件 | 进程名称 | 核心职责 | 关键端口 |
|---|---|---|---|
| kube-apiserver | kube-apiserver | 所有组件与CLI的唯一入口，提供RESTful API，执行认证、授权、准入控制（Admission Control） | 6443（HTTPS） |
| kube-controller-manager | kube-controller-manager | 运行控制器循环（Node Controller、Deployment Controller、Endpoint Controller等），确保集群实际状态与期望状态一致 | 10257（HTTPS） |
| kube-scheduler | kube-scheduler | 为新创建的Pod选择最合适的Worker节点，基于资源请求、亲和性、污点/容忍度等策略打分 | 10259（HTTPS） |
| etcd | etcd | 分布式键值存储，保存集群所有资源对象（Pod、Service、ConfigMap等）的最终状态，是集群的“唯一真相源” | 2379（客户端）、2380（集群通信） |
升级窗口影响： 控制平面组件升级时，kube-apiserver 和 etcd 的短暂不可用将导致整个集群的读写操作阻塞。kube-scheduler 和 kube-controller-manager 的 Leader 选举机制（默认 lease 时长 15s）会在升级期间触发重新选举，造成调度与控制器操作的短暂停顿。
2.2 数据平面（Worker节点）核心组件
数据平面负责运行用户容器，并维护网络与存储规则。每个Worker节点运行以下组件：
| 组件 | 进程名称 | 核心职责 | 关键端口 |
|---|---|---|---|
| kubelet | kubelet | 节点代理，负责管理Pod生命周期（创建、监控、重启），定期向apiserver上报节点状态（Node Status） | 10250（HTTPS）、10255（只读） |
| kube-proxy | kube-proxy | 维护节点上的网络规则（iptables/IPVS），实现Service的负载均衡与集群内通信 | 10256（健康检查） |
| 容器运行时 | containerd / CRI-O / Docker | 拉取镜像、创建/停止容器、管理容器文件系统与资源隔离 | Unix Socket（/var/run/containerd.sock） |
资源预留关键点： kubelet 支持通过
--system-reserved 和 --kube-reserved 参数为系统守护进程（sshd、systemd）与K8s组件预留CPU/内存资源。升级窗口期间，kubelet 重启会导致节点上所有Pod被重新注册，若未预留足够资源，可能触发节点压力驱逐（Node Pressure Eviction）。
2.3 控制平面与数据平面分离原理
Kubernetes 通过控制平面与数据平面严格分离的架构设计，实现集群的弹性伸缩与故障隔离。其核心原则如下：
- 职责分离： 控制平面只做决策（调度、状态协调、API响应），不运行用户容器；数据平面只执行容器生命周期与网络转发，不参与集群全局决策。
- 通信单向依赖： Worker节点上的kubelet主动向apiserver发起心跳与状态上报（Pull模式），控制平面从不主动连接Worker节点。这种设计使得Worker节点故障不会直接影响控制平面稳定性。
- 状态持久化隔离： 所有集群状态仅存储在控制平面的etcd中，数据平面节点无状态。Worker节点重启后，kubelet会重新从apiserver拉取分配给本节点的Pod清单，实现“无状态恢复”。
- 升级影响范围： 控制平面升级影响全局调度与API可用性；数据平面升级仅影响该节点上的Pod，其他节点不受影响。升级窗口策略正是利用这一隔离特性，通过逐节点滚动升级降低业务中断风险。
常见误区： 控制平面与数据平面分离并不意味着网络完全隔离。kubelet 需要访问 apiserver（6443端口），kube-proxy 需要访问 apiserver 获取Service与Endpoint信息。升级前务必检查网络策略与防火墙规则，避免升级期间节点失联。
2.4 组件交互流程与升级影响
下图展示了控制平面与数据平面之间的核心交互路径，以及升级窗口期间可能中断的关键链路：
2.5 升级窗口中的组件依赖关系
在规划升级窗口时，必须遵循以下组件依赖顺序，否则可能导致集群功能异常：
- etcd → kube-apiserver： apiserver 依赖 etcd 存储与读取集群状态，etcd 必须先升级。
- kube-apiserver → kube-controller-manager / kube-scheduler： 控制器与调度器通过 apiserver 监听资源变化，apiserver 升级后它们才能正常工作。
- kube-apiserver → kubelet / kube-proxy： Worker节点组件通过 apiserver 获取Pod清单与Service配置，apiserver 恢复后节点才能重新注册。
- 容器运行时 → kubelet： kubelet 依赖容器运行时创建Pod，运行时升级应在 kubelet 升级之前完成。
升级窗口资源预留建议： 控制平面节点应预留至少 1 个 CPU 核心和 2 GB 内存用于 etcd 与 apiserver 的升级操作；Worker节点应通过 kubelet 的
--system-reserved 参数预留 0.5 核 CPU 和 1 GB 内存，防止升级期间系统守护进程资源不足导致节点失联。