目录
liveness probe–存活探针
例如:
一个nginx的pod
探针会检查:
nginx是否存活---是---继续----nginx是否有返回(是否可用)---是---继续----循环
| |
|__否---重启-------------------------|___否---重启
还有一个很重要的点
liveness的初始值是可用的,换句话说
一个配置了liveness的pod,一开始就先默认它是没有问题的,不需要重启的.
这样的状态会一直持续到探针检测到pod不正常了,这个值才会改变
readiness probe–就绪状态探针
例如:
一个tomcat的pod,配置了replicas=3
探针会检查:
标记,概念理解待补全
2020.7.29更新
readiness这个探针,我在之前把单词拼写错了,这间接导致了我对探针概念的理解
readnes会被理解成可读性探测
readiness正确的理解,应该是就绪状态探测
实验
下面开始记录实验过程
测试liveness需要准备:
新建MySQL用户test001
新建POD:order-replicas
新建svc :order-replicas-svc
新建 secret:mysql-test-secret
将新建的svc、secert与order-replicas相关联,
使得order-replicas能正常连接数据,正常运行
一、观察没有探针的情况,pod无法工作时的情况
此时还没有为order-replicas添加livness探针
我们通过停止数据库容器来模拟order-replicas连接不上数据库的情况
# docker stop alfred-uat-mysql
Order-replicas开始因为连不上数据库,报错
同时我们看一下建卡检查的api
返回了DOWN
在这样的情况下,order-replicas已经无法正常工作了,
但是由于没有添加探针
它仍然是存活状态
二、添加探针后,观察现象,对比(一)
修改order-replicas的yaml文件,为该pod添加liveness探针
用同样的方法,模拟order-replicas连接不上数据库
# docker stop alfred-uat-mysql
持续一段时间后,观察pod状态
发现pod下的容器restart次数增加
说明探针发现了容器的异常,并通过重启的方式,尝试自我修复
测试readness需要准备:
新建MySQL用户test001
新建POD:order-replicas
新建 secret:mysql-test-secret
首先将order和order-replicas都做成order-svc的endpoint
但是order与order-replicas使用不同的账号连接数据库
观察两个pod都会被svc分发请求
通过修改order-replicas连接数据库的账号密码(也可以在数据库修改test001的密码),
加上
# docker restart mysql
重启数据库,迫使所有模块重新连接数据库
模拟出order正常,但是order-replicas无法连接数据库的情况
左图是order-replicas;右图是order
使用kubectl get pods 查看pod的状态
观察order-svc详情,发现order-replicas已经被从endpoint中摘除
说明order-replicas此时已经不会被分配请求。
练习
联合liveness与readiness测试
预期效果:
1、当pod无法响应,readiness探针检测到异常将pod标记为notready;
2、同时liveness探针也检测到异常,将故障容器杀死并重建。
3、要求重建容器后故障恢复。
通过修改yaml文件,(或者进入容器手动修改)
1、设定容器在运行后sleep30秒,然后修改环境变量MYSQL_PASS
2、然后手动重启数据库,迫使容器使用新的MYSQL_PASS重新连接数据库,
这时容器因为连不上数据库报异常,让两个探针都检测到
并且观察到现象
1、readiness摘除故障容器;
2、liveness杀死并重建容器
3、容器重启后故障恢复