livenessProbe 和 readinessProbe 最佳实践

在 Kubernetes 中,livenessProbe 和 readinessProbe 是确保应用高可用性的关键机制,但配置不当可能导致应用频繁重启或流量中断。以下是配置这两个探针的最佳实践:

1. 核心区别与作用

探针类型 目的 失败后果
livenessProbe 检测应用是否 存活(如死锁、内存泄漏)。 重启容器(kubectl restart
readinessProbe 检测应用是否 准备好接收流量(如依赖服务未就绪、缓存未加载)。 从 Service 的 Endpoints 移除 Pod

2. 最佳实践指南

(1) 明确区分两个探针的用途
  • livenessProbe
    • 保守检查:仅检测应用是否处于不可恢复的故障状态(如主线程崩溃)。一般服务没挂掉就认为是正常的。
    • 避免敏感条件:例如,不要用业务逻辑失败(如数据库连接超时)触发重启,除非明确需要。
  • readinessProbe
    • 严格检查:确保所有依赖(如数据库、通过 feign 调用的外部组件、中间件)就绪后才接收流量。
    • 动态调整 :在运行时若依赖服务不可用(如 Redis 宕机),应通过 readinessProbe 主动拒绝流量。
(2) 设置合理的检查端点
  • livenessProbereadinessProbe 使用不同的 HTTP 路径

    yaml 复制代码
    livenessProbe:
      httpGet:
        path: /health/liveness   # 轻量级存活检查(仅进程存活)
        port: 8080
    readinessProbe:
      httpGet:
        path: /health/readiness  # 包含依赖检查(如数据库连接)
        port: 8080
(3) 配置合理的参数
yaml 复制代码
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 10   # 应用启动后等待 10 秒再开始探测
  periodSeconds: 5          # 每 5 秒检查一次
  timeoutSeconds: 3         # 超时时间设为 3 秒
  failureThreshold: 3       # 连续失败 3 次后判定为故障

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 5    # 比 livenessProbe 更早开始检查
  periodSeconds: 5
  timeoutSeconds: 3
  failureThreshold: 1       # 1 次失败即标记为未就绪

关键参数说明

  • initialDelaySeconds必须设置,避免应用未完成初始化就被判定为失败(如 JVM 启动慢)。
  • failureThreshold
    • livenessProbe 可设置较高(如 3),避免偶发故障触发重启。
    • readinessProbe 可设置较低(如 1),快速从负载均衡中剔除异常 Pod。
  • periodSecondstimeoutSeconds:根据应用响应时间调整,避免超时误判。
(4) 结合 startupProbe 处理慢启动应用

对于启动时间较长的应用(如 Java 服务),使用 startupProbe 延迟 livenessProbereadinessProbe 的启动:

yaml 复制代码
startupProbe:
  httpGet:
    path: /actuator/health/startup
    port: 8080
  failureThreshold: 30  # 允许最多 30 次检查失败
  periodSeconds: 5      # 每 5 秒检查一次
  # 总等待时间 = failureThreshold * periodSeconds = 150 秒

如果想了解 k8s 为什么要专门提出 startupProb 来解决慢服务启动的问题,而不是直接把 livenessPro 中初始化的时间设置的长一点。可以参考下面的文章《为什么需要启动探针(StartupProb)?》

(5) 选择适当的探测类型
  • HTTP GET:适合 Web 服务,通过状态码(2xx/3xx 表示成功)判断。

  • Exec:执行命令,返回 0 表示成功(适合非 HTTP 服务):

    yaml 复制代码
    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 应用
yaml 复制代码
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: app
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            failureThreshold: 1
          startupProbe:
            httpGet:
              path: /actuator/health/startup
              port: 8080
            failureThreshold: 30
            periodSeconds: 5
相关推荐
小安运维日记几秒前
RHCA - DO374 | Day01:使用红帽Ansible自动化平台开发剧本
运维·服务器·云原生·自动化·云计算·ansible
白帽子黑客罗哥44 分钟前
云原生安全深度实战:从容器安全到零信任架构
安全·云原生·架构·零信任·容器安全·kubernetes安全·服务网络
Asuncion0072 小时前
K8s控制器详解:从原理到实战
docker·容器·kubernetes
做运维的阿瑞2 小时前
DevOps 生命周期完全指南
运维·容器·devops
大大大大物~3 小时前
数据结构之HashMap(容器)
java·数据结构·容器
梁正雄4 小时前
扩展、Docker-compose-1
docker·容器·composer
知花实央l4 小时前
【数字逻辑】数字逻辑实验实战:74HC151实现逻辑函数+74HC138搭全加器(附接线步骤+避坑指南)
算法·容器·测试用例·逻辑回归
研究司马懿4 小时前
【GitOps】Argo CD app of apps
大数据·开发语言·elasticsearch·搜索引擎·云原生·argocd·gitops
王忘杰4 小时前
K8S Kubernetes集群部署
kubernetes
你总是一副不开心的样子(´ . .̫ .6 小时前
关于监控与部署
云原生·容器·kubernetes