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

原文地址:http://blog.51cto.com/cloudman/2089257

时间: 2024-11-01 10:56:43

Readiness 探测 - 每天5分钟玩转 Docker 容器技术(144)的相关文章

Liveness 探测 - 每天5分钟玩转 Docker 容器技术(143)

Liveness 探测让用户可以自定义判断容器是否健康的条件.如果探测失败,Kubernetes 就会重启容器. 还是举例说明,创建如下 Pod: 启动进程首先创建文件 /tmp/healthy,30 秒后删除,在我们的设定中,如果 /tmp/healthy 文件存在,则认为容器处于正常状态,反正则发生故障. livenessProbe 部分定义如何执行 Liveness 探测: 探测的方法是:通过 cat 命令检查 /tmp/healthy 文件是否存在.如果命令执行成功,返回值为零,Kube

Health Check - 每天5分钟玩转 Docker 容器技术(142)

强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查,进而实现如下需求: 零停机部署. 避免部署无效的镜像. 更加安全的滚动升级. 下面通过实践学习 Kubernetes 的 Health Check 功能. 默认的健康检查 我们首先学习 Kubernetes 默认的健康检查机制: 每个容器启动时都会执行一个进程,此进程由 Dockerf

在 Scale Up 中使用 Health Check - 每天5分钟玩转 Docker 容器技术(

对于多副本应用,当执行 Scale Up 操作时,新副本会作为 backend 被添加到 Service 的负责均衡中,与已有副本一起处理客户的请求.考虑到应用启动通常都需要一个准备阶段,比如加载缓存数据,连接数据库等,从容器启动到正真能够提供服务是需要一段时间的.我们可以通过 Readiness 探测判断容器是否就绪,避免将请求发送到还没有 ready 的 backend. 下面是示例应用的配置文件. 重点关注 readinessProbe 部分.这里我们使用了不同于 exec 的另一种探测方

如何安装和配置 Rex-Ray?- 每天5分钟玩转 Docker 容器技术(74)

Rex-Ray 是一个优秀的 Docker volume driver,本节将演示其安装和配置方法. Rex-Ray 以 standalone 进程的方式运行在 Docker 主机上,安装方法很简单,在需要使用 Rex-Ray driver 的主机 docker1 和 docker2 上运行如下命令: curl -sSL https://dl.bintray.com/emccode/rexray/install | sh - 然后创建并编辑 Rex-Ray 的配置文件 /etc/rexray/c

新书发布《每天5分钟玩转Docker容器技术》

后台不时收到关于纸质版教程书籍的询问,今天终于可以给大家一个交代了. <每天5分钟玩转Docker容器技术>现已在各大书城上架. 比较了一下,目前京东上最实惠:https://item.jd.com/16936307278.html 下面回答几个大家可能关心的问题. 1. 这本书包含哪些内容? 按照年初的计划,整个教程会涵盖容器生态系统中最重要的容器技术和平台技术. 由于版面篇幅的限制,这次出版的<每天5分钟玩转Docker容器技术>内容就是容器技术部分,具体内容如下: 平台技术部

万能日志数据收集器 Fluentd - 每天5分钟玩转 Docker 容器技术(91)

前面的 ELK 中我们是用 Filebeat 收集 Docker 容器的日志,利用的是 Docker 默认的 logging driver json-file,本节我们将使用 fluentd 来收集容器的日志. Fluentd 是一个开源的数据收集器,它目前有超过 500 种的 plugin,可以连接各种数据源和数据输出组件.在接下来的实践中,Fluentd 会负责收集容器日志,然后发送给 Elasticsearch.日志处理流程如下: 这里我们用 Filebeat 将 Fluentd 收集到的

ELK 完整部署和使用 - 每天5分钟玩转 Docker 容器技术(90)

上一节已经部署了容器化的 ELK,本节讨论如何将日志导入 ELK 并进行图形化展示. 几乎所有的软件和应用都有自己的日志文件,容器也不例外.前面我们已经知道 Docker 会将容器日志记录到 /var/lib/docker/containers/<contariner ID>/<contariner ID>-json.log,那么只要我们能够将此文件发送给 ELK 就可以实现日志管理. 要实现这一步其实不难,因为 ELK 提供了一个配套小工具 Filebeat,它能将指定路径下的日

初探 ELK - 每天5分钟玩转 Docker 容器技术(89)

在开源的日志管理方案中,最出名的莫过于 ELK 了.ELK 是三个软件的合称:Elasticsearch.Logstash.Kibana. Elasticsearch一个近乎实时查询的全文搜索引擎.Elasticsearch 的设计目标就是要能够处理和搜索巨量的日志数据. Logstash读取原始日志,并对其进行分析和过滤,然后将其转发给其他组件(比如 Elasticsearch)进行索引或存储.Logstash 支持丰富的 Input 和 Output 类型,能够处理各种应用的日志. Kiba

部署 Graylog 日志系统 - 每天5分钟玩转 Docker 容器技术(92)

Graylog 是与 ELK 可以相提并论的一款集中式日志管理方案,支持数据收集.检索.可视化 Dashboard.本节将实践用 Graylog 来管理 Docker 日志. Graylog 架构 Graylog 架构如下图所示: Graylog 负责接收来自各种设备和应用的日志,并为用户提供 Web 访问接口. Elasticsearch 用于索引和保存 Graylog 接收到的日志. MongoDB 负责保存 Graylog 自身的配置信息. 与 ELK 一样,Graylog 的部署方案很灵