Kubernetes Pod Hook

在生産環境中使用spring架構，由于服務更新過程中，容器服務被直接停止，部分請求仍被分發到終止的容器(沒有配置鈎子，熟悉預設環境)，導緻服務出現500錯誤，這部分錯誤請求資料占用比較少，因為Pod滾動更新都是一對一。因為部分使用者會産生伺服器錯誤的情況，考慮使用優雅的終止方式，将錯誤請求降到最低，直至滾動更新不影響使用者

首先我們先簡單的分析一下"優雅的停止Pod"

優雅停止(Graceful shutdown)這個說法來自于作業系統，比如我們windows關機系統首先會退出軟體然後一步步到達關機，而相對的就是硬終止(Hard shutdown)，簡單的了解就是直接拔電源

到了微服務中，網關會把流量配置設定給每個Pod節點上，比如我們上線更新Pod的時候

如果我們直接将Pod殺死，那這部分流量就無法得到正确處理，會影響部分使用者，通常來說網關或者注冊中心會将我們的服務保持一個心跳，過了心跳逾時之後會自動摘除我們的服務，但是有一個問題就是逾時時間可能是30秒也可能是60秒，雖然不會影響我們的系統，但是會産生使用者輕微抖動。

如果我們在停止前執行一條指令，通知網關或者注冊中心這台主機進行下線，那麼注冊中心就會标記這台主機已經下線，不進行流量轉發，使用者就不會有任何影響，這就是優雅停止，将滾動更新影響最小化

Pod Hook

Pod Hook是由kubelet發起的，當容器中的程序啟動前或者容器中的程序終止之前運作，這是包含在容器的生命周期之中。我們可以同時為Pod中的所有容器都配置hook

在k8s中，理想的狀态是pod優雅釋放，并産生新的Pod。但是并不是每一個Pod都會這麼順利

Pod卡死，處理不了優雅退出的指令或者操作

優雅退出的邏輯有BUG，陷入死循環

代碼問題，導緻執行的指令沒有效果

對于以上問題，k8s的Pod終止流程中還有一個"最多可以容忍的時間"，即grace period (在pod的.spec.terminationGracePeriodSeconds字段定義)，這個值預設是30秒，當我們執行kubectl delete的時候也可以通過--grace-period參數顯示指定一個優雅退出時間來覆寫Pod中的配置，如果我們配置的grace period超過時間之後，k8s就隻能選擇強制kill Pod

Kubernetes等待指定的時間稱為優雅終止寬限期。預設情況下，這是30秒。值得注意的是，這與preStop Hook和SIGTERM信号并行發生。Kubernetes不會等待preStop Hook完成。如果你的應用程式完成關閉并在terminationGracePeriod完成之前退出，Kubernetes會立即進入下一步。

如果您的Pod通常需要超過30秒才能關閉，請確定增加優雅終止寬限期(通過terminationGracePeriodSeconds來實作)

Kubernetes為我們提供了兩種鈎子函數:

PostStart :這個鈎子在容器建立後立即執行。但是，并不能保證鈎子将在容器ENTRYPOINT之前運作，因為沒有參數傳遞給處理程式。 主要用于資源部署、環境準備等。不過需要注意的是如果鈎子花費時間過長以及于不能運作或者挂起，容器将不能達到Running狀态。

PreStop :鈎子在容器終止前立即被調用。它是阻塞的，意味着它是同步的，是以它必須在删除容器的調用出發之前完成。主要用于優雅關閉應用程式、通知其他系統等。如果鈎子在執行期間挂起，Pod階段将停留在Running狀态并且不會達到failed狀态

如果PostStart或者PreStop鈎子失敗，它會殺死容器。是以我們應該讓鈎子函數盡可能的輕量。當然有些情況下，長時間運作指令是合理的，比如在停止容器之前預先保留狀态。

這裡稍微簡單說一下Pod終止的過程

使用者發送指令删除Pod，Pod進入Terminating狀态

service摘除Pod節點

當kubelet看到Pod已被标記終止，開始執行preStop鈎子，假如preStop hook的運作時間超過了grace period，kubelet會發送SIGTERM并等2秒

官方文檔介紹

在Pod Hook鈎子函數中有Exec和HTTP兩種方式

Exec - 用于執行一段特定的指令，不過要注意的是該指令小号的資源會被計入容器

建立容器後，Kubernetes立即發送postStart事件。但是，不能保證在調用Container的入口點之前先調用postStart處理程式。postStart處理程式相對于Container的代碼異步運作，但是Kubernetes對容器的管理會阻塞，直到postStart處理程式完成。在postStart處理程式完成之前，容器的狀态不會設定為RUNNING。

HTTP - 對容器上的特定端點執行HTTP請求

總結： Hook調用的日志沒有暴露給Pod的Event，是以隻能到通過describe指令來擷取，如果是正常的操作是不會有event，如果有錯誤可以看到FailedPostStartHook和FailedPreStopHook這種event。并且如果Hook調用出現錯誤，則Pod狀态不會是Running

簡單的說Kubernetes終止生命周期的每一步

Pod 設定為Terminating狀态，并從所有服務的Endpoints清單中删除

此時，Pod停止停止，但是Pod中運作的容器不受影響

PreStop Hook被執行

preStop Hook發送容器特殊指令或者Http請求到Pod中，Pod應用程式在接收到SIGTERM(該SIGTERM信号是用于導緻程式終止的通用信号。不同于SIGKILL，該信号可以被阻止，處理和忽略。這是禮貌地要求程式終止的正常方法)，如果使用第三方代碼或者管理系統無法控制，則preStop Hook是在不修改應用程式的情況下觸發

SIGTERM信号發送給Pod

此時，Kubernetes将向Pod中的容器發送SIGTERM信号，這個信号即通知容器他們很快将進行關閉。

Kubernetes等待優雅的終止

此時，Kubernetes等待指定的時間稱為優雅終止寬限期。預設情況下，這是30秒(可以修改)，值得注意的是，PreStop Hook和SIGTREM資訊是屬于并行執行，Kubernetes不會等待PreStop Hook完成。

如果Pod在terminationGracePeriod完成之前推出，Kubernetes将進如釋放階段，如果容器在優雅終止寬限期(terminationGracePeriod限定時間)，則會發送SIGKILL信号并強制删除。與此同時，所有的Kubernetes對象也會被清除