健康检查策略

Liveness 探测和 Readiness 探测是两种 Health Check 机制

1. 如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。

2. 两种探测的配置方法完全一样，支持的配置参数也一样。
   不同之处在于探测失败后的行为：

   (1). Liveness 探测是重启容器；
   (2). Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。

3. Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。
   (1). 用 Liveness 探测判断容器是否需要重启以实现自愈；
   (2). 用 Readiness 探测判断容器是否已经准备好对外提供服务。

我们先看下下面采用k8s部署方式时配置含有健康检查pod yaml的内容

• Liveness 探测
• Readiness 探测

Liveness 探测

Liveness 探测让用户可以自定义判断容器是否健康的条件。如果探测失败，Kubernetes 就会重启容器。

我们创建一个 Pod 的配置文件liveness.yaml，可以使用命令kubectl explain pod.spec.containers.livenessProbe查看其使用方法。

apiVersion: v1
kind: Pod
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 10
      periodSeconds: 5

启动进程首先创建文件 /tmp/healthy，30 秒后删除，在我们的设定中，如果 /tmp/healthy 文件存在，则认为容器处于正常状态，反正则发生故障。

livenessProbe 部分定义如何执行 Liveness 探测：

1. 探测的方法是：通过 cat 命令检查 /tmp/healthy 文件是否存在。如果命令执行成功，返回值为零，Kubernetes 则认为本次 Liveness 探测成功；如果命令返回值非零，本次 Liveness 探测失败。
2. initialDelaySeconds: 10 指定容器启动 10 之后开始执行 Liveness 探测，我们一般会根据应用启动的准备时间来设置。比如某个应用正常启动要花 30 秒，那么 initialDelaySeconds 的值就应该大于 30。
3. periodSeconds: 5指定每 5 秒执行一次 Liveness 探测。Kubernetes 如果连续执行 3 次 Liveness 探测均失败，则会杀掉并重启容器。

Readiness 探测

通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。

Readiness 探测的配置语法与 Liveness 探测完全一样，我们创建配置文件readiness.yaml。

apiVersion: v1
kind: Pod
metadata:
  name: readiness
  labels:
    test: readiness
spec:
  restartPolicy: OnFailure
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 10
      periodSeconds: 5

界面配置操作

在界面直接修改升级容器的配置

验证效果

手动模拟pod中进程停服
进入到pod中，kill掉flink的TM进程，发现如下现象

• 若只配置liveness，则会全量重启全部pod！！！
• 若配置了liveness以及readiness，则只会单独重启有问题的pod

后台检查pod详情
kubectl describe pod course-flink-test-taskmanager-1 -n course-data-infra

查看pod的Event事件发现Livenes probe与Readiness probe都检测到了failed事件，各自执行自己的自愈动作

对任务也没有影响