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

对于多副本应用,当执行 Scale Up 操作时,新副本会作为 backend 被添加到 Service 的负责均衡中,与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段,比如加载缓存数据,连接数据库等,从容器启动到正真能够提供服务是需要一段时间的。我们可以通过 Readiness 探测判断容器是否就绪,避免将请求发送到还没有 ready 的 backend。

下面是示例应用的配置文件。

重点关注 readinessProbe 部分。这里我们使用了不同于 exec 的另一种探测方法 -- httpGet。Kubernetes 对于该方法探测成功的判断条件是 http 请求的返回代码在 200-400 之间。

schema 指定协议,支持 HTTP(默认值)和 HTTPS
path 指定访问路径。
port 指定端口。

上面配置的作用是:

  1. 容器启动 10 秒之后开始探测。
  2. 如果 http://[container_ip]:8080/healthy 返回代码不是 200-400,表示容器没有就绪,不接收 Service web-svc 的请求。
  3. 每隔 5 秒再探测一次。
  4. 直到返回代码为 200-400,表明容器已经就绪,然后将其加入到 web-svc 的负责均衡中,开始处理客户请求。
  5. 探测会继续以 5 秒的间隔执行,如果连续发生 3 次失败,容器又会从负载均衡中移除,直到下次探测成功重新加入。

对于 http://[container_ip]:8080/healthy,应用则可以实现自己的判断逻辑,比如检查所依赖的数据库是否就绪,示例代码如下:

① 定义 /healthy 的处理函数。

② 连接数据库并执行测试 SQL。

③ 测试成功,正常返回,代码 200。

④ 测试失败,返回错误代码 503。

⑤ 在 8080 端口监听。

对于生产环境中重要的应用都建议配置 Health Check,保证处理客户请求的容器都是准备就绪的 Service backend。

以上是 Health Check 在 Scale Up 中的应用,下一节我们讨论在 Rolling Update 中如果应用。

书籍:

1.《每天5分钟玩转Kubernetes》
https://item.jd.com/26225745440.html

2.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

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

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

时间: 2024-10-13 12:31:38

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

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

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

在 Rolling Update 中使用 Health Check - 每天5分钟玩转 Docker

上一节讨论了 Health Check 在 Scale Up 中的应用,Health Check 另一个重要的应用场景是 Rolling Update.试想一下下面的情况: 现有一个正常运行的多副本应用,接下来对应用进行更新(比如使用更高版本的 image),Kubernetes 会启动新副本,然后发生了如下事件: 正常情况下新副本需要 10 秒钟完成准备工作,在此之前无法响应业务请求. 但由于人为配置错误,副本始终无法完成准备工作(比如无法连接后端数据库). 先别继续往下看,现在请花一分钟思考

如何配置 Health Check?- 每天5分钟玩转 Docker 容器技术(107)

容器状态是 UP 的,应用就是健康的吗? 还真不一定!Docker 只能从容器启动进程的返回代码判断其状态,而对于容器内部应用的运行情况基本没有了解. 执行 docker run 命令时,通常会根据 Dockerfile 中的 CMD 或 ENTRYPOINT 启动一个进程,这个进程的状态就是 docker ps STATUS 列显示容器的状态. 命令显示: 有的容器正在运行,状态为 UP. 有的容器已经正常停止了,状态是 Exited (0). 有的则因发生故障停止了,退出代码为非 0,例如 

如何 Scale Up/Down 应用?- 每天5分钟玩转 Docker 容器技术(126)

伸缩(Scale Up/Down)是指在线增加或减少 Pod 的副本数.Deployment nginx-deployment 初始是两个副本. k8s-node1 和 k8s-node2 上各跑了一个副本.现在修改 nginx.yml,将副本改成 5 个. 再次执行 kubectl apply: 三个新副本被创建并调度到 k8s-node1 和 k8s-node2 上. 出于安全考虑,默认配置下 Kubernetes 不会将 Pod 调度到 Master 节点.如果希望将 k8s-master

容器在 Weave 中如何通信和隔离?- 每天5分钟玩转 Docker 容器技术(65)

上一节我们分析了 Weave 的网络结构,今天讨论 Weave 的连通和隔离特性. 首先在host2 执行如下命令: weave launch 192.168.56.104 这里必须指定 host1 的 IP 192.168.56.104,这样 host1 和 host2 才能加入到同一个 weave 网络. 运行容器 bbox3: eval $(weave env) docker run --name bbox3 -itd busybox weave 网络连通性 bbox3 能够直接 ping

在 Docker 中使用 flannel - 每天5分钟玩转 Docker 容器技术(60)

上一节我们安装和配置了 flannel,本节在 Docker 中使用 flannel. 配置 Docker 连接 flannel 编辑 host1 的 Docker 配置文件 /etc/systemd/system/docker.service,设置 --bip 和 --mtu. 这两个参数的值必须与 /run/flannel/subnet.env 中 FLANNEL_SUBNET 和FLANNEL_MTU 一致. 重启 Docker daemon. systemctl daemon-reloa

在 overlay 中运行容器 - 每天5分钟玩转 Docker 容器技术(51)

上一节我们创建了 overlay 网络 ov_net1,今天将运行一个 busybox 容器并连接到 ov_net1: 查看容器的网络配置: bbox1 有两个网络接口 eth0 和 eth1.eth0 IP 为 10.0.0.2,连接的是 overlay 网络 ov_net1.eth1 IP 172.17.0.2,容器的默认路由是走 eth1,eth1 是哪儿来的呢? 其实,docker 会创建一个 bridge 网络 "docker_gwbridge",为所有连接到 overlay

在 Scale Up 中使用 Health Check【转】

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

在 Rolling Update 中使用 Health Check【转】

上一节讨论了 Health Check 在 Scale Up 中的应用,Health Check 另一个重要的应用场景是 Rolling Update.试想一下下面的情况: 现有一个正常运行的多副本应用,接下来对应用进行更新(比如使用更高版本的 image),Kubernetes 会启动新副本,然后发生了如下事件: 正常情况下新副本需要 10 秒钟完成准备工作,在此之前无法响应业务请求. 但由于人为配置错误,副本始终无法完成准备工作(比如无法连接后端数据库). 先别继续往下看,现在请花一分钟思考