在 k8s 中，可以为 Pod 里的容器定义一个健康检查"探针"（Probe）。kubelet 就会根据这个 Probe 的返回值决定这个容器的状态，而不是直接以容器是否运行（来自 Docker 返回的信息）作为依据。这种机制，是生产环境中保证应用健康存活的重要手段。
注：
k8s 中并没有 Docker 的 Stop 语义。所以如果容器被探针检测到有问题，查看状态虽然看到的是 Restart，但实际却是重新创建了容器。命令模式探针：Kubernetes 文档中的例子:
[root@kub-k8s-master ~]# cd prome/ [root@kub-k8s-master prome]# vim test-liveness-exec.yaml --- apiVersion: v1 kind: Pod metadata: labels: test: liveness name: test-liveness-exec spec: containers: - name: liveness image: daocloud.io/library/nginx args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 50 livenessProbe: #探针，健康检查 exec: #类型 command: #命令 - cat - /tmp/healthy initialDelaySeconds: 5 #健康检查，在容器启动 5 s 后开始执行 periodSeconds: 5 #每 5 s 执行一次 它在启动之后做的第一件事是在 /tmp 目录下创建了一个 healthy 文件，以此作为自己已经正常运行的标志。而 30 s 过后，它会把这个文件删除掉。 与此同时，定义了一个这样的 livenessProbe（健康检查）。它的类型是 exec，它会在容器启动后，在容器里面执行一句我们指定的命令，比如："cat /tmp/healthy"。这时，如果这个文件存在，这条命令的返回值就是 0，Pod 就会认为这个容器不仅已经启动，而且是健康的。这个健康检查，在容器启动 5 s 后开始执行（initialDelaySeconds: 5），每 5 s 执行一次（periodSeconds: 5）。创建Pod：
[root@kub-k8s-master prome]# kubectl apply -f test-liveness-exec.yaml pod/test-liveness-exec created查看 Pod 的状态：
[root@kub-k8s-master prome]# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-configmap 1/1 Running 0 16h nginx-pod 1/1 Running 0 12h test-liveness-exec 1/1 Running 0 75s由于已经通过了健康检查，这个 Pod 就进入了 Running 状态。
然后30 s 之后，再查看一下 Pod 的 Events：
[root@kub-k8s-master prome]# kubectl describe pod test-liveness-exec发现，这个 Pod 在 Events 报告了一个异常：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Unhealthy 54s (x9 over 3m34s) kubelet, kub-k8s-node1 Liveness probe failed: cat: /tmp/healthy: No such file or directory这个健康检查探查到 /tmp/healthy 已经不存在了，所以它报告容器是不健康的。那么接下来会发生什么呢？
再次查看一下这个 Pod 的状态：
[root@kub-k8s-master prome]# kubectl get pod test-liveness-exec NAME READY STATUS RESTARTS AGE test-liveness-exec 1/1 Running 4 5m19s这时发现，Pod 并没有进入 Failed 状态，而是保持了 Running 状态。这是为什么呢？
RESTARTS 字段从 0 到 1 的变化，就明白原因了：这个异常的容器已经被 Kubernetes 重启了。在这个过程中，Pod 保持 Running 状态不变。注意：Kubernetes 中并没有 Docker 的 Stop 语义。所以虽然是 Restart（重启），但实际却是重新创建了容器。
这个功能就是 Kubernetes 里的Pod 恢复机制，也叫 restartPolicy。它是 Pod 的 Spec 部分的一个标准字段（pod.spec.restartPolicy），默认值是 Always，即：任何时候这个容器发生了异常，它一定会被重新创建。小提示：
Pod 的恢复过程，永远都是发生在当前节点上，而不会跑到别的节点上去。事实上，一旦一个 Pod 与一个节点（Node）绑定，除非这个绑定发生了变化（pod.spec.node 字段被修改），否则它永远都不会离开这个节点。这也就意味着，如果这个宿主机宕机了，这个 Pod 也不会主动迁移到其他节点上去。http get方式探针
[root@kub-k8s-master prome]# vim liveness-httpget.yaml --- apiVersion: v1 kind: Pod metadata: name: liveness-httpget-pod namespace: default spec: containers: - name: liveness-exec-container image: daocloud.io/library/nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 livenessProbe: #探针，健康检查 httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3创建该pod
[root@kub-k8s-master prome]# kubectl create -f liveness-httpget.yaml pod/liveness-httpget-pod created查看当前pod的状态
[root@kub-k8s-master prome]# kubectl describe pod liveness-httpget-pod ... Liveness: http-get http://:http/index.html delay=1s timeout=1s period=3s #success=1 #failure=3 ...测试将容器内的index.html删除掉
登陆容器
[root@kub-k8s-master prome]# kubectl exec -it liveness-httpget-pod /bin/bash root@liveness-httpget-pod:/# mv /usr/share/nginx/html/index.html index.html root@liveness-httpget-pod:/# command terminated with exit code 137可以看到，当把index.html移走后，这个容器立马就退出了。
此时，查看pod的信息
[root@kub-k8s-master prome]# kubectl describe pod liveness-httpget-pod ... Normal Killing 49s kubelet, kub-k8s-node2 Container liveness-exec-container failed liveness probe, will be restarted Normal Pulled 49s kubelet, kub-k8s-node2 Container image "daocloud.io/library/nginx" already present on machine ...看输出，容器由于健康检查未通过，pod会被杀掉，并重新创建
[root@kub-k8s-master prome]# kubectl get pods NAME READY STATUS RESTARTS AGE lifecycle-demo 1/1 Running 1 34h liveness-httpget-pod 1/1 Running 1 5m42srestarts 为 1
重新登陆容器查看
重新登陆容器，发现index.html又出现了，证明容器是被重拉了。
[root@kub-k8s-master prome]# kubectl exec -it liveness-httpget-pod /bin/bash root@liveness-httpget-pod:/# cat /usr/share/nginx/html/index.html