2. 集群蓝图设计原则
多租户集群的蓝图设计是架构落地的第一道防线。设计原则决定了集群的可扩展性、故障隔离能力和运维效率。本章围绕蓝图定义、高可用架构、控制面与数据面分离、节点池规划以及 etcd 集群优化五个核心维度展开，为后续的租户隔离与资源管控奠定基础。
2.1 蓝图定义
集群蓝图（Cluster Blueprint）是对集群基础设施、控制平面、数据平面、网络、存储、安全策略以及租户边界的一体化描述。它不仅是部署清单，更是运维基线。
| 蓝图维度 | 核心内容 | 多租户关注点 |
|---|---|---|
| 基础设施层 | 节点规格、OS 版本、容器运行时、GPU/NPU 驱动 | 节点级隔离（Hypervisor / 物理机） |
| 控制平面 | API Server、Scheduler、Controller Manager 部署拓扑 | 租户 API 限流、审计日志隔离 |
| 数据平面 | CNI、CSI、Ingress、Service Mesh 组件选型 | 网络策略、存储卷隔离、南北向流量管控 |
| 租户边界 | Namespace、RBAC、NetworkPolicy、ResourceQuota | 租户资源上限、权限最小化、网络白名单 |
| 可观测性 | 监控、日志、告警、审计链路 | 租户级指标隔离、日志脱敏 |
实践建议：蓝图应作为 GitOps 仓库中的版本化 YAML/Helmfile 存在，每次变更都经过 PR 评审与 CI 验证，确保集群状态可追溯、可回滚。
2.2 高可用架构设计
多租户集群必须消除单点故障。控制平面与 etcd 的高可用是租户 SLA 的底线。以下架构图展示了典型的高可用控制平面拓扑。
高可用关键指标：
- API Server 可用性：至少 2 个实例，推荐 3 个，通过 Haproxy / Nginx / 云 LB 分发。
- etcd 集群：奇数节点（3/5/7），跨可用区部署，磁盘 IOPS ≥ 1000。
- Controller Manager / Scheduler：leader election 机制，仅主实例工作，备实例待命。
2.3 控制平面与数据平面分离
控制平面与数据平面分离是 Kubernetes 架构的核心原则，在多租户场景下尤为重要。分离策略直接影响租户故障域和运维复杂度。
| 分离维度 | 控制平面 | 数据平面 | 多租户收益 |
|---|---|---|---|
| 节点角色 | Master 节点（专用） | Worker 节点（租户共享或独占） | 控制面故障不影响租户 Pod 运行 |
| 网络平面 | 管理网络（带外） | 业务网络（VPC / VLAN） | 租户流量不污染管理链路 |
| 资源预留 | 预留 CPU/Memory 给系统组件 | 剩余资源全部分配给租户 | 避免租户 Pod 挤占系统组件 |
| 安全边界 | 严格控制 SSH/API 访问 | 租户只能通过 RBAC 访问自身资源 | 租户无法触及控制面配置 |
常见陷阱：不要将 etcd 与控制平面组件混部在同一台机器上，除非是测试环境。etcd 对磁盘 IO 和网络延迟极其敏感，混部会导致控制面不稳定，进而影响所有租户。
2.4 节点池规划
节点池（Node Pool）是管理异构工作负载的核心抽象。在多租户集群中，节点池用于隔离不同租户的计算资源、GPU 类型、操作系统版本和扩缩容策略。
| 节点池类型 | 适用场景 | 隔离级别 | 扩缩容策略 |
|---|---|---|---|
| 系统节点池 | 运行系统组件、监控、日志、DNS | 集群级 | 手动扩缩，预留资源 |
| 通用租户池 | 普通无状态应用、Web 服务 | Namespace + ResourceQuota | Cluster Autoscaler |
| GPU 加速池 | AI/ML 训练、推理任务 | 节点级（taint + toleration） | 手动或按 GPU 指标扩缩 |
| 高安全池 | 金融、合规敏感租户 | 物理机 / 专用实例 | 手动扩缩，禁止自动缩容 |
| 临时/Spot 池 | 批处理、CI/CD、非关键任务 | Namespace + 优先级 | Spot 实例，可被回收 |
节点池规划最佳实践：
- 每个节点池使用 taint + toleration 确保只有匹配的 Pod 可以调度。
- 为每个节点池设置独立的 ResourceQuota 和 LimitRange，防止租户资源争抢。
- GPU 节点池建议使用 nodeSelector 和 topologyKey 确保 GPU 设备拓扑感知调度。
- 高安全池应启用 Pod Security Admission 强制 restricted 级别。
2.5 etcd 集群优化
etcd 是 Kubernetes 控制平面的“数据库”，其性能直接决定集群的响应速度和稳定性。多租户场景下，大量 Namespace、RBAC 规则和 NetworkPolicy 会显著增加 etcd 的存储和查询压力。
| 优化维度 | 推荐配置 | 多租户影响 |
|---|---|---|
| 存储后端 | SSD/NVMe，IOPS ≥ 1000，延迟 < 2ms | 租户资源创建/删除速度 |
| 集群规模 | 3 节点（生产），5 节点（跨 AZ） | 租户数量上限 |
| 磁盘配额 | --quota-backend-bytes=8GB（默认 2GB） | 防止租户资源爆炸导致 etcd 满 |
| 请求限流 | --max-request-bytes=1572864（1.5MB） | 防止大对象请求拖垮 etcd |
| 自动压缩 | --auto-compaction-mode=revision --auto-compaction-retention=1000 | 控制历史版本堆积 |
| 网络隔离 | 独立管理网络，禁止租户访问 | 租户无法直接攻击 etcd |
etcd 健康检查命令：
# 检查 etcd 集群成员状态
etcdctl member list --write-out=table
# 检查端点健康状态
etcdctl endpoint health --cluster
# 检查当前 db 大小
etcdctl endpoint status --cluster --write-out=table
# 查看告警（如磁盘空间不足）
etcdctl alarm list通过以上五个设计原则的落地，多租户集群将具备高可用、强隔离、可扩展的基础架构。下一层我们将深入租户隔离的具体实现策略，包括 RBAC、NetworkPolicy 和 ResourceQuota 的精细化配置。