如何在RollingUpdate中使用HealthCheck

这期内容当中小编将会给大家带来有关如何在Rolling Update中使用Health Check，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

创新互联网站建设公司是一家服务多年做网站建设策划设计制作的公司,为广大用户提供了做网站、成都网站建设，成都网站设计，广告投放，成都做网站选创新互联，贴合企业需求，高性价比，满足客户不同层次的需求一站式服务欢迎致电。

Health Check 另一个重要的应用场景是 Rolling Update。试想一下下面的情况：

现有一个正常运行的多副本应用，接下来对应用进行更新（比如使用更高版本的 image），Kubernetes 会启动新副本，然后发生了如下事件：

1. 正常情况下新副本需要 10 秒钟完成准备工作，在此之前无法响应业务请求。

2. 但由于人为配置错误，副本始终无法完成准备工作（比如无法连接后端数据库）。

先别继续往下看，现在请花一分钟思考这个问题：如果没有配置 Health Check，会出现怎样的情况？

因为新副本本身没有异常退出，默认的 Health Check 机制会认为容器已经就绪，进而会逐步用新副本替换现有副本，其结果就是：当所有旧副本都被替换后，整个应用将无法处理请求，无法对外提供服务。如果这是发生在重要的生产系统上，后果会非常严重。

如果正确配置了 Health Check，新副本只有通过了 Readiness 探测，才会被添加到 Service；如果没有通过探测，现有副本不会被全部替换，业务仍然正常进行。

下面通过例子来实践 Health Check 在 Rolling Update 中的应用。

用如下配置文件 app.v1.yml 模拟一个 10 副本的应用：

10 秒后副本能够通过 Readiness 探测。

很显然，由于新副本中不存在 /tmp/healthy，是无法通过 Readiness 探测的。验证如下：

如果滚动更新失败，可以通过 kubectl rollout undo 回滚到上一个版本。

小结

本章我们讨论了 Kubernetes 健康检查的两种机制：Liveness 探测和 Readiness 探测，并实践了健康检查在 Scale Up 和 Rolling Update 场景中的应用。

上述就是小编为大家分享的如何在Rolling Update中使用Health Check了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。