2026/9/7Kubernetes

Kubernetes 中的探针（Probe）

常见的三种探针是：

Startup Probe：启动探针
Liveness Probe：存活探针
Readiness Probe：就绪探针

可以先用一句话理解：

探针	关注问题	失败后的主要动作
Startup Probe	应用启动完成了吗？	重启容器
Liveness Probe	应用还活着吗？	重启容器
Readiness Probe	应用能接收流量吗？	从 Service 后端摘除，不接收流量

一、为什么需要探针

仅仅判断容器进程是否存在，并不能说明应用是正常的。

例如：

容器进程还在
但是：
- 应用死锁
- HTTP 服务无法响应
- 数据库连接池耗尽
- 应用还在启动
- 依赖服务未就绪
- 只能处理健康检查，无法处理业务请求

如果没有探针，Kubernetes 可能认为容器是正常的。

探针就是让应用告诉 Kubernetes：

我是否已经启动？
我是否还活着？
我是否可以接收业务流量？

二、Startup Probe：启动探针

1. 概念

Startup Probe 用来判断：

应用是否已经完成启动。

它特别适合启动时间比较长的应用，例如：

Java Spring Boot 应用
需要加载大量模型的 AI 服务
启动时需要执行数据库迁移的应用
Elasticsearch
大型缓存服务
启动时需要加载大量配置的应用
第一次启动需要预热的服务

2. 为什么需要 Startup Probe

假设一个 Java 应用启动需要 120 秒。

如果只配置 Liveness Probe：

YAML

那么应用还没启动完成，探针就开始检查：

第 10 秒：检查失败
第 20 秒：检查失败
第 30 秒：检查失败
达到 failureThreshold
容器被重启

结果：

应用还没启动完成，就被 Kubernetes 重启

并且重启后又重新开始启动，形成：

启动 → 探针失败 → 重启 → 启动 → 探针失败 → 重启

这叫做启动失败循环。

Startup Probe 的作用是：

在应用启动成功之前，暂时不要执行 Liveness Probe 和 Readiness Probe。

3. Startup Probe 的工作机制

如果配置了 Startup Probe：

容器启动
  ↓
只执行 Startup Probe

如果 Startup Probe 一直失败：

达到 failureThreshold
  ↓
容器被重启

因此，Startup Probe 主要解决的是：

应用启动比较慢，但启动完成后运行比较稳定。

4. Startup Probe 示例

YAML

含义：

每 10 秒检查一次
每次最多等待 3 秒
最多允许连续失败 30 次
最长启动容忍时间大约为 300 秒

注意：

periodSeconds × failureThreshold

可以粗略估算启动允许时间，但实际还会受到请求耗时和调度时间影响。

三、Liveness Probe：存活探针

1. 概念

Liveness Probe 用来判断：

容器中的应用是否仍然处于可恢复运行状态。

如果 Liveness Probe 持续失败，Kubernetes 会认为应用已经失去活性，并重启容器。

2. Liveness Probe 适合解决什么问题

例如应用进程没有退出，但已经：

死锁
线程池完全阻塞
内部状态异常
HTTP 请求全部超时
事件循环停止
内存泄漏后无法处理请求
长时间没有响应

此时 Kubernetes 可以通过重启容器自动恢复。

3. Liveness Probe 失败后的行为

Liveness Probe 失败
      ↓
达到 failureThreshold

注意：

Liveness Probe 失败通常是重启容器，不一定是删除 Pod。

如果 Pod 属于 Deployment，容器重启次数会增加，但 Pod 名称可能不变。

查看重启次数：

BASH

kubectl get pod

查看详情：

BASH

kubectl describe pod <pod-name>

4. Liveness Probe 示例

YAML

含义：

容器启动 30 秒后开始检查
每 10 秒检查一次
每次最多等待 3 秒
连续失败 3 次后重启容器
Liveness 的 successThreshold 必须为 1

四、Readiness Probe：就绪探针

1. 概念

Readiness Probe 用来判断：

