k8s之liveness and readness

作用：

1. 首先是应用的健康状态上面，可以实时地进行观测；
2. 第二个是可以获取应用的资源使用情况；
3. 第三个是可以拿到应用的实时日志，进行问题的诊断与分析。
   当出现了问题之后，首先要做的事情是要降低影响的范围，进行问题的调试与诊断。最后当出现问题的时候，理想的状况是：可以通过和 K8s 集成的自愈机制进行完整的恢复。
   两种probe
   Liveness（存活探针）
   Readness（就绪探针）
   介绍
   用于判断容器是否存活，既 Pod 状态是否为 running，如果 Liveness 探针判断容器不健康，则会触发 kubelet 杀掉容器，并根据配置的策略判断是否重启容器，如果默认不配置 Liveness 探针，则认为返回默认值认为成功
   用于判断容器是否启动完成，既 Pod 的 Condition 是否为 Ready，如果探测结果不成功，则会将 Pod 从 Endpoint 中移除，直至下次判断成功，再将 Pod 挂回到 Endpoint 上
   检测失败
   Pod挂掉
   切断上层流量到 Pod
   适用场景
   支持重新拉起的应用
   启动后无法立即对外服务的应用
   注意事项
   不论是 Liveness 还是 Readness 探针，选择合适的探测方式可以防止被误操作

2.Liveness 存活指针

Liveness probe 来确定你的应用程序是否正在运行，通俗点将就是是否还活着。一般来说，如果你的程序一旦崩溃了， Kubernetes 就会立刻知道这个程序已经终止了，然后就会重启这个程序。而我们的 liveness probe 的目的就是来捕获到当前应用程序还没有终止，还没有崩溃，如果出现了这些情况，那么就重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去。 kubelet 使用活跃度探头知道什么时候重新启动的容器。例如，liveness probe 可以捕获死锁，应用程序正在运行，但无法取得进展。在这种状态下重新启动容器可以继续存活。
3.Readiness 就绪探针

Readiness 也叫就绪指针，用来判断一个 pod 是否处在就绪状态。当一个 pod 处在就绪状态的时候，它才能够对外提供相应的服务，也就是说接入层的流量才能打到相应的 pod。当这个 pod 不处在就绪状态的时候，接入层会把相应的流量从这个 pod 上面进行摘除。
readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了，现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态，因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态，那么我们就会将他从我们的工作队列(实际上就是我们后面需要重点学习的 Service)中移除出来，这样我们的流量就不会被路由到这个 Pod 里面来了。 使用 readiness probe 来了解容器何时准备开始接受流量。当所有容器准备就绪时，Pod 被认为已准备就绪。此信号的一个用途是控制哪些 Pod 用作服务的后端。当 Pod 未就绪时，它将从服务负载平衡器中删除。例如当一个应用服务有大文件加载时，这种情况下不允许接受用户访问，readiness probe 就不会对这类型的程序启动服务。
4.探测方式

Liveness 指针和 Readiness 指针支持三种不同的探测方式：
1.第一种是 http.Get。它是通过发送 http Get 请求来进行判断的，当返回码是 200-399 之间的状态码时，标识这个应用是健康的
httpGet 里面有一个字段是路径，第二个字段是 port，第三个是 headers。这个地方有时需要通过类似像 header 头的一个机制做 health 的一个判断时，需要配置这个 header，通常情况下，可能只需要通过 health 和 port 的方式就可以了。
spec:
containers:

• name: liveness-http
  image: xxxxx/busybox
  livenessProbe:
  httpGet:
  path: /healthz
  port: 8080
  httpHeaders:
  - name: Custom-Header
  value: Awesome
  initialDelaySeconds: 3
  2.第二种探测方式是 Exec，它是通过执行容器中的一个命令来判断当前的服务是否是正常的，当命令的返回结果是 0，则标识容器是健康的。
  Liveness probe，它里面配置了一个 exec 的一个诊断。接下来，它又配置了一个 command 的字段，这个 command 字段里面通过 cat 一个具体的文件来判断当前 Liveness probe 的状态，当这个文件里面返回的结果是 0 时，或者说这个命令返回是 0 时，它会认为此时这个 pod 是处在健康的一个状态。
  spec:
  containers:
