当前位置: 首页 > >

K8S中pod健康状态的检查

发布时间:

对于Pod的健康状态检测,kubernetes提供了两类探针(Probe)来实现对k8s中Pod的健康状态进行检测
什么是 Container Probes

通过k8s的架构图,我们可以发现,每个Node节点上都有 kubelet 这个组件,Container Probe(容器探针) 也就是容器的健康检查是由 kubelet 定期执行的。Container Probe有以下两种方式,分别为Liveness Probe(存活探针)和Readiness Probe(就绪探针)。


Liveness Probe(存活探针)
用于判断容器是否存活,即Pod是否为running状态,如果LivenessProbe探针探测到容器不健康,则kubelet将kill掉容器,并根据容器的*舨呗跃龆ㄊ欠裰*簦绻桓鋈萜鞑话琇ivenessProbe探针,则Kubelet认为容器的LivenessProbe探针的返回值永远成功。

Readiness Probe(就绪探针)
用于判断容器是否启动完成,即容器的Ready是否为True,可以接收请求,如果ReadinessProbe探测失败,则容器的Ready将为False,控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除,从此不再将任何请求调度此Pod上,直到下次探测成功。


每类探针都支持三种探测方法
ExecAction:在容器中执行特定的命令,命令退出返回0表示成功TCPSocketAction:根据容器IP地址及特定的端口进行TCP检查,端口开放即命令返回值为0则表示容器健康。HTTPGetAction:根据容器IP、端口及访问路径发起一次HTTP请求,如果返回码在200到400之间表示成功

以上每种方式都可以定义在readiness 或者liveness 中。比如定义readiness 中http get 就是意思说如果我定义的这个path的http get 请求返回200-400以外的http code 就把我从所有有我的服务里面删了吧,如果定义在liveness里面就是把我kill 了。
注意,liveness不会*魀od,pod是否会*粲赡愕膔estart policy 控制。


两种探针探测的结果都有以下三者
Success:Container通过了检查。Failure:Container未通过检查。Unknown:未能进行检查,因此不采取任何措施。
*舨呗
Always: 总是*鬙nFailure: 如果失败就*鬘ever: 永远不*
LivenessProbe探针配置
示例一: 通过exec方式做健康探测

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
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:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5

在该配置文件中,对容器执行livenessProbe检查,periodSeconds字段指定kubelet每5s执行一次检查,检查的命令为cat /tmp/healthy,initialDelaySeconds字段告诉kubelet应该在执行第一次检查之前等待5秒,
如果命令执行成功,则返回0,那么kubelet就认为容器是健康的,如果为非0,则Kubelet会Kill掉容器并根据*舨呗岳淳龆ㄊ欠裥枰*(kubernetes默认为POD配置的*舨呗晕狝lways)
注:本例创建了一个容器,通过检查一个文件是否存在来判断容器运行是否正常。容器运行30秒后,将文件删除,这样容器的liveness检查失败从而会将容器*


示例二: 通过HTTP方式做健康探测

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness # 官方用户测试的demo镜像
args:
- /server
livenessProbe:
httpGet:
path: /healthy
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3

在配置文件中,使用k8s.gcr.io/liveness镜像,创建出一个Pod,其中periodSeconds字段指定kubelet每3秒执行一次探测,initialDelaySeconds字段告诉kubelet延迟等待3秒,探测方式为向容器中运行的服务发送HTTP GET请求,请求8080端口下的/healthz, 任何大于或等于200且小于400的代码表示成功。任何其他代码表示失败。


httpGet探测方式有如下可选的控制字段:
host:要连接的主机名,默认为Pod IP,可以在http request head中设置host头部。scheme: 用于连接host的协议,默认为HTTP。path:http服务器上的访问URI。httpHeaders:自定义HTTP请求headers,HTTP允许重复headers。port: 容器上要访问端口号或名称
示例三:通过TCP方式做健康探测

Kubelet将尝试在指定的端口上打开容器上的套接字,如果能建立连接,则表明容器健康。


apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20

TCP检查方式和HTTP检查方式非常相似,示例中两种探针都使用了,在容器启动5秒后,kubelet将发送第一个readinessProbe探针,这将连接到容器的8080端口,如果探测成功,则该Pod将被标识为ready,10秒后,kubelet将进行第二次连接.除此之后,此配置还包含了livenessProbe探针,在容器启动15秒后,kubelet将发送第一个livenessProbe探针,仍然尝试连接容器的8080端口,如果连接失败则*羧萜鳌


ReadinessProbe探针配置

ReadinessProbe探针的使用场景livenessProbe稍有不同,有的时候应用程序可能暂时无法接受请求,比如Pod已经Running了,但是容器内应用程序尚未启动成功,在这种情况下,如果没有ReadinessProbe,则Kubernetes认为它可以处理请求了,然而此时,我们知道程序还没启动成功是不能接收用户请求的,所以不希望kubernetes把请求调度给它,则使用ReadinessProbe探针。
ReadinessProbe和livenessProbe可以使用相同探测方式,只是对Pod的处置方式不同,ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除,而livenessProbe则Kill容器并根据Pod的*舨呗岳淳龆ㄗ鞒龆杂Φ拇胧


ReadinessProbe探针探测容器是否已准备就绪,如果未准备就绪则kubernetes不会将流量转发给此Pod。


ReadinessProbe探针与livenessProbe一样也支持exec、httpGet、TCP的探测方式,配置方式相同,只不过是将livenessProbe字段修改为ReadinessProbe。


readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5

配置探针(Probe)相关属性

探针(Probe)有许多可选字段,可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe):


initialDelaySeconds:Pod启动后延迟多久才进行检查,单位:秒。
periodSeconds:检查的间隔时间,默认为10,单位:秒。
timeoutSeconds:探测的超时时间,默认为1,单位:秒。
successThreshold:探测失败后认为成功的最小连接成功次数,默认为1,在Liveness探针中必须为1,最小值为1。
failureThreshold:探测失败的重试次数,重试一定次数后将认为失败,在readiness探针中,Pod会被标记为未就绪,默认为3,最小值为1。


httpGet的属性

host:主机名或IP
scheme:链接类型,HTTP或HTTPS,默认为HTTP
path:请求路径
httpHeaders:自定义请求头
port:请求端口


参考
https://blog.sctux.com/2018/12/18/kubernetes-liveness/
https://blog.51cto.com/newfly/2137136
https://www.jianshu.com/p/6d0b5065ed91



友情链接: