每天5分钟玩转Kubernetes | Readiness探测
Posted COCOgsta
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了每天5分钟玩转Kubernetes | Readiness探测相关的知识,希望对你有一定的参考价值。
书籍来源:cloudman《每天5分钟玩转Kubernetes》
一边学习一边整理老师的课程内容及试验笔记,并与大家分享,侵权即删,谢谢支持!
除了Liveness探测,Kubernetes Health Check机制还包括Readiness探测。
用户通过Liveness探测可以告诉Kubernetes什么时候通过重启容器实现自愈;Readiness探测则是告诉Kubernetes什么时候可以将容器加入到Service负载均衡池中,对外提供服务。
Readiness探测的配置语法与Liveness探测完全一样,如下所示。
[root@k8s-master ~]# cat readiness.yml
apiVersion: v1
kind: Pod
metadata:
labels:
test: readiness
name: readiness
spec:
restartPolicy: OnFailure
containers:
- name: readiness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 10
periodSeconds: 5
[root@k8s-master ~]#
这个配置文件只是将前面例子中的liveness替换为了readiness,我 们看看有什么不同的效果,如图所示。
Pod readiness的READY状态经历了如下变化:
(1)刚被创建时,READY状态为不可用。
(2)15秒后(initialDelaySeconds + periodSeconds),第一次进行Readiness探测并成功返回,设置READY为可用。
(3)30秒后,/tmp/healthy被删除,连续3次Readiness探测均失败后,READY被设置为不可用。
通过kubectl describe pod readiness也可以看到Readiness探测失败 的日志,如图所示。
下面对Liveness探测和Readiness探测做个比较:
(1)Liveness探测和Readiness探测是两种Health Check机制,如果不特意配置,Kubernetes将对两种探测采取相同的默认行为,即通过判断容器启动进程的返回值是否为零来判断探测是否成功。
(2)两种探测的配置方法完全一样,支持的配置参数也一样。不同之处在于探测失败后的行为:Liveness探测是重启容器;Readiness探测则是将容器设置为不可用,不接收Service转发的请求。
(3)Liveness探测和Readiness探测是独立执行的,二者之间没有依赖,所以可以单独使用,也可以同时使用。用Liveness探测判断容器是否需要重启以实现自愈;用Readiness探测判断容器是否已经准备好对外提供服务。
理解了Liveness探测和Readiness探测的原理,接下来讨论如何在业务场景中使用Health Check。
以上是关于每天5分钟玩转Kubernetes | Readiness探测的主要内容,如果未能解决你的问题,请参考以下文章
每天5分钟玩转Kubernetes | Kubernetes Dashboard安装
每天5分钟玩转Kubernetes | Deployment
每天5分钟玩转Kubernetes | Deployment