除了 Liveness 探测，Kubernetes Health Check 机制还包括 Readiness 探测。
用户通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。
Readiness 探测的配置语法与 Liveness 探测完全一样，下面是个例子：
这个配置文件只是将前面例子中的 liveness 替换为了 readiness，我们看看有什么不同的效果。
Pod readiness 的 READY 状态经历了如下变化：
-
刚被创建时，
READY状态为不可用。 -
15 秒后（initialDelaySeconds + periodSeconds），第一次进行 Readiness 探测并成功返回，设置
READY为可用。 -
30 秒后，
/tmp/healthy被删除，连续 3 次 Readiness 探测均失败后，READY被设置为不可用。
通过 kubectl describe pod readiness 也可以看到 Readiness 探测失败的日志。
下面对 Liveness 探测和 Readiness 探测做个比较：
-
Liveness 探测和 Readiness 探测是两种 Health Check 机制，如果不特意配置，Kubernetes 将对两种探测采取相同的默认行为，即通过判断容器启动进程的返回值是否为零来判断探测是否成功。
-
两种探测的配置方法完全一样，支持的配置参数也一样。不同之处在于探测失败后的行为：Liveness 探测是重启容器；Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。
-
Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈；用 Readiness 探测判断容器是否已经准备好对外提供服务。
理解了 Liveness 探测和 Readiness 探测的原理，下一节我们会讨论如何在业务场景中使用 Health Check。
书籍：1.《每天5分钟玩转Docker容器技术》
2.《每天5分钟玩转OpenStack》