• name: liveness
  image: xxxxx/busybox
  args:
  • /bin/sh
  • -c
  • touch /tmp/healthy
    lienessProbe:
    exec:
    command:
    • cat
  • /tmp/healthy
    3.第三种探测方式是 tcpSocket，它是通过探测容器的 IP 和 Port 进行 TCP 健康检查，如果这个 TCP 的链接能够正常被建立，那么标识当前这个容器是健康的
    tcpSocket 的使用方式其实也比较简单，你只需要设置一个检测的端口，像这个例子里面使用的是 8080 端口，当这个 8080 端口 tcp connect 审核正常被建立的时候，那 tecSocket，Probe 会认为是健康的一个状态。
    spec:
    containers:
• name: goproxy
  image: xxxxx/busybox
  ports:
• containerPort: 8080
  readinessProbe:
  tcpSocket:
  port: 8080
  livenessProbe:
  tcpSocket:
  port: 8080
  5.探测结果

从探测结果来讲主要分为三种：

• 第一种是 success，当状态是 success 的时候，表示 container 通过了健康检查，也就是 Liveness probe 或 Readiness probe 是正常的一个状态；
• 第二种是 Failure，Failure 表示的是这个 container 没有通过健康检查，如果没有通过健康检查的话，那么此时就会进行相应的一个处理，那在 Readiness 处理的一个方式就是通过 service。service 层将没有通过 Readiness 的 pod 进行摘除，而 Liveness 就是将这个 pod 进行重新拉起，或者是删除。
• 第三种状态是 Unknown，Unknown 是表示说当前的执行的机制没有进行完整的一个执行，可能是因为类似像超时或者像一些脚本没有及时返回，那么此时 Readiness-probe 或 Liveness-probe 会不做任何的一个操作，会等待下一次的机制来进行检验。
  那在 kubelet 里面有一个叫 ProbeManager 的组件，这个组件里面会包含 Liveness-probe 或 Readiness-probe，这两个 probe 会将相应的 Liveness 诊断和 Readiness 诊断作用在 pod 之上，来实现一个具体的判断。

6. Global 的参数

Global 的参数。

• 第一个参数叫 initialDelaySeconds，它表示的是说这个 pod 启动延迟多久进行一次检查，比如说现在有一个 Java 的应用，它启动的时间可能会比较长，因为涉及到 jvm 的启动，包括 Java 自身 jar 的加载。所以前期，可能有一段时间是没有办法被检测的，而这个时间又是可预期的，那这时可能要设置一下 initialDelaySeconds；
• 第二个是 periodSeconds，它表示的是检测的时间间隔，正常默认的这个值是 10 秒；
• 第三个字段是 timeoutSeconds，它表示的是检测的超时时间，当超时时间之内没有检测成功，那它会认为是失败的一个状态；
• 第四个是 successThreshold，它表示的是：当这个 pod 从探测失败到再一次判断探测成功，所需要的阈值次数，默认情况下是 1 次，表示原本是失败的，那接下来探测这一次成功了，就会认为这个 pod 是处在一个探针状态正常的一个状态；
• 最后一个参数是 failureThreshold，它表示的是探测失败的重试次数，默认值是 3，表示的是当从一个健康的状态连续探测 3 次失败，那此时会判断当前这个 pod 的状态处在一个失败的状态。

两种probe相互作用，只设置其中一种都无法正常监测集群内容器健康状态。
例如：只配置了Liveness，那么在容器启动，应用还没有成功就绪之前，这个时候Pod是ready的（因为容器成功启动了）。那么流量就会被引入到容器的应用中，可能会导致请求失败。虽然在Liveness检查失败后，重启容器，此时Pod的ready的condition会变为false。但是前面会有一些流量因为错误状态导入。

