Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

Kubernetes 最佳實務。 建立小容器
Kubernetes 最佳實務。 Kubernetes 的命名空間組織

Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

分散式系統可能難以管理,因為它們有許多移動、變化的元素,所有這些元素都需要正常運作才能使系統正常運作。 如果其中一個元素出現故障,系統必須偵測它、繞過它並修復它,而所有這一切都必須自動完成。 在這個 Kubernetes 最佳實踐系列中,我們將學習如何設定就緒性和活躍性測試來測試 Kubernetes 叢集的運作狀況。

健康檢查是一種讓系統知道您的應用程式實例是否正在運行的簡單方法。 如果您的應用程式實例已關閉,則其他服務不應存取它或向其發送請求。 相反,必須將請求發送到已運行或稍後將啟動的應用程式的另一個實例。 此外,系統應該恢復應用程式遺失的功能。

預設情況下,當 Pod 中的所有容器都運作時,Kubernetes 將開始向 Pod 發送流量,並在容器崩潰時重新啟動容器。 這種預設的系統行為一開始可能就足夠好了,但您可以透過使用自訂健全性檢查來提高產品部署的可靠性。

Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

幸運的是,Kubernetes 讓這變得非常容易,因此沒有理由忽略這些檢查。 Kubernetes 提供兩種類型的運作狀況檢查,了解每種類型的使用方式的差異非常重要。

就緒測試旨在告訴 Kubernetes 您的應用程式已準備好處理流量。 在允許服務向 Pod 發送流量之前,Kubernetes 必須驗證就緒檢查是否成功。 如果Readiness測試失敗,Kubernetes將停止向Pod發送流量,直到測試通過。

活性測試告訴 Kubernetes 您的應用程式是存活還是死亡。 在第一種情況下,Kubernetes 將不理會它,在第二種情況下,它將刪除失效的 pod 並用新的 pod 替換。

讓我們想像一個場景,您的應用程式需要 1 分鐘來預熱和啟動。 儘管工作流程已經啟動,但直到應用程式完全載入並運行後,您的服務才會開始運作。 如果您想要將此部署擴展到多個副本,您也會遇到問題,因為這些副本在完全準備好之前不應接收流量。 但是,預設情況下,一旦容器內的進程啟動,Kubernetes 就會開始傳送流量。

使用就緒測試時,Kubernetes 將等到應用程式完全運行後再允許服務將流量傳送到新副本。

Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

讓我們想像另一個場景,其中應用程式長時間掛起,停止服務請求。 隨著進程繼續運行,預設情況下 Kubernetes 會假設一切正常,並繼續向不工作的 pod 發送請求。 但是當使用 Liveness 時,Kubernetes 會偵測到應用程式不再服務請求,並預設重新啟動失效的 Pod。

Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

讓我們看看如何測試就緒性和可行性。 共有三種測試方法:HTTP、Command 和 TCP。 您可以使用其中任何一個來檢查。 測試使用者最常見的方法是 HTTP 探針。

即使您的應用程式不是 HTTP 伺服器,您仍然可以在應用程式內建立一個輕量級 HTTP 伺服器來與 Liveness 測試互動。 之後,Kubernetes 將開始 ping pod,如果 HTTP 回應在 200 或 300 毫秒範圍內,則表示 pod 運作狀況良好。 否則,該模組將被標記為“不健康”。

Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

對於命令測試,Kubernetes 在容器內執行命令。 如果命令返回的退出代碼為零,則容器將被標記為健康,否則,在收到從 1 到 255 的退出狀態號碼時,容器將被標記為「生病」。 如果您不能或不想運行 HTTP 伺服器,但能夠執行檢查應用程式運行狀況的命令,則此測試方法非常有用。

Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

最終的驗證機制是TCP測試。 Kubernetes 將嘗試在指定連接埠上建立 TCP 連線。 如果可以做到這一點,則該容器被認為是健康的;如果不能,則被認為是不可行的。 如果您使用的場景中 HTTP 請求或命令執行測試效果不佳,則此方法可能很有用。 例如,使用 TCP 進行驗證的主要服務是 gRPC 或 FTP。

Kubernetes 最佳實務。 透過就緒性和活躍性測試驗證 Kubernetes 活躍性

可以使用不同的參數以多種方式配置測試。 您可以指定執行頻率、成功和失敗閾值以及等待回應的時間。 有關更多信息,請參閱就緒性和活性測試的文檔。 不過,設定Liveness測試有一個非常重要的點——測試延遲initialDelaySeconds的初始設定。 正如我所提到的,此測試失敗將導致模組重新啟動。 因此,您需要確保在應用程式準備好之前不會開始測試,否則它將開始循環重新啟動。 我建議使用 P99 啟動時間或緩衝區中的平均應用程式啟動時間。 請記住,當應用程式的啟動時間變快或變慢時,請調整此值。

大多數專家都會確認,健康檢查是任何分散式系統的強制性檢查,Kubernetes 也不例外。 使用服務健康檢查可確保 Kubernetes 可靠、無故障運行,並且對使用者而言毫不費力。

很快就會繼續......

一些廣告🙂

感謝您與我們在一起。 你喜歡我們的文章嗎? 想看更多有趣的內容? 通過下訂單或推薦給朋友來支持我們, 面向開發人員的雲 VPS,4.99 美元起, 我們為您發明的入門級服務器的獨特模擬: VPS (KVM) E5-2697 v3(6 核)10​​4GB DDR480 1GB SSD 19Gbps XNUMX 美元或如何共享服務器的全部真相? (適用於 RAID1 和 RAID10,最多 24 個內核和最多 40GB DDR4)。

Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍? 只有這裡 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 電視低至 199 美元 在荷蘭! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起! 閱讀 如何建設基礎設施公司同級使用價值730歐元的Dell R5xd E2650-4 v9000服務器一分錢?

來源: www.habr.com

添加評論