Kubernetes官方NetworkPolicy示例是否有误？按其编写策略未生效

问题 #

我参考Kubernetes的NetworkPolicy文档编写了一条Egress策略，用于KillerCoda的"NetworkPolicy Namespace Selector"场景，初始配置如下：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: space1
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: space2
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

策略创建成功后，执行测试命令：

k -n space1 exec app1-0 -- curl -m 1 microservice1.space2.svc.cluster.local

测试失败，发现DNS出站端口配置未生效。查看KillerCoda提供的正确示例后，将ports:改为- ports:并与- to:对齐，调整后的策略如下：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np
  namespace: space1
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
     - namespaceSelector:
        matchLabels:
         kubernetes.io/metadata.name: space2
  - ports:
    - port: 53
      protocol: TCP
    - port: 53
      protocol: UDP

调整后测试成功。我疑惑为什么Kubernetes官方文档的示例没有采用- ports:这种格式，想问官方的示例是不是有错误？

解答 #

这两种格式都符合Kubernetes NetworkPolicy的语法规范，不存在谁对谁错，只是作用逻辑完全不同：

• 初始配置的逻辑
  最初的格式里，ports嵌套在同一条egress规则下，含义是：仅允许访问space2命名空间中53端口的TCP/UDP流量。但测试命令访问的是业务服务端口（比如常见的80/8080），这条规则并未允许该端口的流量，因此测试失败。

• 调整后配置的逻辑
  调整后的格式将to和ports拆分为两条独立的egress规则：

  1. 第一条规则：允许访问space2命名空间的所有端口流量
  2. 第二条规则：允许访问任意目标的53端口TCP/UDP流量（满足DNS解析需求）
     两种流量都被允许后，DNS解析正常完成，业务服务访问也能通过，测试自然成功。

• 官方文档示例的合理性
  官方文档的示例是正确的，它针对的是限定特定目标+特定端口的场景。比如如果需求是"仅允许向space2的DNS服务发起请求"，那初始配置就是完全正确的。而你在KillerCoda的场景中，实际需要同时允许DNS解析和业务服务访问，因此需要拆分两条独立规则。

内容的提问来源于stack exchange，提问作者Jicaar