不健康NEG引发服务器错误页面的排查与解决方案咨询

我来帮你一步步拆解这个NEG（网络端点组）不健康的问题——虽然你已经开放了防火墙、GKE实例状态也正常，但我们可以从几个核心方向深挖根源：

1. 先确认健康检查的配置细节 #

GKE默认给NEG创建的健康检查，大概率和你的API /health 路径不匹配，这是最常见的诱因。你需要核对：

• 健康检查的路径是不是设置成了 /health（默认可能是 / 或者其他路径）
• 健康检查的端口是否和Pod暴露的端口一致（你的MCS里targetPort是4000，所以健康检查必须指向4000端口）
• 健康检查的协议是否正确（如果你的/health是HTTP接口，要确保用HTTP健康检查，别选成HTTPS或TCP）

你可以用这条命令查看当前健康检查的具体配置：

gcloud compute health-checks list --filter="name~terraback"

如果发现路径、端口不对，要么更新现有健康检查，要么直接在Ingress里自定义健康检查规则。

2. 验证MCS和Pod的关联是否正常 #

你的MCS配置里selector是app: terraback，请确认：

• 所有目标集群里的terraback Pod都带有app: terraback的标签
• Pod的containerPort确实是4000（和MCS的targetPort完全一致）

可以在每个集群里跑这两条命令验证：

# 查看Pod的标签和状态
kubectl get pods -n terraback -l app=terraback -o wide
# 查看Pod暴露的端口
kubectl describe pods <pod-name> -n terraback | grep Ports

3. 直接测试Pod内部的健康端点 #

绕开负载均衡，直接在Pod内部或者通过端口转发测试/health接口是否正常响应：

• 进入Pod内部测试：

kubectl exec -it <pod-name> -n terraback -- curl http://localhost:4000/health

• 如果Pod无法直接访问，用端口转发在本地测试：

kubectl port-forward <pod-name> 4000:4000 -n terraback
# 打开另一个终端执行
curl http://localhost:4000/health

如果这个请求返回非2xx状态码，那问题肯定出在Pod本身的服务上，赶紧看应用日志排查：

kubectl logs <pod-name> -n terraback

4. 查看NEG的后端端点状态 #

直接查看NEG的具体状态，确认哪些端点被标记为不健康：

gcloud compute network-endpoint-groups describe <neg-name> --zone <zone>

输出里会显示每个端点的状态，结合上面的测试结果，就能快速定位是Pod问题还是网络链路问题。

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

如果默认健康检查不符合你的需求，可以直接在MultiClusterIngress里添加自定义配置，示例如下：

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: terraback-ingress
  namespace: terraback
  labels:
    version: v1
spec:
  template:
    spec:
      backend:
        serviceName: terraback-mcs
        servicePort: 8080
      healthChecks:
      - path: /health
        port: 4000
        protocol: HTTP
        timeoutSec: 5
        intervalSec: 10
        healthyThreshold: 2
        unhealthyThreshold: 3

更新Ingress后，GKE会自动创建对应的健康检查并关联到NEG。

总结 #

优先确认Pod的/health端点是否正常响应，再检查健康检查配置是否匹配，最后验证MCS和Pod的标签关联——大部分NEG不健康的问题，都是健康检查不匹配或者Pod服务本身异常导致的。

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