大部分的應用程序我們在部署的時候都會適當的添加監控，對於運行載體容器則更應該如此。kubernetes提供了 liveness probes來檢查我們的應用程序。它是由節點上的kubelet定期執行的。
首先說一下Pod的整個生命階段：
- Pending：表示集群系統正在創建Pod，但是Pod中的container還沒有全部被創建，這其中也包含集群為container創建網絡，或者下載鏡像的時間；
- Running：表示pod已經運行在一個節點商量，並且所有的container都已經被創建。但是並不代表所有的container都運行，它僅僅代表至少有一個container是處於運行的狀態或者進程出於啟動中或者重啟中；
- Succeeded：所有Pod中的container都已經終止成功，並且沒有處於重啟的container；
- Failed：所有的Pod中的container都已經終止了，但是至少還有一個container沒有被正常的終止(其終止時的退出碼不為0)
對於Liveness Probe的結果也有幾個固定的可選項值：
- Success：表示通過檢測
- Failure：表示沒有通過檢測
- Unknown：表示檢測沒有正常進行
Liveness Probe的種類：
- ExecAction：在container中執行指定的命令。當其執行成功時，將其退出碼設置為0；
- TCPSocketAction：執行一個TCP檢查使用container的IP地址和指定的端口作為socket。如果端口處於打開狀態視為成功；
- HTTPGetAcction：執行一個HTTP默認請求使用container的IP地址和指定的端口以及請求的路徑作為url，用戶可以通過host參數設置請求的地址，通過scheme參數設置協議類型(HTTP、HTTPS)如果其響應代碼在200~400之間，設為成功。
當前kubelet擁有兩個檢測器，他們分別對應不通的觸發器(根據觸發器的結構執行進一步的動作)：
- Liveness Probe：表示container是否處於live狀態。如果 LivenessProbe失敗，LivenessProbe將會通知kubelet對應的container不健康了。隨后kubelet將kill掉 container，並根據RestarPolicy進行進一步的操作。默認情況下LivenessProbe在第一次檢測之前初始化值為 Success，如果container沒有提供LivenessProbe，則也認為是Success；
- Readiness Probe：表示container是否以及處於可接受service請求的狀態了。如 果ReadinessProbe失敗，endpoints controller將會從service所匹配到的endpoint列表中移除關於這個container的IP地址。因此對於Service匹配到的 endpoint的維護其核心是Readiness Probe。默認Readiness的初始值是Failure，如果一個container沒有提供 Readiness則被認為是Success。
對於Liveness Probe和Readiness Probe用法都一樣，擁有相同的參數和相同的監測方式。
- initialDelaySeconds：用來表示初始化延遲的時間，也就是告訴監測從多久之后開始運行，單位是秒
- timeoutSeconds: 用來表示監測的超時時間，如果超過這個時長后，則認為監測失敗
當前對每一個Container都可以設置不同的restartpolicy，有三種值可以設置：
- Always: 只要container退出就重新啟動
- OnFailure: 當container非正常退出后重新啟動
- Never: 從不進行重新啟動
如果restartpolicy沒有設置，那么默認值是Always。如果container需要重啟，僅僅是通過kubelet在當前節點進行container級別的重啟。
最后針對Liveness Probe如何使用，請看下面的幾種方式，如果要使用ReadinessProbe只需要將livenessProbe修改為readinessProbe即可：
apiVersion: v1
kind: Pod
metadata:
name: probe-exec
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
exec:
command:
- cat
- /tmp/health
initialDelaySeconds: 5
timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
name: probe-http
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
httpGet:
path: /
port: 80
host: www.baidu.com
scheme: HTTPS
initialDelaySeconds: 5
timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 80
關於kubectl資源創建的語法可以參考: kubernetes技術學習之—Construct語法
我們使用上面的construct創建資源：
kubectl create -f probe.yaml
kubectl get event
kubernetes之配置保活探針與就緒探針
在kubernetes中，kubelet通過liveness探針決定在何時重新啟動容器。例如，容器中的應用運行時進入死鎖狀態，liveness探針對容器進行健康檢查時檢測到這種情況，那么探針檢測失敗，則kubelet就會重新啟動容器。可以看到重新啟動並沒有從根本上解決死鎖問題，只是忽略了問題使容器繼續運行。
kubelet通過readiness類型的探針決定container是否准備就緒處理流量，當pod中的所有container全部處於ready狀態時，pod被認為可以對外提供服務。readiness探針的典型應用是控制pod是否作為service的backend。以下示例中都沒有為容器指定"restart policy"，所以均采用默認值"Always"。
Define a liveness command
有些程序因為長時間運行而進入崩壞的狀態，其中的一個解決辦法是重新啟動，liveness探針專門用來解決此類問題。
下例是運行一個容器的pod，容器image是k8s.gcr.io/busybox，配置文件如下：
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: k8s.gcr.io/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包含一個容器。每隔 periodSeconds秒執行一次liveness探針診斷，initialDelaySeconds表示kubelet在啟動容器后首次執行探針診斷的延遲時間。探針的具體實現是在容器內部執行cat /tmp/healthy命令，如果命令退出碼是0表示容器存活健康，如果非0則kubelet重新啟動容器。
容器啟動以后執行如下指令：
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
創建pod：
kubectl create -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
在30秒之內查看pod事件：
kubectl describe pod liveness-exec
輸出如下：
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
35秒以后，再次查看pod事件，輸出如下：
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
發現探針診斷失敗事件，此時容器被重新啟動，再等待30秒，確定容器被重啟：
kubectl get pod liveness-exec
輸出結果：
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m
restart次數被加1。
Define a liveness HTTP request
以下是HTTP GET類型的liveness探針示例，pod包含一個容器，image是k8s.gcr.io/liveness：
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
注意探針中path、port、httpHeader的配置，kubelet通過這些信息，構建http get請求，並通過kuelet運行的網絡將請求發送到容器的指定端口、路徑上。當應答狀態碼大於等於200小於400時表示探針診斷通過，其它狀態碼表示失敗。kubelet殺死容器然后重新啟動。
Define a TCP liveness probe
TCP類型是最簡單的探針，kubelet嘗試打開容器上的某個端口，如果連接成功建立則診斷通過，否則失敗，示例配置如下：
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
Use a named port
在定義探針時使用命名端口，示例如下：
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
Define readiness probes
容器有時候會暫時無法對外提供服務，比如容器在啟動階段需要下載大量數據配置文件等，此時容器無法對外提供服務但又不能殺死它，而用戶也希望此時容器不要授受來自service的流量 ，readiness類型探針專門處理此種情況。
readiness probe與liveness probe的配置類似，唯一不同的只是字段名稱，將livenessProbe換成readinessProbe，如下：
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
readiness probe暫時阻止pod成為service的backend，當診斷通過時再將pod加入到相應service的后端。liveness探針影響的是單個容器，但readiness探針影響的是整個pod，即如果pod中有多個容器，只要有一個容器的readiness探針診斷失敗，那么整個pod都會處於unready狀態。