Deployment失败：HTTP探针返回500状态码 跨集群部署问题求助

核心问题是HTTP探针返回500导致Pod无法就绪，进而触发MinimumReplicaUnavailable状态。既然资源配额还有剩余，排除资源不足的可能，重点排查探针本身、集群环境差异及服务依赖：

排查步骤 #

• 查看Pod日志与事件细节
  直接获取Pod的运行日志和事件信息，定位探针失败的具体原因：

  # 查看Pod主容器日志
  kubectl logs <service-1-pod-name> -n test-namespace-1
  # 查看Pod事件详情（含探针失败的具体描述）
  kubectl describe pod <service-1-pod-name> -n test-namespace-1
  

  重点关注日志中服务启动过程的报错，以及探针请求对应的错误堆栈。

• 对比Cluster-1与Cluster-2的部署配置差异
  拉取两个集群的Service-1部署yaml，逐一核对：

  • 探针配置：livenessProbe/readinessProbe的路径、端口、HTTP方法、请求头是否完全一致？Cluster-2是否存在路径拼写错误、端口不匹配的情况？
  • 环境变量：检查数据库地址、配置中心地址、密钥等依赖配置，是否和Cluster-1同步？错误的依赖配置会导致服务内部逻辑报错，探针返回500。
  • 存储卷：确认PVC挂载路径、文件权限是否正常？若服务依赖的配置文件在挂载卷中缺失或权限错误，会引发启动异常。

• 验证Cluster-2的节点与网络环境

  • 节点资源：用kubectl top node查看Cluster-2节点的CPU/内存使用率，确认单个节点是否存在资源耗尽（命名空间配额充足不代表单个节点有剩余）。
  • 网络策略：检查Cluster-2的test-namespace-1是否有网络策略限制Pod出站请求？若Service-1需要调用外部依赖（如数据库），网络阻断会导致服务内部错误。
  • 容器运行时：对比两个集群的容器运行时版本（Docker/containerd），版本差异可能导致服务启动异常。

• 手动测试探针请求
  在Cluster-2的Pod内部或同节点的调试Pod中，手动发送探针请求，获取具体错误：

  # 进入目标Pod
  kubectl exec -it <service-1-pod-name> -n test-namespace-1 -- /bin/sh
  # 发送探针请求
  curl http://localhost:<probe-port>/<probe-path>
  

  根据返回的错误信息（如500对应的具体错误码、响应内容）定位问题。

• 检查依赖服务可用性
  确认Service-1依赖的数据库、缓存、其他微服务在Cluster-2中是否正常运行？依赖服务不可用会直接导致Service-1启动失败，探针返回500。

常见解决方向 #

• 若探针配置错误：修正livenessProbe/readinessProbe参数，与Cluster-1保持一致。
• 若环境配置不一致：同步Cluster-1的环境变量、存储卷配置到Cluster-2，确保依赖信息正确。
• 若节点资源不足：将Pod调度到资源充足的节点，或调整节点资源配额。
• 若网络策略阻断：修改网络策略，允许Pod访问依赖服务的IP/端口。
• 若依赖服务异常：先修复依赖服务的可用性，再重新部署Service-1。

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