Kubernets健康检查——配置存活、就绪和启动探测器

这篇博文主要介绍如何给容器配置存活、就绪和启动探测器。

kubelet 使用存活探测器来知道什么时候要重启容器。例如，存活探测器可以捕捉到死锁(应用程序在运行，但是无法继续执行后面的步骤)。这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。

kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量，当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。

kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查，确保这些存活、就绪探测器不会影响应用程序的启动。这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。

一、三种探测方式

LivenessProbe(存活探测)：用于探测容器是否运行，如果探测失败，kubelet会根据配置的重启策略进行相应的处理，如果没有配置该探针，默认就是success!
ReadinessProbe(就绪探测)：一般用于探测容器内的程序是否健康，它的返回值如果为success，那么就代表这个容器已经完成启动，并且程序已经是可以接受流量的状态.
StartupProbe(启动探测)：k8s1.16版本后新加的探测方式，用于判断容器内应用程序是否已经启动，如果配置了startuprobe，就会先禁用其他的探测，直到它成功为止，成功后将不再进行探测。

二、Pod探针的监测方式

# startupProbe  启动检查
----------------------------------
startupProbe:                     #健康检查方式：[readinessProbe,livenessProbe,StartupProbe]failureThreshold: 3             #检测失败3次表示未就绪httpGet:                        #请求方式path: /ready                  #请求路径port: 8182                    #请求端口scheme: HTTP                  #请求协议periodSeconds: 10               #检测间隔successThreshold: 1             #检查成功为2次表示就绪timeoutSeconds: 1               #检测失败1次表示未就绪
----------------------------------# livenessProbe 存活检查
----------------------------------
livenessProbe:                  #健康检查方式：[readinessProbe,livenessProbe,StartupProbe]failureThreshold: 5           #检测失败5次表示未就绪httpGet:                      #请求方式path: /health               #请求路径port: 8080                  #请求端口scheme: HTTP                #请求协议initialDelaySeconds: 60       #初始化时间periodSeconds: 10             #检测间隔successThreshold: 1           #检查成功为2次表示就绪timeoutSeconds: 5             #检测失败1次表示未就绪terminationGracePeriodSeconds: 60  #宽限时间，不能用于设置就绪态探针，它将被 API 服务器拒绝。
----------------------------------# readinessProbe  就绪检查
----------------------------------
案例1[get方式]：
readinessProbe:                   #健康检查方式：[readinessProbe,livenessProbe,StartupProbe]failureThreshold: 3             #检测失败3次表示未就绪httpGet:                        #请求方式path: /ready                  #请求路径port: 8181                    #请求端口scheme: HTTP                  #请求协议periodSeconds: 10               #检测间隔successThreshold: 1             #检查成功为2次表示就绪timeoutSeconds: 1               #检测失败1次表示未就绪案例2 [检查文件内容]：
readinessProbe:                #检查方式exec:                        #使用命令检查command:                   #指令- cat                      #指令- /etc/hosts               #指令initialDelaySeconds: 5       #容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。timeoutSeconds: 2            #检测失败1次表示未就绪successThreshold: 3          #检查成功为2次表示就绪failureThreshold: 2          #检测失败重试次数periodSeconds: 5             #检测间隔
----------------------------------

initialDelaySeconds：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。
periodSeconds：执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1。
timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
successThreshold：探测器在失败后，被视为成功的最小连续成功数。默认值是 1 存活和启动探测的这个值必须是1 最小值是 1。
failureThreshold：当探测失败时，Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。

注意：配置了 startupProbe 之后，livenessProbe和readinessProbe参数将会被暂时禁用，直到程序被检测到启动完成了livenessProbe，readinessProbe才会被启用；在程序启动较慢的时候可以配置startupProbe参数。

三、配置案例

kubernetes官方文档

apiVersion: apps/v1 # 必选，API的版本号
kind: Deployment       # 必选，类型Pod
metadata:       # 必选，元数据name: nginx   # 必选，符合RFC 1035规范的Pod名称labels:       # 可选，标签选择器，一般用于过滤和区分Podapp: nginxrole: frontend # 可以写多个annotations:  # 可选，注释列表，可以写多个app: nginx
spec:   # 必选，用于定义容器的详细信息replicas: 1   # 必选，副本数selector:     # 必选，标签选择器matchLabels:app: nginxrole: frontendtemplate:     # 必选，定义pod模板metadata:labels:       # 可选，标签选择器，一般用于过滤和区分Podapp: nginxrole: frontend # 可以写多个spec:containers:   # 必选，容器列表- name: nginx01 # 必选，符合RFC 1035规范的容器名称image: 192.168.99.1:5000/k8s/nginx:latest    # 必选，容器所用的镜像的地址imagePullPolicy: Always     # 可选，镜像拉取策略command: # 可选，容器启动执行的命令- nginx- -g- "daemon off;"workingDir: /usr/share/nginx/html       # 可选，容器的工作目录ports:  # 可选，容器需要暴露的端口号列表- name: http    # 端口名称containerPort: 80     # 端口号protocol: TCP # 端口协议，默认TCPenv:    # 可选，环境变量配置列表- name: TZ      # 变量名value: Asia/Shanghai # 变量的值- name: LANGvalue: en_US.utf8startupProbe: # 可选，检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。failureThreshold: 3             #检测失败3次表示未就绪httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。path: / # 检查路径port: 80scheme: HTTPperiodSeconds: 10               #检测间隔successThreshold: 1             #检查成功为1次表示就绪timeoutSeconds: 1               #检测失败1次表示未就绪livenessProbe: # 可选，检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。failureThreshold: 3             #检测失败3次表示未就绪httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。path: / # 检查路径port: 80scheme: HTTPperiodSeconds: 10               #检测间隔successThreshold: 1             #检查成功为1次表示就绪timeoutSeconds: 1               #检测失败1次表示未就绪readinessProbe: # 可选，检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。failureThreshold: 3             #检测失败3次表示未就绪httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。path: / # 检查路径port: 80scheme: HTTPperiodSeconds: 10               #检测间隔successThreshold: 1             #检查成功为1次表示就绪timeoutSeconds: 1               #检测失败1次表示未就绪restartPolicy: Always   # 可选，默认为Always

四、监测时间计算

准确的时间计算：每次检查的间隔是10秒，最长超时时间是5秒，也就是单次检查应该是10 + 5 = 15秒(periodSeconds + timeoutSeconds)，并不是10 5
所以最长的重启时间为(10 + 5) 5 (periodSeconds + timeoutSeconds) * failureThreshold

此时又分为了两种情况：

首次启动时：最长重启时间需要加上initialDelaySeconds，因为需要等待initialDelaySeconds秒后才会执行健康检查。最长重启时间：(periodSeconds + timeoutSeconds) * failureThreshold + initialDelaySeconds
程序启动完成后：
此时不需要计入initialDelaySeconds，最长重启时间：(periodSeconds + timeoutSeconds) * failureThreshold