GKE中部署A滚动发布时引发其他部署异常的问题求助

你遇到的是GKE Autopilot环境中，跨Deployment的服务因共享Network Endpoint Group（NEG）导致的联动故障——当某一个Deployment滚动发布触发NEG更新时，共享同一NEG的其他Deployment Pod会被错误缩容重启，且故障呈现固定分组，这大概率和Autopilot自动管理NEG的分组逻辑有关。

核心解决方案 #

1. 为每个服务配置独立NEG #

这是彻底解决问题的最优方案，通过给每个Service添加专属NEG注解，确保每个Deployment对应的Service绑定独立的NEG，完全隔离跨Deployment的NEG操作干扰。

配置示例（为目标Service添加注解）：

apiVersion: v1
kind: Service
metadata:
  name: serviced-deploy-service
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"8000":{}}}'
    cloud.google.com/neg-name: "serviced-neg-8000" # 自定义唯一NEG名称，便于区分管理
spec:
  selector:
    app: SERVICED
  ports:
  - port: 8000
    targetPort: 8000
  type: ClusterIP

注意：每个Service的neg-name必须唯一，避免重复导致NEG共享。

2. 排查Autopilot的NEG自动关联逻辑 #

Autopilot会自动为Service创建并关联NEG，若故障呈现固定分组，很可能是受影响的Service被Autopilot按某种规则（如标签、命名空间、端口）批量绑定到了同一NEG。可以做以下操作：

• 检查所有受影响Service的标签、注解，确认是否存在统一标识被Autopilot用于NEG分组
• 登录GCP控制台查看NEG详情，确认哪些Service/Endpoint被绑定到同一NEG，清理错误关联

3. 调整滚动发布策略降低NEG干扰（应急方案） #

若暂时无法拆分NEG，可调整Deployment的滚动发布参数，减少NEG状态波动带来的影响：

• 设置maxUnavailable: 0和maxSurge: 1，确保滚动发布期间始终有健康Pod在NEG中，避免触发误缩容逻辑
• 优化Pod就绪探针配置，确保Pod完全就绪后再加入NEG，减少NEG状态异常的触发概率

日志对应问题分析 #

从你提供的事件日志可以明确故障链路：

58s Normal ScaleDown pod/SERVICED-deploy-6bdc997488-kd8cz deleting pod for node scale down
58s Normal Killing pod/SERVICED-deploy-6bdc997488-kd8cz Stopping container SERVICED
7s Normal LoadBalancerNegNotReady pod/SERVICED-deploy-6bdc997488-b4gvd Waiting for pod to become healthy in at least one of the NEG(s): [k8s1-42e4f580-SERVICED-SERVICED-deploy-service-8000-4f86fa2f]

当Deployment A的NEG执行挂载/卸载操作时，共享该NEG的SERVICED Pod被误判为需要节点缩容清理，同时新启动的Pod因NEG状态未就绪无法正常注册，最终形成Pod被强制重启的循环。

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