Kubernetes NetworkPolicy怎么落地，是K8s安全治理中经常被忽略的一环。很多集群完成了RBAC和镜像治理，却仍然允许Pod之间默认互通。一旦某个应用被攻破，攻击者可能通过东西向流量访问更多服务、数据库或内部接口。NetworkPolicy的价值，就是为命名空间和服务建立明确的网络边界。
这篇文章会把问题放在企业平台和生产环境中讨论，而不是只停留在单个命令或单项配置。你可以把它和Kubernetes安全、云原生网络、云原生安全配合阅读，先建立整体判断，再回到具体场景设计实施步骤。
本文适用范围
本文讨论Kubernetes集群内部东西向流量控制，重点是NetworkPolicy的落地方法。它不替代Ingress、API网关或服务网格，而是为Pod到Pod、命名空间到命名空间的访问建立基础边界。
先确认网络插件支持
NetworkPolicy是否生效取决于CNI插件。并不是所有网络插件都完整支持NetworkPolicy，落地前要确认当前集群使用的CNI能力、策略语义和可观测工具。否则策略写了也可能不生效。
从默认拒绝开始
建议先在关键命名空间启用默认拒绝策略，再逐步放行必要访问。默认允许模式看似省事，但很难发现多余访问。默认拒绝模式更安全，但需要充分梳理服务依赖。
按命名空间和标签设计策略
NetworkPolicy依赖Pod标签和Namespace标签选择目标。标签体系混乱会导致策略难以维护。建议统一环境、团队、应用和角色标签，避免策略绑定临时名称或不稳定字段。
东西向访问白名单
服务之间的访问应按最小需要放行，例如前端访问后端、后端访问数据库、监控组件访问指标端口。不要为了省事放开整个命名空间到整个命名空间的所有端口。
排障和观测
NetworkPolicy落地后，排障能力很重要。平台应能回答哪条策略阻断了流量、哪个Pod标签没有匹配、哪个端口未放行。否则业务团队遇到访问失败时会倾向于要求关闭策略。
常见问题
NetworkPolicy默认会生效吗？
不会。需要CNI插件支持，并且只有被策略选中的Pod才会受对应规则影响。
是否应该全局默认拒绝？
成熟团队可以逐步推进全局默认拒绝，但建议先从关键命名空间试点，避免一次性影响太大。
NetworkPolicy能控制外部访问吗？
它主要控制Pod网络流量，外部入口通常还需要Ingress、网关、防火墙或服务网格配合。
策略太多怎么维护？
需要统一标签规范、模板化策略和变更评审，并通过可观测工具辅助排障。
小结
Kubernetes NetworkPolicy怎么落地的关键，不是把某个功能单独做出来，而是把规则、流程、指标和复盘机制连接起来。对平台团队来说，先明确边界和目标，再逐步自动化，通常比一次性追求复杂能力更稳妥。后续也可以回到相关标签页继续查找更多文章，形成从概念、实践到选型的完整路径。
转载请注明出处：https://www.cloudnative-tech.com/p/8392/
