Kubernetes健康检查

2025-06-03 18:15:00
丁国栋
原创 8
摘要:本文记录和整理Kubernetes健康检查配置。

在应用滚动更新中健康检查是非常重要的,只有通过检测的Pod才能接收业务流量。在健康检查中有两种探针,分别是readinessProbe和livenessProbe,它们有明显的不同使用场景和设计目的。

以下是Kubernetes中readinessProbe和livenessProbe的区别

  • livenessProbe:检测容器是否存活(是否需要重启)。当探测失败时,kubelet会终止容器并根据重启策略重启Pod。

  • readinessProbe:检测容器是否就绪(是否可接收流量)。探测失败时,Pod会被从Service的Endpoint中移除,但不会触发重启。

livenessProbe(存活探针)

  • 作用:检测 Pod 是否正常运行

  • 失败后果:杀死并重启 Pod(触发 CrashLoopBackoff)

  • 设计目标:恢复不可用的服务实例

readinessProbe(就绪探针)

  • 作用:检测 Pod 是否准备好接收流量

  • 失败后果:从 Service 的 Endpoints 列表中移除该 Pod,不再分配新流量

  • 设计目标:保证流量只转发到真正能处理请求的 Pod

特性 readinessProbe livenessProbe
探测目标 服务是否准备好处理请求 容器是否处于健康运行状态
失败动作 从Service Endpoints移除 重启容器(KILL+重新调度)
检查频率 高频(默认每10秒) 低频(建议30秒+)
生产环境必要性 必需 推荐

典型场景‌

  • livenessProbe:适用于处理死锁、内存泄漏等需重启恢复的场景。

  • readinessProbe:适用于启动初始化、大文件加载等临时不可用但无需重启的场景。

         readinessProbe:
           failureThreshold: 10 # 当探测失败时,Kubernetes 的重试次数。针对 HTTP 或 TCP 检测,可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间。
           httpGet:
             path: /misc-status # 返回大于或等于 200 并且小于 400 的任何代码都标示成功,其它返回代码都标示失败。
             port: 80
             scheme: HTTP
           initialDelaySeconds: 5 # initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒
           periodSeconds: 5 # periodSeconds 字段指定了 kubelet 每隔 5 秒执行一次存活探测。
           successThreshold: 1 # 探针在失败后,被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。
           timeoutSeconds: 2 # 探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。


生产环境配置示例

  1. ‌HTTP服务的完整配置‌
apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
- name: nginx
    image: nginx:1.25
    ports:
  - containerPort: 80
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
        httpHeaders:
    - name: X-Probe-Type
          value: "liveness"
      initialDelaySeconds: 30  # 容器启动后30秒开始探测
      periodSeconds: 10        # 每10秒探测一次
      timeoutSeconds: 3        # 超时时间3秒
      failureThreshold: 3      # 连续失败3次标记为不健康
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5   # 容器启动后5秒开始探测
      periodSeconds: 5         # 每5秒探测一次
      successThreshold: 1      # 成功1次即标记为就绪
      failureThreshold: 2      # 连续失败2次标记为不就绪
  1. ‌TCP服务的完整配置‌
apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
- name: redis
    image: redis:7.2
    ports:
  - containerPort: 6379
    livenessProbe:
      tcpSocket:
        port: 6379
      initialDelaySeconds: 20
      periodSeconds: 15
    readinessProbe:
      exec:
        command: ["redis-cli", "ping"]
      initialDelaySeconds: 10
      periodSeconds: 5

关键配置参数说明

参数 作用
initialDelaySeconds 容器启动后延迟探测的时间(避免启动阶段误判)
periodSeconds 探测频率(默认10秒)
failureThreshold 连续失败次数后标记为不健康(liveness触发重启,readiness触发流量移除)
timeoutSeconds 单次探测超时时间(超过则视为失败)

最佳实践建议

  • 渐进式配置‌:初始部署时调高failureThreshold避免误重启。

  • 独立健康端点‌:为livenessProbe和readinessProbe设计不同路径(如/healthz和/ready)。

  • 组合使用‌:readinessProbe确保流量切换平滑,livenessProbe处理不可恢复错误。

readinessProbe计算逻辑

initialDelay = max(容器启动时间, 依赖服务初始化时间) + 10s缓冲

periodSeconds = min(服务SLA响应时间/2, 10) # 通常5-10秒

failureThreshold = ceil(最大预期抖动时间/periodSeconds) + 1


参考:https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/


发表评论
博客分类