摘要

  • Kubernetes 将 NetworkPolicy 定义为针对被选中 Pod 的预期行为。入站和出站规则是累加的；一个 Pod 到另一个 Pod 的连接，需要源端出站与目的端入站都允许。
  • 文档同时划出边界：没有负责实现它的网络控制器时，资源没有效果；处理是最终发生的，API 不显示具体完成时间；对既有连接的影响由实现决定。
  • 若要对某一网络流作出可验证的表述，必须分别保留策略版本、选择器与端点状态、网络实现、带时间界限的连接观察，以及独立的身份或应用决策记录。

“默认拒绝”很容易让一份 YAML 看上去像已经实现的安全结果。它不是。NetworkPolicy 的价值在于声明性控制面：它可以让特定 Pod 在入站、出站或两个方向上进入隔离状态，并规定仍应允许的连接。这是关于预期网络边界的决策；它不是某个具体连接已经被拒绝、某个允许连接已经建立，或某个工作负载已经安全的证据。

资源模型首先限定了能说什么。NetworkPolicySpec 表示的是预期行为。策略选取 Pod，声明 Ingress 或 Egress 隔离，并给出规则。它们不是按顺序互相覆盖的拒绝项，而是累加的。一个 Pod 在某方向被隔离后，该方向允许的集合是所有适用策略所允许项目的并集。一个源 Pod 要连接目的 Pod，源端的出站与目的端的入站都必须允许。这条规则能解释策略集合，却不能提供某次连接真正观察到的源地址、目的地址、端口、协议、时刻、进程、报文路径或结果。

选择器状态本身是另一项事实。podSelector、namespaceSelector 或 ipBlock 不是永久的具体端点清单。标签会改变，Pod 会被替换，Service 的端点和路由机制也可能改变路径。Kubernetes 还提示，入站或出站机制常常重写源地址或目的地址；发生这种情况时，重写是在 NetworkPolicy 处理之前还是之后并没有被定义，行为可能随网络插件、云提供方、Service 实现或其组合而不同。因此，清单能够说明预期范围，却不能裁定某一条已观察报文在执行点到底以什么地址被处理。

实现层又是独立的证据面。Kubernetes 说明 NetworkPolicy 由网络插件实现；如果创建资源却没有实现它的控制器，资源没有效果，即使 API 依然存在。这不是对某种产品或管理员的指责，而是对证据范围的描述：被 API 服务器接受，只能证明控制面接受了对象，不能证明数据面组件具备能力、已经配置、保持健康并在该时刻实际生效。

时间使结论更窄。Kubernetes 写明，创建的 NetworkPolicy 最终会由网络插件处理，但 Kubernetes API 无法告诉人们究竟何时处理完成。文档也描述了 Pod 或策略变更期间可能存在略不一致的视图。若策略集合改变，既有连接会怎样受到影响，由具体实现定义。这些不是例外条款，而是不能要求一张配置快照讲述它没有保存的运行历史的原因。

协议范围也是边界的一部分。NetworkPolicy 针对四层 TCP、UDP 和在可选支持下的 SCTP 连接定义；其他协议的行为可随插件而变。看似完整的网络边界不能被改写成关于每种报文、每条 hostNetwork 路径、每个 service mesh、加密、工作负载身份、认证、DNS、应用授权或交付结果的通用结论。它们都是不同的控制面，需要各自的证据。

Daniel Kade 建议在重要场景中保留五部分网络流回执。第一部分是策略版本：命名空间、对象身份、generation 或不可变快照、选择器、方向、规则与观察时间。第二部分是选择器和端点状态：相关 Pod 与 Namespace 标签、IP 或 endpoint 映射及读取时刻。第三部分是网络实现：声明的 NetworkPolicy 能力、版本、相关配置与健康证据。第四部分是带时间界限的连接观察：按观察所得的源和目的、协议、端口、方向、结果、采集器和可见性限制。第五部分另存工作负载身份、授权、TLS、DNS、应用响应或部署的证据。敏感细节可以受到保护；把记录关联起来并不等于公开它们。

这种方法也能如实描述普通结果。策略可能正确，而独立的数据面故障仍使连接失败。两个方向都允许的流仍可能在 DNS、TLS、认证或应用层失败。策略可以先被 API 接受，之后才被某个插件真正执行。没有一种情况本身证明缺陷或事故。它们说明，单一清单不应独自承担一条网络流的全部历史。

来源

  1. Kubernetes — Network Policies
  2. Kubernetes — Services, Load Balancing, and Networking
  3. Kubernetes API 参考 — NetworkPolicy v1