故障隔离的核心是NetworkPolicy，默认拒绝策略为第一道闸门，需在命名空间初建时部署兜底拒绝规则；按故障域（前端/后端/数据）精准切分权限；利用命名空间标签与ipBlock实现跨域硬隔离；须通过手动测试、探测Pod和CI/CD检查持续验证防护效果。
故障隔离的核心是让问题止步于局部，不扩散。NetworkPolicy 是 Kubernetes 中实现这一目标最直接、最轻量的手段——它不依赖服务网格或外部防火墙，仅靠声明式规则就能切断异常流量路径，防止故障横向蔓延。
默认拒绝策略是故障隔离的第一道闸门
集群默认全通，意味着一个 Pod 故障后可能连带拖垮数据库、缓存甚至网关。必须在业务命名空间创建之初就部署一条“兜底拒绝”策略：
- 用 podSelector: {} 匹配该命名空间下所有 Pod
- 显式声明 policyTypes: [Ingress, Egress]
- 不写任何
ingress或egress规则，即默认阻断所有进出流量
这条策略不是摆设——它确保后续每一条放行规则都是明确授权的，没有遗漏就等于没有暴露面。
按故障域边界精准切分访问权限
把系统拆成逻辑上互不依赖的单元，每个单元只保留必要的通信链路。例如电商系统可划分为三个故障域：
-
前端域（frontend）：只允许来自
purpose=public命名空间的 80/443 流量，禁止直连后端 -
后端域（backend）：只接受来自
tier=frontend的 8080 请求，且只能访问app=db命名空间的 3306 端口 -
数据域（db）：拒绝所有入站流量，仅允许来自
tier=backend的出站连接（如健康检查探针）
这样即使前端被攻破，攻击者也无法扫描到数据库；后端某服务崩溃，也不会因错误重试风暴打爆 Redis。
利用命名空间标签做跨域通信控制
不同业务线或租户应分配独立命名空间，并打上区分标签（如 team=a、env=prod）。NetworkPolicy 可基于这些标签做硬隔离：
- 用 namespaceSelector 限制跨命名空间调用，比如只允许
team=finance访问支付服务 - 结合 ipBlock 封禁已知异常 IP 段（如某批异常出口 IP），快速遏制横向移动
- 对关键服务（如配置中心、证书签发器）设置单向只读策略，避免误操作或恶意写入
这种基于标签的控制方式比固定 IP 更稳定，也更容易随环境迁移和扩缩容。
验证与持续防护不能只靠一次配置
策略生效后必须验证实际效果，否则等于没设防：
- 用
kubectl exec -it <test-pod> -- nc -zv <target-pod-ip> <port>手动测试连通性 - 部署专用探测 Pod，定期发起跨命名空间 ping 和端口探测，失败时告警
- 在 CI/CD 流水线中加入 NetworkPolicy 合法性检查（如是否缺失默认拒绝、是否存在宽泛的
podSelector: {}放行）
网络策略不是上线前的一次性动作，而是随服务演进持续更新的安全契约。
