liveness、readiness 和 startup 探针是什么，各自何时使用？

Question

IT Interview Practice · Accepted Answer

探针（probe）让 kubelet 检查容器的健康状况并据结果采取行动。共有三种：**liveness**（它还活着吗，还是应该被重启？）、**readiness**（它准备好接收流量了吗？）和 **startup**（它启动完成了吗？）。每一种回答一个不同的问题。

## 三种探针一览

```text
LIVENESS   → “应用卡死/死锁了吗？”         失败 → kubelet 重启容器
READINESS  → “它现在能提供服务吗？”         失败 → 把 Pod 从 Service endpoint 移除
                                                     (不重启)
STARTUP    → “缓慢的启动完成了吗？”         最先运行；运行期间 liveness 与
                                              readiness 被暂缓
```

## Readiness vs liveness —— 关键区别

```text
Readiness 控制流量：
  → readiness 失败的 Pod 会被从 Service 负载均衡器中拉出，
    但保持运行（例如它正在预热缓存，或某个依赖挂了）
Liveness 控制生命：
  → liveness 失败的 Pod 会被杀死并重启（它已损坏到无法恢复）
在本该用 readiness 的地方用了 liveness，会导致无谓的重启循环。
```

## 探针定义

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # 给缓慢启动者一段时间，之后其他探针才介入
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = 最多 5 分钟来启动
        periodSeconds: 10

readinessProbe:          # 把控流量
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # 不健康则重启
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## 探针机制

```text
httpGet    → GET 一个 path；2xx/3xx = 通过     (web 应用最常用)
tcpSocket  → 能否打开一个 TCP 连接？             (用于非 HTTP 服务)
exec       → 运行一条命令；exit 0 = 通过         (自定义检查)
grpc       → 原生 gRPC 健康检查
关键旋钮：initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## 为什么会有 startup 探针

```text
缓慢启动的应用 (JVM 预热、大型迁移) 过去逼你在 liveness 上设一个巨大的
initialDelaySeconds —— 这又使真正的崩溃变得难以及时发现。
startupProbe 解决了这个问题：它保护缓慢的启动过程，只有在它通过之后，
liveness/readiness 才以其正常（紧凑）的节奏开始。
```

```bash
kubectl describe pod app     # 在事件中查看探针失败与重启原因
kubectl get pod app          # READY 列反映 readiness；RESTARTS 反映 liveness
```

## 为什么这很重要

健康探针是 Kubernetes 实现自愈和安全流量路由的方式，因此理解这三种类型以及各自何时使用是必备的可靠性知识。那个关键区别——绊倒许多工程师的——是 **readiness** 与 **liveness** 之间的区别：readiness 控制**流量**（失败的 Pod 会被从 Service 负载均衡器中拉出但保持运行，非常适合它正在预热或某个依赖暂时挂掉的情形），而 liveness 控制**生命**（失败的 Pod 会被杀死并重启，用于它已死锁到无法恢复的情形）。把两者混淆——在本该用 readiness 的地方用 liveness——会导致无谓的重启循环和故障，因此知道每种探针回答哪个问题非常实用。**startup** 探针解决了一个真实的历史痛点：缓慢启动的应用过去逼你在 liveness 上设巨大的 `initialDelaySeconds`（这会延迟对真正崩溃的发现），而 startup 探针保护启动窗口，只有在启动成功后才让 liveness/readiness 以紧凑、正常的节奏运行。理解探针机制（`httpGet`、`tcpSocket`、`exec`、`grpc`）以及调优旋钮（`initialDelaySeconds`、`periodSeconds`、`failureThreshold` 等）让你能正确地配置健康检查，而不是靠猜。由于探针直接决定用户是否命中健康的 Pod、以及损坏的 Pod 是否自动恢复，把它们配对是在 Kubernetes 上运行可靠、生产级 workload 的基础。

三种探针一览

Readiness vs liveness —— 关键区别

探针定义

探针机制

为什么会有 startup 探针

为什么这很重要

相关问题