AWS Load Balancer Controller与Nginx Fabric Gateway API集成实践：NLB实例模式下的健康检查问题解析

背景概述

在Kubernetes环境中，AWS Load Balancer Controller（ALBC）与Nginx Fabric Gateway API的集成是构建云原生应用架构的常见组合。当采用Network Load Balancer（NLB）实例模式时，运维人员常会遇到目标组健康检查异常的问题，这直接影响了服务的高可用性。本文将深入分析该问题的技术本质，并提供经过验证的解决方案。

核心问题分析

在标准部署场景中，当Nginx Fabric Gateway以后端服务形式运行时，ALBC会创建包含所有工作节点EC2实例的NLB目标组。健康检查默认配置为HTTP协议，通过/healthz路径在动态端口（如30632）进行探测。此时会出现以下典型现象：

1. 非均匀健康状态：只有运行Nginx Pod的节点显示健康状态
2. IP访问差异：节点通过私有IP自检成功，但跨节点访问时仅部分IP可达
3. kube-proxy监听：所有节点上kube-proxy都在健康检查端口建立监听

根本原因在于Nginx Fabric默认设置service.externalTrafficPolicy=Local以保持客户端源IP，这导致：

• 健康检查请求不会被路由到非Nginx Pod所在节点
• 节点多IP环境下，只有主网络接口IP（eth0）能正常响应

解决方案对比

方案一：采用Cluster外部流量策略

配置方法：

spec:
  externalTrafficPolicy: Cluster

优势：

• 简化架构，所有节点均可转发流量
• 健康检查自动转为TCP层探测 局限：
• 丢失客户端真实源IP信息
• 不适合需要IP白名单等安全场景

方案二：保持Local策略并优化目标组

实施要点：

1. 启用NLB IP模式：

annotations:
  service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip

2. 确保Nginx Pod反亲和性调度，避免单点故障 技术效果：

• 目标组仅注册Nginx Pod IP
• 保持源IP完整性
• 健康检查精准定位实际服务端点

架构选型建议

对于混合云环境（如EKS与Proxmox共存），建议采用分层解耦设计：

1. 基础设施层：使用NLB/IP模式提供L4负载均衡
2. 业务路由层：通过Nginx Fabric实现高级路由策略
3. 安全控制层：在Ingress Gateway实施WAF等安全措施

运维实践提示

1. 监控指标应同时关注：
   • NLB目标组的健康检查成功率
   • Nginx Pod的分布均衡性
   • 客户端源IP的日志完整性
2. 在集群扩容时，注意验证新节点的网络策略是否允许健康检查流量
3. 对于生产环境，建议通过PodDisruptionBudget确保Nginx Pod的最小可用数量

总结

通过理解Kubernetes服务流量策略与AWS负载均衡器的交互机制，我们可以根据业务需求选择最优的架构方案。对于需要精确流量控制的场景，NLB IP模式配合Nginx Fabric的Local策略提供了理想的技术组合，既保证了功能完整性，又维持了系统的高可用性特征。