kubernetes健康检查liveness和readiness

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、容器重启后故障恢复