当前 Pod 是否已经准备好接收业务流量。

Readiness Probe 失败时，Kubernetes 通常不会重启容器，而是：

Pod 仍然运行
  ↓
从 Service 的 Endpoints 中移除
  ↓
Service 不再向该 Pod 转发新请求

2. Readiness Probe 适合解决什么问题

例如：

应用还没有加载完配置
应用正在启动
数据库连接还没有建立
缓存还没有预热
Pod 正在优雅停止
应用临时过载
依赖服务不可用
正在执行流量切换
正在进行滚动升级

这种情况下，应用不一定需要重启，只需要暂时停止接收流量。

3. Readiness Probe 失败后的行为

Readiness Probe 失败
      ↓
Pod 标记为 NotReady

容器通常仍然继续运行。

查看 Pod 状态：

BASH

kubectl get pod

可能显示：

READY   STATUS
0/1     Running

这表示：

容器还在运行
但 Pod 尚未就绪
Service 不应该向它转发业务请求

4. Readiness Probe 示例

YAML

五、三种探针的核心区别

1. 启动探针

回答：

应用启动完成了吗？

失败后：

重启容器

2. 存活探针

回答：

应用是不是已经卡死或失去恢复能力？

失败后：

重启容器

3. 就绪探针

回答：

应用现在能不能接收业务请求？

失败后：

从 Service 后端摘除

4. 对比表

特性	Startup	Liveness	Readiness
判断目标	是否启动完成	是否仍然存活	是否可以接收流量
失败后是否重启	是	是	否
失败后是否摘除流量	间接	通常会，因为容器重启	是
启动阶段是否执行	最先执行	Startup 成功后执行	Startup 成功后执行
常见用途	慢启动应用	死锁、卡死恢复	流量控制
`successThreshold`	必须为 1	必须为 1	可以大于 1

六、探针的三种检测方式

Kubernetes 常用以下几种探针检测方式：

HTTP GET
TCP Socket
Exec Command
gRPC

七、HTTP 探针

1. 概念

HTTP 探针向容器发送 HTTP 请求，根据返回状态码判断是否成功。

示例：

YAML

httpGet:
  path: /healthz
  port: 8080

默认情况下：

HTTP 状态码 200 到 399：成功
其他状态码：失败

2. HTTP 探针示例

YAML

3. 设置请求头

YAML

有些应用需要特定请求头，可以使用这种方式。

4. 使用 HTTPS

YAML

注意：

证书校验行为需要根据 Kubernetes 探针机制确认
不要把复杂的鉴权流程放入健康检查
健康接口尽量轻量、稳定

5. 使用命名端口

容器端口可以命名：

YAML

ports:
  - name: http
    containerPort: 8080

探针引用：

YAML

readinessProbe:

这样比直接写数字更容易维护。

八、TCP 探针

1. 概念

TCP 探针尝试连接指定端口。

如果 TCP 连接成功，则认为探针成功。

YAML

tcpSocket:
  port: 3306

2. TCP 探针示例

YAML

3. TCP 探针适用场景

适合：

没有 HTTP 接口的 TCP 服务
Redis
MySQL
PostgreSQL
Kafka
自定义 TCP 服务
网络代理服务

4. TCP 探针的局限性

TCP 连接成功只能说明：

端口有人监听

不能说明：

应用业务正常
数据库可以执行查询
Redis 可以读写
服务可以处理有效请求

例如：

进程仍然监听 8080
但内部线程池全部死锁

TCP 探针可能仍然成功。

所以对于 HTTP 服务，通常优先选择具有业务含义的 HTTP 健康接口。

九、Exec 探针

1. 概念

Exec 探针在容器内部执行命令。

YAML

exec:
  command:
    - cat
    - /tmp/healthy

命令退出码为 0：

探针成功

非 0：

探针失败

2. Exec 探针示例

YAML

容器内如果存在：

/tmp/healthy

则探针成功。

3. Redis Exec 示例

YAML

