Kubernetes readinessProbe失败求助：仅用livenessProbe时Pod运行正常

从你提供的配置和日志来看，两个探针的HTTP检查路径、端口完全一致，但仅添加就绪探针后出现故障，结合日志里的连接拒绝错误，核心问题大概率是应用的/health接口在就绪探针触发时，因依赖服务未就绪返回非200状态码，具体分析和解决步骤如下：

关键问题定位 #

日志中明确显示应用尝试连接192.168.241.71:8100失败，随后触发192.168.241.71:8000的连接拒绝panic。这说明你的应用的/health接口逻辑中，可能把对8100端口服务的可用性作为就绪状态的判断标准——当依赖服务未启动时，/health会返回失败状态，导致就绪探针检测不通过。

而存活探针正常的原因是：存活探针触发时，应用进程本身已启动（即使依赖未就绪），或者后续存活探针重试时，依赖服务已完成启动，此时/health返回正常；但就绪探针在初始延迟后首次检测时，依赖仍未就绪，且持续重试未成功，最终导致Pod被标记为未就绪。

排查与解决步骤 #

• 验证/health接口状态：进入Pod内部执行curl -v localhost:8000/health，查看返回的HTTP状态码和响应内容，确认是否因依赖未就绪返回非200。
• 延长就绪探针初始延迟：将readinessProbe的initialDelaySeconds从60调整为90甚至120，给依赖服务足够的启动时间，避免过早触发检测。示例调整：

  readinessProbe:
    httpGet:
      path: /health
      port: 8000
    initialDelaySeconds: 90
    periodSeconds: 5
    failureThreshold: 10
  

• 增加失败重试阈值：添加failureThreshold: 10（默认是3），允许探针在多次失败后继续重试，适配依赖服务的启动波动。
• 检查依赖服务状态：确认192.168.241.71:8100对应的服务是否正常部署、启动，是否存在资源不足或配置错误导致的启动延迟。
• 调整健康检查逻辑：如果该依赖服务并非Pod就绪的必要条件，可以修改应用的/health接口，将依赖检查改为警告级别，而非直接返回失败；或者将存活探针和就绪探针的检查路径区分开——存活探针仅检查进程存活，就绪探针检查核心依赖就绪。

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