当然只配置了Readiness是无法触发容器重启的

注意事项：
在使用 Liveness 指针和 Readiness 指针的时候有一些注意事项。因为不论是 Liveness 指针还是 Readiness 指针都需要配置合适的探测方式，以免被误操作。

• 第一个是调大超时的阈值，因为在容器里面执行一个 shell 脚本，它的执行时长是非常长的，平时在一台 ecs 或者在一台 vm 上执行，可能 3 秒钟返回的一个脚本在容器里面需要 30 秒钟。所以这个时间是需要在容器里面事先进行一个判断的，那如果可以调大超时阈值的方式，来防止由于容器压力比较大的时候出现偶发的超时；
• 第二个是调整判断的一个次数，3 次的默认值其实在比较短周期的判断周期之下，不一定是最佳实践，适当调整一下判断的次数也是一个比较好的方式；
• 第三个是 exec，如果是使用 shell 脚本的这个判断，调用时间会比较长，比较建议大家可以使用类似像一些编译性的脚本 Golang 或者一些 C 语言、C++ 编译出来的这个二进制的 binary 进行判断，那这种通常会比 shell 脚本的执行效率高 30% 到 50%；
• 第四个是如果使用 tcpSocket 方式进行判断的时候，如果遇到了 TLS 的服务，那可能会造成后边 TLS 里面有很多这种未健全的 tcp connection，那这个时候需要自己对业务场景上来判断，这种的链接是否会对业务造成影响

应用部署
vi liveness.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-exec
  name: liveness-exec
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness-exec
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/healthy"]
      initialDelaySeconds: 5    #探测延时时长，第一次探测前等待5秒，默认为0
      periodSeconds: 5          #每5秒执行一次liveness探测,默认值10秒，最小1秒
      timeoutSeconds: 2         #超长时长，默认为1s,最小值也为1s
      failureThreshold: 3       #处于成功状态时，探测操作至少连续多少次的失败才被视为检测不通过，默认为3，最小为1

创建

kubectl apply -f live.yaml --validate=false

查看

kubectl describe po liveness-exec

Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  3m24s                default-scheduler  Successfully assigned kuberhealthy/liveness-exec to dce-10-6-116-12
  Normal   Pulled     67s (x3 over 2m59s)  kubelet            Successfully pulled image "busybox"
  Normal   Created    66s (x3 over 2m59s)  kubelet            Created container liveness-exec
  Normal   Started    65s (x3 over 2m58s)  kubelet            Started container liveness-exec
  Warning  Unhealthy  42s (x9 over 2m47s)  kubelet            Liveness probe failed:
  Normal   Killing    42s (x3 over 2m37s)  kubelet            Container liveness-exec failed liveness probe, will be restarted
  Normal   Pulling    12s (x4 over 3m19s)  kubelet            Pulling image "busybox"

验证成功

http方式

apiVersion : v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness-http
    image: nginx
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh" ,"-c","echo liveness-http test > /usr/share/nginx/html/health"]
    livenessProbe:
      httpGet:
        path: /health
        port: http
        scheme: HTTP

创建

[root@dce-10-6-116-10 ~]# kubectl apply -f live-http.yaml --validate=false

[root@dce-10-6-116-10 ~]# kubectl get po -o wide
liveness-http           1/1     Running             0          91s   172.29.213.217   dce-10-6-116-12   <none>           <none>

测试

[root@dce-10-6-116-10 ~]# curl 172.29.213.217/health
liveness-http test

删除测试页面health

[root@dce-10-6-116-10 ~]# curl 172.29.213.217/health
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.21.3</center>
</body>
</html>

发现容器重启一次

[root@dce-10-6-116-10 ~]# kubectl get po -o wide
liveness-http           1/1     Running             1          7m13s   172.29.213.217   dce-10-6-116-12   <none>           <none>