Kubernetes 最佳實踐：正常終止

談到分散式系統，故障處理是關鍵。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 鉤子是向 pod 中的容器發送的特殊命令或 http 請求。

如果您的應用程序在收到 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，確保您的應用程序正常執行這些終止操作是創建穩定系統和提供良好用戶體驗的核心。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！