通過命令健康檢查的一個例子
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: test-liveness-exec
spec:
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 # 容器執(zhí)行5秒之后進行健康檢查
periodSeconds: 5 # 每隔5秒進行健康檢查
我們定義了一個這樣的 livenessProbe（健康檢查）它的類型是 exec，這意味著蜒什，它會在容器啟動后，在容器里面執(zhí)行一句我們指定的命令，比如：“cat /tmp/healthy”关拒。這時，如果這個文件存在，這條命令的返回值就是 0着绊，Pod 就會認為這個容器不僅已經啟動谐算，而且是健康的。這個健康檢查归露，在容器啟動 5 s 后開始執(zhí)行（initialDelaySeconds: 5）洲脂，每 5 s 執(zhí)行一次
（periodSeconds: 5）。
我們發(fā)現剧包，Pod 并沒有進入 Failed 狀態(tài)恐锦，而是保持了 Running 狀態(tài)。這是為什么呢疆液？
其實一铅，如果你注意到 RESTARTS 字段從 0 到 1 的變化，就明白原因了：這個異常的容器已經被
Kubernetes 重啟了堕油。在這個過程中潘飘，Pod 保持 Running 狀態(tài)不變。
需要注意的是：Kubernetes 中并沒有 Docker 的 Stop 語義掉缺。所以雖然是 Restart（重啟）卜录，但實際卻是重新創(chuàng)建了容器。
這個功能就是 Kubernetes 里的Pod 恢復機制攀圈，也叫 restartPolicy暴凑。它是 Pod 的 Spec 部分的一個標準字段（pod.spec.restartPolicy），默認值是 Always赘来，即：任何時候這個容器發(fā)生了異常现喳，它一定會被重新創(chuàng)建。
但一定要強調的是犬辰，Pod 的恢復過程嗦篱，永遠都是發(fā)生在當前節(jié)點上，而不會跑到別的節(jié)點上去幌缝。事實上灸促，一旦一個 Pod 與一個節(jié)點（Node）綁定，除非這個綁定發(fā)生了變化（pod.spec.node 字段
被修改）涵卵，否則它永遠都不會離開這個節(jié)點浴栽。這也就意味著，如果這個宿主機宕機了轿偎，這個 Pod 也不會主動遷移到其他節(jié)點上去典鸡。
而如果你想讓 Pod 出現在其他的可用節(jié)點上，就必須使用 Deployment 這樣的“控制器”來管理Pod
restartPolicy 和 Pod 里容器的狀態(tài)坏晦，以及 Pod 狀態(tài)的對應關系總結：
1萝玷、只要 Pod 的 restartPolicy 指定的策略允許重啟異常的容器（比如：Always）嫁乘，那么這個 Pod就會保持 Running 狀態(tài)，并進行容器重啟球碉。
否則蜓斧，Pod 就會進入 Failed 狀態(tài) 。
2睁冬、對于包含多個容器的 Pod挎春，只有它里面所有的容器都進入異常狀態(tài)后，Pod 才會進入 Failed 狀態(tài)豆拨。
在此之前搂蜓，Pod 都是 Running 狀態(tài)。此時辽装，Pod 的 READY 字段會顯示正常容器的個數，
所以相味，假如一個 Pod 里只有一個容器拾积，然后這個容器異常退出了。那么丰涉，只有當restartPolicy=Never 時拓巧，這個 Pod 才會進入 Failed 狀態(tài)。
健康檢查發(fā)起HTTP請求
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
健康檢查發(fā)起TCP請求
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
