Readiness 探测 - 天天5分钟玩转 Docker 容器技术（144）

除了 Liveness 探测，Kubernetes Health Check 机制还包括 Readiness 探测。

用户经过 Liveness 探测能够告诉 Kubernetes 何时经过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 何时能够将容器加入到 Service 负载均衡池中，对外提供服务。

Readiness 探测的配置语法与 Liveness 探测彻底同样，下面是个例子：

这个配置文件只是将前面例子中的 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。

书籍：
1.《天天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《天天5分钟玩转OpenStack》
https://item.jd.com/12086376.html