Kubernetes健康检查、就绪检查

作者:卫珍佑 于 2020年05月20日 发布在分类/ K8S

Kubernetes 健康检查、就绪检查

一,健康检查

健康检查(health check)可用于服务运行状态的监控,在分布式系统中,用户访问的不再是单台主机,而是有多个实例来提供服务,用户通过请求负载均衡器来分发流量到不同的实例,负载均衡帮助我们解决单台服务器访问压力,同时提高了系统的高可用,而健康检查作为当前服务实例是否“可用”的标准。也就是说当某个实例故障时,负载均衡器不会把请求流量转发到该实例,而kubernetes提供了两种探针来检查容器的状态, Liveliness Readiness,根据官方文档,Liveliness用来查看容器是否在正常运行,翻译为“存活探针”,Readiness探针是为了查看容器是否准备好了接受HTTP请求,翻译为“就绪探针”。

1,存活探针

   Liveliness)存活探针是让K8S知道你的应用服务是否存活,当我们的应用正常启动后,由于一些原因导致宕机了,导致它无法处理访问请求,默认情况下kubernetes还是会继续向pod发送请求。在配置了存活探针的情况下,如果程序异常了,K8S将会关闭pod,并重新启动新的pod来替换它。

2,就绪探针

  一个服务启动,往往需要一段时间来进行预热和启动,比如一个后端服务启动过程中需要连接数据库等,一个spring项目的启动往往也需要依赖于Java虚拟机,程序在没有完全启动之前是不可以接受流量的,但默认情况下,kubernetes会在容器内的程序启动后立即开始发送流量,因此我们需要配置就绪探针(Readiness),在确保服务启动成功后再开始接收请求流量。

二,探针类型

探针类型是指以哪种方式来进行健康检查,K8S有三种探测健康的类型:HTTPcommandTCP

   1 HTTPGET

     HTTP可能是最常见的探测类型了,即使服务不是http服务,也可以创建一个轻量级的HTTP服务器来响应探测,比如让K8S去探测一个URL,如果返回码在200~300之间,就将应用标记为健康状态,否则就标记为不健康。

   2 commandexec命令)

     命令探测是指K8S在容器内运行一些命令,如果返回的状态码为0,就把容器标记为正常状态,否则,标记为不健康状态。

   3 TCPSocket

     Tcp探测是指,K8S尝试在指定端口上建立tcp连接,如果建立连接,则表明服务是正常的,否则,就人为容器时不健康的状态,我们可以配置初始探测延迟,也就是说等应用服务完全启动成功之前,需要设置一定的时间间隔,然后再开始进行探测。

三,查看具体信息

   一般livelinessreadiness支持的探针类型相同

k8s支持两种健康检查模式:readinessliveness简单的来说,readiness检查是否可以暴露该应用(availabel),liveness检查是否需要重启。三种检查方式:httpGetexectcpSockethttpGet支持两种协议:httphttps exec的方式比较自由,在容器内执行命令,可通过将自定义脚本构建进镜像的方式轻松自定义健康检查方案。

一般使用三种方式中的一中就可以。

###可以通过以下命令查看各字段如何定义

kubectl explain pods.spec.containers.livenessProbe

exec       <Object>

One and only one of the following should be specified. Exec specifies the action to take.

可以使用的命令为容器镜像内支持的命令,以命令的执行结果来确定服务是否正常,比如ps命令过滤服务是否运行,或者查看端口是否存在等

httpGet  <Object>

HTTPGet specifies the http request to perform.

如果部署的是web服务,可以向指定的URL请求,如果返回码为200~300,则服务为正常状态

tcpSocket     <Object>

TCPSocket specifies an action involving a TCP port. TCP hooks not yet  Supported

通过向某个端口发送tcp请求,看是否有响应来判断服务是否正常,

failureThreshold  <integer>

Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1.

连续探测几次失败,才算服务不正常,默认为3次,最小可以设置为1

successThreshold <integer>

Minimum consecutive successes for the probe to be considered successful

after having failed. Defaults to 1. Must be 1 for liveness and startup.

几次探测成功表示服务健康,默认为1次,对于liveness来说只能是1

periodSeconds    <integer>

How often (in seconds) to perform the probe. Default to 10 seconds. Minimum  value is 1.

检测周期,默认为10秒,最小为1

initialDelaySeconds    <integer>

Number of seconds after the container has started before liveness probes

are initiated. More info:  https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

等待服务初始化后再开始健康检查,延迟多少秒之后开始探测,

timeoutSeconds  <integer>

Number of seconds after which the probe times out. Defaults to 1 second.

Minimum value is 1. More info:

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

探测时,无响应的超时时间,默认为1秒,最小值也是1

四,pod 的几种状态

Ø  Pending

   API Server创建了资源对象,并已存入了etcd中,但它尚未被调度成功,或者任处于拉取镜像的过程中。

Ø  Running

   Pod已经被调度至某个节点,并且所有pod内的容器已经被kubelet创建完成

Ø  Succeeded

Pod中的所有容器都已经成功终止,并且不会被重新启动

Ø  Failed

所有容器已经终止,但至少有一个容器终止失败,即容器返回了非0的状态码,或者已经被系统终止

Ø  Unknown

Api Server无法正常获取到pod对象的状态信息,通常是由于其无法与所在工作节点的kubelet通信所导致


五,pod 的创建过程

1,用户向API Server发送创建指令,然后,API server将信息存入etcd中(用户没有定义的字段会默认补齐)

2SchedulerwatchAPI Server的变动,然后并调度资源,然后把结果返回给API server写入etcd

3API Server会给调度到的主机上的kubelet发送指令创建指令,之后kubelet会通过API Server读取etcd中信息

4kubelet会调取本机的docker引擎来运行容器

5docker创建好容器之后会反馈给kubeletkubelet会把信息返回给API Server

6,最后,API Server会把结果写入etcd


六,pod 的终止过程

1,用户向API Server发起终止pod的指令,API Server写入etcd中,并把pod状态标记为terminating

2etcd中设置一定的宽限期返回给API ServerAPI Server向节点的kubelet发送终止信息

3kubeletdocker引擎发送终止指令,docker开始执行结束前事件(preStop),然后关闭容器

4,如果在宽限期内容器没有正常关闭,kubelet会向docker引擎发送强制关闭容器的指令

5,最后容器关闭,API Server会向etcd发送指令清理相关项目信息

七,容器的重启策略

   Pod对象由于容器内的应用程序崩溃或者容器申请超出资源限制等原因都可能导致终止,这时候容器是否会重启,取决于定义的( restartPolicy)重启策略字段所定义的属性:

Ø  Always:只要pod对象终止了,就会重新启动,此为默认设置。

Ø  OnFailure:只在pod对象出现错误时才会重新启动,人为的关闭不会重启。(推荐使用)

Ø  Nerver:从不重启


分享到朋友圈 分享到微信
发表评论
验证码