Liveness Probe

有时候应用的一些功能崩溃了，但pod状态还在正常运行。此时如果流量打到上面，用户就会访问到异常的界面。

如果定义了Liveness Probe，定时检测健康状态和功能，检测到异常后将pod重启，就能避免这种情况

  • 许多长时间运行的应用程序最终会转变为损坏状态，并且除非重新启动否则无法恢复。
  • Kubernetes 提供Liveness Probe来检测和修复此类情况:

image-20200119171045635

实践

创建一个nginx容器，执行命令检查service nginx status

apiVersion: v1
kind: Pod
metadata:
  name: liveness
spec:
  containers:
    - image: nginx
      name: nginx
      tty: true
      livenessProbe:
        exec:
          command:
            - service
            - nginx
            - status
        initialDelaySeconds: 20
        periodSeconds: 5

  • initialDelaySeconds：容器启动后启动活动或就绪探测之前的秒数。 默认为 0 秒。 最小值为 0。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测之前应该等待 20 秒。

  • periodSeconds：执行探测的频率（以秒为单位）。 默认为 10 秒。最小值为 1。

  • timeoutSeconds：探测超时之前的秒数。 默认为 1 秒。最小值为 1。
  • successThreshold：探测失败后被视为成功的最小连续成功次数。 默认为 1。最小值为 1。
  • failureThreshold：当 Pod 启动且探测失败时，Kubernetes 将在放弃之前尝试 failureThreshold 次。 默认为 3。 最小值为 1。

由于执行service nginx status返回正常，所以pod不会restart：

image-20200322154614624


重新更改pod定义，使用ubuntu镜像，由于ubuntu没有装nginx，所以健康检查会失败：

apiVersion: v1
kind: Pod
metadata:
  name: liveness2
spec:
  containers:
    - image: ubuntu
      name: ubuntu
      tty: true
      livenessProbe:
        exec:
          command:
            - service
            - nginx
            - status
        initialDelaySeconds: 20
        periodSeconds: 5

由于进行健康检查失败，所以liveness2会不断Crash和Restart：

image-20200322155011234

3种probe

有 3 种类型的探针可与 Liveness 一起使用：

  • HTTP
  • Command
  • TCP