3、租户隔离模型：基于NetworkPolicy的隔离、基于CiliumNetworkPolicy的增强隔离、基于ClusterMesh的跨集群隔离
在 Kubernetes 多租户环境中，网络隔离是保障租户安全的核心能力。Cilium 在原生 Kubernetes NetworkPolicy 基础上，提供了多层级的隔离模型，覆盖单集群内的基础隔离、增强隔离以及跨集群的全局隔离。本章将系统分析这三种隔离模型的实现原理、能力边界及升级影响。
3.1 基于NetworkPolicy的基础隔离
Kubernetes NetworkPolicy 是业界标准的网络隔离原语，通过标签选择器定义 Pod 之间的通信规则。Cilium 完全兼容该标准，并将其翻译为 eBPF 程序直接加载到网络栈中。
核心机制： NetworkPolicy 通过
podSelector、namespaceSelector 和 ipBlock 三种选择器组合，定义入站（ingress）和出站（egress）规则。Cilium 在升级过程中会保持这些规则的语义一致性，但底层实现从 iptables 切换为 eBPF，带来性能提升和延迟降低。
| 特性 | Kubernetes NetworkPolicy | Cilium 实现优势 |
|---|---|---|
| 规则匹配粒度 | Pod 标签 + Namespace 标签 | 支持更丰富的标签组合，无性能衰减 |
| 默认行为 | 未定义策略时允许所有流量 | 同原生行为，但可配置为默认拒绝 |
| 性能开销 | iptables 规则链遍历，随规则数线性增长 | eBPF 哈希表查找，O(1) 时间复杂度 |
| 升级影响 | 规则定义不变，但底层实现切换 | 零停机迁移，连接跟踪状态保持 |
升级注意事项： 当从传统 CNI（如 Calico、Flannel）迁移至 Cilium 时，NetworkPolicy 资源定义无需修改。但需注意 Cilium 默认使用 eBPF 的 conntrack 替代 iptables conntrack，建议在升级前验证现有策略的流量匹配是否符合预期。
3.2 基于CiliumNetworkPolicy的增强隔离
CiliumNetworkPolicy（CNP）是 Cilium 提供的 CRD 扩展，在原生 NetworkPolicy 基础上增加了大量高级特性，适用于需要精细化控制的租户隔离场景。
关键增强点： CNP 支持 L3/L4/L7 多层策略、基于 HTTP/gRPC 方法的路由控制、DNS 策略、CIDR 规则以及集群内外流量的统一管理。这些能力在升级过程中需要特别注意 CRD 版本兼容性和策略迁移策略。
| 能力维度 | 原生 NetworkPolicy | CiliumNetworkPolicy |
|---|---|---|
| 协议层支持 | L3/L4（IP+端口） | L3/L4/L7（HTTP、gRPC、Kafka 等） |
| 规则匹配条件 | 标签 + IP 段 | 标签 + IP 段 + 服务名 + 域名 + HTTP 方法/路径 |
| 租户隔离粒度 | Pod 级别 | Pod + 服务 + API 端点级别 |
| 集群外流量 | 仅 ipBlock | 支持 toFQDN（域名）、toCIDR、fromCIDR |
| 审计与日志 | 无原生支持 | 集成 Hubble 可观测性，支持策略命中审计 |
升级风险提示： CiliumNetworkPolicy 的 CRD 版本在升级过程中可能发生变化。例如从 Cilium 1.11 升级到 1.12 时，
toFQDN 字段的匹配行为有所调整。建议在升级前使用 cilium policy validate 命令检查现有策略的兼容性，并准备回滚方案。
3.3 基于ClusterMesh的跨集群隔离
ClusterMesh 是 Cilium 的跨集群网络方案，允许将多个 Kubernetes 集群组成一个逻辑网络平面，实现跨集群的服务发现和网络策略统一管理。对于多租户场景，ClusterMesh 提供了跨集群的租户隔离能力。
核心价值： ClusterMesh 通过隧道或直接路由模式连接集群，使用统一的身份标识（Security Identity）跨集群传递，确保租户 Pod 在不同集群间通信时仍受相同策略约束。升级过程中需要关注集群间证书轮换、隧道端点更新以及策略同步延迟。
| 隔离维度 | 单集群隔离 | ClusterMesh 跨集群隔离 |
|---|---|---|
| 身份标识 | 集群内唯一 Security Identity | 全局唯一 Security Identity（跨集群共享） |
| 策略作用域 | 仅限本集群 Namespace | 跨集群 Namespace 统一管理 |
| 服务发现 | 集群内 Service | Global Service（跨集群负载均衡） |
| 加密通信 | 可选（Node-to-Node） | 默认 WireGuard/IPsec 跨集群加密 |
| 升级影响 | 重启 Agent 即可 | 需协调多个集群升级顺序，避免策略空洞 |
升级最佳实践： ClusterMesh 升级应遵循“先升级控制面，再升级数据面”的原则。建议先升级所有集群的 Cilium Operator，再逐个升级 Agent。升级期间跨集群策略会暂时失效，需提前规划维护窗口。使用
cilium clustermesh status 监控集群间连接状态。
3.4 三种隔离模型的对比与升级影响总结
下表从多个维度对比三种隔离模型，帮助运维人员根据租户需求选择合适的方案，并评估升级过程中的影响。
| 对比维度 | NetworkPolicy | CiliumNetworkPolicy | ClusterMesh |
|---|---|---|---|
| 适用场景 | 基础租户隔离，合规要求 | 精细化安全管控，API 级隔离 | 多集群灾备、全球部署 |
| 策略复杂度 | 低（仅 L3/L4） | 高（L3/L4/L7 + DNS + CIDR） | 中（需考虑跨集群身份映射） |
| 性能开销 | 低（eBPF 加速） | 中（L7 解析额外开销） | 中（隧道封装开销） |
| 升级影响范围 | 单集群，Agent 重启 | 单集群，CRD 版本兼容 | 多集群，需协调升级顺序 |
| 回滚难度 | 低（策略定义不变） | 中（CRD 版本回退需迁移） | 高（跨集群状态同步复杂） |
| 推荐升级策略 | 滚动升级，逐个节点 | 预检策略兼容性，分批升级 | 先升级控制面，再数据面，预留窗口 |
关键升级建议：
- 对于仅使用 NetworkPolicy 的租户，升级风险最低，但仍需验证 eBPF conntrack 与现有连接跟踪的兼容性。
- 对于使用 CiliumNetworkPolicy 的租户，务必在升级前执行
cilium policy validate --cluster-network-policy检查所有 CRD 实例。 - 对于 ClusterMesh 场景，建议在测试环境模拟跨集群升级流程，验证策略同步延迟不超过 30 秒。
- 所有升级操作都应配合 Hubble 监控，实时观察策略命中率和流量变化。