設定探查和負載平衡器運作狀態檢查

除了負載平衡器運作狀態檢查之外，Kubernetes 還提供數種執行應用程式運作狀態檢查的方式。您可以執行下列 Kubernetes 內建探查與負載平衡器運作狀態檢查，做為 Pod 內容中的命令，或做為 kubelet 或主機 IP 地址的 HTTP/TCP 探查。

活體探查和整備探查應不同且獨立 （或至少具有不同的逾時值）。如果應用程式發生暫時問題，整備探查會將 Pod 標記為未就緒，直到問題解決為止。如果活體探查設定不正確，活體探查可能會終止 Pod。

啟動探查

使用啟動探查來保護初始化週期較長的應用程式。在啟動探查成功之前，其他探查都會停用。

您可以定義 Kubernetes 應等待應用程式啟動的時間上限。如果在設定的時間上限之後，Pod 仍然失敗啟動探查，應用程式會終止，並建立新的 Pod。

當應用程式的啟動時間無法預測時，請使用啟動探查。如果您知道您的應用程式需要 10 秒才能啟動，請initialDelaySeconds改用活體探查或整備探查。

活體探查

使用即時性探查來偵測應用程式問題，或程序是否在沒有問題的情況下執行。活體探查可以偵測程序繼續執行但應用程式變得沒有回應的死結條件。使用活體探查時，請執行下列動作：

• 使用 initialDelaySeconds 延遲第一個探查。

• 請勿為即時性和整備性探查設定相同的規格。

• 請勿將活體探查設定為取決於 Pod 外部的因素 （例如資料庫）。

• 設定特定 的活體探查terminationGracePeriodSeconds。如需詳細資訊，請參閱 Kubernetes 文件。

準備度探查

使用整備探查來偵測下列項目：

• 應用程式是否已準備好接受流量

• 部分可用性，其中應用程式可能暫時無法使用，但預期在特定操作完成後會再次正常運作

準備度探查有助於確保應用程式組態和相依性在執行時沒有問題或錯誤，以便應用程式可以為流量提供服務。不過，設定不佳的準備度探查可能會導致中斷，而不是防止中斷。以外部因素為基礎的準備度探查，例如與資料庫的連線，都可能導致所有 Pod 失敗探查。此類故障可能會導致中斷，而且可能會導致從後端服務到使用故障 Pod 的其他 服務發生串聯故障。

傳入資源和負載平衡器運作狀態檢查

Application Load Balancer 和 Kubernetes ingress提供運作狀態檢查功能。針對 Application Load Balancer 運作狀態檢查，指定目標連接埠和路徑。

注意： 對於 Kubernetes ingress，將會有取消註冊延遲。Application Load Balancer 的預設值為 300 秒。請考慮使用您用於整備探查的相同值來設定輸入資源或負載平衡器運作狀態檢查。 

NGINX 也提供運作狀態檢查。如需詳細資訊，請參閱 NGINX 文件。

Istio 輸入和輸出閘道沒有與 NGINX 的 HTTP 運作狀態檢查相當的運作狀態檢查機制。不過，您可以使用 Istio 斷路器或DestinationRule極端值偵測來實現類似的功能。

如需詳細資訊，請參閱 EKS 最佳實務 – 負載平衡 （可用性和 Pod 生命週期）。