k8s之健康檢查(Health Check)

強大的自愈能力是 Kubernetes 這類容器編排引擎的一個重要特性。自愈的默認實現方式是自動重啓發生故障的容器。除此之外，用戶還可以利用 Liveness 和 Readiness 探測機制設置更精細的健康檢查，進而實現如下需求：

零停機部署。
避免部署無效的鏡像。
更加安全的滾動升級。

下面通過實踐學習 Kubernetes 的 Health Check 功能。

默認的健康檢查

我們首先學習 Kubernetes 默認的健康檢查機制：

每個容器啓動時都會執行一個進程，此進程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果進程退出時返回碼非零，則認爲容器發生故障，Kubernetes 就會根據 restartPolicy 重啓容器。

下面我們模擬一個容器發生故障的場景，Pod 配置文件如下：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: healthcheck
  name: healthcheck
spec:
  restartPolicy: OnFailure
  containers:
  - name: healthcheck
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10; exit 1

Pod 的 restartPolicy 設置爲 OnFailure，默認爲 Always。

sleep 10; exit 1 模擬容器啓動 10 秒後發生故障。

執行 kubectl apply 創建 Pod，命名爲 healthcheck。

# kubectl apply -f healthcheck.yml
pod/healthcheck created

過幾分鐘查看 Pod 的狀態：

# kubectl get pod healthcheck 
NAME          READY   STATUS             RESTARTS   AGE
healthcheck   0/1     CrashLoopBackOff   4          3m39s

可看到容器當前已經重啓了 4 次。

在上面的例子中，容器進程返回值非零，Kubernetes 則認爲容器發生故障，需要重啓。但有不少情況是發生了故障，但進程並不會退出。比如訪問 Web 服務器時顯示 500 內部錯誤，可能是系統超載，也可能是資源死鎖，此時 httpd 進程並沒有異常退出，在這種情況下重啓容器可能是最直接最有效的解決方案，那我們如何利用 Health Check 機制來處理這類場景呢？

答案就是 Liveness 探測，我們下一節學習。

Liveness 探測

Liveness 探測讓用戶可以自定義判斷容器是否健康的條件。如果探測失敗，Kubernetes 就會重啓容器。

還是舉例說明，創建如下 Pod：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness
spec:
  restartPolicy: OnFailure
  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: 10
      periodSeconds: 5

啓動進程首先創建文件 /tmp/healthy，30 秒後刪除，在我們的設定中，如果 /tmp/healthy 文件存在，則認爲容器處於正常狀態，反正則發生故障。

livenessProbe 部分定義如何執行 Liveness 探測：

探測的方法是：通過 cat 命令檢查 /tmp/healthy 文件是否存在。如果命令執行成功，返回值爲零，Kubernetes 則認爲本次 Liveness 探測成功；如果命令返回值非零，本次 Liveness 探測失敗。
initialDelaySeconds: 10 指定容器啓動 10 之後開始執行 Liveness 探測，我們一般會根據應用啓動的準備時間來設置。比如某個應用正常啓動要花 30 秒，那麼 initialDelaySeconds 的值就應該大於 30。
periodSeconds: 5 指定每 5 秒執行一次 Liveness 探測。Kubernetes 如果連續執行 3 次 Liveness 探測均失敗，則會殺掉並重啓容器。

下面創建 Pod liveness：

# kubectl apply -f liveness.yaml
pod/liveness created

從配置文件可知，最開始的 30 秒，/tmp/healthy 存在，cat 命令返回 0，Liveness 探測成功，這段時間 kubectl describe pod liveness 的 Events部分會顯示正常的日誌。

# kubectl describe pod liveness

Events:
  Type    Reason     Age   From                Message
  ----    ------     ----  ----                -------
  Normal  Scheduled  31s   default-scheduler   Successfully assigned default/liveness to k8s-node2
  Normal  Pulling    30s   kubelet, k8s-node2  Pulling image "busybox"
  Normal  Pulled     30s   kubelet, k8s-node2  Successfully pulled image "busybox"
  Normal  Created    30s   kubelet, k8s-node2  Created container liveness
  Normal  Started    29s   kubelet, k8s-node2  Started container liveness

35 秒之後，日誌會顯示 /tmp/healthy 已經不存在，Liveness 探測失敗。再過幾十秒，幾次探測都失敗後，容器會被重啓。

Events:
  Type     Reason     Age               From                Message
  ----     ------     ----              ----                -------
  Normal   Scheduled  47s               default-scheduler   Successfully assigned default/liveness to k8s-node2
  Normal   Pulling    46s               kubelet, k8s-node2  Pulling image "busybox"
  Normal   Pulled     46s               kubelet, k8s-node2  Successfully pulled image "busybox"
  Normal   Created    46s               kubelet, k8s-node2  Created container liveness
  Normal   Started    45s               kubelet, k8s-node2  Started container liveness
  Warning  Unhealthy  3s (x3 over 13s)  kubelet, k8s-node2  Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing    3s                kubelet, k8s-node2  Container liveness failed liveness probe, will be restarted

