GKE Autopilot集群中Ingress后端显示不健康的问题排查求助

您好，我来帮您一步步排查这个GKE Autopilot环境下Ingress后端不健康的问题——毕竟直接用LoadBalancer服务正常，换成NodePort+Ingress就出问题，大概率是健康检查或者Autopilot的集群限制导致的，咱们挨个来确认：

1. 优先检查Pod的就绪/存活探针配置 #

GKE Autopilot对Pod的健康状态要求很严格，尤其是Ingress关联的场景：ALB的后端健康检查会直接关联Pod的readinessProbe（就绪探针）配置。如果你的Deployment里没定义就绪探针，GKE会自动生成一个默认的健康检查，但默认检查的可能是80端口（而你的应用用的是8000），或者默认路径/返回的不是200 OK，这就会导致后端被判定为不健康。

建议给Deployment加上符合你应用情况的就绪探针，比如：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: o-famil-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: o-famil
  template:
    metadata:
      labels:
        app: o-famil
    spec:
      containers:
      - name: o-famil-container
        image: 你的应用镜像
        ports:
        - containerPort: 8000
        # 添加就绪探针
        readinessProbe:
          httpGet:
            path: /healthz  # 替换成你的应用实际的健康检查路径，比如根路径"/"（如果返回200的话）
            port: 8000
          initialDelaySeconds: 5  # 应用启动后等待5秒再开始检查
          periodSeconds: 10  # 每10秒检查一次
        # 可选：加上存活探针，确保Pod异常时被重启
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8000
          initialDelaySeconds: 15
          periodSeconds: 20

更新Deployment后，再观察Pod的Ready状态是否为True，之后看Ingress后端的健康状态是否恢复。

2. 验证NodePort服务的可达性 #

虽然LoadBalancer服务正常，但NodePort在Autopilot集群中，需要确认ALB的健康检查流量能正常访问到NodePort：

• 先用kubectl describe service ofamily-service-np查看服务的NodePort端口（比如30XXX）
• 用集群内的临时Pod测试访问：

kubectl run -it --rm test-pod --image=curlimages/curl -- curl <集群节点IP>:<NodePort>

如果能正常返回应用内容，说明服务本身没问题；如果访问失败，检查Pod的网络策略（Autopilot默认是否有拦截？）或者应用是否绑定了错误的IP（比如只绑定了localhost，导致集群内无法访问）。

3. 自定义Ingress的健康检查配置 #

如果你的应用在/路径下不返回200 OK，或者需要特定的健康检查路径，光靠Pod的探针还不够，需要给Ingress配置自定义的BackendConfig来覆盖默认健康检查：

首先创建BackendConfig资源：

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: o-family-backend-config
spec:
  healthCheck:
    checkIntervalSec: 10
    port: 8000
    type: HTTP
    requestPath: /healthz  # 替换成你的应用健康检查路径

然后更新Ingress的annotations，关联这个BackendConfig：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: o-family-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
    networking.gke.io/managed-certificates: "duckdns"
    kubernetes.io/ingress.global-static-ip-name: "ingress"
    cloud.google.com/backend-config: '{"default": "o-family-backend-config"}'  # 添加这行
spec:
  rules:
  - host: ofamily.duckdns.org
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: ofamily-service-np
            port:
              number: 8000

应用更新后，GCP的ALB会使用你定义的健康检查规则，这样就能匹配你的应用需求了。

4. 检查Pod和Ingress的状态细节 #

• 查看Pod的日志和状态：kubectl logs <你的Pod名称> 确认应用是否正常启动，没有报错；kubectl describe pod <你的Pod名称> 看Pod的Conditions里Ready是否为True，有没有事件提示健康检查失败。
• 查看Ingress的状态：kubectl describe ingress o-family-ingress 看事件里有没有提示健康检查配置错误，或者端点更新失败的信息。

5. 确认ManagedCertificate的状态 #

虽然证书一般不直接影响后端健康，但如果证书还在Provisioning状态，Ingress的配置可能有延迟。用kubectl get managedcertificates duckdns查看状态，如果是Active就没问题；如果是其他状态，先解决证书的问题（比如域名解析是否正确，是否符合DuckDNS的要求）。

总结一下：最常见的原因是缺少就绪探针或者健康检查路径不匹配，因为Autopilot集群会严格依据Pod的就绪状态来更新Ingress的后端端点。先从探针配置入手，再验证服务可达性，应该就能解决问题了。

备注：内容来源于stack exchange，提问作者kubexplore