Kubernetes NetworkPolicy引发请求延迟的原因及优化咨询

延迟产生的核心原因 #

1. 认证请求的目标未被纳入出站允许规则
   你的NetworkPolicy仅明确允许了6类出站流量，而Kubernetes NetworkPolicy默认会拒绝所有未被显式允许的流量。如果API认证请求需要访问的服务（比如身份认证服务器、密钥服务等）不在这6条规则覆盖范围内，Pod发起的认证连接会被持续阻塞，直到TCP连接超时，这就是2.5分钟延迟的直接原因——未应用策略时集群默认允许所有出站流量，请求能快速完成。

2. Pod选择器配置存在疏漏
   当前策略的podSelector.matchLabels.app字段为空，这会导致两种问题：一是可能意外将策略应用到集群中所有没有app标签的Pod，扩大了规则影响范围；二是如果目标应用Pod的app标签有值，这条策略根本不会生效到你的应用Pod上，反而可能引发其他流量异常（结合你的现象，更可能是认证流量被拦截）。

优化方案 #

1. 定位并补充认证请求的出站规则 #

• 先通过应用日志或在Pod内执行tcpdump抓包，明确认证请求需要访问的目标IP/域名、端口、协议。
• 根据目标类型添加对应规则：
  • 如果是集群内Pod，补充podSelector规则：

    - ports:
        - protocol: TCP
          port: <认证服务端口>
      to:
        - podSelector:
            matchLabels:
              <认证服务的标签键>: <标签值>
    

  • 如果是外部IP，补充ipBlock规则：

    - ports:
        - protocol: TCP
          port: <认证服务端口>
      to:
        - ipBlock:
            cidr: <认证服务IP/掩码>
    

2. 修正Pod选择器配置 #

给podSelector.matchLabels.app补充正确的标签值，确保策略仅应用到你的目标应用Pod上，比如：

podSelector:
  matchLabels:
    app: api-service # 替换为你的应用Pod实际的app标签值

3. 优化规则结构，减少匹配开销 #

将同类型的规则合并，降低网络插件的规则匹配压力。比如多个访问同一IP段的端口可以合并：

- ports:
    - protocol: TCP
      port: 3306
    - protocol: TCP
      port: 443
  to:
    - ipBlock:
        cidr: 10.100.100.0/24 # 若目标IP在同一网段

4. 快速验证问题根源 #

可以临时添加一条允许所有出站流量的规则，验证是否是策略拦截导致的延迟：

- ports:
    - protocol: TCP
      port: 0
      endPort: 65535
  to:
    - ipBlock:
        cidr: 0.0.0.0/0

如果添加后延迟消失，即可确认是缺少对应出站规则的问题，再逐步缩小范围添加必要规则即可。

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