2. 集群架构基础：Kubernetes 核心组件与节点角色

Kubernetes 集群的物理与逻辑结构遵循严格的控制平面（Control Plane）与数据平面（Data Plane）分离原则。控制平面负责全局决策与状态管理，数据平面负责运行实际工作负载。理解这一分层是设计多租户隔离架构的前提。

2.1 核心组件总览

集群由一组协作的组件构成，按职责分为控制平面组件与节点组件。下表列出各组件的核心功能与部署位置：

组件 所属平面 核心职责 部署节点
API Server 控制平面 所有组件交互的网关，提供 RESTful API，执行认证、授权、准入控制 Master 节点
etcd 控制平面 分布式键值存储，保存集群全部状态数据（配置、元数据、资源对象） Master 节点
Scheduler 控制平面 监测未调度的 Pod，根据资源需求、约束、亲和性等策略绑定到合适节点 Master 节点
Controller Manager 控制平面 运行各类控制器（Deployment、ReplicaSet、Node 等），确保实际状态收敛到期望状态 Master 节点
kubelet 数据平面 节点代理，负责管理 Pod 生命周期、挂载卷、上报节点与 Pod 状态 Worker 节点
kube-proxy 数据平面 维护节点上的网络规则，实现 Service 的负载均衡与网络转发 Worker 节点
Container Runtime 数据平面 实际运行容器的软件（如 containerd、CRI-O） Worker 节点
设计要点：在多租户隔离架构中，API Server 是租户请求的唯一入口，所有租户隔离策略（RBAC、NetworkPolicy、ResourceQuota）均通过 API Server 的准入控制链生效。etcd 的存储隔离则决定了租户数据的物理边界。

2.2 节点角色：Master 与 Worker

Kubernetes 集群中的节点分为两类角色，职责严格分离：

  • Master 节点（控制平面节点）：运行 API Server、etcd、Scheduler、Controller Manager。通常部署奇数个（3 或 5）以实现高可用。Master 节点不调度用户工作负载，以保证控制平面稳定性。
  • Worker 节点（数据平面节点）：运行 kubelet、kube-proxy、Container Runtime。承载用户 Pod，提供计算、存储、网络资源。Worker 节点数量可弹性伸缩。
关键原则：控制平面组件不应与用户工作负载混合部署。在多租户场景中，若控制平面被租户 Pod 抢占资源，可能导致全局调度延迟或 API 响应超时，影响所有租户。

2.3 控制平面与数据平面分离原则

分离原则是 Kubernetes 架构的基石，其核心价值体现在以下三个维度：

  1. 安全边界：控制平面 API 仅对管理员和经过认证的租户开放；数据平面网络策略隔离租户 Pod 之间的流量。
  2. 故障隔离：Worker 节点故障仅影响该节点上的租户负载，不会导致控制平面不可用；控制平面组件通过多副本实现自愈。
  3. 可扩展性：控制平面与数据平面可独立扩缩容。租户数量增长时，优先扩展 Worker 节点；API 请求量增长时，扩展 API Server 实例。
Kubernetes 集群核心组件架构 控制平面（Master 节点） API Server 认证 · 授权 · 准入控制 · REST API etcd 分布式键值存储 · 集群状态持久化 Scheduler Pod 调度与绑定 Controller Manager 控制器循环 · 状态收敛 数据平面（Worker 节点） Worker 节点 1 kubelet kube-proxy Container Runtime 租户 Pod A · 租户 Pod B Worker 节点 2 kubelet kube-proxy Container Runtime 租户 Pod C · 租户 Pod D 控制平面与数据平面严格分离 Master 不调度用户 Pod，Worker 不运行控制组件

2.4 组件通信流程

一个典型的 Pod 创建请求经过的组件链路如下，体现控制平面与数据平面的协作：

  1. 用户请求 → 通过 kubectl 或 API 调用发送到 API Server。
  2. API Server 执行认证、授权、准入控制（MutatingWebhook、ValidatingWebhook），验证通过后将 Pod 对象写入 etcd。
  3. Scheduler 通过 Watch 机制监测到未调度的 Pod，根据资源策略选择一个 Worker 节点，将绑定结果写回 API Server。
  4. kubelet 在对应 Worker 节点上监测到新 Pod 被调度到本节点，调用 Container Runtime 启动容器。
  5. Controller Manager 中的控制器（如 ReplicaSet Controller）持续监测状态，确保运行副本数符合期望。
多租户影响：若某个租户在 API Server 上发起大量写请求（如频繁创建/删除 Pod），可能造成 etcd 写入压力增大，影响其他租户的 API 响应延迟。建议为不同租户配置独立的 API 优先级与公平性（APF）队列。
Pod 创建请求组件通信流程 用户/kubectl API Server etcd Scheduler kubelet Container Runtime Controller Manager ① 创建 Pod ② 写入 ③ Watch 未调度 Pod ④ 绑定结果 ⑤ 启动容器 ⑥ 状态监控

2.5 高可用部署建议

在生产环境中，控制平面与数据平面的高可用配置如下：

组件 高可用策略 推荐副本数
API Server 多实例 + 负载均衡（如 HAProxy、Nginx） 3
etcd 集群模式，奇数节点，Raft 共识 3 或 5
Scheduler 多实例 + Leader Election 3
Controller Manager 多实例 + Leader Election 3
Worker 节点 Pod 反亲和 + 跨可用区分布 ≥ 3
多租户高可用考量：控制平面组件的高可用应独立于租户数量设计。即使单个租户的负载激增，控制平面仍应保持稳定的 API 响应能力。建议为 API Server 配置独立的资源配额与限流策略，防止租户间相互干扰。
← 上一章 📖 返回目录 下一章 →