Pod生命周期

Mon, 01 Jun 2026 00:00:00 +0000

Pod 生命周期里，最容易影响线上稳定性的部分，往往不是“能不能启动”，而是探针配得对不对。

这篇就重点讲三个探针：

livenessProbe
readinessProbe
startupProbe

先记住三句话

livenessProbe 失败：容器会被重启。
readinessProbe 失败：容器不接流量，但不一定重启。
startupProbe 生效期间：liveness/readiness 会被暂时屏蔽，给慢启动应用“保护期”。

三个探针分别解决什么问题

1. livenessProbe：进程还“活着”吗

它解决的是“程序假死”问题。

比如：进程还在，但线程卡死、连接池耗尽、接口永远不返回。这个时候容器看起来在运行，但其实已经不可用。

livenessProbe 连续失败后，kubelet 会重启容器。

适合场景：

进程可能进入死锁/卡死
希望通过重启自愈

2. readinessProbe：现在能接流量吗

它解决的是“服务可用性”问题。

即使进程活着，也可能暂时不能服务，比如：

应用刚启动，缓存还没预热
依赖数据库暂时不可达
正在做优雅下线

readinessProbe 失败时，Pod 会从 Service Endpoints 里移除，不再接收新流量。

适合场景：

有初始化过程
对外服务前有前置依赖
需要灰度或优雅摘流

3. startupProbe：给慢启动应用留时间

它解决的是“启动慢导致误杀”的问题。

有些应用启动要几十秒甚至几分钟。如果只配 livenessProbe，很可能应用还没起来就被判死，不断重启，最终 CrashLoopBackOff。

配置 startupProbe 后，在它成功之前，liveness/readiness 不会生效。

适合场景：

Java 大应用
需要加载大量模型/数据
启动期有迁移、预热等重操作

一个常用的探针组合示例

apiVersion: apps/v1
kind: Deployment
metadata:
 name: demo-app
spec:
 replicas: 2
 selector:
 matchLabels:
 app: demo-app
 template:
 metadata:
 labels:
 app: demo-app
 spec:
 containers:
 - name: app
 image: demo/app:1.0.0
 ports:
 - containerPort: 8080

 startupProbe:
 httpGet:
 path: /healthz
 port: 8080
 periodSeconds: 5
 failureThreshold: 24

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

 readinessProbe:
 httpGet:
 path: /ready
 port: 8080
 initialDelaySeconds: 3
 periodSeconds: 5
 timeoutSeconds: 2
 failureThreshold: 2
 successThreshold: 1

这个配置表达的意思：

LivenessProbe on giftiaのblog

Pod生命周期

先记住三句话

三个探针分别解决什么问题

1. livenessProbe：进程还“活着”吗

2. readinessProbe：现在能接流量吗

3. startupProbe：给慢启动应用留时间

一个常用的探针组合示例