2. 基础概念回顾：Kubernetes 控制平面组件
在深入探讨控制平面升级对租户隔离通信的影响之前，必须首先厘清 Kubernetes 控制平面各核心组件的职责与交互关系。控制平面是集群的“大脑”，负责全局决策与状态管理；其任何变更（如版本升级、配置调整）都会直接波及数据平面的通信路径与隔离策略。
2.1 控制平面组件总览
Kubernetes 控制平面由四个核心组件构成，它们通常运行在独立的 Master 节点上（或通过静态 Pod 托管）。下表总结了各组件的核心功能、通信协议及关键端口：
| 组件 | 核心职责 | 主要通信协议 | 默认端口 |
|---|---|---|---|
| API Server (kube-apiserver) | 集群网关，所有组件与 CLI 的唯一入口；提供 RESTful API 进行资源操作 | HTTPS (TLS) | 6443 |
| etcd | 分布式键值存储，保存集群全部状态数据（配置、状态、元数据） | gRPC / HTTP (TLS) | 2379 (客户端), 2380 (对等) |
| Controller Manager (kube-controller-manager) | 运行各类控制器（如 Node Controller、Deployment Controller），确保实际状态趋近期望状态 | HTTPS (与 API Server 通信) | 10257 |
| Scheduler (kube-scheduler) | 为新创建的 Pod 分配最合适的 Node；基于资源需求、约束、亲和性等策略决策 | HTTPS (与 API Server 通信) | 10259 |
关键理解：API Server 是唯一直接操作 etcd 的组件。Controller Manager 和 Scheduler 仅通过 API Server 读取或写入集群状态，从不直接访问 etcd。这种分层设计保证了状态一致性与访问控制的可审计性。
2.2 组件间通信架构
下图展示了控制平面内部组件之间的通信流向与依赖关系。箭头方向表示请求发起方与接收方：
2.3 核心组件深度解析
2.3.1 API Server (kube-apiserver)
API Server 是控制平面的前端，负责处理所有 RESTful API 请求。其关键特性包括：
- 认证与鉴权：支持多种认证策略（X.509 证书、Bearer 、Webhook），并通过 RBAC 或 ABAC 进行授权。
- 准入控制：请求持久化到 etcd 之前，会经过一系列 Admission Controller 的校验与修改（如
NamespaceLifecycle、MutatingAdmissionWebhook）。 - 版本化 API：提供
/api/v1、/apis/apps/v1等分组版本，支持资源类型的演进与弃用。
升级影响点：API Server 版本升级可能导致 API 资源版本的弃用（如
extensions/v1beta1 在 1.16 后被移除）。租户隔离策略若依赖旧版 API，必须在升级前完成迁移。
2.3.2 etcd
etcd 是集群状态的最终存储后端，采用 Raft 共识算法保证强一致性。其数据模型为分层键值空间，所有 Kubernetes 资源均以 /registry/<resource_type>/<namespace>/<name> 格式存储。
- 租约与 watch：API Server 通过 etcd 的 watch 机制实时感知状态变化，并推送给 Controller Manager 与 Scheduler。
- 存储隔离：etcd 本身不提供租户级隔离；隔离由 API Server 的 RBAC 与 Namespace 机制在上层实现。
2.3.3 Controller Manager
Controller Manager 是一个控制器集合，每个控制器专注于一种资源类型。常见控制器包括：
| 控制器 | 职责 | 对租户隔离的影响 |
|---|---|---|
| Node Controller | 监控节点健康状态，管理节点生命周期 | 影响 Pod 调度与驱逐策略 |
| Namespace Controller | 处理 Namespace 的创建与删除 | 直接决定租户隔离边界 |
| ServiceAccount Controller | 自动为 Namespace 创建默认 ServiceAccount | 影响 Pod 身份与权限 |
| EndpointSlice Controller | 管理 Service 的后端端点列表 | 影响服务发现与网络策略 |
2.3.4 Scheduler
Scheduler 负责将未调度的 Pod 绑定到合适的 Node。其调度流程分为两个阶段：
- 过滤（Predicates）：排除不满足 Pod 资源请求、节点亲和性、污点容忍等条件的节点。
- 打分（Priorities）：对剩余节点按资源利用率、拓扑分布等策略打分，选择最优节点。
升级风险提示：Scheduler 的调度策略（如
NodeSelector、PodAffinity）在版本升级后可能出现行为变更。例如，Kubernetes 1.20 后默认启用 NodeAffinity 的 requiredDuringSchedulingIgnoredDuringExecution 语义增强。租户隔离场景下，错误的调度策略可能导致跨租户 Pod 共置，违反隔离要求。
2.4 组件间通信协议与安全
控制平面组件之间的所有通信均使用 TLS 加密，默认证书由集群 CA 签发。下表总结了各通信链路的协议与安全机制：
| 通信链路 | 协议 | 认证方式 | 加密 |
|---|---|---|---|
| 客户端 → API Server | HTTPS | 客户端证书 / Bearer | TLS 1.2+ |
| API Server → etcd | gRPC over HTTP/2 | 客户端证书（双向 TLS） | TLS 1.2+ |
| Controller Manager → API Server | HTTPS | ServiceAccount / 客户端证书 | TLS 1.2+ |
| Scheduler → API Server | HTTPS | ServiceAccount / 客户端证书 | TLS 1.2+ |
在控制平面升级过程中，上述通信链路的证书轮换、API 版本兼容性以及 etcd 的存储格式变更（如从 v2 迁移到 v3）是影响租户隔离通信稳定性的关键因素。