k8s容器健康检查

一、概述

RestartPolicy

默认情况下，容器启动的时候会执行一个主进程，如果进程退出码不是0，则k8s会认为该容器异常，而此时k8s会根据事先设置的restartPolicy策略来选择如何处理容器。目前常用的restartPolicy有以下三种：

Always：当容器终止退出后，总是重启容器，默认策略
Onfailure：当容器异常退出时（退出码为非0），重启容器
Never：当容器终止退出时，不重启容器

健康检查机制

如上述所述，restartpolicy的触发条件是容器退出的返回值为非零，然后被认为是容器故障，需要重启。但是，很多时候容器pod本身的启动没有异常，而却出现了应用层面上的错误，如资源资源锁死，进程OOM等等，此时服务依旧是启动失败，但是容器并没有触发重启操作，这种情况下就需要k8s的健康检查机制出手了。
k8s的健康检查（Health Check）常用于检测容器中的应用实例是否处于正常工作中，是一种用于保障业务可用性的机制。在负载均衡的情况下，如果实例的状态不符合预期，则会把该实例“踢”下线，不承担相应的业务流量，等待其重启恢复正常。
k8s的健康检查有主要以探针的方式来进行，目前有以下三种探针：

Liveness probes
Readiness probes
Startup probes

而通过结合Restartpolicy和健康检查机制，k8s可以实现以下需求：

异常实例自动剔除并重启相关实例
多种类型探针检查，保证异常的pod不接受业务流量
无感发布，可用性更高的滚动升级

二、探针的探测方式及参数

上述描述的三类探针目前支持的探测方式包括以下三种方式：

httpGet
tcpSocket
exec

除了上述方式以外，探针还支持很多配置参数，通过这些参数能够精确地控制指针的检测行为：

#全局参数
initialDelaySeconds：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。
periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。存活探测的这个值必须是 1。最小值是 1。
failureThreshold：当探测失败时，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
#对于http检测方式的指针，可以在httpGet上配置额外的参数字段
host：连接使用的主机名，默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。
scheme ：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 HTTP。
path：访问 HTTP 服务的路径。
httpHeaders：请求中自定义的 HTTP 头。HTTP 头字段允许重复。
port：访问容器的端口号或者端口名。如果数字必须在 1 ～ 65535 之间。

三、livenessProbe

Liveness probes（存活性探针）用于检查容器pod中的应用程序是否存活，当pod中的应用程序被检查为不存活时，k8s会删除pod并按照设定的restartpolicy处理pod。

配置exec方式的Liveness probes

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: tomcat
  name: tomcat-example
spec:
  containers:
  - name: tomcat
    image: dockerhub.kungeek.com/csp/ftsp-api-test:11111
    ports:
    - containerPort: 8080      
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 5

这种方式的存活检测，kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。

配置TCP方式的Liveness probes

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: tomcat
  name: tomcat-example
spec:
  containers:
  - name: tomcat
    image: dockerhub.kungeek.com/csp/ftsp-api-test:11111
    ports:
    - containerPort: 8080      
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 5

这种方式的存活探测是使用 TCP 套接字。通过配置，kubelet 会尝试在指定端口和容器建立套接字链接。如果能建立链接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。

配置http方式的Liveness probes

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: tomcat
  name: tomcat-example
spec:
  containers:
  - name: tomcat
    image:  dockerhub.kungeek.com/csp/ftsp-api-test:11111
    ports:
    - containerPort: 8080      
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

这种存活探测方式是使用 HTTP GET 请求得到请求的返回码，任何大于或等于 200 并且小于 400 的返回码标示成功，其它返回码都标示失败。

四、readinessProbe

Readiness Probes又名为就绪探测器，用于在容器启动后探测应用程序是否已经启动完成并做好处理业务流量的准备。
Readiness Probes与Liveness Probes的配置类似，唯一的区别就是使用readinessProbe关键字来替换到livenessProbe关键字。
示例：

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

readinessProbe与livenessProbe可在同一个容器上并行使用，可以确保流量不会被发给还没准备好的容器，并且在容器出现异常失败的时候将其重新启动。

五、startupProbe

在某些情况下，容器中的应用程序启动的时候有可能需要较多的初始化时间，这时候为了得出正确的健康检查结果，我们需要灵活地根据初始化时间来调整相关的健康检查参数（如：
initialDelaySeconds），除此之外K8S在1.16版本之后提供了一个新的关键字startupProbe来应对这种启动时间过长的情况。在startupProbe检测中，通过设置failureThreshold * periodSeconds参数来保证有足够长的时间来应对这种慢启动的情况。
示例：

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

如此一来，应用程序将会有最多 5 分钟(30 * 10 = 300s) 的时间来完成它的启动。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁可以快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 restartPolicy 来设置 Pod 状态。

来源： https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

来自为知笔记(Wiz)