1. 多租户网络基础：概念、隔离需求与 NetPolicy 角色

1.1 多租户概念与核心特征

多租户（Multi-Tenancy）是一种软件架构模式，允许单个 Kubernetes 集群实例同时服务多个相互隔离的“租户”。每个租户可以是一个团队、一个项目、一个业务线或一个外部客户。在 Kubernetes 语境下，租户通常对应一个 命名空间（Namespace） 或一组命名空间的集合。

1.2 网络隔离需求：为什么默认网络不隔离？

Kubernetes 默认的网络模型是“扁平网络”：集群内所有 Pod 都可以直接通信，无论它们属于哪个命名空间。这种设计简化了服务发现和微服务调用，但在多租户场景下带来了严重的安全风险。

• 风险一：数据泄露 —— 租户 A 的数据库 Pod 可能被租户 B 的恶意 Pod 直接访问。
• 风险二：横向移动 —— 攻击者攻破一个租户的 Pod 后，可以自由扫描并攻击集群内其他租户的服务。
• 风险三：流量干扰 —— 一个租户的高流量应用可能耗尽网络带宽，影响其他租户的延迟和吞吐。

因此，多租户集群必须引入 网络隔离策略，将默认的“允许所有”转变为“默认拒绝，按需放行”。

1.3 NetPolicy 在 Kubernetes 中的角色

NetworkPolicy（简称 NetPolicy）是 Kubernetes 原生的 API 资源，用于定义 Pod 组之间的网络通信规则。它在多租户架构中扮演着 “网络防火墙” 的角色，是实施租户间隔离的核心工具。

NetPolicy 的工作机制基于以下三个要素：

1. 选择器（PodSelector） —— 指定策略作用于哪些 Pod（通常通过标签选择）。
2. 策略类型（PolicyTypes） —— 定义是控制入站流量（Ingress）、出站流量（Egress），还是两者都控制。
3. 规则（Ingress/Egress Rules） —— 定义允许哪些来源（IP 段、命名空间、Pod 标签）访问目标 Pod，或允许目标 Pod 访问哪些目的地。

下面这张图展示了 NetPolicy 在集群中的核心位置与作用范围：

1.4 NetPolicy 与 CNI 插件的关系

NetPolicy 本身只是一个 API 定义，真正的网络规则执行依赖于底层的 CNI（Container Network Interface）插件。如果集群使用的 CNI 插件不支持 NetworkPolicy（例如 Flannel 的默认模式），那么定义的策略将不会生效。

1.5 多租户网络隔离的典型策略模式

在实际生产环境中，多租户网络隔离通常采用以下三种策略模式的组合：

• 默认拒绝所有入站流量 —— 每个租户的 Pod 默认不接收来自任何来源的流量，除非显式添加允许规则。
• 允许同命名空间内通信 —— 允许同一租户内的 Pod 互相访问，便于微服务调用。
• 显式允许跨租户通信 —— 对于需要共享的服务（如监控、日志收集），通过精细的标签选择器或 IP 段规则放行特定流量。

下面是一个典型的“默认拒绝 + 同命名空间允许”策略示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: tenant-a
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: tenant-a
  policyTypes:
  - Ingress

第一个策略拒绝所有入站流量，第二个策略允许来自同一命名空间的流量。两个策略叠加后，租户 A 的 Pod 只能被同命名空间的 Pod 访问，外部流量全部被阻断。