談到分散式系統，故障處理是關鍵。Kubernetes 利用控制器來監控系統狀態並重新啟動已停止執行的服務，可有效解決這個問題。另一方面，Kubernetes 通常可以在系統正常執行過程中強制終止應用程式。

本期的“Kubernetes 最佳實踐”系列視訊中，我們來看看如何幫助 Kubernetes 更高效地完成工作並減少應用程式的停機時間。

在預裝容器領域，大多數應用程式都在虛擬機器或物理機上執行。如果某個應用程式崩潰，啟動替代程式需要很長時間。如果您只有一兩臺機器執行應用程式，這種恢復時間是不可接受的。

相比之下，較為常見的做法是通過程序級別的監控來重新啟動崩潰的應用程式。如果應用程式崩潰，監控程序可以捕獲退出程式碼並立即重新啟動應用程式。

隨著 Kubernetes 等系統的出現，已不再需要程序監控系統，因為 Kubernetes 自己會重新啟動崩潰的應用程式。Kubernetes 使用事件迴圈來確保容器和節點等資源的健康狀況。這意味著您不用再手動執行這些監控程序。如果某個資源未通過執行狀況檢查，Kubernetes 會自動啟動替代資源。

Kubernetes 終止生命週期

Kubernetes 不僅僅可以監控應用程式崩潰，它還可以建立更多的應用程式副本以在多臺機器上執行，更新應用程式，甚至同時執行多個版本的應用程式！

這意味著 Kubernetes 可以出於多種原因終止一個完全健康的容器。如果您通過滾動更新來更新部署，Kubernetes 會慢慢終止舊的 pod，同時加速生成新的 pod。如果您排空節點，Kubernetes 會終止該節點上的所有 pod。如果某個節點的資源耗盡，Kubernetes 會終止 pod 以釋放這些資源（

為了最大程度減小對終端使用者的影響，並儘可能縮短恢復時間，應用程式能夠正常終止十分重要。

實際上，這意味著您的應用程式需要處理 SIGTERM 訊息，並在收到此類訊息後開始關閉。這意味著要儲存所有需要儲存的資料、關閉網路連線、完成剩下的工作以及其他類似任務。

一旦 Kubernetes 決定終止 pod，將發生一系列事件。我們來看看 Kubernetes 終止生命週期的各個步驟。

1 – 將 pod 設定為“正在終止”狀態，並將其從所有服務的端點列表中移除

此時，pod 停止獲取新流量，Pod 中執行的容器不受影響。

2 – 執行 preStop 鉤子

preStop 鉤子

如果您的應用程式在收到 SIGTERM 後未正常關閉，可使用此鉤子觸發正常關閉。大多數程式在收到 SIGTERM 後都會正常關閉，但如果您使用的是第三方程式碼或管理的系統不受您控制，preStop 鉤子將是一個不錯的方案，可幫您在不修改應用程式的情況下觸發正常關閉。

3 – 向 pod 傳送 SIGTERM 訊號

此時，Kubernetes 將向 pod 中的容器傳送 SIGTERM 訊號。此訊號通知容器它們即將被關閉。

您的程式碼應偵聽此事件，並在此時開始“乾淨地”關閉。這可能包括停止所有長時間連線（如資料庫連線或 WebSocket 流）、儲存當前狀態或類似任務。

即使您現在已經在使用 preStop 鉤子，也有必要測試一下應用程式在您向它傳送 SIGTERM 訊號後的反應，以免在實際使用時對實際情況感到驚訝！

4 – Kubernetes 等待片刻（寬限期）

此時，Kubernetes 將等待片刻，此時間稱為終止寬限期，具體值可指定。預設值為 30 秒。需要注意的是，這與 preStop 鉤子和 SIGTERM 訊號並行發生。Kubernetes 不會等待 preStop 鉤子完成。

如果您的應用在 terminationGracePeriod 完成之前完成關閉並退出，Kubernetes 將立即轉到下一步。

如果您的 pod 通常需要 30 秒以上的時間才能關閉，請務必延長寬限期。您可以通過在 Pod YAML 中設定 terminationGracePeriodSeconds 選項來實現此目的。例如，可將該值改為 60 秒：

5 – 向 pod 傳送 SIGKILL 訊號，pod 隨即被移除

如果寬限期結束後容器仍在執行，將向容器傳送 SIGKILL 訊號並強制將它們移除。此時，所有 Kubernetes 物件將被一同清理。

結論

Kubernetes 可以出於各種原因終止 pod，確保您的應用程式正常執行這些終止操作是建立穩定系統和提供良好使用者體驗的核心。