Kubernetes 多租户挑战：安全风险、网络隔离与资源争抢
在 Kubernetes 中实现多租户并非简单的命名空间划分。当多个团队、应用或客户共享同一集群时，控制面与数据面会暴露出一系列深层问题。本节从安全风险、网络隔离需求和资源争抢三个维度拆解核心挑战，并分析传统方案的局限性，为后续引入准入控制与 Cilium 协同升级奠定问题基线。
2.1 多租户场景下的安全风险
共享集群意味着攻击面扩大。租户之间的恶意或意外行为可能通过以下路径突破隔离边界：
- Pod 逃逸与容器突破：若租户 A 的容器存在内核漏洞，攻击者可能逃逸至宿主机，进而影响租户 B 的工作负载。
- API Server 暴露：未经细粒度 RBAC 约束的 ServiceAccount 可能被用于枚举集群资源或执行越权操作。
- 网络平面嗅探：在扁平网络或未加密的 CNI 模式下，租户 B 可能通过抓包获取租户 A 的敏感流量。
- Secrets 与 ConfigMap 泄露：命名空间隔离不阻止集群内任意 ServiceAccount 读取同一命名空间下的 Secret（若 RBAC 配置不当）。
- 恶意 Admission Webhook：租户若可部署 Validating/MutatingWebhookConfiguration，可能拦截或篡改其他租户的 Pod 创建请求。
关键指标：CNCF 2024 年调查显示，68% 的 Kubernetes 安全事件与多租户隔离配置错误直接相关，其中网络平面泄露和 RBAC 过度授权占比最高。
2.2 网络隔离需求
多租户网络隔离不仅是“不通”的问题，更涉及微分段、加密与出口控制。下表对比了不同隔离粒度下的需求差异：
| 隔离粒度 | 典型场景 | 网络需求 | 实现难度 |
|---|---|---|---|
| 命名空间级 | 开发/测试环境 | 禁止跨命名空间通信 | 低 |
| 应用级 | 微服务间调用 | 基于标签的 L3/L4 策略 + L7 HTTP 方法过滤 | 中 |
| 租户级 | SaaS 多租户生产集群 | 全加密（mTLS）+ 出口审计 + DNS 策略 | 高 |
| 节点级 | 合规敏感工作负载 | 节点间 VXLAN/Geneve 隧道 + 租户专属子网 | 高 |
传统 NetworkPolicy 仅支持 L3/L4 五元组匹配，无法感知 HTTP 路径、gRPC 方法或 Kafka Topic，导致租户间 API 级别的访问控制必须依赖服务网格或自定义代理，增加了运维复杂度。
2.3 资源争抢问题
多租户共享集群的物理资源（CPU、内存、磁盘 IO、网络带宽）时，缺乏隔离会导致“吵闹邻居”效应。具体表现为：
- CPU 与内存抢占：租户 A 的突发 Pod 可能挤占租户 B 的 Guaranteed QoS Pod，导致后者 OOMKilled。
- 网络带宽争抢：租户 B 的大规模数据迁移作业可能耗尽节点带宽，使租户 A 的在线服务延迟飙升。
- API Server 限流：租户 C 的异常控制器频繁 List-Watch 所有资源，触发 API Server 的 max-inflight 限制，影响全局控制面响应。
- 存储 IOPS 竞争：共享 PV 后端（如 NFS、Ceph）在无 QoS 限制时，租户 D 的批量写入会阻塞租户 E 的数据库事务。
常见误区：仅设置 ResourceQuota 和 LimitRange 无法解决网络带宽和 IOPS 争抢。这些资源属于节点级或存储后端级，Kubernetes 原生调度器不感知网络带宽与磁盘 IO 容量。
2.4 传统方案的局限性
业界尝试过多种多租户隔离方案，但均存在明显短板。下表从五个关键维度进行对比：
| 方案 | 网络隔离 | 资源隔离 | 控制面安全 | 运维复杂度 | 性能开销 |
|---|---|---|---|---|---|
| 命名空间 + RBAC | 无（需额外 NetworkPolicy） | 仅 CPU/内存配额 | 中等（易配置错误） | 低 | 无 |
| NetworkPolicy（Kubernetes 原生） | 仅 L3/L4 | 不涉及 | 不涉及 | 中 | 低（依赖 CNI 实现） |
| 虚拟集群（vCluster） | 需额外 CNI 插件 | 控制面隔离好 | 高（独立 API Server） | 高 | 中（控制面冗余） |
| 服务网格（Istio/Linkerd） | L7 + mTLS | 不涉及 | 中等（Sidecar 注入点） | 高 | 高（Sidecar 代理） |
| 节点级隔离（NodeSelector/Taints） | 物理隔离 | 强（独占节点） | 高 | 高（资源碎片） | 无 |
传统方案的核心痛点可归纳为三点：
- 策略碎片化：网络策略、资源配额、RBAC、Pod 安全标准由不同组件管理，缺乏统一的策略执行点。
- 缺乏 L7 感知：原生 NetworkPolicy 无法对 HTTP 路径、gRPC 方法或 Kafka Topic 进行细粒度控制，租户间 API 级隔离必须依赖服务网格。
- 无内置加密与审计：Kubernetes 本身不提供工作负载间 mTLS 或流量审计能力，需额外部署 cert-manager、SPIFFE 或服务网格。
2.5 挑战总结与升级方向
综合以上分析，Kubernetes 多租户的核心矛盾在于：共享集群的经济性与租户间强隔离的安全性之间的平衡。传统方案在策略统一性、L7 感知和加密能力上存在结构性缺陷。
下一阶段的升级方向应聚焦于：
- 策略统一：通过准入控制（Admission Controller）作为单一策略注入点，将网络、安全、资源策略统一为声明式配置。
- 网络增强：引入 eBPF 数据面（Cilium），实现 L3-L7 全栈网络策略，并内置 mTLS 加密与可观测性。
- 资源保障：结合 Cilium 带宽管理（Bandwidth Manager）与 Kubernetes 动态资源调度，实现网络 IO 与 CPU 的协同隔离。