Kubernetes 网络策略用选择器约束 Pod 之间的流量
说明 Pod 网络隔离、选择器、默认拒绝与服务路径,并分析插件实现、NAT、DNS 和持续验证。
Kubernetes 网络策略用选择器约束 Pod 之间的流量
Kubernetes 为 Pod 提供网络连通,但工作负载不应默认拥有访问集群内所有端点的权限。NetworkPolicy 用 Pod、命名空间和端口选择规则描述允许的入站与出站流量,让应用通信从隐含连通变成可审查契约。
网络策略不是防火墙产品的完整替代,也不会自动加密或认证流量。它能否生效取决于集群网络插件是否实现相关能力,策略对象创建成功不代表数据面一定执行。
隔离由策略选择与方向共同决定
策略通过 podSelector 选择当前命名空间中的 Pod,并声明 ingress、egress 或两种方向。当某个 Pod 在某方向被至少一条策略选择后,该方向进入隔离状态,只允许所有适用策略并集中的流量。策略之间通常是叠加允许,而不是按顺序覆盖。
入站连接同时要被目标 Pod 的入站规则允许,出站还要被源 Pod 的出站规则允许。只在一侧放行可能仍然不通。回复流量如何处理由实现和连接跟踪决定,不能把每个返回包都简单视为独立新连接。
Kubernetes 官方文档给出了 NetworkPolicy 的选择器和规则语义:https://kubernetes.io/docs/concepts/services-networking/network-policies/ 。应用规则前应绑定集群版本和网络插件文档,特别是 IPBlock、命名空间标签和协议支持。
默认拒绝要配合基础依赖逐步落地
建立最小权限常从命名空间默认拒绝入站和出站开始,但直接启用会中断 DNS、服务发现、监控、日志、证书和控制面依赖。应先盘点流量,按工作负载建立允许清单,在非生产环境和审计工具中验证。
DNS 是常见遗漏。工作负载通常需要访问集群 DNS 的 UDP 和 TCP 53 端口,具体目标命名空间与标签由发行版决定。外部 API 访问要考虑域名解析后 IP 变化;原生 NetworkPolicy 主要按选择器、端口和 CIDR 工作,不等同于域名级策略。
健康探针、节点来源流量和云负载均衡路径也可能因实现不同而表现不同。不能只依据应用间调用画规则,应从入口、节点、系统命名空间和运维通道共同测试。
选择器和 IP 范围表达不同身份
podSelector 表示一组动态工作负载,namespaceSelector 表示带标签的命名空间,两者组合可限定特定命名空间中的特定 Pod。YAML 缩进错误可能把组合关系写成并集,扩大访问范围。策略评审应检查解析后的对象,而不是只看视觉格式。
标签成为安全边界后,其写权限必须受控。若应用团队可以随意给命名空间加上“trusted”标签,选择器规则就失去意义。标签命名、所有权和准入策略要与网络策略一起治理。
ipBlock 适合表达集群外 CIDR,但服务地址转换发生在策略前还是后由实现决定。Pod IP、节点 IP 与外部源地址可能经过 NAT。对关键路径应抓取实际流量并参考插件行为,不能假设策略看到客户端原始地址。
服务抽象与网络策略不是同一层
Service 提供稳定虚拟地址并把流量转发到后端 EndpointSlice;NetworkPolicy 通常选择实际 Pod。Kubernetes 服务与网络概念文档说明了这些资源的角色:https://kubernetes.io/docs/concepts/services-networking/ 。允许访问 Service 的端口,不代表策略按 Service 名称识别,也不保证后端 Pod 端口与服务端口相同。
服务网格可以提供工作负载身份、加密和第七层授权,但不会自动替代网络层隔离。流量经过 sidecar 后,策略看到的源或端口可能变化。两层控制应明确顺序和责任,避免一层放行被误认为另一层已验证身份。
宿主网络 Pod、节点进程和特权工作负载可能超出普通 Pod 网络假设。高风险环境还需要节点防火墙、云安全组、入口网关和身份授权形成纵深防护。
验证要包含失败路径和持续漂移
测试应从真实源 Pod 发起到目标地址、端口和协议的连接,既验证允许路径,也验证预期拒绝。仅执行配置静态检查无法发现插件未启用、标签不匹配、NAT 路径和 DNS 问题。自动测试可在部署后运行短生命周期探针,并清理测试资源。
策略日志和流量观测要回答哪条规则允许或拒绝了连接,但并非所有插件提供相同可见性。至少要监控策略对象数量、无策略工作负载、新命名空间默认状态和关键连接失败。应用变更新增依赖时,应先更新通信契约,再发布工作负载。
紧急放行应限制命名空间、端口和时长,并留下原因。使用 0.0.0.0/0 或宽泛命名空间标签解决故障,会把临时恢复变成永久横向移动路径。
网络策略的核心价值是把允许通信写成可版本化、可测试的应用依赖。它需要网络插件、标签治理、流量观测和身份控制配合;只有 YAML 对象而没有数据面验证,不能视为隔离已经成立。
资料依据
- Kubernetes Project:Network Policies,https://kubernetes.io/docs/concepts/services-networking/network-policies/
- Kubernetes Project:Services, Load Balancing, and Networking,https://kubernetes.io/docs/concepts/services-networking/