k8s容器存活探测

对于Pod的健康状态检测&＃xff0c;kubernetes提供了两类探针(Probe)来执行对Pod的健康状态检测&＃xff1a;

liveness probe&＃xff08;存活探针&＃xff09;
用于判断容器是否存活&＃xff0c;即Pod是否为running状态&＃xff0c;如果LivenessProbe探针探测到容器不健康&＃xff0c;则kubelet将kill掉容器&＃xff0c;并根据容器的重启策略是否重启&＃xff0c;如果一个容器不包含LivenessProbe探针&＃xff0c;则Kubelet认为容器的LivenessProbe探针的返回值永远成功。

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

每类探针都支持三种探测方法

exec&＃xff1a;通过执行命令来检查服务是否正常&＃xff0c;针对复杂检测或无HTTP接口的服务&＃xff0c;命令返回值为0则表示容器健康。

httpGet&＃xff1a;通过发送http请求检查服务是否正常&＃xff0c;返回200-399状态码则表明容器健康。

tcpSocket&＃xff1a;通过容器的IP和Port执行TCP检查&＃xff0c;如果能够建立TCP连接&＃xff0c;则表明容器健康。

每种方式都可以定义在readiness 或者liveness 中。比如定义readiness 中http get 就是意思说如果我定义的这个path的http get 请求返回200-400以外的http code 就把我从所有有我的服务里面删了吧&＃xff0c;如果定义在liveness里面就是把我kill 了。
注意&＃xff0c;liveness不会重启pod&＃xff0c;pod是否会重启由你的restart policy 控制。

探针探测的结果有以下三者之一

Success&＃xff1a;Container通过了检查。
Failure&＃xff1a;Container未通过检查。
Unknown&＃xff1a;未能执行检查&＃xff0c;因此不采取任何措施。

重启策略

Always: 总是重启
OnFailure: 如果失败就重启
Never: 永远不重启


LivenessProbe探针配置
示例一: 通过exec方式做健康探测

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: k8s.gcr.io/busybox args:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5


在该配置文件中&＃xff0c;对容器执行livenessProbe检查&＃xff0c;periodSeconds字段指定kubelet每5s执行一次检查&＃xff0c;检查的命令为cat /tmp/healthy&＃xff0c;initialDelaySeconds字段告诉kubelet应该在执行第一次检查之前等待5秒&＃xff0c;
如果命令执行成功&＃xff0c;则返回0&＃xff0c;那么kubelet就认为容器是健康的&＃xff0c;如果为非0&＃xff0c;则Kubelet会Kill掉容器并根据重启策略来决定是否需要重启(kubernetes默认为POD配置的重启策略为Always)

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

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: k8s.gcr.io/liveness # 官方用户测试的demo镜像args:- /serverlivenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: X-Custom-Headervalue: AwesomeinitialDelaySeconds: 3 periodSeconds: 3


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

httpGet探测方式有如下可选的控制字段:

host&＃xff1a;要连接的主机名&＃xff0c;默认为Pod IP&＃xff0c;可以在http request head中设置host头部。
scheme: 用于连接host的协议&＃xff0c;默认为HTTP。
path&＃xff1a;http服务器上的访问URI。
httpHeaders&＃xff1a;自定义HTTP请求headers&＃xff0c;HTTP允许重复headers。
port&＃xff1a; 容器上要访问端口号或名称

示例三&＃xff1a;通过TCP方式做健康探测
Kubelet将尝试在指定的端口上打开容器上的套接字&＃xff0c;如果能建立连接&＃xff0c;则表明容器健康。

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


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

ReadinessProbe探针配置
ReadinessProbe探针的使用场景livenessProbe稍有不同&＃xff0c;有的时候应用程序可能暂时无法接受请求&＃xff0c;比如Pod已经Running了&＃xff0c;但是容器内应用程序尚未启动成功&＃xff0c;在这种情况下&＃xff0c;如果没有ReadinessProbe&＃xff0c;则Kubernetes认为它可以处理请求了&＃xff0c;然而此时&＃xff0c;我们知道程序还没启动成功是不能接收用户请求的&＃xff0c;所以不希望kubernetes把请求调度给它&＃xff0c;则使用ReadinessProbe探针。
ReadinessProbe和livenessProbe可以使用相同探测方式&＃xff0c;只是对Pod的处置方式不同&＃xff0c;ReadinessProbe是将Pod IP:Port从对应的EndPoint列表中删除&＃xff0c;而livenessProbe则Kill容器并根据Pod的重启策略来决定作出对应的措施。

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

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

readinessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5


配置探针(Probe)相关属性
探针(Probe)有许多可选字段&＃xff0c;可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe)&＃xff1a;

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