本文分享自華為雲社群《Kubernetes探針原理介紹》,作者: 可以交個朋友。
簡介
容器探針(Container Probes)是一種機制,由 kubelet 對容器執行定期的探查,從而獲取容器的狀態。探針的型別有三種:
- 啟動探針(Startup Probe)
- 存活探針(Liveness Probe)
- 就緒探針(Readiness Probe)
探針功能
啟動探針
啟動探針(StartupProbe)主要用於檢測容器內的應用是否已經成功啟動並完成初始化任務。它的主要作用有以下幾點:
-
延緩其他探針生效
: 在容器啟動初期,啟動探針先於存活探針(LivenessProbe)和就緒探針(ReadinessProbe)生效。當啟動探針配置存在時,kubelet 不會執行存活和就緒探針,直到啟動探針成功為止。這對於某些啟動時間較長或者啟動過程中有複雜初始化序列的應用程式來說非常重要,可以避免在應用還未完全啟動時就被誤判為不健康或就緒,進而被錯誤地重啟或流量過早湧入。 -
防止頻繁重啟
: 若應用啟動期間,存活探針或就緒探針就開始工作,而此時應用可能還沒有完全啟動成功,這兩個探針可能會因為應用未能及時響應而觸發容器重啟,造成不必要的服務中斷和迴圈重啟。啟動探針的存在可以有效地防止此類情況的發生。
存活探針
存活探針(Liveness Probe)主要作用是檢測容器內主程序或服務是否仍然執行正常且響應健康檢查。具體來說:
自動恢復
: 當存活探針檢測失敗時,kubelet 將認為該容器內的主程序已經不再健康或者已停止提供預期的服務。此時,kubelet 會根據 Pod 的重啟策略來決定是否應該重新啟動這個容器。透過這種方式,存活探針可以幫助實現故障自愈,及時恢復服務的可用性。就緒探針
就緒探針(Readiness Probe)主要作用是檢測容器是否已經準備好對外提供服務。具體來說:
-
流量路由控制
: 當就緒探針成功時,表示該容器內部的應用程式已處於可接受請求的狀態,此時 kubelet 會將該容器標記為“就緒”狀態,Service 將會將其 IP 地址新增到後端服務列表中,允許 Service 開始將網路流量轉發至這個 Pod。 -
避免無效請求
: 如果就緒探針失敗,則意味著容器可能還在啟動過程中、正在重啟服務、或者由於某種原因暫時無法正常響應請求。在這種情況下,kubelet 會將容器從 Service 的後端池中移除,確保不會向其傳送任何使用者請求,從而避免了因應用未準備完畢而引起的錯誤響應和使用者體驗下降。 -
平滑過渡
: 透過就緒探針,Kubernetes 可以實現滾動更新或部署過程中的平滑過渡,新版本的容器在透過就緒探針驗證前,不會承擔任何實際流量,直到它們完全啟動並做好處理請求的準備。
探針方式
探針實現方式有三種:
HTTP GET請求
: Kubernetes 透過向容器內應用傳送一個HTTP GET請求來檢查應用的狀態。如果收到的 HTTP 響應碼在 200-399 範圍內,則認為該探測成功。
livenessProbe: #可指定其他兩種探針型別 httpGet: #指定探針方式 path: /healthz #http請求路徑 port: 8080 #請求埠 httpHeaders: # 可選,用於設定自定義HTTP頭部 - name: Custom-Header value: huawei
TCP Socket檢查
: Kubernetes 嘗試與容器上指定的埠建立 TCP 連線。如果能夠成功建立連線,則說明探測成功。
livenessProbe: tcpSocket: port: 8080
exec執行命令
: 在容器內部執行一個命令,並根據命令退出時返回的狀態碼判斷容器是否正常執行。通常情況下,如果命令返回 0,則表示成功。
livenessProbe: exec: command: - cat - /tmp/health
啟動探針、存活探針和就緒探針同時支援這三種方式。每種探針可以選擇不同探測方式
探針配置引數
Kubernetes中的探針都支援一些通用的引數來定義它們的行為。以下是這些探針通常使用的配置引數:
initialDelaySeconds
:容器啟動後要等待多少秒後才啟動啟動、存活和就緒探針。 如果定義了啟動探針,則存活探針和就緒探針的延遲將在啟動探針已成功之後才開始計算。 如果 periodSeconds 的值大於 initialDelaySeconds,則 initialDelaySeconds 將被忽略。預設是 0 秒,最小值是 0。
periodSeconds
:執行探測的時間間隔(單位是秒)。預設是 10 秒。最小值是 1。
timeoutSeconds
:探測的超時後等待多少秒。預設值是 1 秒。最小值是 1。
successThreshold
:探針在失敗後,被視為成功的最小連續成功數。預設值是 1。 存活和啟動探針的這個值必須是 1。
failureThreshold
:探針連續失敗了 failureThreshold 次之後, Kubernetes 認為總體上檢查已失敗:容器狀態未就緒、不健康、不活躍。 對於啟動探針或存活探針而言,如果至少有 failureThreshold 個探針已失敗, Kubernetes 會將容器視為不健康併為這個特定的容器觸發重啟操作。 kubelet 遵循該容器的terminationGracePeriodSeconds 設定。
terminationGracePeriodSeconds
:k8s1.25以上版本新增,為 kubelet 配置從為失敗的容器觸發終止操作到強制容器執行時停止該容器之前等待的寬限時長。 預設值是繼承 Pod 級別的 terminationGracePeriodSeconds 值(如果不設定則為 30 秒),最小值為 1。就緒探針不需要配置該引數
完整配置示例:
livenessProbe: #可以選擇 httpGet、tcpSocket 或 exec 中的一種 httpGet: path: /health port: 8080 httpHeaders: - name: Custom-Header value: huawei #通用引數: initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 1 successThreshold: 1 failureThreshold: 3 terminationGracePeriodSeconds: 30 readinessProbe: # 就緒探針配置類似 startupProbe: # 啟動探針配置也相似
配置建議
如果應用是慢啟動型別,建議配置啟動探針或者為存活探針配置initialDelaySeconds
引數,避免存活探針過早介入導致容器頻繁重啟。如果應用啟動時間不固定建議使用啟動探針。
可以將啟動探針initialDelaySeconds
、periodSeconds
的值調低,讓啟動探針更快感知容器健康狀態;由於啟動探針探測成功後就會退出不會影響容器後續執行,可以將failureThreshold
的值調大,避免應用還未啟動完成過早觸發重啟
failureThreshold
設定比就緒探針大,這樣如果應用有問題應該先切斷流量
點選關注,第一時間瞭解華為雲新鮮技術~