GKE ingress-gce添加新规则后网络端点异常解绑问题排查求助

排查步骤 #

1. 检查核心资源的事件与状态 #

• 执行 kubectl describe ingress <你的Ingress名称>，重点看Events字段里的Sync相关记录，有没有报错、超时或状态异常提示
• 查看后端服务和端点状态：kubectl describe service <后端服务名称>、kubectl describe endpoints <后端服务名称>，找端点解绑动作的触发事件，是否有健康检查失败、资源冲突等标注
• 通过Cloud Logging过滤resource.type="http_load_balancer"，筛选jsonPayload.event_subtype包含backend_service的日志，定位GCE负载均衡器侧解绑操作的具体原因

2. 验证Ingress与后端配置合法性 #

• 确认新添加的主机/路径规则格式合规：GCE Ingress要求路径必须以/开头，且同一主机下不能有重复的路径匹配规则（优先级冲突会导致同步异常）
• 检查后端健康配置：执行kubectl describe pod <后端Pod名称>看就绪探针状态，或gcloud compute health-checks describe <关联的健康检查名称>，确认健康检查的端口、路径、超时参数是否和Pod的就绪探针匹配——第一次同步时健康检查未就绪可能导致端点被临时移除

3. 查看Ingress控制器日志 #

GKE的GCE Ingress控制器运行在kube-system命名空间，执行以下命令查看同步过程的细节：

kubectl logs -n kube-system -l app=glbc --tail=100

重点找同步Ingress配置时的错误日志，比如API调用超时、资源创建顺序问题等

为什么重复应用配置能解决问题？ #

大概率是第一次同步时出现了状态不一致：

• Ingress控制器向GCE API提交资源更新后，GCE侧的后端服务/健康检查还未完全就绪，控制器误判状态触发了解绑
• 重新应用配置时，控制器会触发全量同步，此时GCE侧的资源已经完成初始化，同步逻辑能正确绑定端点
• 部分旧版本GKE的Ingress控制器存在同步逻辑bug，重复应用会绕过首次同步的异常分支

建议解决方向 #

• 先确保后端Pod的就绪探针正常返回，健康检查状态为HEALTHY后，再更新Ingress配置
• 确认Ingress的kubernetes.io/ingress.class注解已正确设置为gce（避免和其他Ingress控制器冲突）
• 若集群版本较旧，考虑升级到GKE稳定版（1.24+），部分旧版本的同步逻辑bug已被修复

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