对于多副本应用, 当执行 Scale Up 操作时, 新副本会作为 backend 被添加到 Service 的负责均衡中, 与已有副本一起处理客户的请求考虑到应用启动通常都需要一个准备阶段, 比如加载缓存数据, 连接数据库等, 从容器启动到正真能够提供服务是需要一段时间的我们可以通过 Readiness 探测判断容器是否就绪, 避免将请求发送到还没有 ready 的 backend
下面是示例应用的配置文件
重点关注 readinessProbe 部分这里我们使用了不同于 exec 的另一种探测方法 -- httpGetKubernetes 对于该方法探测成功的判断条件是 http 请求的返回代码在 200-400 之间
schema 指定协议, 支持 HTTP(默认值) 和 HTTPS
path 指定访问路径
port 指定端口
上面配置的作用是:
容器启动 10 秒之后开始探测
如果
http://[container_ip]:8080/healthy
返回代码不是 200-400, 表示容器没有就绪, 不接收 Service web-svc 的请求
每隔 5 秒再探测一次
直到返回代码为 200-400, 表明容器已经就绪, 然后将其加入到 web-svc 的负责均衡中, 开始处理客户请求
探测会继续以 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
来源: https://www.cnblogs.com/CloudMan6/p/8621305.html