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容許重複標頭。