kubernetes Readiness and liveness and startupProbe

kubernetes Pod 的生命周期（Readiness and liveness and startupProbe）

容器探針

為什么要使用readiness and liveness？

因為k8s中采用大量的異步機制、以及多種對象關系設計上的解耦，當應用實例數 增加/刪除、或者應用版本發生變化觸發滾動升級時，系統并不能保證應用相關的service、ingress配置總是及時能完成刷新。在一些情況下，往往只是新的Pod完成自身初始化，系統尚未完成EndPoint、負載均衡器等外部可達的訪問信息刷新，老得Pod就立即被刪除，最終造成服務短暫的額不可用，這對于生產來說是不可接受的，所以這個時候存活探針（Readiness）就登場了

啟動探針（startup Probe）

有時候，服務啟動之后并不一定能夠立馬使用，我們以前常做的就是使用就緒探針設置initialDelay(容器啟動后多少s開始探測)值，來判斷服務是否存活，大概設置如下

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

但是這個時候會出現這么一個情況，如果我們的服務A啟動需要60s ，如果采用上面探針的會，這個pod就陷入死循環了，因為啟動之后經過10s探測發現不正常就會更具重啟策略進行重啟Pod，一直進入死循環。那聰明的你肯定能猜到我們調整下initialDelay的值不就好了嗎？ 但是你能保證每個服務你都知道啟動需要多少s 能好嗎？
聰明的您肯定又想到了 哪我們可以調整下failureThreshold的值就好了，但是應該調整為多大呢？如果我們設置成

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 5
  initialDelay：10
  periodSeconds: 10

如果設置成這樣，第一次pod 是能正常啟動了，但是我們到后面探測的話需要（5*10s=50s）我們才能發現我們的服務不可用。這在生產中是不允許發生的，所以我們采用startupProbe使用和livenessProbe一樣的探針來判斷服務是否啟動成功了

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 10
  initialDelay：10
  periodSeconds: 10

我們這只成這樣的話，只要服務在1010=100s內任何時候啟動來都行，探針探測成功后就交給livenessProbe進行繼續探測了，當我們發現問題的時候110=10 在10s內就能發現問題，并及時作出響應。

服務探針(readiness probe)

檢測容器中的程序是否啟動就緒,只有當檢測容器中的程序啟動成功之后,才會變成running狀態,否則就是容器啟動成功,他還是失敗的信號(因為他里面的服務沒有探測成功)

存活探針(liveness Probe)(是否運行)

檢測容器是否在運行,只是單純的檢測容器是否存活,并不會檢測里面的服務是否正常.如果探針檢測到失敗,他將啟動他的重啟策略.

三種類型的處理程序:

• 1, ExecAction: 通過自定義命令來進行探測,當返回值是0的時候說明存活,當返回值非0的時候表示不存活.
• 2, TCPSocketAction: 對容器上的端口進行tcp檢查,如果端口是打開的,則說明存活
• 3, HTTPGetAction: 對指定端口和url地址執行HTTP Get請求,如果響應的狀態碼大于等于200且小于400,則認為存活

每次探測都只能只能是下面三種結果:

• 1, 成功: 容器通過了測試
• 2, 失敗: 容器未通過測試
• 3, 未知: 測試失敗,因此不會采取任何動作

探針示例:

ExecAction

# cat nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  restartPolicy: OnFailure
  containers:
  - name: nginx
    image: nginx:1.14.1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
    - name: https
      containerPort: 443
      protocol: TCP
    livenessProbe:
      exec:
        command: ["test","-f","/usr/share/nginx/html/index.html"]
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 5
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 15
      timeoutSeconds: 1

我們啟動這個容器,測試一下服務探針.

kubectl create -f nginx.yaml

我們進入到nginx容器里面把index這個文件刪除了,看看詳細信息

#kubectl describe pod nginx
.....
Events:
  Type     Reason     Age                From                    Message
  ----     ------     ----               ----                    -------
  Normal   Scheduled  4m24s              default-scheduler       Successfully assigned default/nginx to 192.168.1.124
  Normal   Pulling    4m23s              kubelet, 192.168.1.124  pulling image "nginx:1.14.1"
  Normal   Pulled     4m1s               kubelet, 192.168.1.124  Successfully pulled image "nginx:1.14.1"
  Warning  Unhealthy  57s                kubelet, 192.168.1.124  Readiness probe failed: HTTP probe failed with statuscode: 404
  Warning  Unhealthy  50s (x3 over 60s)  kubelet, 192.168.1.124  Liveness probe failed:
  Normal   Killing    50s                kubelet, 192.168.1.124  Killing container with id docker://nginx:Container failed liveness probe.. Container will be killed and recreated.
  Normal   Pulled     50s                kubelet, 192.168.1.124  Container image "nginx:1.14.1" already present on machine
  Normal   Created    49s (x2 over 4m)   kubelet, 192.168.1.124  Created container
  Normal   Started    49s (x2 over 4m)   kubelet, 192.168.1.124  Started container

很明顯的從事件信息里面可以看到他服務探測有一次是報錯404的,然后立馬就執行了重啟容器的過程

探針參數介紹:

exec: 使用自定義命令編寫探針
httpGet: 使用http訪問的方式探測
tcpSocket: 使用tcp套接字來探測
failureThreshold: 連續失敗幾次算真正的失敗
initialDelaySeconds: 容器啟動多少秒之后開始探測(因為容器里面的服務啟動需要時間)
periodSeconds: 探測時間間隔多少秒
timeoutSeconds: 命令執行的超時時間

HTTPGet的探針參數:

1. host: 探測那個主機(URL)
2. path: 訪問的路徑(URI)
3. port: 訪問的端口(必須字段)
4. scheme：用于連接主機的方案（HTTP或HTTPS）。默認為HTTP
5. httpHeaders：要在請求中設置的自定義標頭。HTTP允許重復標頭。