Kubernetes Liveness Probe存活探针 / Readiness Probe就绪探针介绍（Startup Probe启动探针）重启容器

文章目录

[Kubernetes 中的 Liveness / Readiness 探针详解](#Kubernetes 中的 Liveness / Readiness 探针详解)
- 一、为什么需要探针？
- [二、Liveness Probe（存活探针）](#二、Liveness Probe（存活探针）)
- [三、Readiness Probe（就绪探针）](#三、Readiness Probe（就绪探针）)
- 四、核心区别
- [五、Startup Probe（补充）](#五、Startup Probe（补充）)
- - [Startup Probe（启动探针）](#Startup Probe（启动探针）)
  - 使用场景
  - 示例
  - 关键点
- 六、最佳实践
- - [1️⃣ 区分两个探针的职责](#1️⃣ 区分两个探针的职责)
  - [2️⃣ 健康检查接口设计](#2️⃣ 健康检查接口设计)
  - [3️⃣ Readiness 要检查依赖](#3️⃣ Readiness 要检查依赖)
  - [4️⃣ Liveness 不要过于严格](#4️⃣ Liveness 不要过于严格)
  - [5️⃣ 合理设置参数](#5️⃣ 合理设置参数)
- 七、常见踩坑
- - [❌ 1. 没有 Readiness Probe](#❌ 1. 没有 Readiness Probe)
  - [❌ 2. Liveness 检查依赖服务](#❌ 2. Liveness 检查依赖服务)
  - [❌ 3. 探针过于频繁](#❌ 3. 探针过于频繁)
  - [❌ 4. 健康接口太重](#❌ 4. 健康接口太重)
- 八、总结

Kubernetes 中的 Liveness / Readiness 探针详解

在使用 Kubernetes 进行容器编排时，如何判断一个 Pod 是否健康、是否可以对外提供服务，是运维中非常关键的问题。

Kubernetes 提供了三种健康检查机制，其中最常用的是：

Liveness Probe（存活探针）
Readiness Probe（就绪探针）

（另外还有一个较新的 Startup Probe，这里会顺带提一下）

本文将从原理、区别、配置与实战角度，深入讲解它们的使用方法。

一、为什么需要探针？

容器"运行中（Running）"并不代表"可用"。

常见问题包括：

应用线程死锁（进程还在，但无法响应）
服务启动未完成（比如还在加载模型、连接数据库）
依赖服务异常（数据库、缓存不可用）
内部错误导致服务不可用

👉 如果没有探针：

流量可能被发送到"假活"的 Pod
Kubernetes 无法自动修复异常实例

二、Liveness Probe（存活探针）

作用

判断容器是否"还活着"

如果失败：

👉 Kubernetes 会 重启容器

典型场景

应用发生死锁
内存泄漏导致不可用
线程卡死但进程未退出

工作机制

Kubernetes 定期执行检查：

成功 → 正常运行
失败达到阈值 → 重启容器

示例配置

yaml 复制代码

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

常见检查方式

类型	说明
HTTP	请求接口
TCP	检查端口
Exec	执行命令

示例（Exec）

yaml 复制代码

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

三、Readiness Probe（就绪探针）

作用

判断容器是否"可以接收流量"

如果失败：

👉 Pod 会被 从 Service 的负载均衡中移除

典型场景

应用刚启动（还没 ready）
依赖服务不可用（数据库挂了）
服务负载过高，需要暂时摘流

工作机制

成功 → Pod 加入 Service
失败 → Pod 从 Service 移除（不会重启）

示例配置

yaml 复制代码

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

四、核心区别

特性	Liveness Probe	Readiness Probe
作用	是否存活	是否可接流量
失败结果	重启容器	从 Service 移除
是否影响流量	❌	✅
是否触发重启	✅	❌

五、Startup Probe（补充）

Kubernetes 还提供：

Startup Probe（启动探针）

👉 解决慢启动问题

使用场景

Java 应用（Spring Boot）
AI 模型加载
大型初始化流程

示例

yaml 复制代码

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

关键点

Startup Probe 成功前：
- 不执行 liveness / readiness
防止应用"还没启动就被杀掉"

六、最佳实践

1️⃣ 区分两个探针的职责

Liveness：判断是否需要重启
Readiness：判断是否接流量

👉 不要混用同一个接口

2️⃣ 健康检查接口设计

推荐设计三个接口：

复制代码

/healthz   -> liveness
/ready     -> readiness
/startup   -> startup

3️⃣ Readiness 要检查依赖

例如：

数据库连接
Redis
外部 API

否则：

👉 服务"看起来正常"，但实际不可用

4️⃣ Liveness 不要过于严格

错误示例：

把数据库依赖放到 liveness

👉 会导致：

数据库短暂异常 → 容器疯狂重启（雪崩）

5️⃣ 合理设置参数

关键参数：

yaml 复制代码

initialDelaySeconds
periodSeconds
timeoutSeconds
failureThreshold

建议：

高延迟系统 → 增大 timeout
慢启动 → 增大 initialDelay
防止抖动 → 提高 failureThreshold

七、常见踩坑

❌ 1. 没有 Readiness Probe

结果：

流量打到未初始化服务

❌ 2. Liveness 检查依赖服务

结果：

外部依赖异常 → 容器被重启（错误行为）

❌ 3. 探针过于频繁

结果：

增加系统负担
触发误判

❌ 4. 健康接口太重

结果：

健康检查本身变慢甚至失败

👉 建议：健康接口要 轻量、快速、无副作用

八、总结

Kubernetes 探针是实现 高可用、自愈能力 的核心机制之一：

Liveness Probe → 解决"死而不僵"
Readiness Probe → 解决"未 ready 就接流量"
Startup Probe → 解决"慢启动误杀"

👉 三者配合，才能构建真正稳定的生产系统