环境介绍
主机 | IP地址 | 服务 |
---|---|---|
master | 192.168.1.21 | k8s+httpd+nginx |
node01 | 192.168.1.22 | k8s |
node02 | 192.168.1.23 | k8s |
基于 https://blog.51cto.com/14320361/2464655 的实验继续进行
一、Pod的liveness和readiness探针
Kubelet使用liveness probe(存活探针)来确定何时重启容器。例如,当应用程序处于运行状态但无法做进一步操作,liveness探针将捕获到deadlock,重启处于该状态下的容器,使应用程序在存在bug的情况下依然能够继续运行下去
Kubelet使用readiness probe(就绪探针)来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态,那么它们将会被从service的load balancer中移除。
Probe支持以下三种检查方法:
<1>exec-命令
在用户容器内执行一次命令,如果命令执行的退出码为0,则认为应用程序正常运行,其他任务应用程序运行不正常。
livenessProbe:
exec:
command:
- cat
- /home/laizy/test/hostpath/healthy
<2>TCPSocket
将会尝试打开一个用户容器的Socket连接(就是IP地址:端口)。如果能够建立这条连接,则认为应用程序正常运行,否则认为应用程序运行不正常。
livenessProbe:
tcpSocket:
port: 8080
<3>HTTPGet
调用容器内Web应用的web hook,如果返回的HTTP状态码在200和399之间,则认为应用程序正常运行,否则认为应用程序运行不正常。每进行一次HTTP健康检查都会访问一次指定的URL。
httpGet: #通过httpget检查健康,返回200-399之间,则认为容器正常
path: / #URI地址
port: 80 #端口号
#host: 127.0.0.1 #主机地址
scheme: HTTP #支持的协议,http或者https
httpHeaders:’’ #自定义请求的header
参数说明
**initialDelaySeconds:**容器启动后第一次执行探测是需要等待多少秒。
**periodSeconds:**执行探测的频率。默认是10秒,最小1秒。
**timeoutSeconds:**探测超时时间。默认1秒,最小1秒。
**successThreshold:**探测失败后,最少连续探测成功多少次才被认定为成功。默认是1。对于liveness必须是1。最小值是1。
探针探测的结果有以下三者之一:
Success:Container通过了检查。
Failure:Container未通过检查。
Unknown:未能执行检查,因此不采取任何措施。
1. LivenessProbe(活跃度)
(1)编写一个livenss的yaml文件
[root@node02 ~]# vim livenss.yaml
kind: Pod
apiVersion: v1
metadata:
name: liveness
labels:
test: liveness
spec:
restartPolicy: OnFailure
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
livenessProbe: #存活探测
exec: #通过执行命令来检查服务是否正常
command: #命令模式
- cat
- /tmp/test
initialDelaySeconds: 10 #pod运行10秒后开始探测
periodSeconds: 5 #检查的频率,每5秒探测一次
该配置文件给Pod配置了一个容器。periodSeconds 规定kubelet要每隔5秒执行一次liveness probe。initialDelaySeconds 告诉kubelet在第一次执行probe之前要的等待10秒钟。探针检测命令是在容器中执行 cat /tmp/healthy 命令。如果命令执行成功,将返回0,kubelet就会认为该容器是活着的并且很健康。如果返回非0值,kubelet就会杀掉这个容器并重启它。
(2)运行一下
[root@master ~]# kubectl apply -f liveness.yaml
(3)查看一下
[root@master ~]# kubectl get pod -w
Liveness活跃度探测,根据探测某个文件是否存在,来确定某个服务是否正常运行,如果存在则正常,负责,它会根据你设置的Pod的重启策略操作Pod。
2. Readiness(敏感探测、就绪性探测)
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。
(1)编写一个readiness的yaml文件
[root@master ~]# vim readiness.yaml
kind: Pod
apiVersion: v1
metadata:
name: readiness
labels:
test: readiness
spec:
restartPolicy: Never
containers:
- name: readiness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/test;