3. 多租户网络隔离模型：基于Namespace的软隔离与基于CNI的硬隔离

在生产级Kubernetes集群中，多租户网络隔离是保障安全与稳定性的核心能力。本章深入剖析两种主流隔离模型：基于Namespace的软隔离（逻辑隔离）与基于CNI的硬隔离（物理/策略隔离）。理解两者的差异、适用场景及组合策略，是设计生产回滚方案的前提。

3.1 软隔离：Namespace级别的网络边界

Kubernetes原生提供的Namespace是一种逻辑隔离机制。默认情况下，不同Namespace中的Pod可以通过Cluster IP或DNS名称直接通信，这种“默认允许”模式构成了软隔离的基础。

3.1.1 软隔离的通信模型

在未配置NetworkPolicy时，所有Namespace间的Pod通信是全开放的。软隔离的“软”体现在：

• 共享网络平面：所有Pod共享同一个CNI插件管理的虚拟网络（如Flannel的VXLAN、Calico的BGP）。
• 策略驱动：隔离效果完全依赖NetworkPolicy对象的生效状态，一旦策略被误删除或未正确应用，隔离即失效。
• 无状态阻断：软隔离不维护连接跟踪表，策略变更后已有连接可能继续存在。

3.1.2 软隔离的典型配置

以下是一个基于Namespace标签的NetworkPolicy示例，实现“只允许同一租户的Pod访问”：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tenant: a
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          tenant: a

3.2 硬隔离：CNI层面的网络强制

硬隔离通过CNI插件在网络基础设施层实施隔离，不依赖Kubernetes控制平面的策略引擎。常见的实现方式包括：

• VXLAN/Geneve封装：为每个租户分配独立的VNI（VXLAN Network Identifier），数据包在宿主机层面即被隔离。
• BGP路由策略：通过Calico的BGP Peering，为不同租户发布独立的路由表，实现L3隔离。
• MACVLAN/IPVLAN：将物理网卡直接分配给租户Pod，实现硬件级别的网络隔离。

3.2.1 硬隔离的通信模型

硬隔离的核心在于数据平面隔离：即使Kubernetes控制平面完全失效，租户间的网络也无法互通。其典型架构如下：

3.2.2 硬隔离的CNI实现对比

3.3 软硬隔离的协同与回滚策略

在生产环境中，软隔离 + 硬隔离的组合使用是最佳实践。软隔离提供灵活的策略控制，硬隔离提供底线安全。回滚验证时必须同时考虑两者的状态一致性。

3.3.1 回滚验证的关键检查点

1. 软隔离层：确认NetworkPolicy的spec.podSelector和spec.ingress/egress规则与回滚前一致。
2. 硬隔离层：检查CNI插件的VNI/BGP路由表是否已清理旧租户的残留条目。
3. 数据路径：通过tcpdump或bpftrace验证跨租户数据包是否被正确丢弃。
4. 性能基线：回滚后测量吞吐量和延迟，确保硬隔离封装/解封装未引入额外抖动。

3.4 生产窗口内的隔离回滚决策树

在生产变更窗口内，当网络隔离策略回滚时，运维人员需快速判断隔离模型是否已恢复。以下决策树可作为操作指南：