上一节讨论了 Health Check 在 Scale Up 中的应用,Health Check 另一个重要的应用场景是 Rolling Update。试想一下下面的情况:
现有一个正常运行的多副本应用,接下来对应用进行更新(比如使用更高版本的 image),Kubernetes 会启动新副本,然后发生了如下事件:
-
正常情况下新副本需要 10 秒钟完成准备工作,在此之前无法响应业务请求。
-
但由于人为配置错误,副本始终无法完成准备工作(比如无法连接后端数据库)。
先别继续往下看,现在请花一分钟思考这个问题:如果没有配置 Health Check,会出现怎样的情况?
因为新副本本身没有异常退出,默认的 Health Check 机制会认为容器已经就绪,进而会逐步用新副本替换现有副本,其结果就是:当所有旧副本都被替换后,整个应用将无法处理请求,无法对外提供服务。如果这是发生在重要的生产系统上,后果会非常严重。
如果正确配置了 Health Check,新副本只有通过了 Readiness 探测,才会被添加到 Service;如果没有通过探测,现有副本不会被全部替换,业务仍然正常进行。
下面通过例子来实践 Health Check 在 Rolling Update 中的应用。
用如下配置文件 app.v1.yml
模拟一个 10 副本的应用:
>>>阅读全文