GCP GKE内部负载均衡与Workload重启通信异常问询

一、Workload自动重启的可能原因 #

• 资源泄漏触发重启：如果应用存在内存/CPU泄漏，运行5-7天后资源耗尽，会触发kubelet的OOMKilled或CPU限流，导致Pod被强制重启。可通过kubectl describe pod <pod-name> -n k8s-cym查看Pod事件，或在GCP监控里查看Pod资源使用率趋势确认。
• 容器探针检测失败：如果Workload配置了livenessProbe，当应用内部出现异常（比如数据库连接池耗尽、死锁），探针连续失败会触发Pod重启。注意这和Ingress的健康检查是独立机制，容器自身探针优先级更高。
• 节点周期性维护：GCP节点会定期进行系统更新或硬件维护，Kubernetes会将Pod调度到其他节点，导致原Pod重启。可通过kubectl get events -n k8s-cym或GCP控制台的节点操作记录排查。
• 应用内部逻辑崩溃：比如定时任务引发的内存溢出、线程池耗尽等问题，运行一段时间后导致应用进程崩溃，进而触发Pod重启。查看Pod重启前的日志（kubectl logs <pod-name> -n k8s-cym --previous）能找到相关线索。

二、重启后LoadBalancer通信中断的原因 #

结合Backend进入UnHealthy状态的现象，核心问题集中在健康检查与Pod启动节奏不匹配及端点同步延迟：

• 启动延迟导致健康检查失败：Workload启动需要20秒完成数据库连接，但当前健康检查配置（间隔60秒、不健康阈值5次）看似宽松，可健康阈值仅1次——Pod重启后，容器启动完成但还在初始化阶段，此时健康检查请求会返回失败，GCP后端服务会快速标记该端点为UnHealthy，LB停止转发流量。如果未配置readinessProbe，Kubernetes会立即将新Pod加入端点列表，导致LB向未就绪的Pod发请求，加剧中断。
• 端点同步延迟：Pod重启后，Kubernetes更新EndpointSlice，但GCP负载均衡器同步端点状态存在一定延迟。旧Pod已被销毁，新Pod还没通过健康检查，这段时间LB可能仍在向旧IP转发流量，导致通信中断。手动重启Workload相当于强制触发端点刷新，或新Pod启动后健康检查通过的时机刚好契合同步窗口，因此能恢复。
• 健康检查路径/端口不匹配：如果健康检查的目标路径（比如默认的/）在应用初始化阶段无法返回200状态码，或检查端口与应用实际监听端口不一致，会导致健康检查持续失败，后端服务一直处于UnHealthy状态。

排查与修复建议 #

1. 确认Pod重启原因：
   执行kubectl get pods -n k8s-cym -o jsonpath='{.items[*].status.containerStatuses[*].lastState.terminated.reason}'查看重启触发原因，或通过Pod事件日志定位问题。
2. 优化容器探针配置：
   添加readinessProbe并设置合理的初始延迟（大于20秒初始化时间），确保应用就绪后才被加入后端服务。示例配置：

   livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 30
     periodSeconds: 10
   readinessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 25
     periodSeconds: 5
   

3. 检查GCP后端服务健康检查：
   在GCP控制台进入对应负载均衡器的后端服务，查看健康检查的失败详情（比如连接超时、返回码异常），调整检查路径或端口。
4. 监控资源使用率：
   在GCP监控中创建Pod的CPU、内存仪表盘，排查是否存在周期性资源上升的情况，确认是否有内存/CPU泄漏。

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