如果 redis-cli ping 返回成功，则 Pod 就绪。

4. MySQL Exec 示例

YAML

注意：

容器镜像中必须有对应命令
命令执行会消耗容器资源
不要执行复杂或耗时很长的脚本
密码处理要注意安全
脚本退出码必须准确反映健康状态

5. Exec 探针的缺点

Exec 探针会在容器内启动进程，可能产生额外开销。

如果探针执行频率太高，例如：

YAML

periodSeconds: 1

可能导致：

创建大量子进程
增加 CPU 消耗
影响应用自身性能
探针进程堆积

因此，能用 HTTP 探针时，通常优先使用 HTTP 探针。

十、gRPC 探针

Kubernetes 支持对实现 gRPC Health Checking Protocol 的服务进行探测。

示例：

YAML

也可以指定服务名：

YAML

readinessProbe

应用需要实现标准 gRPC 健康检查接口。

gRPC 探针适合的场景

gRPC 服务
不提供 HTTP 接口的 RPC 服务
已经实现标准健康检查协议的微服务

注意：

port 必须是数字端口
内置 gRPC Probe 的配置能力相对简单
复杂 TLS、鉴权需求可能需要使用 Exec 探针或额外健康检查服务
gRPC 探针依赖应用实现标准健康检查协议

十一、一个完整 Deployment 示例

下面是一个同时配置三种探针的例子：

YAML

三个接口可以有不同含义：

/health/startup：应用是否完成启动
/health/live：应用是否还活着
/health/ready：应用是否可以接收流量

十二、Spring Boot 示例

Spring Boot 使用 Actuator 时，可以配置：

PROPERTIES

management.endpoint.health.probes.enabled=true
management.endpoints.web.exposure.include=health

常见接口：

/actuator/health/liveness
/actuator/health/readiness

Kubernetes 配置：

YAML

生产中不建议简单把所有外部依赖都放入 Liveness 检查。

例如：

数据库暂时不可用

这更可能意味着应用暂时“不应接收流量”，而不是应用本身已经死掉。

通常可以：

放入 Readiness
不放入 Liveness
避免数据库故障导致所有 Pod 无限重启

十三、探针参数详解

1. initialDelaySeconds

YAML

initialDelaySeconds: 30

容器启动后等待多少秒，再开始第一次探测。

不过配置 Startup Probe 后，通常不需要过度依赖 initialDelaySeconds。

2. periodSeconds

YAML

periodSeconds: 10

两次探测之间的间隔，单位是秒。

常见建议：

Readiness：5～10 秒
Liveness：10～30 秒
Startup：5～10 秒

具体要根据应用特点调整。

3. timeoutSeconds

YAML

timeoutSeconds: 3

单次探测最多等待多长时间。

如果健康接口本身只需要几十毫秒，通常不需要设置很大。

但也不要设置得过小，例如：

YAML

timeoutSeconds: 1

在高负载或网络抖动时可能产生误判。

4. failureThreshold

YAML

failureThreshold: 3

连续失败多少次后认为探针失败。

例如：

YAML

periodSeconds: 10
failureThreshold: 3

理论上大约连续失败 30 秒后触发动作。

对于 Liveness，不建议设置得过于敏感，否则短暂抖动就会重启应用。

5. successThreshold

YAML

successThreshold: 2

连续成功多少次后认为探针恢复成功。

限制：

Liveness 必须为 1
Startup 必须为 1
Readiness 可以大于或等于 1

Readiness 使用大于 1 可以减少短暂抖动造成的流量反复切换。

6. terminationGracePeriodSeconds

可以在探针级别指定终止宽限时间：

YAML

容器因 Liveness Probe 失败而被重启时，Kubernetes 会尝试优雅终止。

一般优先使用 Pod 级别的：

YAML

spec:
  terminationGracePeriodSeconds: 30

十四、探针与 Service 的关系

Readiness Probe 会影响 Service 的后端列表。

例如：

Pod A：Ready
Pod B：NotReady
Pod C：Ready

