4. 常见故障类型概览：连通性故障、策略冲突、命名空间泄漏、CNI 插件异常
在多租户 Kubernetes 集群中，NetworkPolicy 是隔离网络流量的核心手段，但实际运维中故障类型多样且相互交织。本章将四种最常见故障类型进行系统化分类，帮助运维人员快速定位问题根因。
4.1 故障类型总览
下表从故障现象、根因范围、影响面三个维度对比四种典型故障：
| 故障类型 | 典型现象 | 根因范围 | 影响面 |
|---|---|---|---|
| 连通性故障 | Pod 间无法通信、超时、连接拒绝 | 策略缺失、标签不匹配、端口错误 | 租户内或跨租户 |
| 策略冲突 | 部分流量通过、部分被拦截，行为不一致 | 多条策略规则叠加、优先级歧义 | 单个租户或共享命名空间 |
| 命名空间泄漏 | 非预期 Pod 可访问受保护服务 | namespaceSelector 范围过大、缺少隔离策略 | 跨租户安全边界 |
| CNI 插件异常 | 所有 Pod 网络不通、策略不生效、节点报错 | CNI 组件故障、配置错误、内核模块缺失 | 集群全局或节点级 |
关键认知： 四种故障并非完全独立。例如 CNI 异常可能导致所有策略失效，进而表现为连通性故障；策略冲突也可能被误判为命名空间泄漏。排查时应从底层（CNI）向顶层（策略规则）逐层验证。
4.2 连通性故障
连通性故障是最常见的表象，通常由以下三类原因引发：
- 策略规则缺失： 未定义允许 ingress/egress 规则，默认 deny 生效。
- 标签选择器不匹配： podSelector 或 namespaceSelector 的标签键值对与目标 Pod/命名空间实际标签不一致。
- 端口/协议错误： 策略中指定的 port 或 protocol 与目标服务实际监听端口不匹配。
排查建议： 使用
kubectl run netshoot --image=nicolaka/netshoot -it --rm 启动诊断 Pod，通过 curl、nc、tcpdump 逐跳验证连通性。同时检查 kubectl describe networkpolicy 确认规则是否匹配目标 Pod。
4.3 策略冲突
当同一命名空间或跨命名空间存在多条 NetworkPolicy 时，规则叠加可能导致非预期的允许或拒绝。Kubernetes 的策略模型为“白名单叠加”——所有生效的 ingress/egress 规则取并集，但不同策略间的规则可能相互矛盾。
常见冲突场景：
- 默认拒绝 + 部分允许： 一条策略拒绝所有入站，另一条策略允许特定来源，实际行为取决于规则顺序和选择器范围。
- 跨命名空间策略重叠： 租户 A 的命名空间策略允许来自租户 B 的流量，但租户 B 的命名空间策略拒绝出站到租户 A，导致单向连通。
- 端口级冲突： 一条策略允许 TCP 80，另一条策略拒绝所有端口，最终结果取决于策略的生效顺序（Kubernetes 中策略无优先级，所有匹配策略均生效）。
避坑提示： Kubernetes NetworkPolicy 没有“优先级”或“权重”概念。所有匹配目标 Pod 的策略规则都会生效，且规则之间是“或”关系。不要试图通过策略顺序控制流量，应确保每条策略的规则集合是精确且无歧义的。
4.4 命名空间泄漏
命名空间泄漏指流量跨越了预期的租户边界，导致非授权访问。根本原因通常是 namespaceSelector 使用不当：
- 空选择器：
namespaceSelector: {}匹配所有命名空间，极易造成泄漏。 - 标签范围过大： 使用通用标签（如
env: production）作为选择器，可能意外匹配到其他租户的命名空间。 - 缺少出站限制： 仅限制入站而不限制出站，Pod 仍可主动访问其他命名空间的服务。
最佳实践： 为每个租户命名空间打上唯一标签（如
tenant: alpha），并在策略中精确使用 namespaceSelector: matchLabels: {tenant: alpha}。同时为每个命名空间配置默认拒绝出站策略，防止数据外泄。
4.5 CNI 插件异常
CNI 插件是网络策略的底层执行者。如果 CNI 组件异常，所有 NetworkPolicy 规则都将失效。常见异常包括：
| 异常类型 | 典型症状 | 排查方向 |
|---|---|---|
| DaemonSet Pod 异常 | calico-node / cilium-agent 等 Pod 处于 CrashLoopBackOff | 检查日志、资源限制、节点内核版本 |
| CNI 配置丢失 | 节点上 /etc/cni/net.d/ 目录为空或配置错误 | 检查 kubelet 配置、CNI 安装脚本 |
| 内核模块缺失 | iptables 规则未写入、eBPF 程序加载失败 | 检查内核版本、模块加载状态 |
| 数据平面故障 | Pod 间 ping 通但策略不生效 | 检查 Felix/Cilium agent 状态、策略同步日志 |
快速验证： 在 CNI 异常时，即使删除所有 NetworkPolicy，Pod 间仍可能无法通信。反之，如果删除策略后 Pod 恢复正常通信，则问题大概率在策略层而非 CNI 层。
4.6 故障类型关系图
下图展示了四种故障类型之间的依赖与转化关系，帮助运维人员在排查时建立全局视角：
排查原则： 始终从基础设施层（CNI）开始验证，确认底层网络正常后再逐层向上排查策略规则。避免在 CNI 异常时盲目调整 NetworkPolicy 规则，那样只会增加排查复杂度。