GKE内部Ingress反复挂载卸载可用区NEG的原因、影响及规避方案

观测到的典型事件日志 #

kind: "Event"
message: "Attach 2 network endpoint(s) (NEG "k8s1-28f1xxx2-xxxxx-app-1443-e95eee64" in zone "us-east1-b")"

kind: "Event"
message: "Detach 6 network endpoint(s) (NEG "k8s1-28fxxx2-xxxxxx-app-1443-e95eee64" in zone "us-east1-b")"

一、NEG反复挂载/卸载的核心触发原因 #

• 后端Pod状态频繁波动：这是最常见的诱因。如果Ingress对应后端工作负载的Pod出现频繁重启、被驱逐、就绪探针偶发失败，或者滚动更新参数配置不合理（maxSurge/maxUnavailable设置过高，导致批量Pod同时被销毁重建），NEG控制器会实时同步端点列表，触发Attach/Detach操作。从日志中Detach 6个端点、仅Attach 2个端点的数量差来看，该场景的匹配度最高。
• 节点状态不稳定：如果集群节点频繁出现NotReady状态、节点自动扩缩容触发节点频繁上下线，节点上运行的所有Pod端点会被批量从NEG移除，新节点上调度启动的Pod就绪后又会被重新挂载到NEG。
• 控制器状态同步异常：GKE NEG控制器会周期性比对NEG实际端点和Kubernetes EndpointSlice的预期状态，如果控制器和GCP控制面API通信出现间歇性超时、权限临时异常，会出现状态判定不一致，触发反复的修正操作。
• 配置频繁变更：如果频繁修改Ingress注解、关联Service的配置、后端服务参数，会触发Ingress全量同步流程，连带触发NEG的端点更新。

二、该行为对网络性能的影响 #

该行为会直接导致网络性能下降，和观测到的高延迟现象直接相关：

• NEG端点更新过程中，负载均衡转发规则存在秒级的配置同步窗口，请求如果被转发到已经被Detach但还未从转发规则中完全剔除的端点，会出现连接超时、TCP重传，直接拉高请求延迟，严重时会返回5xx错误。
• 频繁的Attach/Detach操作会触发GCP负载均衡控制面的限流规则，导致配置同步任务积压，进一步拉长异常时间窗口。
• 端点持续波动会导致Ingress同步任务永远无法收敛，长期停留在待同步状态。

三、问题规避方案 #

注意："Scheduled for sync"是Ingress控制器的待同步中间状态，并非健康稳定状态。正常运行的Ingress在配置收敛后会退出该状态，仅当配置或端点发生变更时才会短暂进入。观测到的持续待同步，本质是NEG端点反复变动导致同步任务不断被追加，无法完成收敛。
可按以下优先级排查修复：

• 优先排查后端工作负载稳定性
  • 检查Ingress对应Service关联的Pod是否存在重启、就绪探针失败的情况，适当调大就绪探针的失败阈值、初始延迟时间，避免偶发的业务负载波动导致Pod被误判定为非Ready。
  • 调整工作负载滚动更新策略，将maxUnavailable设置为0，控制maxSurge比例不超过25%，避免批量Pod同时被销毁重建。
• 排查集群节点稳定性
  • 检查节点自动扩缩容的触发阈值，避免因资源水位小幅波动就触发节点频繁上下线；测试环境可固定节点池规模，临时关闭自动扩缩容验证问题是否复现。
  • 排查节点是否存在CPU/内存不足、磁盘占满等资源压力问题，这类问题会导致kubelet进程异常、节点反复进入NotReady状态。
• 优化NEG同步配置
  • 给Internal Ingress添加注解cloud.google.com/neg: '{"ingress": true, "exposed_ports": {"1443": {"neg_v2": true}}}'，启用第二代NEG架构，降低端点同步的控制面开销，提升同步效率。
  • 非生产环境可适当调大NEG控制器的同步周期，减少过于频繁的状态比对修正操作。
• 收敛配置变更频率：如果使用自动化配置同步工具持续下发Ingress/Service配置，排查是否存在无关字段的无意义变更，避免触发不必要的Ingress重建同步。

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