Kubernetes 存活探测（Liveness Probe）详解：原理、配置与最佳实践

正文如下👇

Kubernetes Liveness Probes

存活探测（Liveness Probe）用于判断 容器中的应用是否仍然存活并正常运行。通过定义合理的探测规则，可以显著提升 Pod 的稳定性、可用性和自愈能力。

本文将围绕 Kubernetes（K8s）中的存活探测 进行系统讲解，并结合大量示例，帮助你在实际生产环境中正确使用 Liveness Probe。

本文将涵盖以下内容：

• 什么是 Kubernetes 存活探测（Liveness Probe）
• Kubernetes 中还有哪些探测机制
• 如何定义 Kubernetes 存活探测
• Liveness Probe 的常见配置示例
• 如何验证存活探测是否生效
• 存活探测失败的排查思路
• Liveness Probe 的最佳实践

什么是 Kubernetes 存活探测（Liveness Probe）：

Kubernetes 存活探测是一种用于判断 容器是否仍在正常运行 的机制。

当存活探测失败时，Kubernetes 会认为该容器处于异常状态，并 自动重启容器，以恢复服务。

Liveness Probe 通常用于检测以下问题：

• 应用进入死锁状态
• 进程假死、不再响应请求
• 内部异常但进程未退出，无法自愈

存活探测可以通过以下方式实现：

• 执行容器内命令
• 发送 HTTP 请求
• 检测 TCP 端口是否可达

当应用停止响应时，Kubernetes 可以主动介入并重启容器，从而提高系统整体的可靠性。

存活探测在 Kubernetes 中的作用：

在 Kubernetes 中，kubelet 负责执行存活探测，并根据探测结果决定是否重启容器。

• 如果探测成功： 不执行任何操作，也不会产生事件日志
• 如果探测失败： kubelet 会记录事件，并根据 restartPolicy 杀掉并重启容器

什么时候应该使用存活探测？

当 Pod 看起来“还在运行”，但 应用实际上已经无法正常工作 时，就非常适合使用 Liveness Probe。

例如：

• 应用发生死锁
• 服务端口还在，但接口不再响应
• 应用线程阻塞，无法处理请求

这种情况下，容器不会自动退出，但已经无法对外提供服务，存活探测可以帮助 Kubernetes 自动恢复。

什么时候不需要存活探测？

如果应用在出现致命错误时 会主动退出进程，那么 kubelet 会根据 restartPolicy 自动重启容器，此时并不一定需要额外配置 Liveness Probe。

例如 NGINX：

• 启动速度快
• 出现致命错误会直接退出
• Kubernetes 可以自然地重启它

存活探测的三种类型：

Kubernetes 支持三种存活探测方式，适用于不同类型的应用场景：

1️⃣ HTTP GET 探测

向指定的 HTTP 接口发送请求：

• 返回码为 2xx 或 3xx：探测成功
• 其他返回码：探测失败

适用于 Web 服务。

2️⃣ TCP Socket 探测

尝试连接指定端口：

• 端口可达：探测成功
• 端口不可达：探测失败

适用于无 HTTP 接口的服务，如数据库、中间件。

3️⃣ Exec（命令）探测

在容器内执行命令：

• 命令返回 0：探测成功
• 非 0：探测失败

适用于需要自定义检测逻辑的场景。

Kubernetes 中还有哪些探测机制？

Kubernetes 一共提供了三种探测：

• Liveness Probe（存活探测）
• Readiness Probe（就绪探测）
• Startup Probe（启动探测）

本文重点介绍存活探测，但你也需要理解另外两种。

Readiness Probe（就绪探测）

用于判断应用 是否已准备好接收流量。

• 探测失败：Pod 会被从 Service 的 Endpoints 中移除
• 探测成功：开始接收请求
• 不会重启容器

适用于以下场景：

• 应用启动依赖外部服务（如数据库）
• 服务过载，需要临时摘流量

Startup Probe（启动探测）

用于判断 应用是否已完成启动。

配置 Startup Probe 后：

• 在其成功之前，Liveness 和 Readiness 探测不会生效
• 避免启动慢的应用被误判为异常

非常适合：

• 启动时间长
• 需要初始化大量资源的应用

Kubernetes 探测是如何工作的？

Kubernetes 中的探测由 kubelet 负责执行。

应用需要支持以下探测处理方式之一：

• ExecAction：在容器内执行命令
• TCPSocketAction：检测 TCP 端口
• HTTPGetAction：HTTP 请求检测
• gRPC 探测（K8s v1.24+）

每次探测结果分为三种：

• Success（成功）
• Failure（失败）
• Unknown（无法完成探测）

Liveness Probe 与 Readiness Probe 的区别：

一个常见的设计是：

• Readiness 控制流量
• Liveness 控制进程存活

二者结合使用，可以显著提升系统稳定性。

如何定义 Kubernetes 存活探测

存活探测在 Pod YAML 中通过 livenessProbe 定义。

示例：HTTP 探测

apiVersion: v1kind: Podmetadata:  name: example-podspec:  containers:  - name: example-container    image: myapp:latest    livenessProbe:      httpGet:        path: /health        port: 8080      initialDelaySeconds: 3      periodSeconds: 5

含义说明：

• initialDelaySeconds：容器启动后延迟多久开始探测
• periodSeconds：每隔多久执行一次探测

示例：Exec 探测

livenessProbe:  exec:    command: ["cat", "/tmp/healthy"]  initialDelaySeconds: 5  periodSeconds: 10

常见 Liveness Probe 配置参数：

• initialDelaySeconds：首次探测延迟
• periodSeconds：探测周期
• timeoutSeconds：单次探测超时时间
• successThreshold：成功次数阈值
• failureThreshold：失败次数阈值

在配置前，应充分了解应用的 启动时间和运行特性。

如何判断存活探测是否生效？

可以通过以下方式检查：

1、查看 Pod 事件

kubectl describe pod <pod-name>

2、查看容器日志

kubectl logs <pod-name>

3、查看pod状态

kubectl get pods

4、手动访问探测接口

curl http://<pod-ip>:<port>/health

存活探测失败的常见原因与排查

1️⃣ 应用启动太慢

解决方案：

• 增大 initialDelaySeconds
• 使用 Startup Probe

2️⃣ 探测路径或端口配置错误

解决方案：

• 确认接口路径正确
• 确认端口与容器监听端口一致

3️⃣ 资源不足导致超时

解决方案：

• 调整 timeoutSeconds
• 合理设置 CPU / 内存 request & limit

Liveness Probe 最佳实践

• 探测逻辑要简单、轻量
• 与 Readiness Probe 配合使用
• 避免探测接口依赖核心业务逻辑
• 设置合理的失败阈值，防止频繁重启
• 定期检查和调整探测配置
• 配合监控与告警，及时发现问题

总结：

合理使用 Liveness Probe、Readiness Probe 和 Startup Probe，可以显著提升 Pod 的稳定性和可用性。

关键不在于“是否配置探测”，而在于：

是否理解应用本身，并为其设计合适的探测策略。

只有贴合业务特性的探测配置，才能真正发挥 Kubernetes 自愈能力的价值。