2. 集群架构基础回顾：单集群 vs 多集群、控制平面与数据平面、节点与Pod的调度逻辑、命名空间的默认隔离能力
在深入多租户隔离方案之前，必须重新审视 Kubernetes 集群架构的核心概念。这些基础组件直接决定了租户隔离的边界、粒度与成本。本节从四个维度展开：集群拓扑、平面划分、调度逻辑与命名空间隔离。
2.1 单集群 vs 多集群：隔离的第一道选择题
集群是 Kubernetes 中最大的管理边界。选择单集群还是多集群，本质是在资源共享效率与故障隔离半径之间做权衡。
| 对比维度 | 单集群（Single Cluster） | 多集群（Multi-Cluster） |
|---|---|---|
| 管理开销 | 低，仅需运维一套控制平面 | 高，每集群独立运维、升级、监控 |
| 资源共享 | 高，节点池统一调度，碎片率低 | 低，集群间资源无法直接共享 |
| 故障爆炸半径 | 大，控制平面故障影响所有租户 | 小，单集群故障不影响其他集群 |
| 租户隔离强度 | 弱，依赖 RBAC + NetworkPolicy + 命名空间 | 强，物理/虚拟集群边界天然隔离 |
| 网络复杂度 | 低，Pod 间可直接通信 | 高，需 Service Mesh 或集群互联方案 |
| 适用场景 | 开发测试、中小规模、信任度高的多团队 | 生产多租户、合规要求高、跨地域部署 |
架构建议： 对于多租户生产环境，推荐采用多集群 + 单集群内命名空间隔离的混合模式。核心敏感租户分配独立集群，普通租户共享集群但使用强化的命名空间策略。
2.2 控制平面与数据平面：职责分离与隔离边界
Kubernetes 架构严格区分控制平面（Control Plane）与数据平面（Data Plane）。理解这一分层对设计租户隔离方案至关重要。
隔离关键点：
- 控制平面共享风险： 单集群中所有租户共用 apiserver、etcd、scheduler。一个恶意的 Pod 如果通过漏洞攻击 apiserver，可能影响全局。
- 数据平面隔离： 租户 Pod 运行在不同节点上时，通过节点级隔离（VM/物理机）实现强隔离；运行在同一节点时，依赖 Linux 内核命名空间与 cgroups。
- 网络代理隔离： kube-proxy 的 iptables/IPVS 规则是节点级别的，一个租户的 Service 配置错误可能影响节点上其他租户的网络规则。
2.3 节点与Pod的调度逻辑：资源分配与租户干扰
调度器（kube-scheduler）负责将 Pod 绑定到合适的节点。在多租户场景下，调度策略直接影响资源争抢与性能隔离。
常见调度干扰问题：
- 资源争抢： 未设置 ResourceQuota 时，一个租户的突发 Pod 可能占满节点 CPU，导致同节点其他租户 Pod 饥饿。
- 节点共享： 不同租户的 Pod 调度到同一节点时，共享内核、CPU 缓存、内存带宽，存在侧信道攻击风险。
- 调度器盲区： 默认调度器不感知租户身份，需通过调度器扩展（Scheduler Extender）或自定义调度器实现租户感知调度。
2.4 命名空间的默认隔离能力：边界与局限
命名空间（Namespace）是 Kubernetes 内置的逻辑隔离单元，也是多租户隔离的第一道防线。但它的隔离能力是有限的，理解其边界才能正确设计补充策略。
2.4.1 命名空间提供的隔离
| 隔离维度 | 是否隔离 | 说明 |
|---|---|---|
| 资源对象名称 | ✅ 是 | 不同命名空间下可存在同名 Service、ConfigMap、Secret |
| 资源配额 | ✅ 是（需配置 ResourceQuota） | 限制命名空间内 CPU/内存/PVC 总量 |
| RBAC 权限 | ✅ 是（需配置 RoleBinding） | Role 作用域限定在单个命名空间 |
| 网络通信 | ❌ 否（默认互通） | Pod 可通过 Service DNS 跨命名空间访问 |
| Pod 安全策略 | ❌ 否（需额外配置） | PodSecurityPolicy / OPA Gatekeeper 需单独绑定 |
| 节点资源 | ❌ 否 | 命名空间不绑定节点，Pod 可调度到任意节点 |
| 网络策略 | ⚠️ 部分（需 NetworkPolicy） | NetworkPolicy 默认允许所有流量，需显式拒绝 |
2.4.2 命名空间隔离的典型局限
# 跨命名空间访问示例：默认允许
# 在 namespace-a 中的 Pod 可以直接访问 namespace-b 中的 Service
curl http://service-b.namespace-b.svc.cluster.local:8080
# 需要显式创建 NetworkPolicy 来阻断
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-cross-ns
namespace: namespace-a
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: namespace-a
关键认知： 命名空间提供的是管理隔离而非安全隔离。它防止资源名称冲突，但不阻止网络互通、不隔离节点资源、不限制内核级访问。对于多租户生产环境，必须叠加 NetworkPolicy、ResourceQuota、LimitRange、Pod Security Admission 等机制才能达到可接受的隔离水平。
2.5 本章小结：架构基础对多租户隔离的启示
- 集群拓扑选择： 单集群适合信任度高的内部多团队，多集群适合强隔离要求的商业多租户。
- 平面分离： 控制平面是共享的单点故障域，数据平面隔离依赖节点级与容器级技术。
- 调度策略： 默认调度器不感知租户，需通过节点标签、污点、拓扑约束实现租户资源隔离。
- 命名空间局限： 命名空间是逻辑隔离单元，必须配合网络策略、配额、安全策略才能构建完整隔离方案。