k8s 部署服务常见错误原因

健康检查报错

Client.Timeout exceeded while awaiting headers

我们可以通过 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 工具或应用内置指标，分析健康检查端点慢的根本原因。优化应用性能或简化健康检查逻辑。

Liveness/Readiness prob failed：HTTP probe failed with statuscode：503

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

其健康检查的流程如下：

返回的健康状态类型：

• UP：所有依赖正常 (HTTP 200)
• DOWN：关键依赖故障 (HTTP 503)
• OUT_OF_SERVICE：维护模式 (HTTP 503)
• UNKNOWN：未知状态

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

connection reset by peer

比如：

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

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

关键点：

• RST (Reset) 包：目标服务器主动终止了连接
• 169.254.1.1：Kubernetes 节点内部使用的链路本地地址
• 21.79.199.85:9180：目标服务地址（可能是您集群内的服务或外部服务）

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

connection refused

比如：

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 的区别：

特征	connection refused	connection reset by peer
发生阶段	三次握手前	连接建立后
TCP 状态	SYN_SENT → 无响应	ESTABLISHED → 异常终止
根本原因	服务端无监听	连接被强制关闭
错误类型	主动拒绝连接	异常终止连接
常见场景	服务未启动/端口错误	服务崩溃
排查重点	服务启动是否正常	服务稳定性