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

个人名片

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

• 专栏导航：

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

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 <pod-name>

重点关注：

• 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 <pod-name> --tail=100

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

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

3.3 手动访问健康检查端点

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

kubectl exec -it <pod-name> -- sh
curl 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 <namespace>

并测试网络连通性：

kubectl exec -it <pod-name> -- curl http://<service-name>:<port>

3.6 检查资源限制

如果 Pod 因 OOM 被杀死：

kubectl describe pod <pod-name> | grep -i "OOMKilled"

调整 resources 配置：

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

3.7 检查 NetworkPolicy

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

kubectl get networkpolicy -n <namespace>

确保允许流量通过：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-db-access
spec:
  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

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