通過命令健康檢查的一個例子
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