一 存活探针存在的意义
1.1 kubernet通过存活探针(liveness probe)检查容器是否还在运行，可以为pod中的每个容器单独指定存活探针，如果探针执行失败，kubernets会重启容器
二 存活探针的三种探测机制
2.1 HTTP GET探针是对容器的IP地址以及指定的端口执行HTTP GET请求，如果探测收到响应，并且响应的返回码是20x，30x则认为探测成功
如果探测的返回值不是或者根本不响应，则表示容器探测失败，需要重启容器
2.2 TCP套接字探针，是尝试在容器里面建立TCP端口连接，建立成功则探测成功，反之，则探测失败
2.3 Exec探针，在容器里面执行任意的命令，如果返回状态码是0则表示探测成功，反之则探测失败，需要重启容器
三 三种存活的创建示范以及代码展示
3.1 创建基于HTTP的存活探针的yaml配置
#cat kubia-liveness-probe.yml
apiVersion: v1 kind: Pod metadata: name: kubia-liveness spec: containers: - image: luksa/kubia-unhealthy name: kubia livenessProbe: httpGet: path: / port: 8080
initialDelaySecond: 15
ports: - containerPort: 8080 protocol: TCP
3.2 创建该pod
k create -f kubia-liveness-probe.yml
pod/kubia-liveness created
3.3 等待几分钟观察pod的运行状况
[root@node01 Chapter04]# k get po NAME READY STATUS RESTARTS AGE kubia-liveness 1/1 Running 5 11m
3.4 观察pod的整个生命周期的状况(省略无关内容)
[root@node01 Chapter04]# k describe po kubia-liveness Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 12m default-scheduler Successfully assigned default/kubia-liveness to node01 Normal Created 6m38s (x3 over 10m) kubelet Created container kubia Normal Started 6m38s (x3 over 10m) kubelet Started container kubia Normal Killing 5m22s (x3 over 9m2s) kubelet Container kubia failed liveness probe, will be restarted Normal Pulling 4m52s (x4 over 12m) kubelet Pulling image "luksa/kubia-unhealthy" Normal Pulled 4m48s (x4 over 10m) kubelet Successfully pulled image "luksa/kubia-unhealthy" Warning Unhealthy 2m2s (x13 over 9m22s) kubelet Liveness probe failed: HTTP probe failed with statuscode: 500
可以看到当在pod中加入存活探针之后，kubelet会周期性的去执行HTTP GET探针，并且在返回500返回码是显示探测失败，并重新拉取镜像，而不是简单的重启容器
四 配置有效探针需要注意的几点
4.1 存活探针应该检查什么
以上演示的探针仅仅是一个get请求，检测服务端是否响应，虽然看起来过于简单，但是对比没有探针的情况下已经是大大的进步了，但为了更好的进行存活检查，需要对get请求的路径
做更进一步详细的描述以达到将所有重要的组件进行检查，以确保这些组件都能健康稳定的运行
4.2 保存探针的轻量型
一个探针不应该过多的消耗系统资源，并且不可运行太长时间，这样会大大的减慢容器的运行，因为探针的cpu配额会计入容器的cpu配额
4.3 无需在探针里面实现重复循环
无需在探针检测逻辑实现重复循环