AWS ALB Ingress控制器中健康检查路径与302重定向问题的解决方案

在Kubernetes环境中使用AWS ALB Ingress控制器时，开发人员可能会遇到目标组健康检查失败的问题。典型场景是当应用程序对根路径"/"的访问返回302重定向响应时，ALB的健康检查机制会将其视为失败，导致目标组被标记为不健康状态。

问题本质分析

AWS ALB的健康检查默认期望收到200 OK的HTTP状态码。当应用程序设计为对未认证用户自动重定向到登录页面（例如返回302重定向到/login路径）时，这种设计会与ALB的默认健康检查行为产生冲突。特别是在前端应用场景中，这种认证重定向是非常常见的实现方式。

解决方案详解

方案一：扩展成功状态码范围

通过为Ingress或Service添加特定注解，可以配置ALB将302重定向响应也视为健康状态：

annotations:
  alb.ingress.kubernetes.io/success-codes: "200,302"

这种方法简单直接，但需要注意它会应用于该Ingress关联的所有目标组。如果只需要对特定服务生效，可以将注解直接添加到对应的Service资源上。

方案二：定制健康检查路径

更精确的解决方案是指定一个专用的健康检查端点：

annotations:
  alb.ingress.kubernetes.io/healthcheck-path: "/health"

应用需要实现这个/health端点，确保它：

1. 不进行任何重定向
2. 快速返回200状态码
3. 包含必要的应用健康状态检查逻辑

这种方法的最佳实践是让健康检查端点尽可能轻量级，避免执行复杂的业务逻辑检查，只验证应用的基础运行状态。

方案选型建议

对于新系统设计，推荐采用方案二的定制健康检查路径方式，因为：

1. 它提供了更精确的健康状态判断
2. 避免了将业务重定向逻辑与基础设施健康检查耦合
3. 可以针对不同服务设置不同的检查标准

对于现有系统的快速修复，方案一更为便捷，但需要注意它可能掩盖真正的服务异常情况。

实施注意事项

1. 在Kubernetes中，Ingress级别的注解会覆盖Service级别的注解
2. 健康检查配置变更后，需要等待ALB完成配置更新（通常需要1-2分钟）
3. 在生产环境变更前，建议先在测试环境验证配置效果
4. 监控系统需要相应调整，确保能正确捕获服务真实健康状态