NetworkPolicy 隔离：AI 平台默认不该所有服务互通
一、默认互通在 AI 平台里风险很高
很多 Kubernetes 集群默认 Pod 之间可以互相访问。对简单系统，这能减少配置成本；对 AI 平台，这个默认很危险。模型服务、向量库、对象存储代理、控制面和业务网关都有不同权限。如果所有服务互通，一次应用漏洞就可能横向移动。
NetworkPolicy 的目标不是制造复杂网络，而是建立最小访问边界。谁能访问模型服务，模型服务能访问哪些下游，都应该显式声明。默认拒绝，再按需要放行。
二、先按命名空间和角色定义通信矩阵
不要一上来写 YAML。先画出通信矩阵：入口网关到推理服务，推理服务到缓存和对象存储，控制器到 API Server 和模型仓库。矩阵清楚后，再转成策略。
flowchart TD A[Ingress Gateway] --> B[Inference Service] B --> C[Vector DB] B --> D[Object Storage Proxy] E[Platform Controller] --> B F[Batch Worker] --> B G[Unknown Pod] -.阻断.-> B这张图里的虚线同样重要。要明确哪些访问不应该发生。
三、用默认拒绝策略打底
下面示例给推理命名空间设置默认拒绝入站，再由后续策略放行指定来源。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: ai-inference spec: podSelector: {} policyTypes: - Ingress默认拒绝上线前要灰度验证。否则漏掉依赖会直接造成服务不可用。可以先在测试命名空间跑策略，再用流量回放确认。
四、网络隔离要和身份认证一起做
NetworkPolicy 只能控制网络路径，不能替代应用认证。允许访问模型服务的 Pod，仍然要携带合法身份和权限。网络层负责减少攻击面，应用层负责判断能做什么。
还要注意 DNS、监控和日志流量。默认拒绝后，服务可能无法访问 DNS 或指标采集器。策略中要明确放行必要系统组件。很多 NetworkPolicy 事故，不是业务链路错，而是基础依赖被挡住。
最后，策略需要审计。新增服务时必须更新通信矩阵，不能靠临时放开整个命名空间解决问题。临时放开最容易变成永久漏洞。
出站策略也不能忽略。模型服务通常需要访问对象存储、向量库或模型仓库，但不应该默认访问任意外网。可以把外部依赖收敛到代理服务，再让策略只放行代理地址。这样既方便审计，也能在外部服务异常时统一熔断。
排障时要准备策略命中检查。网络不可达时，先确认 DNS、Service、Endpoint，再看 NetworkPolicy。不要一上来删除策略验证问题。更好的方式是在临时测试 Pod 中使用相同标签复现访问路径，并把结果写回通信矩阵。
策略变更也需要发布流程。每次新增放行规则，都应说明业务原因、来源标签、目标端口和预计保留时间。临时调试规则要自动过期。网络策略如果只增不减，几个月后就会退化成另一种默认互通。
同时要把拒绝日志接入统一检索，否则策略生效后很难定位是谁被挡住。
五、总结
AI 平台的 NetworkPolicy 应以默认拒绝为起点，再按通信矩阵放行必要路径。网络隔离不能替代身份认证，但能显著降低横向移动风险。上线策略前要灰度验证 DNS、监控和业务依赖。基础设施要托底，第一步就是不要让所有服务默认互相信任。
