在Kubernetes中，可以为Pod里的容器定义一个健康检查探针（Probe），这样Kubernetes会根据这个Probe的返回值决定这个容器的状态，而不是直接以容器是否允许（来自Docker返回的信息）作为依据。
apiVersion: v1kind: Podmetadata: ?labels: ???test: liveness ?name: test-liveness-execspec: ?containers: ?- name: liveness ???image: busybox ???args: ???- /bin/sh ???- -c ???- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 ???livenessProbe: ?????exec: ???????command: ???????- cat ???????- /tmp/healthy ???initialDelaySeconds: 5 ???periodSeconds: 5
这个Pod的容器在启动之后做的第一件事是在/tmp目录下创建一个healthy文件，以此作为自己已经正常运行的标识，而30s过后它会把这个文件删除掉。同时还定义了一个livenessProbe，类型是exec，它会在容器启动后执行指定的命令：“cat /tmp/healthy”，如果这个文件存在，这条命令返回值就是0，Pod就会认为这个容器不仅已经启动，而且是健康的，这个健康检查在启动5s后开始执行，每5s执行一次。
$ kubectl create -f test-liveness-exec.yaml$ kubectl get podNAME ???????????????READY ????STATUS ???RESTARTS ??AGEtest-liveness-exec ??1/1 ??????Running ??0 ?????????10s####30s后$ kubectl describe pod test-liveness-execFirstSeen LastSeen ???Count ??From ???????????SubobjectPath ??????????Type ???????Reason ?????Message--------- -------- ???----- ??---- ???????????------------- ??????????-------- ???------ ?????-------2s ???????2s ?????1 ??{kubelet worker0} ??spec.containers{liveness} ??Warning ????Unhealthy ??Liveness probe failed: cat: can‘t open ‘/tmp/healthy‘: No such file or directory$ kubectl get pod test-liveness-execNAME ??????????READY ????STATUS ???RESTARTS ??AGEliveness-exec ??1/1 ??????Running ??1 ?????????1m可以看到，健康检查报告容器不健康，但是Pod保存了running状态，这是为什么呢？
认真看可以发现。RESTARTS字段已经变成1了，即这个异常的容器已经被Kubernetes重启了，在这个过程中，Pod保存Running状态不变。Kubernetes没有Docker的Stop语义，所以虽然是重启，实际却是重新创建了容器，这个功能就是Kubernetes里的Pod恢复机制（restartPolicy），它是Pod的Spec部分的一个标准字段（pod.spec.restartPolicy），默认值为Always，即任何时候这个容器发送了异常，一定会被重新创建。
Pod的恢复过程，永远都是发送在当前节点上，而不会跑到别的节点上去，即如果这个宿主机宕机了，这个pod也不会主动迁移到其他节点上去。如果想让Pod出现在其他可用节点上，就必须用Deployment这样的控制器来管理Pod。
[Kubernetes]容器健康检查和恢复机制
原文地址：https://www.cnblogs.com/yuxiaoba/p/9750601.html