存活探测（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（无法完成探测）

一个常见的设计是：

• 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 ：每隔多久执行一次探测

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

常见 Liveness Probe 配置参数：

• initialDelaySeconds ：探测延迟

• periodSeconds ：探测周期

• timeoutSeconds ：单次探测超时时间

• successThreshold ：成功次数阈值

• failureThreshold ：失败次数阈值

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

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

可以通过以下方式检查：

1、查看 Pod 事件

kubectl describe pod <pod-name>

kubectl logs <pod-name>

kubectl get pods

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 自愈能力的价值。