赞
踩
1.Liveness 探测和 Readiness 探测是两种 Health Check 机制,如果不特意配置, Kubernetes 将对两种探测采取相同的默认行为,即通过判断容器启动进程的返回值是否为零来判断探测是否成功。
2.两种探测的配置方法完全一样,支持的配置参数也一样。不同之处在于探测失败后的行为:Liveness 探测是重启容器;Readiness 探测则是将容器设置为不可用,不接收 Service 转发的请求。
Liveness 探测和 Readiness 探测是独立执行的,二者之间没有依赖,所以可以单独使用,也可以同时使用。用 Liveness 探测判断容器是否需要重启以实现自愈;用Readiness 探测判断容器是否已经准备好对外提供服务。
Heath Check在滚动更新Rolling Up 中的应用
现有一个正常运行的多副本应用,接下来对应用进行更新(比如使用更高版本的image),Kubernetes 会启动新副本,然后发生了如下事件:
1.正常情况下新副本需要 10 秒钟完成准备工作,在此之前无法响应业务请求。
2.但由于人为配置错误,副本始终无法完成准备工作(比如无法连接后端数据库)。先别继续往下看,现在请花一分钟思考这个问题:如果没有配置 Health Check,会出现怎样的情况?
因为新副本本身没有异常退出,默认的 Health Check 机制会认为容器已经就绪,进而会逐步用新副本替换现有副本,其结果就是:当所有旧副本都被替换后,整个应用将无法处理请求,无法对外提供服务。如果这是发生在重要的生产系统上,后果会非常严重。
如果正确配置了 Health Check,新副本只有通过了 Readiness 探测,才会被添加到Service;如果没有通过探测,现有副本不会被全部替换,业务仍然正常进行。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。