2. 多租户网络基础：Kubernetes网络模型、CNI插件与租户隔离原理
多租户隔离在网络层面的实现，依赖于对Kubernetes原生网络模型的深刻理解以及CNI（Container Network Interface）插件的正确选型。本章将剖析Kubernetes网络模型的核心约束，对比主流CNI插件的隔离能力，并揭示租户网络隔离的底层原理。
2.1 Kubernetes网络模型：三大核心原则
Kubernetes对集群网络提出了三个硬性要求，任何CNI实现都必须满足这些约束，这也是多租户网络设计的基石：
- Pod间无NAT通信：任意两个Pod（无论是否在同一Node）可以直接通过IP地址通信，无需地址转换。
- Node与Pod间无NAT通信：Node上的进程（如kubelet）可以直接访问Pod IP。
- Pod自身视角：Pod看到的自身IP与其他Pod看到的该Pod IP一致，不存在地址伪装。
设计启示：上述模型保证了网络拓扑的“扁平化”，但多租户场景下，扁平网络意味着所有Pod默认可达。租户隔离的本质，就是在不破坏扁平模型的前提下，通过策略或 overlay 技术限制不必要的连通性。
2.2 CNI插件分类与隔离能力对比
不同的CNI插件在租户隔离维度上表现出显著差异。下表对比了三种主流CNI架构的隔离机制：
| CNI类型 | 代表插件 | 隔离粒度 | 网络策略支持 | 租户隔离方式 |
|---|---|---|---|---|
| Overlay | Flannel (VXLAN), Calico (IPIP) | Namespace级别 | 有限（需额外组件） | 虚拟网络封装，天然隔离二层广播域 |
| 路由式 | Calico (BGP), Cilium (eBPF) | Pod级别 | 原生支持（NetworkPolicy） | 基于iptables/eBPF的L3/L4/L7策略 |
| Spine/Leaf | Contrail, OVN-Kubernetes | 租户/虚拟网络 | 强（逻辑交换机/路由器） | 逻辑网络隔离 + 分布式ACL |
2.3 租户隔离原理：从Namespace到NetworkPolicy
Kubernetes原生的租户隔离依赖两层机制：Namespace作为逻辑边界，NetworkPolicy作为流量控制门禁。
- Namespace隔离（软隔离）：Namespace将资源（Pod、Service、ConfigMap）分组，但默认不阻断网络流量。Pod A在ns-a中仍可访问ns-b中的Pod B。
- NetworkPolicy隔离（硬隔离）：通过定义Ingress/Egress规则，实现Pod级别的白名单流量控制。一旦Namespace中存在任何NetworkPolicy，默认拒绝所有未显式允许的流量。
- CNI增强隔离：部分CNI（如Cilium）支持基于身份的安全策略，将租户标识嵌入到网络数据包中，实现跨集群的租户隔离。
常见误区：仅创建Namespace并不能实现网络隔离。必须配合NetworkPolicy或CNI级别的租户网络定义。在Argo CD多租户场景中，如果未正确配置NetworkPolicy，一个租户的Application Controller可能直接访问另一个租户的API Server。
2.4 多租户网络拓扑：逻辑隔离与物理共享
下图展示了一个典型的多租户Kubernetes集群网络拓扑，其中两个租户共享同一物理节点，但通过VXLAN overlay和NetworkPolicy实现逻辑隔离：
2.5 CNI数据平面隔离机制详解
不同CNI在数据平面实现隔离的方式各有侧重，理解这些机制有助于在Argo CD多租户场景中做出正确的网络选型：
| 隔离机制 | 工作原理 | 性能影响 | 适用场景 |
|---|---|---|---|
| VXLAN/Geneve封装 | 将租户流量封装在UDP隧道中，不同租户使用不同VNI | 中等（封装/解封装开销） | 公有云、混合云、需要L2扩展 |
| BGP路由分发 | 通过BGP将Pod路由宣告到网络，利用路由表隔离 | 低（无封装） | 私有云、高性能计算、低延迟场景 |
| eBPF/XDP | 在内核层面执行网络策略，基于身份标识过滤 | 极低（内核旁路） | 高吞吐、低延迟、细粒度策略 |
| iptables/ipset | 通过Node上的iptables规则实现网络策略 | 中等（规则链遍历） | 中小规模集群、兼容性优先 |
2.6 租户网络隔离的Argo CD视角
在Argo CD多租户部署中，网络隔离直接影响Application Controller与目标集群之间的通信路径：
- 控制面流量：Argo CD Server/Controller与Kubernetes API Server之间的通信，通常走集群外部网络或Service网络，不受Pod NetworkPolicy影响。
- 数据面流量：Argo CD Repo Server拉取Git仓库、Application Controller同步资源时，可能涉及跨租户的Pod网络访问。如果Repo Server部署在租户A的Namespace中，而目标集群在租户B，则需要显式配置NetworkPolicy允许跨Namespace流量。
- 优化建议：将Argo CD控制面组件部署在独立的“基础设施”Namespace中，并配置宽松的NetworkPolicy以允许其访问所有租户集群；租户之间的流量则通过严格的NetworkPolicy隔离。
关键结论：多租户网络隔离不是单一技术可以完成的，而是Namespace逻辑边界、NetworkPolicy策略控制、CNI数据平面隔离三者协同的结果。在Argo CD查询优化场景中，网络拓扑的清晰度直接决定了跨租户资源同步的延迟和可靠性。