共计 988 个字符，预计需要花费 3 分钟才能阅读完成。

这篇文章将为大家详细讲解有关如何理解 Readiness 探测，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

Readiness 探测

除了  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 探测判断容器是否已经准备好对外提供服务。

关于如何理解 Readiness 探测 就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。