Kubernetes网络策略怎么用，是很多团队在做集群安全和服务隔离时都会遇到的问题。因为在不少默认网络环境里，Pod 与 Pod 之间、命名空间与命名空间之间的访问往往比想象中更开放。如果没有显式的网络访问控制，一个被入侵的工作负载就可能在集群内部横向扩散。NetworkPolicy 的价值，正是把这些原本隐性的访问关系，变成可声明、可治理、可审计的网络策略。
写在前面
- 本文适用范围： 适合正在建设 Kubernetes 集群安全、推进命名空间隔离，或想掌握 NetworkPolicy 基本用法的团队。
- 本文前置知识： 需要了解 Pod、Namespace、Service、标签选择器和基础 Kubernetes 网络概念。
- 本文评估口径： 本文重点讨论企业落地中的策略思路和使用方法，不比较具体 CNI 产品参数。
很多团队第一次接触 NetworkPolicy，会把它理解成“给 Kubernetes 加一个防火墙”。这个理解不算错，但还不够准确。更本质地说，NetworkPolicy 是 Kubernetes 里用来表达“谁能访问谁、通过什么端口访问、从哪里访问”的声明式访问控制方式。
先说结论：NetworkPolicy 不是为了全部封死，而是让访问关系显式化
如果只先记住一句话，可以直接记这句：Kubernetes 网络策略的核心，不是让所有 Pod 都不能通信，而是让每一条允许的访问路径都有明确依据。
这意味着 NetworkPolicy 的目标不是“越严越好”，而是：
- 哪些服务真的需要互相访问
- 哪些命名空间应该彼此隔离
- 哪些端口应该被限制
- 哪些出站访问根本不应该存在
换句话说，NetworkPolicy 的价值在于把“默认模糊开放”变成“按需放行”。
Kubernetes 网络策略到底是什么
Kubernetes 网络策略通常指 NetworkPolicy 资源。它是一种声明式配置，用来约束 Pod 的网络流量，主要包括：
- Ingress：谁可以访问当前 Pod
- Egress：当前 Pod 可以访问谁
它常常围绕三类条件进行控制：
- Pod 标签
- Namespace 标签
- 端口和协议
因此你可以通过 NetworkPolicy 表达这样的规则：
- 只有网关 Pod 可以访问后端服务
- 只有应用服务可以访问数据库
- 某个命名空间不能主动访问外网
- 指定服务只能暴露某个端口给指定来源
为什么 Kubernetes 集群需要 NetworkPolicy
如果 Pod 默认都能彼此访问，通常会带来这些问题：
- 服务之间访问边界不清晰
- 测试服务可能误打生产依赖
- 被入侵的工作负载更容易横向移动
- 敏感组件缺少最小访问控制
- 审计时很难解释哪些访问本来就不应该存在
在微服务和多租户环境里，随着服务数量增长，这种“默认开放”的风险会越来越大。NetworkPolicy 的作用，就是让集群内部访问关系从隐式默认，变成显式治理。
使用 NetworkPolicy 前，先确认这个前提
这是最容易被忽略的一点：你的 CNI 网络插件必须支持 NetworkPolicy。
如果底层网络插件不支持，即使你创建了 NetworkPolicy 资源，也可能完全不会生效。所以在真正落地前，先确认这些问题：
- 当前 CNI 是否支持 NetworkPolicy
- 是否同时支持 Ingress 和 Egress 策略
- 不同环境是否使用了相同或行为一致的 CNI
- 平台侧是否已经有默认网络策略在生效
这一步非常关键。很多“策略写了但没效果”的问题，本质上都不是 YAML 写错，而是底层前提没有满足。
Kubernetes网络策略怎么用：先掌握这 4 个设计原则
1. 从关键服务开始，不要一上来全量封锁
如果团队第一次做 NetworkPolicy，就直接把所有命名空间全收紧，通常很容易误伤正常业务。更稳妥的方式，是先从数据库、消息队列、管理面、核心后端等关键服务开始。
2. 先梳理访问关系，再写策略
NetworkPolicy 不是凭感觉写的。真正有效的策略，前提是你知道：
- 哪些服务之间确实存在调用
- 哪些命名空间之间应该互通
- 哪些端口是必须暴露的
- 哪些出站访问没有业务必要
3. 标签规范比策略数量更重要
如果 Pod 和 Namespace 标签本身混乱，NetworkPolicy 也很难长期维护。标签体系越清晰，策略越容易表达。
4. Ingress 和 Egress 都要考虑
很多团队只做入站控制，却忽略了出站访问。如果一个被攻陷的 Pod 可以随意对外连接，风险仍然很大。真正完整的网络隔离通常要同时考虑入口和出口。
一个典型的 NetworkPolicy 示例
下面这个例子表示：只允许带有 role=gateway 标签的 Pod 访问带有 app=orders 标签的 Pod 的 8080 端口。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-gateway-to-orders
namespace: production
spec:
podSelector:
matchLabels:
app: orders
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: gateway
ports:
- protocol: TCP
port: 8080这个例子的重点不在 YAML 本身，而在策略思路：
- 先明确保护对象是谁
- 再明确允许的来源是谁
- 最后收敛到指定端口和协议
这比“谁都能访问，只靠应用层自己拦”更适合作为底层访问边界。
NetworkPolicy 和 API 鉴权、零信任是什么关系
很多团队会把这些概念混在一起，但它们关注的不是同一层：
- NetworkPolicy：网络层控制谁能连谁
- API 鉴权：应用层判断调用方有没有权限访问某个接口
- 零信任：更上层的访问控制理念，强调身份、上下文和持续验证
所以 NetworkPolicy 不是用来替代 API 鉴权的，也不是零信任的全部。但它可以成为零信任和 Kubernetes 安全落地中的一个重要基础能力，用来降低默认开放和横向移动风险。
企业落地时最容易踩的 5 个坑
1. 没确认 CNI 支持就开始写策略
这是最基础也最常见的问题。
2. 标签体系混乱，策略难维护
如果 Pod 标签没有统一规范，后面任何 NetworkPolicy 都会越来越难改。
3. 一次性收紧太多流量
没有渐进式验证时，业务很容易被误伤。
4. 只做 Ingress，不做 Egress
这样虽然限制了别人访问服务，但服务自己仍然可能随意向外通信。
5. 没有验证机制
写完策略并不代表真的生效。团队还需要验证：
- 业务访问是否按预期放通
- 非法访问是否确实被拒绝
- 是否影响现有健康检查和内部依赖
企业更稳妥的推进顺序是什么
如果你的团队刚开始做 Kubernetes 网络策略，更现实的顺序通常是：
- 先确认 CNI 插件支持情况
- 先梳理关键命名空间和关键服务访问关系
- 先给数据库、消息队列、管理面等敏感组件加 Ingress 限制
- 再逐步扩展到业务服务之间的访问控制
- 最后补 Egress 控制、审计和与安全体系的联动
这种方式比一开始就“全量默认拒绝”更稳，也更容易理解影响范围。
总结：Kubernetes 网络策略真正解决的是“访问边界不清”
回到 Kubernetes网络策略怎么用 这个问题，最核心的答案就是：先确认底层支持，再梳理访问关系，用 NetworkPolicy 把关键服务和命名空间之间的允许访问路径显式表达出来。
它的价值不在于把集群变成“谁都访问不了”，而在于让网络访问更可解释、更可治理、更符合最小权限原则。对企业来说，真正值得优先做的，也通常不是一次性全量封锁，而是先从高风险、高价值组件开始，小步推进网络隔离。
FAQ
创建了 NetworkPolicy，一定会生效吗？
不一定。前提是底层 CNI 插件支持 NetworkPolicy，否则资源创建成功也可能不真正限制流量。
NetworkPolicy 能替代 API 鉴权吗？
不能。NetworkPolicy 管的是网络层访问边界，API 鉴权管的是应用层身份和权限，两者应该配合使用。
Kubernetes 网络策略要一开始就全量启用吗？
通常不建议。更稳妥的方式是先保护关键服务和关键命名空间，再逐步扩大范围。
只做 Ingress 控制够吗？
很多时候不够。为了降低异常外联和横向移动风险，Egress 控制也很重要。
转载请注明出处：https://www.cloudnative-tech.com/p/6528/