Service 通常只会把流量转发给：

Pod A
Pod C

查看 Endpoints：

BASH

kubectl get endpoints <service-name>

较新的 Kubernetes 也可以查看：

BASH

kubectl get endpointslice

如果所有 Pod 的 Readiness 都失败：

Service 没有可用后端

客户端可能收到：

Connection refused
503 Service Unavailable

十五、探针与滚动发布

Deployment 滚动更新时，Readiness Probe 非常重要。

过程大致是：

如果没有正确配置 Readiness Probe，Deployment 可能认为新 Pod 已经可以接收流量，导致：

流量发给还没启动完成的 Pod
请求失败
发布期间出现 5xx
旧 Pod 过早终止

十六、优雅终止与 Readiness

Pod 被删除时，通常会经历：

应用应该能够正确处理：

SIGTERM

例如：

停止接收新请求
等待已有请求完成
关闭数据库连接
刷新缓存
保存必要状态

可以配合：

YAML

但不建议只依赖 sleep，更重要的是应用本身要实现优雅关闭。

十七、Readiness Gate

除了内置 Readiness Probe，Pod 还可以使用自定义 Readiness Gate。

它允许外部控制器向 Pod 增加额外的就绪条件。

示例：

YAML

spec:
  readinessGates:
    - conditionType: example.com/ready

Pod 只有同时满足：

容器 Readiness Probe 成功
+
自定义 condition 为 True

才会被认为是 Ready。

适合：

云负载均衡器完成注册后才允许接收流量
网络插件完成配置后才允许提供服务
外部控制器确认资源已准备好
Service Mesh 或特殊平台集成

这是比较进阶的用法。

十八、常见错误配置

错误一：Liveness 检查外部依赖

例如：

Liveness Probe 检查数据库

当数据库短暂故障时：

更合理的方式通常是：

Readiness 检查数据库连接
Liveness 只检查应用自身是否还能工作

错误二：探针接口执行复杂逻辑

不建议健康接口每次都执行：

大量数据库查询
调用多个外部服务
复杂计算
读取大文件
访问多个远程系统

健康接口应该：

快速
轻量
稳定
可重复调用
不产生明显副作用

错误三：没有 Startup Probe，直接使用严格 Liveness

应用启动需要 2 分钟，但配置：

YAML

initialDelaySeconds: 5
failureThreshold: 3
periodSeconds:

大约 20 秒后就可能重启，导致应用永远启动不了。

改用 Startup Probe：

YAML

错误四：Readiness 接口永远返回成功

如果应用已经不能正常处理业务，但 Readiness 仍返回 200：

Pod 仍在 Service 后端
客户端继续访问
请求持续失败

Readiness 必须反映应用当前是否真的可以处理流量。

错误五：探针端口写错

容器监听：

探针却检查：

YAML

port: 80

结果必然失败。

可以检查：

BASH

kubectl exec -it <pod-name> -- sh

然后测试：

BASH

wget -qO- http://127.0.0.1:8080/healthz

错误六：健康接口只监听 localhost 或错误地址

容器内的 HTTP 探针通常从 Pod 网络命名空间访问。

应用应该监听：

0.0.0.0

而不是只监听某个不可访问地址。

十九、探针故障排查

1. 查看 Pod 事件

BASH

kubectl describe pod <pod-name>

常见事件：

Liveness probe failed
Readiness probe failed
Startup probe failed

2. 查看容器日志

BASH

kubectl logs <pod-name>

如果容器已经重启过：

BASH

kubectl logs <pod-name> --previous

3. 手工访问健康接口

进入容器：

BASH

kubectl exec -it <pod-name> -- sh

测试 HTTP：

BASH

wget -S -O- http://127.0.0.1:8080/healthz

如果镜像中有 curl：

BASH

curl -v http://127.0.0.1:8080/healthz

测试端口：

BASH

nc -zv 127.0.0.1 8080

4. 查看 Pod 状态

BASH

