设置容器健康检查
操作场景
健康检查是指容器运行过程中,根据用户需要,定时检查容器健康状况。若不配置健康检查,如果容器内应用程序异常,Pod将无法感知,也不会自动重启去恢复。最终导致虽然Pod状态显示正常,但Pod中的应用程序异常的情况。
Kubernetes提供了三种健康检查的探针:
- 存活探针:livenessProbe,用于检测容器是否正常,类似于执行ps命令检查进程是否存在。如果容器的存活检查失败,集群会对该容器执行重启操作;若容器的存活检查成功则不执行任何操作。
- 就绪探针:readinessProbe,用于检查用户业务是否就绪,如果未就绪,则不转发流量到当前实例。一些程序的启动时间可能很长,比如要加载磁盘数据或者要依赖外部的某个模块启动完成才能提供服务。这时候程序进程已启动,但是并不能对外提供服务。这种场景下该检查方式就非常有用。如果容器的就绪检查失败,集群会屏蔽请求访问该容器;若检查成功,则会开放对该容器的访问。
- 启动探针:startupProbe,用于探测应用程序容器什么时候启动了。 如果配置了这类探测器,就可以控制容器在启动成功后再进行存活性和就绪检查, 确保这些存活、就绪探针不会影响应用程序的启动。 这可以用于对启动慢的容器进行存活性检测,避免它们在启动运行之前就被终止。
检查方式
- HTTP 请求检查
HTTP 请求方式针对的是提供HTTP/HTTPS服务的容器,集群周期性地对该容器发起HTTP/HTTPS GET请求,如果HTTP/HTTPS response返回码属于200~399范围,则证明探测成功,否则探测失败。使用HTTP请求探测必须指定容器监听的端口和HTTP/HTTPS的请求路径。
例如:提供HTTP服务的容器,HTTP检查路径为:/health-check;端口为:80;主机地址可不填,默认为容器实例IP,此处以172.16.0.186为例。那么集群会周期性地对容器发起如下请求:GET http://172.16.0.186:80/health-check。您也可以为HTTP请求添加一个或多个请求头部,例如设置请求头名称为Custom-Header,对应的值为example。
图1 HTTP请求检查
- TCP 端口检查
对于提供TCP通信服务的容器,集群周期性地对该容器建立TCP连接,如果连接成功,则证明探测成功,否则探测失败。选择TCP端口探测方式,必须指定容器监听的端口。
例如:有一个nginx容器,它的服务端口是80,对该容器配置了TCP端口探测,指定探测端口为80,那么集群会周期性地对该容器的80端口发起TCP连接,如果连接成功则证明检查成功,否则检查失败。
图2 TCP 端口检查
- 执行命令检查
命令检查是一种强大的检查方式,该方式要求用户指定一个容器内的可执行命令,集群会周期性地在容器内执行该命令,如果命令的返回结果是0则检查成功,否则检查失败。
对于上面提到的TCP端口检查和HTTP请求检查,都可以通过执行命令检查的方式来替代:
- 对于TCP端口探测,可以使用程序对容器的端口尝试connect,如果connect成功,脚本返回0,否则返回-1。
- 对于HTTP请求探测,可以使用脚本命令来对容器尝试使用wget命令进行探测。
wget http://127.0.0.1:80/health-check
并检查response 的返回码,如果返回码在200~399 的范围,脚本返回0,否则返回-1。如下图:
图3 执行命令检查
- 必须把要执行的程序放在容器的镜像里面,否则会因找不到程序而执行失败。
- 如果执行的命令是一个shell脚本,由于集群在执行容器里的程序时,不在终端环境下,因此不能直接指定脚本为执行命令,需要加上脚本解析器。比如脚本是/data/scripts/health_check.sh,那么使用执行命令检查时,指定的程序应该是sh /data/scripts/health_check.sh。
- GRPC检查
GRPC检查可以为GRPC应用程序配置启动、活动和就绪探针,而无需暴露任何HTTP端点,也不需要可执行文件。Kubernetes可以通过GRPC 连接到工作负载并查询其状态。
- GRPC检查仅在CCE v1.25及以上版本集群中支持。
- 使用GRPC检查时,您的应用需支持GRPC健康检查协议。
- 与HTTP和TCP探针类似,如果配置错误,都会被认作是探测失败,例如错误的端口、应用未实现健康检查协议等。
图4 GRPC检查
公共参数说明
参数 |
参数说明 |
---|---|
检测周期(periodSeconds) |
探针检测周期,单位为秒。 例如,设置为30,表示每30秒检测一次。 |
延迟时间(initialDelaySeconds) |
延迟检查时间,单位为秒,此设置与业务程序正常启动时间相关。 例如,设置为30,表明容器启动后30秒才开始健康检查,该时间是预留给业务程序启动的时间。 |
超时时间(timeoutSeconds) |
超时时间,单位为秒。 例如,设置为10,表明执行健康检查的超时等待时间为10秒,如果超过这个时间,本次健康检查就被视为失败。若设置为0或不设置,默认超时等待时间为1秒。 |
成功阈值(successThreshold) |
探测失败后,将状态转变为成功所需要的最小连续成功次数。例如,设置为1时,表明健康检查失败后,健康检查需要连续成功1次,才认为工作负载状态正常。 默认值是 1,最小值是 1。 存活和启动探测的这个值必须是 1。 |
最大失败次数(failureThreshold) |
当探测失败时重试的次数。 存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。 默认值是 3,最小值是 1。 |
YAML示例
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness image: <image_address> args: - /server livenessProbe: # 存活探针 httpGet: # 以HTTP请求检查为例 path: /healthz # HTTP检查路径为/healthz port: 80 # 检查端口为80 httpHeaders: # 可选,请求头名称为Custom-Header,对应的值为Awesome - name: Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3 readinessProbe: # 就绪探针 exec: # 以执行命令检查为例 command: # 需要执行的命令 - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 startupProbe: # 启动探针 httpGet: # 以HTTP请求检查为例 path: /healthz # HTTP检查路径为/healthz port: 80 # 检查端口为80 failureThreshold: 30 periodSeconds: 10