Kubernetes Ingress-Nginx 与 Cloudflare 521 错误问题深度解析

问题背景

在 Kubernetes 生产环境中，使用 AWS EKS 集群配合 Nginx Ingress Controller 和 CDN 服务是一种常见架构。然而，当 Ingress-Nginx Pod 进行滚动更新或重启时，即使集群中有多个副本运行，CDN 仍可能间歇性返回 521 错误（Origin Web Server Down），这给业务连续性带来了挑战。

问题本质分析

521 错误表明 CDN 无法连接到源站服务器。在技术实现层面，这反映了以下关键点：

1. 连接生命周期管理：当 Ingress-Nginx Pod 进入终止状态时，Kubernetes 会立即从 Service 的 Endpoints 列表中移除该 Pod，但 AWS NLB 的目标组健康检查机制存在延迟

2. 多层超时配置不匹配：CDN、NLB 和 Ingress-Nginx 各自有不同的超时设置，缺乏协调会导致连接中断

3. 优雅终止处理不足：默认配置下，Ingress-Nginx 会等待现有连接完成，但如果没有活动连接则会立即终止，而 NLB 可能需要更长时间来更新目标状态

解决方案详解

1. 超时配置优化

关键原则是确保各层级的超时时间从外到内（CDN → NLB → Ingress-Nginx）递减：

• CDN：默认超时时间为 100 秒
• AWS NLB：调整健康检查间隔和超时设置
• Ingress-Nginx：通过配置增加 worker-shutdown-timeout

2. NLB 目标类型调整

将 NLB 的目标类型从 "instance" 模式改为 "ip" 模式：

• Instance 模式：NLB 通过节点端口路由流量，无法感知 Pod 级别的状态变化
• IP 模式：NLB 直接监控 Pod IP，能够更快检测到 Pod 终止状态

3. 优雅终止增强

在 Ingress-Nginx 的 Pod 模板中添加 preStop 钩子：

lifecycle:
  preStop:
    exec:
      command: ["sleep", "60"]

这会在 Pod 收到终止信号后等待 60 秒，确保：

1. NLB 有足够时间更新目标组状态
2. 现有连接能够正常完成
3. CDN 可以平滑切换到其他健康的 Pod

配置示例

以下是经过优化的 Ingress-Nginx 配置片段：

controller:
  config:
    worker-shutdown-timeout: 240s
  pod:
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "60"]

最佳实践建议

1. 监控与告警：设置针对 521 错误的监控，特别是部署和更新期间
2. 测试验证：在预发布环境中模拟 Pod 中断场景，验证配置效果
3. 版本管理：保持 Ingress-Nginx 和 Kubernetes 版本更新，获取最新的优雅终止改进
4. 容量规划：确保有足够的 Ingress-Nginx 副本（至少 2 个），避免单点故障

总结

通过理解 Kubernetes 生命周期管理、NLB 运行机制和 CDN 行为特征的交互关系，我们能够有效解决 Ingress-Nginx 滚动更新期间的 521 错误问题。关键在于协调各层级的超时设置、优化负载均衡器的目标检测机制，以及增强 Pod 的优雅终止能力。这些优化措施共同确保了服务的高可用性和平滑的部署体验。