kubectl get pod <pod-name> -o wide

重点关注：

READY
RESTARTS
STATUS

例如：

READY   STATUS    RESTARTS
0/1     Running   5

可能表示：

容器存活但未就绪
Liveness 触发过多次重启
Readiness 接口失败

二十、推荐的探针设计方式

1. 一般 Web 应用

YAML

2. 启动快的简单服务

可以只配置：

YAML

3. 无 HTTP 接口的 TCP 服务

YAML

4. gRPC 服务

YAML

前提是应用实现 gRPC Health Checking Protocol。

5. 特殊服务使用 Exec

YAML

脚本要：

成功时退出 0
失败时退出非 0
执行时间短
不修改业务数据
不产生大量日志

二十一、一个更完整的生产示例

YAML

这个示例实现了：

慢启动保护
应用卡死自动重启
未就绪时不接收流量
发布时尽量保证服务不中断
终止前给请求处理留出时间
Readiness 连续成功两次后才重新接收流量

二十二、探针设计的核心原则

原则一：Liveness 不要过于敏感

Liveness 失败会重启容器，配置过于严格会造成：

短暂抖动 → 重启
网络延迟 → 重启
数据库短暂故障 → 重启

原则二：Readiness 可以更积极

Readiness 失败只会摘除流量，通常比重启更安全。

因此可以让 Readiness 更快反映应用状态。

原则三：Startup 用于保护慢启动

如果应用启动时间不稳定或较长，优先使用 Startup Probe，而不是把 Liveness 的 initialDelaySeconds 设置得特别大。

原则四：健康检查要有明确语义

推荐分别设计：

/live：应用本身是否还能运行
/ready：应用是否可以接收流量
/startup：应用是否完成初始化

不要让三个探针都简单访问同一个接口，却表达不同含义。

原则五：不要把健康检查做成业务接口

健康检查应该：

无副作用
快速返回
不修改数据
不依赖复杂流程
避免调用过多外部服务

二十三、最终总结

最重要的记忆方式是：

Startup：
你启动好了吗？
 
Liveness：

失败后的行为：

Startup 失败：
重启容器

常见组合：

生产环境中最推荐的思路是：

Startup 负责启动保护
Liveness 负责故障自愈
Readiness 负责流量控制

还有一些探针的进阶细节，但核心内容已经讲完了。补充几个生产中很实用的点：

1. 探针只检查容器，不检查 Service

探针配置在 Pod/Container 上，通常访问：

Pod IP + 容器端口

它不会经过：

Service
Ingress
外部负载均衡器

所以探针正常，不代表 Service、Ingress 或外部网络一定正常。

2. 探针请求一般不受 NetworkPolicy 影响

HTTP、TCP、Exec 探针由节点上的 kubelet 执行。不同网络插件实现可能略有差异，但不能简单把探针当作普通外部客户端流量。

如果健康检查依赖其他服务，还要考虑：

Pod 到依赖服务的网络策略
DNS
Service 解析
端口访问权限

3. 探针会消耗资源

每次探测都会产生资源开销：

HTTP/TCP：网络请求
Exec：创建进程
gRPC：建立或复用连接
健康接口：可能执行应用逻辑

不要把探测周期设置得过短，例如：

YAML

periodSeconds: 1

尤其不要让健康接口执行复杂 SQL 或大量远程调用。

4. 探针失败不等于应用一定崩溃

可能是：

探针路径错误
端口错误
应用启动慢
timeoutSeconds 太小
CPU 被限制
DNS 或网络异常
HTTPS 配置错误
健康接口本身实现有问题

排查时不要只看 RestartCount，还要看：

BASH

5. 使用 `terminationGracePeriodSeconds` 配合优雅退出

YAML

spec:
  terminationGracePeriodSeconds: 30

应用收到 SIGTERM 后，应当：

停止接收新请求
等待正在处理的请求完成
关闭数据库连接
刷新必要数据
正常退出

否则即使 Readiness 配置正确，仍可能出现请求中断或数据丢失。

