一、概述

在 spring boot 2.3 中引入了容器探针，也就是减少了 /actuator/health/liveness 和 /actuator/health/readiness 这两个健康检查门路，对于部署在 k8s 中的利用，spring-boot-actuator 将通过这两个门路主动进行健康检查。本文次要依据官网文档的形容实际并记录应用流程，从如下几个方面进行介绍：

  1. k8s 中的健康检查
  2. spring-boot-actuator 中的 k8s 探针
  3. spring boot 健康检查在 k8s 中的实际

二、K8s 容器健康检查

1、k8s 中的探针

kubernetes 提供了三种探针（反对exec、tcp和http形式）来探测容器的状态：

  • LivenessProbe：容器存活性查看，用于判断容器是否衰弱，通知 kubelet 一个容器什么时候处于不衰弱的状态。如果 LivenessProbe 探针探测到容器不衰弱，则 kubelet 将删除该容器，并依据容器的重启策略做相应的解决。如果一个容器不蕴含 LivenessProbe 探针，那么 kubelet 认为该容器的 LivenessProbe 探针返回的值永远是 Success；
  • ReadinessProbe：容器就绪性查看，用于判断容器是否启动实现且筹备接管申请。如果ReadinessProbe探针探测到失败，Endpoint Controller 将从 Service 的 Endpoint 中删除蕴含该容器所在 Pod 的 IP 地址的Endpoint条目。如果容器不提供就绪态探针，则默认状态为 Success。
  • startupProbe: 容器启动查看，批示容器中的利用是否曾经启动。如果提供了启动探针，则所有其余探针都会被禁用，直到此探针胜利为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。
startupProbe 是在k8s v1.16退出了alpha版，官网对其作用的解释是：
Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state is Success

2、k8s 的探针处理程序

Probe 探针查看是由 kubelet 对容器执行的定期诊断，kubelet 调用由容器实现的 Handler （处理程序），每一个探针都能够配置如下三种类型的处理程序：

  • ExecAction： 在容器内执行指定命令，如果命令退出时返回码为 0 则认为诊断胜利。

通过执行命令的形式来查看服务是否失常，比方应用 cat 命令查看 pod 中的某个重要配置文件是否存在，若存在，则示意pod衰弱，反之异样。Exec 探测形式的 yaml 文件语法如下：

spec:    containers:    - name: liveness      image: k8s.gcr.io/busybox      args:      - /bin/sh      - -c      - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600      livenessProbe:               #抉择livenessProbe的探测机制        exec:                      #执行以下命令，如果文件存在则探测胜利        command:          - cat          - /tmp/healthy        initialDelaySeconds: 5          #在容器运行五秒后开始探测        periodSeconds: 5                #查看工夫距离为 5s 查看一次

  • TCPSocketAction： 对容器的 IP 地址上的指定端口执行 TCP 查看，如果端口关上，则诊断被认为是胜利的。
    这种形式与HTTPget的探测机制有些相似，tcpsocket健康检查实用于TCP业务，tcpSocket探测形式的yaml文件语法如下：

    spec:  containers:  - name: goproxy    image: k8s.gcr.io/goproxy:0.1    ports:      - containerPort: 8080    #这里两种探测机制都用上了，都是为了和容器的8080端口建设TCP连贯    readinessProbe:      tcpSocket:        port: 8080      initialDelaySeconds: 5  # 容器启动 5s 后开始第一次就绪性探测    periodSeconds: 10       # 每 10s 进行一次探测  livenessProbe:      tcpSocket:        port: 8080      initialDelaySeconds: 15  # 容器启动 15s 后开始第一次就存活性探测    periodSeconds: 20  # 每 20s 进行一次探测

    在上述的yaml配置文件中，两类探针都应用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连贯容器的8080端口，如果探测胜利，则该pod为衰弱，十秒后，kubelet将进行第二次连贯。

除了readinessProbe探针外，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，依然尝试连贯容器的8080端口，如果连贯失败，则重启容器。

  • HTTPGetAction： 对容器的 IP 地址上指定端口和门路执行 HTTP Get 申请，如果响应的状态码大于等于 200 且小于 400，则诊断被认为是胜利的。

Httpget探测形式的yaml文件语法如下：

spec:    containers:    - name: liveness      image: k8s.gcr.io/liveness      livenessProbe:              #采纳livenessProbe机制探测        httpGet:                  #采纳httpget的形式          scheme: HTTP         #指定协定，也反对https          path: /healthz          #检测是否能够拜访到网页根目录下的healthz网页文件          port: 8080              #监听端口是8080        initialDelaySeconds: 3     #容器运行3秒后开始探测        periodSeconds: 3                #探测频率为3秒

上述配置文件中，探测形式为项容器发送HTTP GET申请，申请的是 8080 端口下的 healthz 文件，返回任何大于或等于200且小于400的状态码示意胜利，任何其余代码示意异样。

每次探测都将取得以下三种后果之一：

  • Success（胜利）：容器通过了诊断。
  • Failure（失败）：容器未通过诊断。

  • Unknown（未知）：诊断失败，因而不会采取任何口头。

    3、k8s 探针的配置

    Probe 有如下配置字段，能够应用这些字段准确的管制存活和就绪检测的行为：

  • initialDelaySeconds：容器启动后要期待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。
  • periodSeconds：执行探测的工夫距离（单位是秒）。默认是 10 秒。最小值是 1。
  • timeoutSeconds：探测的超时后期待多少秒。默认值是 1 秒。最小值是 1。
  • successThreshold：探测器在失败后，被视为胜利的最小间断胜利数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。
  • failureThreshold：当探测失败时，Kubernetes 的重试次数。 存活探测状况下的放弃就意味着重新启动容器。 就绪探测状况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
阐明：在 Kubernetes 1.20 版本之前，exec 探针会疏忽 timeoutSeconds：探针会无限期地 继续运行，甚至可能超过所配置的限期，直到返回后果为止。这一缺点在 Kubernetes v1.20 版本中失去修复。

LivenessProbe配置例子：

livenessProbe:  httpGet:    path: /actuator/health/liveness    port: 8080  initialDelaySeconds: 30        // 容器启动30s后启动第一次探测  periodSeconds: 10              //  每隔10s启动一次探测  timeoutSeconds: 3               // 超时工夫3s  successThreshold: 1             // 胜利1次即示意容器衰弱  failureThreshold: 5             // 间断5次失败，则断定容器不衰弱，默认3次

4、何时应用

何时应用启动探针

kubelet 应用启动探测器能够晓得应用程序容器什么时候启动了。 如果配置了这类探测器，就能够管制容器在启动胜利后再进行存活性和就绪查看， 确保这些存活、就绪探测器不会影响应用程序的启动。 这能够用于对慢启动容器进行存活性检测，防止它们在启动运行之前就被杀掉。

何时应用存活探针

kubelet 应用存活探测器来晓得什么时候要重启容器。 例如，存活探测器能够捕捉到死锁（应用程序在运行，然而无奈继续执行前面的步骤）。 这样的状况下重启容器有助于让应用程序在有问题的状况下更可用。

何时应用就绪探针

kubelet 应用就绪探测器能够晓得容器什么时候筹备好了并能够开始承受申请流量， 当一个 Pod 内的所有容器都筹备好了，能力把这个 Pod 看作就绪了。 这种信号的一个用处就是管制哪个 Pod 作为 Service 的后端。 在 Pod 还没有筹备好的时候，会从 Service 的负载均衡器中被剔除的。

参考文章：

官网 k8s 容器探针