AWS EKS中readinessProbe失效与ALB Ingress配置优化咨询

背景说明 #

我们服务器采用AWS EKS与ALB Ingress架构，现有容器探针配置如下：

readinessProbe:
  failureThreshold: 3
  httpGet:
    path: /
    port: 3000
    scheme: HTTP
  initialDelaySeconds: 30
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 1
livenessProbe:
  httpGet:
    path: /
    port: 3000
    scheme: HTTP
  initialDelaySeconds: 45
  periodSeconds: 15

ALB Ingress配置：

kind: Ingress
metadata:
  name: alb-ingress
  namespace: prod
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS":443}]'
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: access_logs.s3.enabled=false

近期Pod因OOM被杀死后重启，我们原本预期Pod要等readinessProbe就绪（30秒初始延迟+10秒探测，共40秒）后才接收流量，但实际重启后立刻收到了流量。排查发现ALB目标组健康检查配置如下：

Port: Traffic port
Healthy threshold: 2 consecutive health check successes
Unhealthy threshold: 2 consecutive health check failures
Timeout: 5 seconds
Interval: 15 seconds

问题根源是目标组健康检查间隔15秒和livenessProbe的periodSeconds一致，要是Pod在15秒内完成重启，目标组没法检测到Pod故障，导致流量提前转发。试过缩短目标组检查间隔，但没法彻底解决问题，现咨询两个问题：

1. 如何正确配置AWS EKS与ALB Ingress中的readinessProbe？ #

readinessProbe的核心是判断Pod是否真的准备好接流量，针对当前问题，你可以从这几个方面调整：

• 优化健康检查逻辑：别只用根路径/做探测，改成专门的就绪检查接口（比如/health/readiness），在这个接口里校验依赖服务连接、核心进程初始化状态，确保返回200时Pod确实能处理请求。
• 调整成功阈值：把successThreshold从1改成2，确保Pod连续两次探测成功才标记为就绪，避免重启后临时就绪就接流量。
• 用Ingress注解同步配置：通过ALB Ingress的注解，让目标组健康检查自动复用readinessProbe的参数，避免两边配置不一致。给Ingress添加以下注解：

  alb.ingress.kubernetes.io/healthcheck-path: /health/readiness  # 和readinessProbe路径一致
  alb.ingress.kubernetes.io/healthcheck-port: "3000"             # 和readinessProbe端口一致
  alb.ingress.kubernetes.io/healthcheck-interval-seconds: "10"   # 和readinessProbe的periodSeconds一致
  alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "1"     # 和readinessProbe的timeoutSeconds一致
  alb.ingress.kubernetes.io/success-threshold-count: "2"         # 和调整后的successThreshold一致
  alb.ingress.kubernetes.io/failure-threshold-count: "3"         # 和readinessProbe的failureThreshold一致
  

• 按需延长初始延迟：如果Pod初始化需要更长时间，比如依赖加载慢，就把initialDelaySeconds调大，确保Pod完成所有准备工作后才开始探测。

2. ALB目标组健康检查与容器探针匹配的最佳实践 #

核心思路：各司其职，协同联动 #

• readinessProbe和ALB目标组健康检查完全对齐：
  两者都是判断Pod是否能接流量，所以路径、端口、检查间隔、成功/失败阈值必须一致。用Ingress注解自动同步是最优方式，不用手动维护两份配置，避免人为失误。
• livenessProbe独立于流量转发逻辑：
  livenessProbe是检测Pod是否存活，失败了就重启Pod，不用和ALB目标组对齐。它的检查间隔可以比readinessProbe稍长（比如当前的15秒），因为关注的是Pod长期存活状态，不是短期就绪。
• 合理配置阈值：
  • 成功阈值（successThreshold）设为2-3，确保Pod稳定就绪后再放流量进来，避免重启后偶发的就绪状态导致问题。
  • 失败阈值（failureThreshold）设为3-5，防止网络抖动或短暂资源不足导致误判Pod不可用。
• 应对快速重启场景：
  要解决Pod快速重启后目标组没检测到故障的问题，除了对齐配置，还可以：
  1. 把readinessProbe的initialDelaySeconds设到足够长，保证Pod完成所有初始化（比如缓存预热、数据库连接）后才通过探测。
  2. 把ALB目标组的Unhealthy threshold改成1，一次检查失败就标记为不健康，缩短故障检测时间。但要注意，这可能会因短暂网络问题误判，得结合业务场景权衡。
  3. 用Kubernetes的初始化容器（initContainer），先完成依赖准备工作，再启动业务容器，确保readinessProbe探测时Pod已经完全就绪。
• 拒绝默认配置：
  别依赖ALB或Kubernetes的默认健康检查参数，根据自己Pod的实际情况（初始化时间、资源消耗、依赖服务）定制配置。

内容的提问来源于stack exchange，提问作者zangw