前面的文章介紹了 Service 與 Ingress，讓外部或叢集內的請求可以連線到 Pod。

但是 Pod 處於 Running 狀態，不一定代表裡面的應用程式真的可以正常提供服務。例如程式可能發生錯誤、卡住，或是應用程式還在啟動中。

這時就可以透過 Probe（探針） 檢查容器內的應用程式狀態。

Probe 主要可以分成三種：

• Liveness Probe
• Readiness Probe
• Startup Probe

Liveness Probe

Liveness Probe 用來檢查容器內的應用程式是否還能正常運作。

當 Liveness Probe 連續檢查失敗並達到設定的次數後，Kubernetes 會將容器重新啟動。

簡單來說：

Liveness Probe：程式還活著嗎？如果真的壞掉了就重新啟動。

例如可以透過 HTTP 請求檢查 nginx 是否正常：

apiVersion: v1
kind: Pod
metadata:
  name: probe-demo
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80

      livenessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 10

這裡使用 httpGet 對容器的 / 發送 HTTP 請求。

initialDelaySeconds: 5 代表容器啟動後等待 5 秒才開始進行檢查。

periodSeconds: 10 則代表每 10 秒進行一次檢查。

如果 HTTP 檢查持續失敗，達到失敗次數的條件後，Kubernetes 就會重新啟動容器。

Readiness Probe

Readiness Probe 用來判斷容器目前是否已經準備好接收流量。

有些應用程式雖然已經啟動，但可能還需要載入設定、連接資料庫或進行其他初始化工作。

這時如果馬上將請求送進 Pod，就可能發生錯誤。

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10

當 Readiness Probe 檢查失敗時，Kubernetes 不會因為這個 Probe 直接重新啟動容器，而是將 Pod 標記為尚未 Ready，使 Service 暫時不將一般流量送到這個 Pod。

等到 Readiness Probe 再次檢查成功後，Pod 就可以重新接收流量。

所以可以簡單理解成：

Readiness Probe：現在準備好接收流量了嗎？

Startup Probe

有些應用程式啟動時間比較長，如果太早執行 Liveness Probe，可能會把「還在啟動」的程式誤認為發生故障。

這時就可以使用 Startup Probe。

startupProbe:
  httpGet:
    path: /
    port: 80
  periodSeconds: 5
  failureThreshold: 30

設定 Startup Probe 後，在 Startup Probe 成功以前，Liveness Probe 與 Readiness Probe 不會開始執行。

以上面的設定為例：

5 秒 × 30 次 = 最多 150 秒

代表應用程式最多可以有約 150 秒的時間完成啟動。

如果 Startup Probe 成功，就代表應用程式已經完成啟動，接著才會開始執行其他 Probe。

可以簡單理解成：

Startup Probe：程式啟動完成了嗎？

三種 Probe 的差異

三種 Probe 雖然都是用來檢查應用程式，但是目的並不相同。

Probe 的檢查方式

Probe 不只有前面使用的 HTTP 檢查方式，Kubernetes 還提供其他不同的檢查方式，例如：

• httpGet：發送 HTTP 請求進行檢查。
• tcpSocket：嘗試連線到指定 TCP Port。
• exec：在容器內執行指定指令，依照指令執行結果判斷是否成功。
• grpc：透過 gRPC Health Checking Protocol 進行檢查。

實際使用哪一種方式，可以依照應用程式提供的服務與檢查方式決定。

Probe 可以讓 Kubernetes 不只是知道「容器有沒有啟動」，還能進一步判斷應用程式目前是否真的可以正常工作，並根據不同 Probe 的結果決定是否重新啟動容器或停止將流量送到 Pod。