深入解析Antrea项目中K8s原生NetworkPolicy的端口与IP块限制问题

在Kubernetes网络策略的实际应用中，Antrea作为CNI插件对原生NetworkPolicy的实现存在一些需要特别注意的行为细节。本文将通过一个典型场景，剖析策略规则定义方式对流量控制的影响。

问题现象还原

用户遇到一个看似矛盾的策略行为：当采用以下两种不同语法结构的NetworkPolicy时，对443端口的访问控制产生了截然不同的结果：

策略定义A（失效案例）

ingress:
  - from:
      - ipBlock:
          cidr: 0.0.0.0/0
    ports:
      - port: 443
      - port: 30000

策略定义B（有效案例）

ingress:
  - ports:
      - port: 443
      - port: 30000
  - from:
      - ipBlock:
          cidr: 0.0.0.0/0

技术原理剖析

规则语法结构差异

这两种写法在Kubernetes NetworkPolicy规范中具有本质区别：

1. 定义A是单一规则，要求同时满足：

   • 源IP属于0.0.0.0/0网段
   • 目标端口为443或30000

2. 定义B实际上是两条独立规则：

   • 第一条：允许任意源IP访问443/30000端口（无from限制）
   • 第二条：允许0.0.0.0/0网段访问所有端口（无ports限制）

实际应用场景分析

在用户案例中，API Server通过Service访问webhook时：

1. Service代理机制：API Server实际访问的是Service ClusterIP，经过kube-proxy或IPVS转发后，最终请求的源IP是节点IP（hostNetwork场景）或CNI分配的IP

2. 策略匹配逻辑：

   • 定义A要求精确匹配源IP段+端口，而Service转发的流量源IP可能不符合预期
   • 定义B的第一条规则通过无限制的端口规则放行了关键流量

最佳实践建议

1. 明确策略边界：

   • NetworkPolicy仅作用于非hostNetwork Pod
   • 对Service的访问控制需考虑实际的endpoint Pod

2. 策略编写原则：

   # 推荐结构：分离端口控制与地址控制
   ingress:
     - ports:  # 端口白名单
         - port: 443
       from:   # 精细化的地址控制
         - podSelector: {}
         - ipBlock: 
             cidr: 10.0.0.0/8
   

3. 高级场景方案：

   • 对于需要控制Service流量的场景，可考虑Antrea原生策略
   • 节点级别访问控制需结合K8s原生机制或系统防火墙

总结

通过这个案例我们可以理解，Kubernetes NetworkPolicy的规则结构会直接影响策略效果。在实际生产环境中，建议采用"先明确端口范围，再细化地址控制"的策略编写方式，并充分理解底层网络流量路径，才能设计出符合预期的网络策略。