6. Readiness 适合临时摘流量

如果应用遇到短暂问题，推荐：

Readiness 失败

而不是：

Liveness 失败

例如数据库短暂不可用时：

Readiness 失败：暂时停止接流量
Liveness 失败：重启应用

通常前者更安全，避免所有副本同时重启造成雪崩。

7. 健康检查最好区分三类状态

推荐定义：

/startup：初始化完成了吗？
/live：进程和核心运行循环正常吗？
/ready：依赖和业务条件满足，可以接流量吗？

典型判断：

接口	可以检查
startup	配置加载、端口启动、初始化任务
live	主线程、事件循环、关键内部状态
ready	数据库连接、缓存连接、配置加载、流量开关

但不要把所有外部依赖都放进 /live。

8. 注意 Pod 启动探针与容器重启策略

容器被探针杀死后，是否重新启动还与：

YAML

restartPolicy

有关。

Deployment、StatefulSet 中通常使用：

YAML

restartPolicy: Always

普通 Pod 常见：

YAML

restartPolicy: Never

如果是一次性 Job，不应该简单使用 Liveness Probe 代替任务状态判断。

9. Job/CronJob 不一定适合配置 Liveness

Job 的目标是：

任务执行完成并退出

如果给长时间运行的任务配置不合适的 Liveness，可能导致任务被反复重启。

Job 更关注：

进程退出码
backoffLimit
activeDeadlineSeconds
completions
parallelism

10. 探针和 PodDisruptionBudget 是不同机制

探针解决：

应用是否存活、是否接流量

PDB 解决：

节点维护或主动驱逐时，最多允许多少副本同时不可用

二者可以配合：

Readiness Probe + PDB + 多副本

实现更安全的滚动升级和节点维护。

11. 慢启动应用不要只把初始延迟调大

不推荐只写：

YAML

initialDelaySeconds: 300

更推荐：

YAML

这样启动完成后，Liveness 和 Readiness 可以立即按正常频率检查，而不是始终等待很长时间。

12. 探针参数可以按应用类型调整

普通 HTTP 服务

YAML

periodSeconds: 10
timeoutSeconds: 2
failureThreshold:

关键生产服务

YAML

periodSeconds: 5
timeoutSeconds: 3
failureThreshold:

慢启动 Java 应用

YAML

startupProbe:
  periodSeconds: 10
  failureThreshold: 60

高延迟批处理服务

可以适当增大：

YAML

timeoutSeconds: 5
failureThreshold: 5

参数没有绝对标准，应结合启动耗时、请求延迟和故障恢复策略测试。

13. 最终决策表

现象	适合的处理
应用启动很慢	Startup Probe
应用进程死锁	Liveness Probe
数据库暂时不可用	Readiness Probe
应用预热未完成	Readiness Probe
端口是否监听	TCP Probe
HTTP 接口是否正常	HTTP Probe
gRPC 健康状态	gRPC Probe
没有健康接口	Exec Probe
一次性任务执行完成	依靠进程退出码和 Job 状态

总结就是：

Startup：控制启动阶段
Liveness：负责自动重启
Readiness：负责流量摘除
HTTP/TCP/Exec/gRPC：负责定义“如何检查”

探针配置没有脱离应用独立存在，最终要结合：

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10

↓

Startup Probe 成功

↓

开始执行 Liveness Probe 和 Readiness Probe

startupProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 30

↓

Kubelet 重启容器

↓

容器重新启动

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3
  successThreshold: 1

↓

从 Service 后端摘除

↓

不再接收新的 Service 流量

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

livenessProbe:
  httpGet:
    scheme: HTTP
    path: /healthz
    port: 8080
  initialDelaySeconds: 20
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
    httpHeaders:
      - name: X-Health-Check
        value: Kubernetes

livenessProbe:
  httpGet:
    scheme: HTTPS
    path: /healthz
    port: 8443

httpGet:

path: /ready

port: http

livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3

