2. 租户隔离蓝图基础:回顾 Kubernetes 网络策略、命名空间隔离与 CNI 插件
在深入排查升级后租户网络不通的问题之前,必须重新夯实租户隔离的三大基础支柱:命名空间(Namespace)作为逻辑边界、网络策略(NetworkPolicy)作为流量控制规则、CNI 插件作为底层连通性实现。升级过程中任何一层的变化都可能导致隔离失效。
2.1 命名空间隔离:逻辑边界与资源配额
命名空间是 Kubernetes 实现多租户隔离的第一道防线。它提供资源对象的逻辑分组,配合 ResourceQuota 和 LimitRange 实现资源层面的硬隔离。
| 隔离维度 | 实现机制 | 升级影响点 |
|---|---|---|
| 对象可见性 | API Server 通过 namespace 字段过滤资源列表 | RBAC 规则在升级后可能因 API 版本变更导致权限失效 |
| 资源配额 | ResourceQuota 对象限制 CPU/内存/PVC 总量 | 升级后配额控制器行为变化可能导致 Pod 创建失败 |
| 网络边界 | 命名空间本身不阻断流量,需配合 NetworkPolicy | CNI 升级可能重置默认网络策略的生效状态 |
排查要点:升级后若租户 Pod 无法启动,优先检查命名空间的 ResourceQuota 是否因 API 版本迁移导致配额字段解析异常。使用
kubectl describe quota -n <tenant> 确认配额状态。
2.2 Kubernetes 网络策略(NetworkPolicy):细粒度流量控制
NetworkPolicy 是 Kubernetes 原生提供的防火墙规则,基于 Pod 标签选择器和 命名空间选择器定义哪些流量可以进出目标 Pod。升级后最常见的故障场景就是 NetworkPolicy 规则因 API 版本变更或 CNI 插件行为差异而失效。
2.2.1 核心规则模型
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: tenant-isolation
namespace: tenant-a
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
tenant: tenant-a
- podSelector:
matchLabels:
app: backend
ports:
- protocol: TCP
port: 8080
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8
except:
- 10.96.0.0/12
ports:
- protocol: TCP
port: 443
升级陷阱:Kubernetes 1.24+ 移除了 Dockershim,部分 CNI 插件(如 Calico 3.24 以下版本)依赖 Docker 网络栈进行策略实现。升级前务必确认 CNI 版本与 Kubernetes 版本的兼容性矩阵。
2.2.2 默认拒绝与白名单模式
生产环境推荐使用 默认拒绝所有入站/出站流量,然后按需开放白名单的策略模式。升级后若发现租户间意外互通,通常是因为默认拒绝策略未正确迁移。
# 默认拒绝所有入站流量
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: default-deny-egress
namespace: tenant-a
spec:
podSelector: {}
policyTypes:
- Egress
2.3 CNI 插件在租户隔离中的核心作用
CNI(Container Network Interface)插件负责为 Pod 分配 IP 地址、配置网络接口,并实现 NetworkPolicy 的底层数据平面。不同 CNI 插件的隔离实现机制差异巨大,升级后故障排查必须理解其工作原理。
| CNI 插件 | 隔离实现方式 | 升级常见问题 |
|---|---|---|
| Calico | BGP 路由分发 + iptables/IPVS 策略规则 | Felix 组件升级后 iptables 规则顺序变化导致策略失效 |
| Cilium | eBPF 程序直接挂载到网络设备 | 内核版本不兼容导致 eBPF 程序加载失败 |
| Flannel | VXLAN 或 host-gw 隧道封装 | 不支持 NetworkPolicy,需额外部署策略引擎 |
| Weave Net | Fast Datapath 用户态转发 | 升级后 weave-kube 组件 CRD 版本冲突 |
关键认知:NetworkPolicy 是控制平面的声明式规则,CNI 插件是数据平面的执行者。升级后即使 NetworkPolicy 对象存在且语法正确,如果 CNI 插件的数据平面未正确应用规则,隔离依然会失效。排查时必须同时检查控制平面(
kubectl get networkpolicy)和数据平面(CNI 插件状态)。
2.4 租户隔离蓝图:三大组件协同关系
下图展示了命名空间、NetworkPolicy 和 CNI 插件在租户隔离蓝图中的协同工作方式。升级后任何一层出现断裂都会导致租户网络不通。
2.5 升级后租户隔离失效的典型根因
基于上述三大组件,升级后租户网络不通的根因可归纳为以下三类,每类对应不同的排查路径:
- 命名空间层失效:ResourceQuota 字段在新 API 版本中被弃用或重命名,导致 Pod 创建被拒绝;RBAC 规则因 API 组版本迁移导致 ServiceAccount 无法访问资源。
- NetworkPolicy 层失效:策略对象语法在新版本中不再兼容(如
podSelector: {}的语义变化);CNI 插件升级后未重新加载策略规则;默认拒绝策略在升级过程中被删除。 - CNI 数据平面失效:CNI 二进制文件版本与 kubelet 版本不匹配;内核模块(如 eBPF、iptables 内核模块)未正确加载;节点重启后 CNI 配置未持久化。
快速诊断命令:升级后执行
kubectl run test-pod --image=busybox -n <tenant> -- sleep 3600,然后进入 Pod 执行 ping <目标 Pod IP> 和 wget -O- <目标 Service>,结合 tcpdump 确认数据包是否被丢弃在 CNI 数据平面。
2.6 租户隔离蓝图升级前后对比
下表总结了升级前后各隔离组件可能发生的变化,帮助快速定位故障范围:
| 组件 | 升级前状态 | 升级后可能状态 | 影响 |
|---|---|---|---|
| 命名空间配额 | 正常分配资源 | 配额字段解析失败,Pod Pending | 租户无法部署新工作负载 |
| NetworkPolicy 规则 | 白名单规则生效 | 规则语法兼容,但数据平面未应用 | 租户间意外互通或完全隔离 |
| CNI 数据平面 | Pod 网络连通正常 | iptables 规则顺序错乱或 eBPF 程序未加载 | Pod 间网络不通或延迟激增 |
| kube-proxy | Service 转发正常 | iptables/IPVS 模式变更导致 Service 不可达 | 租户 Service 访问失败 |