AWS Load Balancer Controller与Nginx Ingress Controller共存问题解析

在Kubernetes集群中同时部署AWS Load Balancer Controller和Nginx Ingress Controller时，可能会遇到服务状态异常的问题。本文将从技术原理和解决方案两个维度，深入分析这一典型部署场景下的常见问题。

问题现象

当在已部署AWS Load Balancer Controller的集群中安装Nginx Ingress Controller时，Ingress-Nginx的LoadBalancer类型服务会持续处于Pending状态。系统日志中可能出现如下关键错误信息：

Failed build model due to unable to resolve at least one subnet (0 match VPC and tags: [kubernetes.io/role/internal-elb])

根本原因分析

这个问题源于两个控制器对LoadBalancer类型服务的处理机制冲突：

1. AWS Load Balancer Controller的Webhook机制：默认情况下会拦截并处理所有LoadBalancer类型的Service资源
2. Nginx Ingress的负载均衡需求：需要创建独立的AWS负载均衡器资源

当两个控制器同时工作时，AWS Load Balancer Controller会尝试接管Nginx Ingress创建的Service资源，但由于子网标签等配置不匹配，导致资源创建失败。

解决方案

通过调整AWS Load Balancer Controller的配置参数可以解决此问题：

# 在Helm values中配置
enableServiceMutatorWebhook: false

这个配置会禁用AWS Load Balancer Controller对Service资源的修改能力，允许Nginx Ingress Controller独立管理自己的负载均衡器资源。

配置建议

对于需要在同一集群中部署多个入口控制器的场景，建议采用以下最佳实践：

1. 明确职责划分：

   • AWS Load Balancer Controller：管理应用层Ingress资源
   • Nginx Ingress Controller：处理需要特殊功能的流量路由

2. 资源隔离：

   • 为不同控制器创建独立的Namespace
   • 使用Annotations明确指定负载均衡器类型

3. 子网标签管理：

   • 确保至少有一个子网具有kubernetes.io/role/elb标签
   • 内部负载均衡器需要kubernetes.io/role/internal-elb标签

深入理解

从Kubernetes的扩展机制来看，这个问题涉及到Admission Controller的工作流程。AWS Load Balancer Controller通过Mutating Webhook拦截Service资源的创建/更新操作，当检测到LoadBalancer类型时就会尝试接管。

通过禁用Service Mutator Webhook，我们实际上是在告诉Kubernetes："对于Service资源，不要调用AWS Load Balancer Controller的修改逻辑"，从而让Nginx Ingress Controller能够按照自己的方式创建负载均衡器。

总结

在复杂的Kubernetes生产环境中，多个入口控制器共存是常见需求。理解各组件间的交互机制，合理配置控制器行为，是保证系统稳定运行的关键。本文描述的问题和解决方案不仅适用于AWS环境，其背后的设计思路也可以推广到其他云服务提供商的类似场景中。