当前位置：首页 > news >正文

k8s 部署服务常见错误原因

news 2025/6/13 15:07:23

健康检查报错

我们可以通过 kubectl describe pod <pod-name> 命令来查看 Pod 详情（包括 Probe 配置、事件、容器状态、重启次数等关键信息）。

如果采用的健康检查方式是 http，事件（event）部分可能会记录以下错误信息：

Liveness probe failed: Get "http://:...": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

该错误表明 k8s 在发起健康检查时，服务未在超时时间内返回响应。

可能原因：

问题排查思路：

手动调用健康检查接口，并观察响应时间是否经常超过当前的 timeoutSeconds。
- 在 Pod 内: kubectl exec -it <pod-name> -- curl -v http://localhost:<health-check-port><health-check-path>
- 在节点上 (获取 Pod IP): curl -v http://<pod-ip>:<health-check-port><health-check-path>
查看应用日志: kubectl logs [–previous] - 查找应用启动、运行期间，特别是健康检查端点被访问时的错误、警告或延迟信息。

解决思路：

调整 Probe 参数 (临时缓解/验证): 这是最快见效的方法，尤其是增大 timeoutSeconds (如设为 5, 10)
检查资源: 使用 kubectl top, kubectl describe node 检查 Pod 和节点的 CPU/内存使用情况。调整资源 requests/limits。
监控应用性能: 结合 APM 工具或应用内置指标，分析健康检查端点慢的根本原因。优化应用性能或简化健康检查逻辑。

Spring Boot 应用的健康检查接口一般为 /actuator/health。

其健康检查的流程如下：
在这里插入图片描述
返回的健康状态类型：

如果出现 503，则说明其依赖的服务出现了故障，或自身服务器过载或处于主动维护状态，无法处理请求。

比如：

readiness probe failed：read tcp 169.254.1.1:38579->21.79.199.85:9180:read: connection reset by peer

这个错误表明 Kubernetes 探针在建立 TCP 连接后，被对方强制中断。

在这里插入图片描述
关键点：

可能原因是：服务突然崩溃

比如：

readiness probe failed：read tcp 169.254.1.1:38579->21.79.199.85:9180:read: connection refused

该错误说明客户端在尝试与服务端建立 tcp 连接时就已经失败了。

该问题一般是出现在容器内服务的启动阶段。此时出现该错误很正常，因为一般会将 readiness probe 的配置比较激进，容易在服务启动阶段就检测不通过。但由于不影响服务启动后的运行，因此不必过多关注。

更多 rediness probe 的介绍可以见《livenessProbe 和 readinessProbe 最佳实践》。

与 connect reset by peer 的区别：