更换GCP计费账户后Kubernetes Pod启动探针超时故障求助

故障现象 #

Startup probe failed: Get "http://10.200.1.231:8080/api/is_alive": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

此前业务运行正常，更换Google Cloud Platform（GCP）计费账户后出现该问题。

探针配置 #

readinessProbe:
    httpGet:
        path: /api/v1/ready
        port: 8080
      initialDelaySeconds: 20
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 3
    livenessProbe:
      httpGet:
        path: /api/v1/healthz
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 20
      timeoutSeconds: 5
      failureThreshold: 3
    startupProbe:
      httpGet:
        path: /api/v1/startup
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 60
      timeoutSeconds: 5
      failureThreshold: 3        
    resources:
      requests:
       memory: "2Gi"
       cpu: "2000m"
      limits:
       memory: "2Gi"
       cpu: "2000m"

已完成排查 #

• 确认应用及探针配置无变更
• 初步检查网络连接未发现明显异常
• 确认Kubernetes集群整体资源充足

可能原因分析 #

故障与GCP计费账户更换强关联，重点排查GCP侧配置变更影响：

1. 资源配额重置/不足：新计费账户可能未继承原账户的资源配额（CPU、内存、网络带宽等），导致Pod无法获得足够资源完成启动，引发探针超时。
2. VPC防火墙规则变更：新账户对应的VPC子网防火墙规则可能阻断了Kubernetes节点到Pod的探针请求（需验证节点到Pod IP的8080端口连通性）。
3. 镜像仓库访问权限丢失：若应用镜像存储在GCR，更换账户后可能失去拉取权限，导致Pod启动缓慢或失败，间接触发探针超时。
4. 节点资源限制变更：新账户下的集群节点可能配置了更严格的资源隔离策略，即使集群整体资源充足，单个节点也无法为Pod分配足够资源。

排查步骤 #

1. 检查GCP资源配额：
   登录GCP控制台，进入「IAM与管理」→「配额」，查看Pod所在区域的CPU、内存、网络带宽等配额是否超限，是否满足业务需求。
2. 验证节点到Pod的连通性：
   在Pod所在的Kubernetes节点上执行命令：curl -v http://10.200.1.231:8080/api/v1/startup，确认是否能正常访问探针接口，是否存在超时或拒绝响应。
3. 检查Pod镜像拉取状态：
   执行kubectl describe pod <pod-name>查看Pod事件，确认镜像是否成功拉取，是否有权限相关报错。
4. 核对VPC防火墙规则：
   进入GCP VPC控制台，检查节点所在子网的防火墙规则，确认是否允许内部流量（节点到Pod IP段的8080端口）通过。
5. 查看应用启动日志：
   执行kubectl logs <pod-name>或kubectl logs <pod-name> --previous（若Pod已重启），确认应用启动过程中是否存在依赖服务无法访问、初始化超时等异常。

解决方法 #

1. 配额不足处理：
   在GCP控制台申请提升对应资源的配额；若业务允许，可适当降低Pod的resources.requests配置。
2. 防火墙规则修复：
   添加允许节点到Pod IP段8080端口的入站防火墙规则，或调整现有规则覆盖探针流量。
3. 镜像权限修复：
   为新计费账户配置GCR镜像拉取权限，或更换镜像仓库为新账户可访问的地址。
4. 探针参数调整：
   若应用启动耗时增加，可调整启动探针参数：
   • 提高initialDelaySeconds至30以上
   • 延长timeoutSeconds至10
   • 提高failureThreshold至5
     给应用更多启动缓冲时间，同时排查应用启动缓慢的根本原因（如依赖服务延迟）。

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