AWS负载均衡控制器中ALB规则优先级管理的优化实践

在Kubernetes环境中使用AWS负载均衡控制器（AWS Load Balancer Controller）管理ALB时，我们遇到一个典型的生产环境问题：当通过Ingress Controller管理多个服务的ALB规则时，删除某个旧版本服务会导致其他服务短暂返回404错误。这种现象在EKS集群中尤为明显，特别是在使用Ingress Group管理多个唯一FQDN服务的情况下。

问题现象与背景 当部署新版本服务并与旧版本并行运行后删除旧版本时，ALB会在几秒内对某些随机服务返回固定的404响应。所有ALB变更都通过Ingress Controller完成，不存在手动操作。核心问题出现在规则优先级管理机制上。

根本原因分析 经过AWS ALB服务团队深入排查，发现问题源于竞态条件。具体场景如下：

1. 当集群运行30个服务时，每个服务都有唯一的FQDN，通过单个ALB监听器的30条规则（每条规则对应一个服务）进行管理
2. 新版本服务（如service-a-v2.xyz.com）与旧版本（service-a-v1.xyz.com）并行运行，旧版本规则优先级为3
3. 删除旧版本时，Ingress Controller会：
   • 先发送DeleteRule API删除旧规则
   • 然后隐式发送27个ModifyRule API请求，试图将剩余规则优先级保持连续（1-29）

ALB服务端的实现特性加剧了这个问题：

• 变更以批处理方式执行
• 首个API请求后会等待10秒收集后续变更
• 这导致部分ModifyRule请求可能被延迟处理，造成短暂时间内某些规则"丢失"

解决方案演进 AWS负载均衡控制器团队在v2.12.0版本中引入了重要改进：

• 使用SetRulePriorities API替代原有的多ModifyRule API调用方式
• 优化规则优先级调整逻辑，避免大规模连锁修改
• 减少ALB数据平面更新时的窗口期风险

生产环境建议 对于使用较早版本控制器的用户，建议：

1. 尽快升级至v2.12.0或更高版本
2. 在测试环境验证规则删除场景下的行为
3. 监控ALB的HTTPCode_ELB_4XX_Count指标
4. 考虑使用alb.ingress.kubernetes.io/group.order注解时注意其相对优先级特性

这个案例典型地展示了Kubernetes控制器与云服务API交互时可能出现的边缘情况，也体现了开源社区与云服务提供商协作解决问题的价值。通过这次优化，AWS负载均衡控制器在ALB规则管理方面变得更加健壮，为生产环境提供了更高的稳定性保障。