Kubernetes 就绪探针（Readiness Probe）失败排查指南：从 HTTP 500 错误到问题解决_readiness probe failed

个人名片

🎓作者简介：java领域优质创作者
🌐个人主页：码农阿豪
📞工作室：新空间代码工作室（提供各种软件服务)
💌个人邮箱：[2435024119@qq.com]
📱个人微信：15279484656
🌐个人导航网站：www.forff.top
💡座右铭：总有人要赢。为什么不能是我呢？

• 专栏导航：

码农阿豪系列专栏导航
面试专栏：收集了java相关高频面试题，面试实战总结🍻🎉🖥️
Spring5系列专栏：整理了Spring5重要知识点与实战演练，有案例可直接使用🚀🔧💻
Redis专栏：Redis从零到一学习分享，经验总结，案例实战💐📝💡
全栈系列专栏：海纳百川有容乃大，可能你想要的东西里面都有🤸🌱🚀

目录

• Kubernetes 就绪探针（Readiness Probe）失败排查指南：从 HTTP 500 错误到问题解决
• • 引言
  • 1. 什么是 Readiness Probe？
  • • 1.1 Readiness Probe 的作用
    • 1.2 Readiness Probe 的配置方式
  • 2. 为什么会出现 HTTP 500 错误？
  • 3. 排查与解决方案
  • • 3.1 检查 Pod 状态和事件
    • 3.2 查看应用日志
    • 3.3 手动访问健康检查端点
    • 3.4 调整 Readiness Probe 参数
    • 3.5 检查依赖服务
    • 3.6 检查资源限制
    • 3.7 检查 NetworkPolicy
  • 4. 最佳实践
  • 5. 总结
  • 6. 进一步阅读

Kubernetes 就绪探针（Readiness Probe）失败排查指南：从 HTTP 500 错误到问题解决

引言

在 Kubernetes 中，Readiness Probe（就绪探针） 用于确定 Pod 是否准备好接收流量。如果探针失败，Pod 不会被加入 Service 的负载均衡池，导致请求无法到达该 Pod。常见的错误之一是：

Readiness probe failed: HTTP probe failed with statuscode: 500

本文将从 问题现象、可能原因、排查方法、解决方案 等多个角度，深入分析如何解决此类问题，并提供代码示例和最佳实践。

---

1. 什么是 Readiness Probe？

1.1 Readiness Probe 的作用

Kubernetes 使用 Readiness Probe 检测 Pod 是否已经启动并可以处理请求。如果探针失败，Pod 会被标记为 NotReady，并从 Service 的 Endpoints 中移除，直到探针再次成功。

1.2 Readiness Probe 的配置方式

探针支持三种检测方式：

1. HTTP GET：检查指定的 HTTP 端点是否返回 2xx 或 3xx。
2. TCP Socket：检查指定的端口是否能建立 TCP 连接。
3. Exec：在容器内执行命令，返回 0 表示成功。

示例配置：

readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 # 容器启动后等待 5 秒开始探测 periodSeconds: 5 # 每 5 秒探测一次 failureThreshold: 3 # 连续失败 3 次后标记为未就绪

---

2. 为什么会出现 HTTP 500 错误？

当探针返回 HTTP 500 时，意味着：

• 应用内部发生错误（如数据库连接失败、依赖服务不可用）。
• 探针配置错误（路径、端口不正确）。
• 应用启动太慢，探针超时。
• 网络策略或资源限制导致 Pod 无法正常工作。

---

3. 排查与解决方案

3.1 检查 Pod 状态和事件

使用 kubectl describe pod 查看 Pod 的详细状态：

kubectl describe pod 

重点关注：

• Events：是否有 Readiness probe failed 或其他错误（如 OOMKilled）。
• Readiness Probe 配置：路径、端口是否正确。

示例输出：

Events: Warning Unhealthy 3s (x3 over 13s) kubelet Readiness probe failed: HTTP probe failed with statuscode: 500

3.2 查看应用日志

使用 kubectl logs 检查应用日志：

kubectl logs  --tail=100

如果应用依赖数据库或外部服务，检查是否有连接错误：

ERROR: Failed to connect to MySQL: dial tcp 10.0.0.1:3306: connect: connection refused

3.3 手动访问健康检查端点

进入 Pod 并手动访问探针端点：

kubectl exec -it  -- shcurl http://localhost:8080/health

如果返回 500，说明应用内部有问题。

3.4 调整 Readiness Probe 参数

如果应用启动较慢，可以增加 initialDelaySeconds：

readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 # 等待 30 秒再开始探测 periodSeconds: 5 failureThreshold: 3

3.5 检查依赖服务

如果应用依赖数据库、Redis 或其他微服务，确保它们正常运行：

kubectl get pods -n 

并测试网络连通性：

kubectl exec -it  -- curl http://:

3.6 检查资源限制

如果 Pod 因 OOM 被杀死：

kubectl describe pod  | grep -i \"OOMKilled\"

调整 resources 配置：

resources: requests: cpu: \"500m\" memory: \"512Mi\" limits: cpu: \"1000m\" memory: \"1Gi\"

3.7 检查 NetworkPolicy

如果 Pod 无法访问依赖服务，可能是 NetworkPolicy 限制：

kubectl get networkpolicy -n 

确保允许流量通过：

apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-db-accessspec: podSelector: matchLabels: app: my-app ingress: - from: - podSelector: matchLabels: app: my-app ports: - protocol: TCP port: 3306 # MySQL 端口

---

4. 最佳实践

1. 健康检查端点设计：

   • /health 应该只检查关键依赖（如数据库、缓存）。
   • 避免在该端点执行复杂逻辑。

2. 合理的探针参数：

   • initialDelaySeconds 应大于应用启动时间。
   • failureThreshold 和 periodSeconds 应根据业务需求调整。

3. 日志和监控：

   • 使用 Prometheus + Grafana 监控探针状态。
   • 通过日志分析探针失败原因。

---

5. 总结

问题 排查方法 解决方案 应用返回 500 kubectl logs 修复代码或依赖 探针配置错误 kubectl describe pod 修正 path 或 port 应用启动慢 观察日志 增加 initialDelaySeconds 依赖服务不可用 kubectl get svc 检查数据库/缓存 资源不足 kubectl top pod 调整 resources 网络策略限制 kubectl get networkpolicy 调整 NetworkPolicy

通过以上方法，可以系统性地解决 Readiness probe failed: HTTP probe failed with statuscode: 500 问题，确保 Kubernetes 应用稳定运行。

---

6. 进一步阅读

• Kubernetes 官方文档 - Configure Liveness and Readiness Probes
• Best Practices for Kubernetes Health Checks

希望这篇指南能帮助你快速定位和解决问题！ 🚀