livenessProbe:
  exec:
    command:
      - sh
      - -c
      - test -f /tmp/healthy
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

readinessProbe:

exec:

command:

- redis-cli

- ping

readinessProbe:
  exec:
    command:
      - sh
      - -c
      - mysqladmin ping -h 127.0.0.1 -uroot -p"$MYSQL_ROOT_PASSWORD"

livenessProbe:
  grpc:
    port: 50051
  initialDelaySeconds: 10
  periodSeconds: 10

:

grpc:

port: 50051

service: my-app-readiness

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
 
  template:
    metadata:
      labels:
        app: web-app
 
    spec:
      containers:
        - name: web
          image: example/web-app:1.0
          ports:
            - name: http
              containerPort: 8080
 
          startupProbe:
            httpGet:
              path: /health/startup
              port: http
            periodSeconds: 10
            timeoutSeconds: 3
            failureThreshold: 30
 
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
            periodSeconds: 10
            timeoutSeconds: 3
            failureThreshold: 3
 
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3
            successThreshold: 1

startupProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  failureThreshold: 30
  periodSeconds: 10
 
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
 
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  periodSeconds: 5
  failureThreshold: 3

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  terminationGracePeriodSeconds: 30

创建新 Pod
  ↓
新 Pod 启动
  ↓
Startup Probe 成功
  ↓
Readiness Probe 成功
  ↓
新 Pod 加入 Service
  ↓
旧 Pod 逐步退出

Pod 开始终止
  ↓
从 Service 中移除
  ↓
执行 preStop
  ↓
发送 SIGTERM
  ↓
等待 terminationGracePeriodSeconds
  ↓
发送 SIGKILL

lifecycle:
  preStop:
    exec:
      command:
        - sh
        - -c
        - sleep 10

数据库故障
  ↓
所有 Pod Liveness 失败
  ↓
所有 Pod 重启
  ↓
应用重连数据库
  ↓
数据库压力更大
  ↓
故障扩大

5

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

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  periodSeconds: 10
  failureThreshold: 30
 
livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
 
readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 3

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
 
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

livenessProbe:
  tcpSocket:
    port: 9000
 
readinessProbe:
  tcpSocket:
    port: 9000

livenessProbe:
  grpc:
    port: 50051
 
readinessProbe:
  grpc:
    port: 50051

readinessProbe:
  exec:
    command:
      - /bin/sh
      - -c
      - /app/check-ready.sh

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
 
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
 
  selector:
    matchLabels:
      app: order-service
 
  template:
    metadata:
      labels:
        app: order-service
 
    spec:
      terminationGracePeriodSeconds: 30
 
      containers:
        - name: order-service
          image: example/order-service:1.2.0
 
          ports:
            - name: http
              containerPort: 8080
 
          startupProbe:
            httpGet:
              path: /health/startup
              port: http
            periodSeconds: 10
            timeoutSeconds: 3
            failureThreshold: 30
 
          livenessProbe:
            httpGet:
              path: /health/live
              port: http
            periodSeconds: 10
            timeoutSeconds: 3
            failureThreshold: 3
 
          readinessProbe:
            httpGet:
              path: /health/ready
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3
            successThreshold: 2
 
          lifecycle:
            preStop:
              exec:
                command:
                  - sh
                  - -c
                  - sleep 5
 
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi

你还活着吗？

Readiness：

你现在能接流量吗？

Liveness 失败：

重启容器

Readiness 失败：

停止向 Pod 转发流量，但通常不重启容器

慢启动应用：
Startup + Liveness + Readiness
 
普通 HTTP 服务：
Liveness + Readiness
 
纯 TCP 服务：
TCP Liveness + TCP Readiness
 
gRPC 服务：
gRPC Liveness + gRPC Readiness
 
无健康接口的特殊服务：
Exec Probe

kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous

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

3

应用启动时间

健康接口语义

依赖服务

Service 流量

优雅终止

滚动发布

资源限制

PDB

LMr.Lu' Notes