歡迎光臨
每天分享高質量文章

Kubernetes健康檢查如何做?官方推薦教程

編者語:這是 Google 開發者佈道師 Sandeep Dinesh[1]的視頻[2]和博客系列 “如何充分利用 Kubernetes 環境” 的第三部分。


分佈式系統管理比較困難。很重要的原因是系統正常工作依賴很多不同的組件。任何一個組件出了問題,系統必須要能發現出問題的組件,繞開並且修複它,所有的這些都要自動完成。

健康檢查是發現你的應用實體是否正常工作的簡單方式。如果應用的某個實體不能工作,其他的服務不應該訪問或者請求該實體。請求應該發送給應用的其他正常實體,過一段時間再嘗試異常實體。系統應該保證應用處於正常狀態。

預設情況下,Kubernetes 在容器內的 Pod 啟動後開始向 Pod 發送流量,併在容器崩潰時重新啟動容器。雖然這已經“足夠好”,然而你可以通過自定義的健康檢查讓部署過程更加完美。Kubernetes 非常容易實現自定義健康檢查,所以沒有理由不去用它。

我們詳細介紹一下如何在 Kubernetes 集群中選擇和設置 Readiness 和 Liveness 探針[3]。

健康檢查型別

Kubernetes 提供了2種健康檢查的方式。下麵我們來瞭解一下這兩種健康檢查的區別和使用。

READINESS

設計 Readiness 探針的目的是用來讓 Kubernetes 知道你的應用何時能對外提供服務。在服務發送流量到 Pod 之前,Kubernetes必須確保 Readinetes 探針檢測成功。如果 Readiness 探針檢測失敗了,Kubernetes 會停掉 Pod 的流量,直到 Readiness 檢測成功。

LIVENESS

Liveness 探針能讓 Kubernetes 知道你的應用是否存活。如果你的應用是存活的,Kubernetes 不做任何處理。如果是掛掉的,Kubernetes 會移除異常的 Pod,並且啟一個新的 Pod 替換它。

健康檢查的作用

我們來看兩種場景下,如何使用Readiness 和 Liveness 探針幫助你構建更健壯的應用。

READINESS

假設你的應用需要時間進行預熱和啟動。即便行程已經啟動,你的服務依然是不可用的,直到它真的運行起來。如果想讓你的應用橫向部署多實體,這也可能會導致一些問題。因為新的複本在沒有完全準備好之前,不應該接收請求。但是預設情況下,只要容器內的行程啟動完成,Kubernetes 就會開始發送流量過來。如果使用 Readiness 探針, Kubernetes 就會一直等待,直到應用完全啟動,才會允許發送流量到新的複本。


LIVENESS

我們設想另外一種場景,你的應用產生了死鎖,導致行程一直夯住,並且停止處理請求。因為行程還處在活躍狀態,預設情況下, Kubernetes 認為一切正常,會繼續向異常Pod 發送流量。通過使用 Liveness 探針, Kubernetes 會發現應用不再處理請求,然後重啟異常的 Pod 。

探針型別

接下來就是如何定義 Liveness 和 Readiness 探針了。有3種型別的探針實現方式可以選擇,分別是:HTTP、Command、TCP。你可以使用任何一種方式實現 Liveness 和 Readiness 探針。

HTTP

HTTP 可能是 Liveness 探針的最常用的實現方式。即便你的應用不是一個 HTTP 服務,你也可以通過在應用內部集成一個輕量級的HTTP 服務,以支持 Liveness 探針。Kubernetes 通過 ping 一個路徑,如果 HTTP 響應的狀態碼是 2xx 或者 3xx ,說明該應用是健康狀態,否則就是不健康狀態。
更多 HTTP探針信息[4]

COMMAND

對於命令列探針,kubernetes 在容器內運行命令,如果傳回0,說明服務是健康狀態,否則就是不健康狀態。當你不能或者不想提供額外的 HTTP 服務,但是能使用命令列的時候,通過命令列來進行健康檢查很有用的。
更多 Command探針信息[5]

TCP

最後一種是 TCP 探針。Kubernetes 嘗試跟某個端口建立一個 TCP 連接。如果能建立連接,表示容器是健康狀態,否則是不健康狀態。
假如 HTTP 和命令列都不能使用的情況下, TCP 的方式就派上用場了。例如 gRPC[6]或者 FTP 服務中,TCP 型別就是首選。

更多 TCP探針信息[7]

配置探針啟動的延遲

探針有多種配置。你能指定探針多久執行一次、成功和失敗的閾值、多長時間的響應等待等等。 探針配置文件[8]非常清楚的介紹了這些不同的配置的作用。
當你使用 Liveness 探針的時候,initialDelaySeconds 是你需要設置的非常重要的配置。

如前面說的,Liveness 探針檢查失敗會導致 Pod 重啟。你必須確保 Liveness 探針在應用準備好之後生效。否則,應用會一直不停被重啟。

我推薦使用 p99[9]作為 initialDelaySeconds 的生效時間,或者簡單的使用平均啟動時間加一個緩衝時間。如果應用的啟動時間變長或者變短了,確保更新了這個配置。

總結

很多人都會告訴你,分佈式系統必須有健康檢查,Kubernetes 也不例外。Kubernetes 提供了非常方便的健康檢查,為你Kubernetes 中的服務提供更穩定的、更可靠的、更高的正常運行時間。

本文作者Sandeep Dinesh,由鄧啟明翻譯。轉載譯文請註明出處,技術原創及架構實踐文章,歡迎通過公眾號選單「聯繫我們」進行投稿。


參考鏈接

[1] https://twitter.com/sandeepdinesh?lang=en

[2] https://www.youtube.com/playlist?list=PLIivdWyY5sqL3xfXz5xJvwzFW_tlQB_GB

[3] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

[4] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request

[5] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command

[6] https://grpc.io/

[7] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-tcp-liveness-probe

[8] https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes

[9] https://www.quora.com/What-is-p99-latency


相關閱讀:


Kubernetes大集群怎麼管?基於監控的彈性伸縮方法

從美圖容器優化實踐談Kubernetes網絡方案設計

管理數萬個實體,服務上百個業務:kubernetes在騰訊游戲的使用及演進歷程

活動預告:

6 月 1 ~ 2 日,GIAC 全球互聯網架構大會將於深圳舉行。GIAC 是高可用架構技術社區推出的面向架構師、技術負責人及高端技術從業人員的技術架構大會。今年的 GIAC 已經有騰訊、阿裡巴巴、百度、今日頭條、科大訊飛、新浪微博、小米、美圖、Oracle、鏈家、唯品會、京東、餓了麽、美團點評、羅輯思維、ofo、曠視LinkedInPivotal等公司專家出席。


本期 GIAC 大會上,部分精彩的議題如下:

參加 GIAC,盤點2018最新技術。點擊“閱讀原文”瞭解大會更多詳情

赞(0)

分享創造快樂