livenessProbe 和 readinessProbe 最佳实践
在 Kubernetes 中，livenessProbe 和 readinessProbe 是确保应用高可用性的关键机制，但配置不当可能导致应用频繁重启或流量中断。以下是配置这两个探针的最佳实践：
1. 核心区别与作用
| 探针类型 | 目的 | 失败后果 |
|---|---|---|
| livenessProbe | 检测应用是否 存活（如死锁、内存泄漏）。 | 重启容器（kubectl restart） |
| readinessProbe | 检测应用是否 准备好接收流量（如依赖服务未就绪、缓存未加载）。 | 从 Service 的 Endpoints 移除 Pod |
2. 最佳实践指南
(1) 明确区分两个探针的用途
livenessProbe：- 保守检查：仅检测应用是否处于不可恢复的故障状态（如主线程崩溃）。一般服务没挂掉就认为是正常的。
- 避免敏感条件：例如，不要用业务逻辑失败（如数据库连接超时）触发重启，除非明确需要。
readinessProbe：- 严格检查：确保所有依赖（如数据库、通过 feign 调用的外部组件、中间件）就绪后才接收流量。
- 动态调整：在运行时若依赖服务不可用（如 Redis 宕机），应通过
readinessProbe主动拒绝流量。
(2) 设置合理的检查端点
-
为
livenessProbe和readinessProbe使用不同的 HTTP 路径：livenessProbe:httpGet:path: /health/liveness # 轻量级存活检查（仅进程存活）port: 8080 readinessProbe:httpGet:path: /health/readiness # 包含依赖检查（如数据库连接）port: 8080
(3) 配置合理的参数
livenessProbe:httpGet:path: /actuator/health/livenessport: 8080initialDelaySeconds: 10 # 应用启动后等待 10 秒再开始探测periodSeconds: 5 # 每 5 秒检查一次timeoutSeconds: 3 # 超时时间设为 3 秒failureThreshold: 3 # 连续失败 3 次后判定为故障readinessProbe:httpGet:path: /actuator/health/readinessport: 8080initialDelaySeconds: 5 # 比 livenessProbe 更早开始检查periodSeconds: 5timeoutSeconds: 3failureThreshold: 1 # 1 次失败即标记为未就绪
关键参数说明：
initialDelaySeconds：必须设置，避免应用未完成初始化就被判定为失败（如 JVM 启动慢）。failureThreshold：livenessProbe可设置较高（如 3），避免偶发故障触发重启。readinessProbe可设置较低（如 1），快速从负载均衡中剔除异常 Pod。
periodSeconds和timeoutSeconds：根据应用响应时间调整，避免超时误判。
(4) 结合 startupProbe 处理慢启动应用
对于启动时间较长的应用（如 Java 服务），使用 startupProbe 延迟 livenessProbe 和 readinessProbe 的启动：
startupProbe:httpGet:path: /actuator/health/startupport: 8080failureThreshold: 30 # 允许最多 30 次检查失败periodSeconds: 5 # 每 5 秒检查一次# 总等待时间 = failureThreshold * periodSeconds = 150 秒
如果想了解 k8s 为什么要专门提出 startupProb 来解决慢服务启动的问题，而不是直接把 livenessPro 中初始化的时间设置的长一点。可以参考下面的文章《为什么需要启动探针（StartupProb）？》。
(5) 选择适当的探测类型
-
HTTP GET：适合 Web 服务，通过状态码（2xx/3xx 表示成功）判断。
-
Exec：执行命令，返回 0 表示成功（适合非 HTTP 服务）：
readinessProbe:exec:command:- /app/check-dependency.sh # 自定义脚本检查依赖 -
TCP Socket：仅检查端口是否开放（适用非 HTTP 协议）。
(6) 避免依赖下游服务
readinessProbe不要深度检查外部依赖（如数据库、API）：- 若外部服务宕机，所有 Pod 都会被标记为未就绪，导致全面故障。
- 改为在应用内部实现熔断机制（如 Hystrix），部分功能降级。
(7) 日志与监控
- 记录探针检查结果：在
/health端点返回详细信息（如版本、依赖状态）。 - 监控探针失败：通过 Prometheus 监控
kubelet_probe_errors_total，及时报警。
3. 示例配置
Spring Boot 应用
apiVersion: apps/v1
kind: Deployment
spec:template:spec:containers:- name: applivenessProbe:httpGet:path: /actuator/health/livenessport: 8080initialDelaySeconds: 30periodSeconds: 10failureThreshold: 3readinessProbe:httpGet:path: /actuator/health/readinessport: 8080initialDelaySeconds: 5periodSeconds: 5failureThreshold: 1startupProbe:httpGet:path: /actuator/health/startupport: 8080failureThreshold: 30periodSeconds: 5