关于springboot:spring-boot-应用在-k8s-中的健康检查一

10次阅读

共计 3873 个字符，预计需要花费 10 分钟才能阅读完成。

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

k8s 中的健康检查
spring-boot-actuator 中的 k8s 探针
spring boot 健康检查在 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

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 次

何时应用启动探针

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

何时应用存活探针

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

何时应用就绪探针

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

参考文章：

官网 k8s 容器探针

正文完