k8s 之微服務的優雅退出

#前言

前面有文章簡單介紹過 k8s 優雅退出的內容今天再來補充一下微服務在 k8s 中不同情況下需要處理的情況

基於 k8s service 服務發現

如果我們的服務是基於 k8s 的 service 實現服務發現那麼我們的服務是可以不去處理優雅退出的

流程如下圖

可看出我們的 service 會在 Deploy 的生命週期中自動更新對應的 endpoints 列表以此保證我們上游服務通過 service 訪問服務時總能過濾掉 term 中的服務
所以這種情況我們就可以不用刻意去做服務的優雅退出直接通過默認的優雅退出機制即可

# 基於註冊中心的服務發現

如果我們的服務是通過傳統的註冊中心實現 (類似 SpringCloud 體系)
這種架構會有如下幾個特點
1. 每個下游服務都會註冊到 discovery
2. 每個上游服務都通過 discovery 獲取下游服務的地址
3. discovery 會提供註冊 (register), 心跳 (renew), 下線 (cancel)
(服務註冊之後會週期發送心跳否則 discovery 會自動下線掉服務)

假設我們的下游服務不去做優雅退出 (處理 sigterm 信號) 而是依賴 k8s 默認的優雅退出 (30 秒的 sigkill)

那麼上游服務在下游服務 term 階段還是能在 discovery 中訪問到下游服務那麼就可能出現問題

如下圖

所以我們就必須在我們的應用中處理好 k8s 的 sigterm 信號及時將 terminating 狀態的 pod 從 discovery 中下線

如下以 go 代碼示例

c := make(chan os.Signal, 1)
signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT, syscall.SIGTERM)
//監聽
for {
    s := <-c
    switch s {
        case syscall.SIGQUIT, syscall.SIGTERM, syscall.SIGINT:
            // 監聽退出信號 將服務從discovery下線
            discovery.cancel()
            return
    }
}

流程如下圖

後記

如上就是我們在 k8s 中使用微服務時需要關注的優雅退出內容希望對你有幫助

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Hch8IqRTAsZSqkykkLwZCA

基於 k8s service 服務發現

後記

猜你喜歡