每天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 | Heapster

每天5分钟玩转Kubernetes | Deployment

每天5分钟玩转Kubernetes | 先把Kubernetes跑起来

每天5分钟玩转Kubernetes | Network Policy