前言

由於現在 Pod 的數量越來越多了，因此如何控管好每個 Pod 可說是非常重要的動作，在開始細部介紹 K8s 是如何確保 Pod 是可以正常運行之前，首先要來做個事情準備，而這個就是 Pod 的 Health Check。

什麼是 Health Check？

Health Check 顧名思義就是健康檢查，通常我們做健康檢查的時候，醫生都會問我們各個部位有沒有哪邊不舒服，如果都正常就代表我們其實沒有生病， Pod 也是一樣的道理，只要定時地透過訪問某個路徑來確保真的有回傳資料就可以確保此 Pod 真的是處於正常的健康狀態。

如何進行 Health Check？

一般來說 Health Check 有兩種做法。

• 定期的透過指令去訪問 container

  這種方式就不需借助 K8s，直接在 Dockerfile 內加上指令就可以，方法有非常多種，只要確保 container 可以正常回應需求即可，筆者通常都會利用 tail 輸出 container 的記錄檔，以確保 container 是真的有在運行。

• 定期發送一個 HTTP request 給 container

  這個就必須要透過 K8s 的幫忙了，在 K8s 中一共有兩種方式進行，這兩種方式的使用場景也不太一樣，所以讀者未來要設定 Health Check 的時候也可以自行評估看看要使用哪種方式進行。

K8s Health Check

上面提到 K8s 的 Health Check 就是透過定時發送一個 HTTP request 到 container 中，這邊就來介紹一下 K8s 是如何做到的。

• livenessProbe(存活探針)

  用於判斷 Pod 是否為 Running 狀態，如果 livenessProbe 探測到容器不健康，則該 Pod 將被砍掉並重啟，如果該 Pod 不包含 livenessProbe，則 K8s 會認為該 Pod 的 livenessProbe 返回值永遠成功。

• readinessProbe(就續探針)

  用於判斷 Pod 是否啟動完成可以接收請求，如果 readinessProbe 失敗，則會將此 Pod 從對應的 service 的連線列表中移除，從此不再將任何請求調度此Pod上，直到下次探測成功。

Health Check 寫法

由於 Health Check 是透過定時發送一個 HTTP request 到 container 中，所以這邊一樣沿用之前寫好的 Deployment，並把 Health Check 加進去，也因為 livenessProbe 以及 readinessProbe 兩者寫法幾乎一樣，所以這邊筆者只會挑其中一種來做示範。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    minReadySeconds: 60
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: helloworld
          image: w5151381guy/helloworld
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 200m
              memory: 500Mi
            limits:
              cpu: 500m
              memory: 800Mi
          livenessProbe:
            httpGet:
              path: /
              scheme: HTTP
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 60
            successThreshold: 2
            failureThreshold: 5

接下來要使用的是 livenessProbe，因此會在 container 內加上 livenessProbe 的設定，接下來就是細部設定要訪問的 container 路徑，在訪問的過程都是用 GET 這個 HTTP method，所以才會加上 httpGet。

接下來就講講訪問路徑的詳細設定吧！

• path

  設定 Health Check 要造訪的路徑，通常要進行 Health Check 時都會有一個獨立的路徑叫 /healthz ，但因為筆者並沒有多設定這個路徑要做的事情所以就直接打根路徑了。

• scheme

  設定要造訪的 scheme，預設為 HTTP 也可設定為 HTTPS。

• port

  設定要造訪的 port，這邊通常都會跟 container 走一樣的 port。

講完訪問路徑之後，接下來要講 Health Check 每次訪問時的設定了。

• initialDelaySeconds

  設定 Pod 剛啟動時要間隔多久再啟動 Health Check。

• periodSeconds

  每多久訪問一次，預設為 10 秒。

• successThreshold

  設定訪問幾次而且都成功就代表 Pod 成功運行，預設為 1 次。

• failureThreshold

  代表 Pod 回傳不如預期時，會再重新嘗試的次數，預設為 3 次。

有 Health Check 的 Pod

可以發現在 container 的詳細資料中多了一個 Liveness，也可以看到這個 Liveness 主要是在做什麼事情。

無 Health Check 的 Pod

沒有 Health Check 的 Pod 其 container 也不會有 Liveness，所以根據 livenessProbe 的預設值這裡永遠都會回傳探測成功。

小結

今天介紹了 K8s 的 Health Check，未來讀者要建立 Pod 的時候要記得把 Health Check 的設定一併加進去，這樣也會方便控管 Pod 整體運作。

接下來就要介紹 K8s 內部是如何溝通以及 Pod 是如何被刪除的，如果有任何問題都歡迎在下面留言給我，那我們就下一篇文章見嘍～