每天5分钟玩转Kubernetes | Readiness探测

书籍来源：cloudman《每天5分钟玩转Kubernetes》

一边学习一边整理老师的课程内容及试验笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：每天5分钟玩转Kubernetes | 汇总_COCOgsta的博客-CSDN博客

---

除了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。