3. 集群蓝图设计原则：多租户集群蓝图设计目标、租户资源配额、节点池划分、控制平面与数据平面分离

多租户集群蓝图是构建企业级 Kubernetes 平台的顶层设计产物。它并非简单的集群安装参数集合，而是一套将租户边界、资源预算、工作负载特征、网络与安全策略统一映射到基础设施上的结构化方案。本章围绕四个核心设计维度展开：设计目标、资源配额、节点池划分、控制与数据平面分离。

3.1 多租户集群蓝图设计目标

设计蓝图的首要任务是明确“多租户”在集群中的具体含义。不同组织对租户隔离的深度要求差异巨大，从简单的命名空间软隔离到完全独立的控制平面硬隔离。蓝图设计目标应覆盖以下五个关键维度：

3.2 租户资源配额设计

资源配额是蓝图落地的核心控制手段。Kubernetes 原生提供 ResourceQuota 和 LimitRange 对象，但在多租户场景下，需要结合集群容量规划进行分层设计。

3.2.1 分层配额模型

推荐采用“集群 → 节点池 → 租户 → 命名空间”四层配额模型，每层职责明确：

• 集群层： 设置全局预留资源（系统组件 + 缓冲区），不直接分配给租户。
• 节点池层： 通过节点池的实例规格与数量上限，控制租户可调度的物理资源天花板。
• 租户层： 使用 ResourceQuota 定义租户在集群内的总资源上限，跨多个命名空间共享。
• 命名空间层： 使用 LimitRange 约束单个 Pod 或容器的资源请求/限制范围，防止异常 Pod 耗尽租户配额。

3.2.2 配额计算示例

假设集群总资源为 100 核 CPU / 400 GB 内存，预留 20% 给系统组件与弹性缓冲区，剩余 80 核 / 320 GB 可供分配。三个租户的配额分配如下：

# 租户 A 的 ResourceQuota 示例
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
  namespace: tenant-a-prod
spec:
  hard:
    requests.cpu: "40"
    requests.memory: "160Gi"
    limits.cpu: "48"
    limits.memory: "192Gi"
    persistentvolumeclaims: "20"
    pods: "200"
    count/ingresses.extensions: "10"

3.3 节点池划分策略

节点池（Node Pool）是云原生基础设施中实现物理/虚拟资源分组的关键抽象。在多租户蓝图中，节点池划分直接决定了故障域边界与性能隔离效果。

3.3.1 划分依据

节点池划分应综合考虑以下因素：

• 租户信任等级： 高安全租户（如金融核心）使用独占节点池；低安全租户（如开发测试）可共享节点池。
• 工作负载类型： GPU 密集型、内存密集型、高 I/O 型分别规划不同实例规格的节点池。
• 地理/可用区分布： 跨可用区部署节点池，实现租户应用的高可用容灾。
• 操作系统与内核版本： 需要特定内核特性（如 eBPF、SCTP）的租户使用专用节点池。

3.3.2 节点池与租户绑定关系

通过 nodeSelector、nodeAffinity 或 taint/toleration 将租户工作负载绑定到指定节点池：

# 为租户 A 的生产节点池打标签
kubectl label node node-az1-001 node-pool=tenant-a-prod
kubectl label node node-az2-001 node-pool=tenant-a-prod

# 为节点池设置污点，防止非租户 A 的 Pod 调度上来
kubectl taint node node-az1-001 tenant=tenant-a-prod:NoSchedule

# 租户 A 的 Deployment 通过 toleration 和 nodeSelector 绑定
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-tenant-a
  namespace: tenant-a-prod
spec:
  template:
    spec:
      tolerations:
      - key: "tenant"
        operator: "Equal"
        value: "tenant-a-prod"
        effect: "NoSchedule"
      nodeSelector:
        node-pool: tenant-a-prod

3.4 控制平面与数据平面分离

控制平面与数据平面的分离是保障多租户集群稳定性的基石。控制平面承载 API Server、Scheduler、Controller Manager 以及 etcd；数据平面由所有工作节点及其上的 Pod 网络组成。分离设计包含三个层次：

3.4.1 物理/逻辑分离

• 物理分离： 控制平面节点独立部署，不运行任何租户 Pod。推荐至少 3 个控制面节点跨可用区部署，使用独立的 etcd 集群。
• 网络分离： 控制平面通信使用独立网络平面（如带外管理网络），与数据平面 Pod 网络、Service 网络、节点网络隔离。
• 负载分离： 控制平面组件（如 kube-apiserver）通过专用负载均衡器暴露，不与数据平面入口网关混用。

3.4.2 租户访问控制平面路径

租户对控制平面的访问必须经过严格的认证、授权与审计管道：

租户请求路径:
  用户/kubectl → 身份认证代理（OIDC/LDAP） → kube-apiserver（TLS）
    → RBAC 鉴权 → Admission Webhook（配额/策略校验） → etcd 持久化

关键安全措施：

• 禁止租户直接访问 etcd 或 kube-scheduler。
• 使用 SubjectAccessReview 实现细粒度 API 权限控制。
• 开启审计日志，记录所有租户对控制平面的操作。

3.4.3 数据平面隔离机制

数据平面隔离主要依赖 Cilium 提供的 eBPF 网络策略：

• Pod 网络隔离： 通过 CiliumNetworkPolicy 实现 L3/L4/L7 层访问控制，默认拒绝跨租户流量。
• Service 隔离： 租户 Service 仅在其命名空间内可见，跨租户 Service 发现需显式配置。
• DNS 隔离： 使用 CoreDNS 的 rewrite 插件或 Cilium 的 DNS 策略限制租户 DNS 查询范围。

3.5 蓝图设计原则总结

综合以上四个维度，多租户集群蓝图设计应遵循以下核心原则：

1. 最小权限原则： 租户默认无权访问其他租户的资源，包括网络、存储、API 对象。
2. 资源预算硬约束： 所有租户必须配置 ResourceQuota 和 LimitRange，禁止无限制使用集群资源。
3. 故障域显式划分： 通过节点池、可用区、污点/容忍度将租户工作负载隔离到独立故障域。
4. 控制面与数据面严格分离： 控制平面组件独立部署，数据平面通过 eBPF 策略实现租户间网络隔离。
5. 可观测性内置： 从设计之初就规划租户维度的监控、日志、审计能力，避免后期打补丁。
6. 自动化与 GitOps： 蓝图配置（节点池、配额、网络策略）应通过 GitOps 管道声明式管理，避免人工误操作。