Kubernetes-启动/存活/就绪探针

背景

当一个新Pod创建后，Service就能立即选择到它，并会把请求转发给Pod 。但是通常一个Pod启动是需要时间的，部分应用在启动时需要进行加载上游相关服务连接等，如果Pod还没准备好，这时把请求转给Pod的话，Pod也无法处理，会造成请求失败的情况发生。

简介

启动探针（Startup Probe）：用于检查容器中的应用是否已经启动。如果启动探针失败，Kubernetes会等待一段时间，然后再次进行检查，直到应用启动。这可以用于应用启动时间较长，需要一段时间初始化的场景。如果配置了这类探针，存活探针和就绪探针成功之前不会重启，确保这些探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。

存活探针（Liveness Probe）：用于检查容器是否还在运行。如果存活探针失败，Kubernetes会杀掉容器，然后根据我们的部署配置来重启它。可以用于应用自身无法恢复的问题，需要重启来恢复的场景（如死锁）。

就绪探针（Readiness Probe）：用于检查容器是否准备好服务请求。如果就绪探针失败，Kubernetes会停止将流量转发到该Pod，直到探针再次成功。这可以用于控制哪些Pod应该接收流量，哪些不应该。

探测方式

• 支持 存活命令 （命令返回0值则表示存活）
• http接口（返回大于或等于 200 并且小于 400 的任何代码都表示成功）
• tcp探活（如果能建立连接，这个容器就被看作是健康的）
• grpc探活（需要实现监控检查接口）

相关参数

• initialDelaySeconds：容器启动后要等待多少秒后才启动启动、存活和就绪探针。 如果定义了启动探针则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。 如果 periodSeconds 的值大于 initialDelaySeconds，则 initialDelaySeconds 将被忽略。默认是 0 秒，最小值是 0。

• periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。

• timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。

• successThreshold：探针在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。

• failureThreshold：探针连续失败了 failureThreshold 次之后， Kubernetes 认为总体上检查已失败：容器状态未就绪、不健康、不活跃。 对于启动探针或存活探针而言，如果至少有 failureThreshold 个探针已失败， Kubernetes 会将容器视为不健康并为这个特定的容器触发重启操作。 kubelet 遵循该容器的 terminationGracePeriodSeconds 设置。 对于失败的就绪探针，kubelet 继续运行检查失败的容器，并继续运行更多探针； 因为检查失败，kubelet 将 Pod 的 Ready 状况 设置为 false。

• terminationGracePeriodSeconds：为 kubelet 配置从为失败的容器触发终止操作到强制容器运行时停止该容器之前等待的宽限时长。 默认值是继承 Pod 级别的 terminationGracePeriodSeconds 值（如果不设置则为 30 秒），最小值为 1。

启动探针

例子：

ports:
name: liveness-port
  containerPort: 8080
# 配置存活探针
livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1 # 失败一次就会进行重启
  periodSeconds: 10 # 每10秒进行一次探活
  
# 配置启动探针
startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30 # 最多失败30次（10*30=300s）超过
  periodSeconds: 10 # 每10秒进行检查一次

应用将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器状态作出快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 restartPolicy 来执行进一步处置。

存活探针

livenessProbe:
  initialDelaySeconds: 3 # 执行第一次探测前应该等待 3 秒
  failureThreshold: 1 # 失败一次就会进行重启
  periodSeconds: 3 # 每三秒执行一次
  httpGet:
    path: /healthz
    port: 8080

在上面的配置中，执行第一次探测前会等待 3 秒，然后每3秒执行一次，如果http接口返回大于或等于 200 并且小于 400 的任何代码则认为容器是健康存活的。 如果处理程序返回失败代码，则 kubelet 会杀死这个容器然后将其重启。

就绪探针

readinessProbe: 
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10 # 每10秒进行一次检查是否就绪
  initialDelaySeconds: 3 # 首次执行前先等待3s

就绪探针检查容器是否已经准备好接收请求（流量），如果探测成功则会进行转发请求。就绪探针确保服务中的pod都是可用的，确保客户端只与正常的pod交互并且客户端永远不会知道系统存在问题。不会像存活探针探测失败会重启pod。

注意：就绪探针和存活探针在容器的整个生命周期中保持运行状态。

就绪和存活探测可以在同一个容器上并行使用。 两者共同使用，可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。

livenessProbe:
  initialDelaySeconds: 3 # 执行第一次探测前应该等待 3 秒
  failureThreshold: 1 # 失败一次就会进行重启
  periodSeconds: 3 # 每三秒执行一次
  httpGet:
    path: /healthz
    port: 8080
readinessProbe: 
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10 # 每10秒进行一次检查是否就绪
  initialDelaySeconds: 3 # 首次执行前先等待3s

应用

探针接口日志排除

因为探测的接口比较频繁，如果都采集到es会导致大量的日志数据都是healthz接口的日志，所以决定不采集该接口的日志。

1. fluentd配置文件新增过滤器排除掉healthz接口（end filter）

   <filter kubernetes.**>
         @type grep
         <exclude>
           key message
           pattern /.*\/healthz/
         </exclude>
       </filter>

   

2. 测试访问healthz接口是否还能落库

1. 可以看到已经没有healthz日志数据入库

应用模板改造

HTTP 应用

- containerPort: {{.Port}}
  name: http # 添加http名字方便直接进行引用

# 存活探针
  livenessProbe:
    failureThreshold: 3 #连续3次探测失败则会根据restartPolicy进行处理
    initialDelaySeconds: 5 # 首次执行前delay 5秒
    periodSeconds: 5 # 每5s探测一次
    successThreshold: 1 # 成功1次即可向该pod发送流量
    timeoutSeconds: 1 # 探测超时时间(秒)
    httpGet:
      path: /healthz
      port: http
  # 就绪探针
  readinessProbe:
    failureThreshold: 3 # 连续3次探测失败则不向该pod发送流量
    initialDelaySeconds: 5 # 首次执行前delay 5秒
    periodSeconds: 5 # 每5s探测一次
    successThreshold: 1 # 成功1次即可向该pod发送流量
    timeoutSeconds: 1 # 探测超时时间(秒)
    httpGet:
      path: /healthz
      port: http

GRPC 应用

需要实现grpc的healthz标准访问接口

TODO

资料

1. Fluentd config：https://docs.fluentd.org/configuration/config-file
2. Liveness readiness probes：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
3. Grpc health check：https://github.com/grpc/grpc/blob/master/doc/health-checking.md