# kubectl get pod liveness 
NAME       READY   STATUS    RESTARTS   AGE
liveness   1/1     Running   1          76s

除了 Liveness 探測，Kubernetes Health Check 機制還包括 Readiness 探測。

Readiness 探測

用戶通過 Liveness 探測可以告訴 Kubernetes 什麼時候通過重啓容器實現自愈；Readiness 探測則是告訴 Kubernetes 什麼時候可以將容器加入到 Service 負載均衡池中，對外提供服務。

Readiness 探測的配置語法與 Liveness 探測完全一樣，下面是個例子：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness
spec:
  restartPolicy: OnFailure
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 10
      periodSeconds: 5

這個配置文件只是將前面例子中的 liveness 替換爲了 readiness，我們看看有什麼不同的效果。

[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          10s
[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   1/1     Running   0          20s
[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   1/1     Running   0          35s
[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          61s
[root@k8s-master ~]# kubectl describe pod readiness

Pod readiness 的 READY 狀態經歷瞭如下變化：

剛被創建時，READY 狀態爲不可用。
15 秒後（initialDelaySeconds + periodSeconds），第一次進行 Readiness 探測併成功返回，設置 READY 爲可用。
30 秒後，/tmp/healthy 被刪除，連續 3 次 Readiness 探測均失敗後，READY 被設置爲不可用。

通過 kubectl describe pod readiness 也可以看到 Readiness 探測失敗的日誌。

Events:
  Type     Reason     Age                From                Message
  ----     ------     ----               ----                -------
  Normal   Scheduled  95s                default-scheduler   Successfully assigned default/readiness to k8s-node2
  Normal   Pulling    94s                kubelet, k8s-node2  Pulling image "busybox"
  Normal   Pulled     94s                kubelet, k8s-node2  Successfully pulled image "busybox"
  Normal   Created    93s                kubelet, k8s-node2  Created container readiness
  Normal   Started    93s                kubelet, k8s-node2  Started container readiness
  Warning  Unhealthy  4s (x12 over 59s)  kubelet, k8s-node2  Readiness probe failed: cat: can't open '/tmp/healthy': No such file or directory

下面對 Liveness 探測和 Readiness 探測做個比較：

Liveness 探測和 Readiness 探測是兩種 Health Check 機制，如果不特意配置，Kubernetes 將對兩種探測採取相同的默認行爲，即通過判斷容器啓動進程的返回值是否爲零來判斷探測是否成功。
兩種探測的配置方法完全一樣，支持的配置參數也一樣。不同之處在於探測失敗後的行爲：Liveness 探測是重啓容器；Readiness 探測則是將容器設置爲不可用，不接收 Service 轉發的請求。
Liveness 探測和 Readiness 探測是獨立執行的，二者之間沒有依賴，所以可以單獨使用，也可以同時使用。用 Liveness 探測判斷容器是否需要重啓以實現自愈；用 Readiness 探測判斷容器是否已經準備好對外提供服務。

在業務場景中使用 Health Check。

在 Scale Up 中使用 Health Check

對於多副本應用，當執行 Scale Up 操作時，新副本會作爲 backend 被添加到 Service 的負載均衡中，與已有副本一起處理客戶的請求。考慮到應用啓動通常都需要一個準備階段，比如加載緩存數據，連接數據庫等，從容器啓動到正真能夠提供服務是需要一段時間的。我們可以通過 Readiness 探測判斷容器是否就緒，避免將請求發送到還沒有 ready 的 backend。

下面是示例應用的配置文件。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: web
        image: myhttpd
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /healthy
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    run: web
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80

重點關注 readinessProbe 部分。這裏我們使用了不同於 exec 的另一種探測方法 -- httpGet。Kubernetes 對於該方法探測成功的判斷條件是 http 請求的返回代碼在 200-400 之間。

schema 指定協議，支持 HTTP（默認值）和 HTTPS。
path 指定訪問路徑。
port 指定端口。

上面配置的作用是：

容器啓動 10 秒之後開始探測。

如果 http://[container_ip]:8080/healthy 返回代碼不是 200-400，表示容器沒有就緒，不接收 Service web-svc 的請求。

每隔 5 秒再探測一次。

直到返回代碼爲 200-400，表明容器已經就緒，然後將其加入到 web-svc 的負責均衡中，開始處理客戶請求。

探測會繼續以 5 秒的間隔執行，如果連續發生 3 次失敗，容器又會從負載均衡中移除，直到下次探測成功重新加入。

對於 http://[container_ip]:8080/healthy，應用則可以實現自己的判斷邏輯，比如檢查所依賴的數據庫是否就緒，示例代碼如下：

① 定義 /healthy 的處理函數。

② 連接數據庫並執行測試 SQL。

③ 測試成功，正常返回，代碼 200。

④ 測試失敗，返回錯誤代碼 503。

⑤ 在 8080 端口監聽。

對於生產環境中重要的應用都建議配置 Health Check，保證處理客戶請求的容器都是準備就緒的 Service backend。

在 Rolling Update 中如果應用。

在 Rolling Update 中使用 Health Check

上一節討論了 Health Check 在 Scale Up 中的應用，Health Check 另一個重要的應用場景是 Rolling Update。試想一下下面的情況：

現有一個正常運行的多副本應用，接下來對應用進行更新（比如使用更高版本的 image），Kubernetes 會啓動新副本，然後發生瞭如下事件：

正常情況下新副本需要 10 秒鐘完成準備工作，在此之前無法響應業務請求。
但由於人爲配置錯誤，副本始終無法完成準備工作（比如無法連接後端數據庫）。

思考問題：如果沒有配置 Health Check，會出現怎樣的情況？

因爲新副本本身沒有異常退出，默認的 Health Check 機制會認爲容器已經就緒，進而會逐步用新副本替換現有副本，其結果就是：當所有舊副本都被替換後，整個應用將無法處理請求，無法對外提供服務。如果這是發生在重要的生產系統上，後果會非常嚴重。

如果正確配置了 Health Check，新副本只有通過了 Readiness 探測，纔會被添加到 Service；如果沒有通過探測，現有副本不會被全部替換，業務仍然正常進行。

下面通過例子來實踐 Health Check 在 Rolling Update 中的應用。

用如下配置文件 app.v1.yml 模擬一個 10 副本的應用：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10; touch /tmp/healthy; sleep 30000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

10 秒後副本能夠通過 Readiness 探測。

# kubectl get deployments. app
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
app    0/10    10           0           8s

# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-6dd7f876c4-575v5   1/1     Running   0          25s
app-6dd7f876c4-9kwk9   1/1     Running   0          25s
app-6dd7f876c4-bx4pf   1/1     Running   0          25s
app-6dd7f876c4-f6qf2   1/1     Running   0          25s
app-6dd7f876c4-fxp2m   1/1     Running   0          25s
app-6dd7f876c4-k76mr   1/1     Running   0          25s
app-6dd7f876c4-mfqsq   1/1     Running   0          25s
app-6dd7f876c4-whkc7   1/1     Running   0          25s
app-6dd7f876c4-x9q87   1/1     Running   0          25s
app-6dd7f876c4-xf8dv   1/1     Running   0          25s

接下來滾動更新應用，配置文件 app.v2.yml 如下：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

很顯然，由於新副本中不存在 /tmp/healthy，是無法通過 Readiness 探測的。驗證如下：

# kubectl apply -f app.yml --record 
deployment.apps/app configured
[root@k8s-master ~]# kubectl get deployments. app
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
app    8/10    5            8           80s

# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-6dd7f876c4-575v5   1/1     Running   0          2m3s
app-6dd7f876c4-9kwk9   1/1     Running   0          2m3s
app-6dd7f876c4-f6qf2   1/1     Running   0          2m3s
app-6dd7f876c4-fxp2m   1/1     Running   0          2m3s
app-6dd7f876c4-k76mr   1/1     Running   0          2m3s
app-6dd7f876c4-whkc7   1/1     Running   0          2m3s
app-6dd7f876c4-x9q87   1/1     Running   0          2m3s
app-6dd7f876c4-xf8dv   1/1     Running   0          2m3s
app-7d7559dd99-6w2kn   0/1     Running   0          49s
app-7d7559dd99-jnbxg   0/1     Running   0          49s
app-7d7559dd99-mxbwg   0/1     Running   0          49s
app-7d7559dd99-n59vq   0/1     Running   0          49s
app-7d7559dd99-t49cp   0/1     Running   0          49s

這個截圖包含了大量的信息，值得我們詳細分析。

先關注 kubectl get pod 輸出：

從 Pod 的 AGE 欄可判斷，最後 5 個 Pod 是新副本，目前處於 NOT READY 狀態。
舊副本從最初 10 個減少到 8 個。

再來看 kubectl get deployment app 的輸出：

DESIRED 10 表示期望的狀態是 10 個 READY 的副本。
CURRENT 13 表示當前副本的總數：即 8 箇舊副本 + 5 個新副本。
UP-TO-DATE 5 表示當前已經完成更新的副本數：即 5 個新副本。
AVAILABLE 8 表示當前處於 READY 狀態的副本數：即 8箇舊副本。

在我們的設定中，新副本始終都無法通過 Readiness 探測，所以這個狀態會一直保持下去。

上面我們模擬了一個滾動更新失敗的場景。不過幸運的是：Health Check 幫我們屏蔽了有缺陷的副本，同時保留了大部分舊副本，業務沒有因更新失敗受到影響。

接下來我們要回答：爲什麼新創建的副本數是 5 個，同時只銷毀了 2 箇舊副本？

原因是：滾動更新通過參數 maxSurge 和 maxUnavailable 來控制副本替換的數量。

maxSurge

此參數控制滾動更新過程中副本總數的超過 DESIRED 的上限。maxSurge 可以是具體的整數（比如 3），也可以是百分百，向上取整。maxSurge 默認值爲 25%。

在上面的例子中，DESIRED 爲 10，那麼副本總數的最大值爲：
roundUp(10 + 10 * 25%) = 13

所以我們看到 CURRENT 就是 13。

maxUnavailable

此參數控制滾動更新過程中，不可用的副本相佔 DESIRED 的最大比例。 maxUnavailable 可以是具體的整數（比如 3），也可以是百分百，向下取整。maxUnavailable 默認值爲 25%。

在上面的例子中，DESIRED 爲 10，那麼可用的副本數至少要爲：
10 - roundDown(10 * 25%) = 8

所以我們看到 AVAILABLE 就是 8。

maxSurge 值越大，初始創建的新副本數量就越多；maxUnavailable 值越大，初始銷燬的舊副本數量就越多。

理想情況下，我們這個案例滾動更新的過程應該是這樣的：

首先創建 3 個新副本使副本總數達到 13 個。
然後銷燬 2 箇舊副本使可用的副本數降到 8 個。
當這 2 箇舊副本成功銷燬後，可再創建 2 個新副本，使副本總數保持爲 13 個。
當新副本通過 Readiness 探測後，會使可用副本數增加，超過 8。
進而可以繼續銷燬更多的舊副本，使可用副本數回到 8。
舊副本的銷燬使副本總數低於 13，這樣就允許創建更多的新副本。
這個過程會持續進行，最終所有的舊副本都會被新副本替換，滾動更新完成。
而我們的實際情況是在第 4 步就卡住了，新副本無法通過 Readiness 探測。這個過程可以在 kubectl describe deployment app 的日誌部分查看。

Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  11m   deployment-controller  Scaled up replica set app-6dd7f876c4 to 10
  Normal  ScalingReplicaSet  10m   deployment-controller  Scaled up replica set app-7d7559dd99 to 3
  Normal  ScalingReplicaSet  10m   deployment-controller  Scaled down replica set app-6dd7f876c4 to 8
  Normal  ScalingReplicaSet  10m   deployment-controller  Scaled up replica set app-7d7559dd99 to 5

如果滾動更新失敗，可以通過 kubectl rollout undo 回滾到上一個版本。

# kubectl rollout history deployment app
deployment.extensions/app 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=app.yml --record=true
2         kubectl apply --filename=app.yml --record=true

# kubectl get deployments. app
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
app    8/10    5            8           14m

 kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-6dd7f876c4-575v5   1/1     Running   0          14m
app-6dd7f876c4-9kwk9   1/1     Running   0          14m
app-6dd7f876c4-f6qf2   1/1     Running   0          14m
app-6dd7f876c4-fxp2m   1/1     Running   0          14m
app-6dd7f876c4-k76mr   1/1     Running   0          14m
app-6dd7f876c4-whkc7   1/1     Running   0          14m
app-6dd7f876c4-x9q87   1/1     Running   0          14m
app-6dd7f876c4-xf8dv   1/1     Running   0          14m
app-7d7559dd99-6w2kn   0/1     Running   0          13m
app-7d7559dd99-jnbxg   0/1     Running   0          13m
app-7d7559dd99-mxbwg   0/1     Running   0          13m
app-7d7559dd99-n59vq   0/1     Running   0          13m
app-7d7559dd99-t49cp   0/1     Running   0          13m

如果要定製 maxSurge 和 maxUnavailable，可以如下配置：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    rollingUpdate:
      maxSurge: 35%
      maxUnavailable: 35%
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

小結
本章討論了 Kubernetes 健康檢查的兩種機制：Liveness 探測和 Readiness 探測，並實踐了健康檢查在 Scale Up 和 Rolling Update 場景中的應用。

k8s之健康檢查(Health Check)

默認的健康檢查

Liveness 探測

Readiness 探測

在 Scale Up 中使用 Health Check

在 Rolling Update 中使用 Health Check

maxSurge

maxUnavailable

chrom快捷鍵

VSCode 快捷鍵 Mac

mysql命令行客戶端神器mycli安裝

VScode快捷鍵

sublime text3的快捷鍵

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結