spring boot 應用在 k8s 中的健康檢查(一)

一、概述

在 spring boot 2.3 中引入了容器探針舆声,也就是增加了 /actuator/health/liveness/actuator/health/readiness 這兩個健康檢查路徑端壳,對于部署在 k8s 中的應用,spring-boot-actuator 將通過這兩個路徑自動進行健康檢查志膀。本文主要根據(jù)官方文檔的描述實踐并記錄使用流程佑吝,從如下幾個方面進行介紹:

  1. k8s 中的健康檢查
  2. spring-boot-actuator 中的 k8s 探針
  3. spring boot 健康檢查在 k8s 中的實踐

二坐昙、K8s 容器健康檢查

1、k8s 中的探針

kubernetes 提供了三種探針(支持exec迹蛤、tcp和http方式)來探測容器的狀態(tài):

  • LivenessProbe:容器存活性檢查民珍,用于判斷容器是否健康襟士,告訴 kubelet 一個容器什么時候處于不健康的狀態(tài)盗飒。如果 LivenessProbe 探針探測到容器不健康,則 kubelet 將刪除該容器陋桂,并根據(jù)容器的重啟策略做相應的處理逆趣。如果一個容器不包含 LivenessProbe 探針,那么 kubelet 認為該容器的 LivenessProbe 探針返回的值永遠是 Success嗜历;
  • ReadinessProbe:容器就緒性檢查宣渗,用于判斷容器是否啟動完成且準備接收請求抖所。如果ReadinessProbe探針探測到失敗,Endpoint Controller 將從 ServiceEndpoint 中刪除包含該容器所在 Pod 的 IP 地址的Endpoint條目痕囱。如果容器不提供就緒態(tài)探針田轧,則默認狀態(tài)為 Success
  • startupProbe: 容器啟動檢查鞍恢,指示容器中的應用是否已經(jīng)啟動傻粘。如果提供了啟動探針,則所有其他探針都會被禁用帮掉,直到此探針成功為止弦悉。如果啟動探測失敗,kubelet 將殺死容器蟆炊,而容器依其重啟策略進行重啟稽莉。 如果容器沒有提供啟動探測,則默認狀態(tài)為 Success涩搓。

startupProbe 是在k8s v1.16加入了alpha版污秆,官方對其作用的解釋是:
Indicates whether the application within the Container is started. All other probes are disabled if a startup probe is provided, until it succeeds. If the startup probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a startup probe, the default state is Success

2、k8s 的探針處理程序

Probe 探針檢查是由 kubelet 對容器執(zhí)行的定期診斷昧甘,kubelet 調(diào)用由容器實現(xiàn)的 Handler (處理程序)混狠,每一個探針都可以配置如下三種類型的處理程序:

  • ExecAction: 在容器內(nèi)執(zhí)行指定命令,如果命令退出時返回碼為 0 則認為診斷成功疾层。

通過執(zhí)行命令的方式來檢查服務是否正常将饺,比如使用 cat 命令查看 pod 中的某個重要配置文件是否存在,若存在痛黎,則表示pod健康予弧,反之異常。Exec 探測方式的 yaml 文件語法如下:

spec:  
  containers:  
  - name: liveness  
    image: k8s.gcr.io/busybox  
    args:  
    - /bin/sh  
    - -c  
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600  
    livenessProbe:               #選擇livenessProbe的探測機制  
      exec:                      #執(zhí)行以下命令湖饱,如果文件存在則探測成功
        command:  
        - cat  
        - /tmp/healthy  
      initialDelaySeconds: 5          #在容器運行五秒后開始探測  
      periodSeconds: 5                #檢查時間間隔為 5s 檢查一次

  • TCPSocketAction: 對容器的 IP 地址上的指定端口執(zhí)行 TCP 檢查掖蛤,如果端口打開,則診斷被認為是成功的井厌。
    這種方式與HTTPget的探測機制有些類似蚓庭,tcpsocket健康檢查適用于TCP業(yè)務,tcpSocket探測方式的yaml文件語法如下:
spec:  
  containers:  
  - name: goproxy  
    image: k8s.gcr.io/goproxy:0.1  
    ports:  
      - containerPort: 8080  
    #這里兩種探測機制都用上了仅仆,都是為了和容器的8080端口建立TCP連接  
    readinessProbe:  
      tcpSocket:  
        port: 8080  
      initialDelaySeconds: 5  # 容器啟動 5s 后開始第一次就緒性探測
      periodSeconds: 10       # 每 10s 進行一次探測
    livenessProbe:  
      tcpSocket:  
        port: 8080  
      initialDelaySeconds: 15  # 容器啟動 15s 后開始第一次就存活性探測
      periodSeconds: 20  # 每 20s 進行一次探測

在上述的yaml配置文件中器赞,兩類探針都使用了,在容器啟動5秒后墓拜,kubelet將發(fā)送第一個readinessProbe探針港柜,這將連接容器的8080端口,如果探測成功,則該pod為健康夏醉,十秒后爽锥,kubelet將進行第二次連接。

除了readinessProbe探針外畔柔,在容器啟動15秒后氯夷,kubelet將發(fā)送第一個livenessProbe探針较店,仍然嘗試連接容器的8080端口平匈,如果連接失敗,則重啟容器阔加。

  • HTTPGetAction: 對容器的 IP 地址上指定端口和路徑執(zhí)行 HTTP Get 請求奢啥,如果響應的狀態(tài)碼大于等于 200 且小于 400秸仙,則診斷被認為是成功的。

Httpget探測方式的yaml文件語法如下:

spec:  
  containers:  
  - name: liveness  
    image: k8s.gcr.io/liveness  
    livenessProbe:              #采用livenessProbe機制探測  
      httpGet:                  #采用httpget的方式  
        scheme: HTTP         #指定協(xié)議桩盲,也支持https  
        path: /healthz          #檢測是否可以訪問到網(wǎng)頁根目錄下的healthz網(wǎng)頁文件  
        port: 8080              #監(jiān)聽端口是8080  
      initialDelaySeconds: 3     #容器運行3秒后開始探測  
      periodSeconds: 3                #探測頻率為3秒  

上述配置文件中寂纪,探測方式為項容器發(fā)送HTTP GET請求,請求的是 8080 端口下的 healthz 文件赌结,返回任何大于或等于200且小于400的狀態(tài)碼表示成功捞蛋,任何其他代碼表示異常。

每次探測都將獲得以下三種結果之一:

  • Success(成功):容器通過了診斷柬姚。
  • Failure(失斈馍肌):容器未通過診斷。
  • Unknown(未知):診斷失敗量承,因此不會采取任何行動搬设。

3、k8s 探針的配置

Probe 有如下配置字段撕捍,可以使用這些字段精確的控制存活和就緒檢測的行為:

  • initialDelaySeconds:容器啟動后要等待多少秒后存活和就緒探測器才被初始化拿穴,默認是 0 秒,最小值是 0忧风。
  • periodSeconds:執(zhí)行探測的時間間隔(單位是秒)默色。默認是 10 秒。最小值是 1狮腿。
  • timeoutSeconds:探測的超時后等待多少秒腿宰。默認值是 1 秒。最小值是 1缘厢。
  • successThreshold:探測器在失敗后吃度,被視為成功的最小連續(xù)成功數(shù)。默認值是 1昧绣。 存活和啟動探測的這個值必須是 1规肴。最小值是 1捶闸。
  • failureThreshold:當探測失敗時夜畴,Kubernetes 的重試次數(shù)拖刃。 存活探測情況下的放棄就意味著重新啟動容器。 就緒探測情況下的放棄 Pod 會被打上未就緒的標簽贪绘。默認值是 3兑牡。最小值是 1。

說明:在 Kubernetes 1.20 版本之前税灌,exec 探針會忽略 timeoutSeconds:探針會無限期地 持續(xù)運行均函,甚至可能超過所配置的限期,直到返回結果為止菱涤。這一缺陷在 Kubernetes v1.20 版本中得到修復苞也。

LivenessProbe配置例子:

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 30        // 容器啟動30s后啟動第一次探測
  periodSeconds: 10              //  每隔10s啟動一次探測
  timeoutSeconds: 3               // 超時時間3s
  successThreshold: 1             // 成功1次即表示容器健康
  failureThreshold: 5             // 連續(xù)5次失敗,則判定容器不健康粘秆,默認3次

4如迟、何時使用

何時使用啟動探針

kubelet 使用啟動探測器可以知道應用程序容器什么時候啟動了。 如果配置了這類探測器攻走,就可以控制容器在啟動成功后再進行存活性和就緒檢查殷勘, 確保這些存活、就緒探測器不會影響應用程序的啟動昔搂。 這可以用于對慢啟動容器進行存活性檢測玲销,避免它們在啟動運行之前就被殺掉。

何時使用存活探針

kubelet 使用存活探測器來知道什么時候要重啟容器摘符。 例如贤斜,存活探測器可以捕捉到死鎖(應用程序在運行,但是無法繼續(xù)執(zhí)行后面的步驟)逛裤。 這樣的情況下重啟容器有助于讓應用程序在有問題的情況下更可用蠢古。

何時使用就緒探針

kubelet 使用就緒探測器可以知道容器什么時候準備好了并可以開始接受請求流量, 當一個 Pod 內(nèi)的所有容器都準備好了别凹,才能把這個 Pod 看作就緒了草讶。 這種信號的一個用途就是控制哪個 Pod 作為 Service 的后端。 在 Pod 還沒有準備好的時候炉菲,會從 Service 的負載均衡器中被剔除的堕战。

5、使用啟動探測器保護慢啟動容器

有時候拍霜,會有一些現(xiàn)有的應用程序在啟動時需要較多的初始化時間嘱丢。 要不影響對引起探測死鎖的快速響應,這種情況下祠饺,設置存活探測參數(shù)是要技巧的越驻。 技巧就是使用一個命令來設置啟動探測,針對HTTP 或者 TCP 檢測,可以通過設置 failureThreshold * periodSeconds 參數(shù)來保證有足夠長的時間應對糟糕情況下的啟動時間缀旁。
所以记劈,前面的例子就變成了:

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

幸虧有啟動探測,應用程序?qū)凶疃?5 分鐘(30 * 10 = 300s) 的時間來完成它的啟動并巍。 一旦啟動探測成功一次目木,存活探測任務就會接管對容器的探測,對容器死鎖可以快速響應懊渡。 如果啟動探測一直沒有成功刽射,容器會在 300 秒后被殺死,并且根據(jù) restartPolicy 來設置 Pod 狀態(tài)剃执。

參考文章:

官網(wǎng) k8s 容器探針

最后編輯于
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末誓禁,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子肾档,更是在濱河造成了極大的恐慌现横,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,755評論 6 507
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件阁最,死亡現(xiàn)場離奇詭異戒祠,居然都是意外死亡,警方通過查閱死者的電腦和手機速种,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,305評論 3 395
  • 文/潘曉璐 我一進店門姜盈,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人配阵,你說我怎么就攤上這事馏颂。” “怎么了棋傍?”我有些...
    開封第一講書人閱讀 165,138評論 0 355
  • 文/不壞的土叔 我叫張陵救拉,是天一觀的道長。 經(jīng)常有香客問我瘫拣,道長亿絮,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,791評論 1 295
  • 正文 為了忘掉前任麸拄,我火速辦了婚禮派昧,結果婚禮上,老公的妹妹穿的比我還像新娘拢切。我一直安慰自己蒂萎,他們只是感情好,可當我...
    茶點故事閱讀 67,794評論 6 392
  • 文/花漫 我一把揭開白布淮椰。 她就那樣靜靜地躺著五慈,像睡著了一般纳寂。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上泻拦,一...
    開封第一講書人閱讀 51,631評論 1 305
  • 那天毙芜,我揣著相機與錄音,去河邊找鬼聪轿。 笑死爷肝,一個胖子當著我的面吹牛猾浦,可吹牛的內(nèi)容都是我干的陆错。 我是一名探鬼主播,決...
    沈念sama閱讀 40,362評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼金赦,長吁一口氣:“原來是場噩夢啊……” “哼音瓷!你這毒婦竟也來了?” 一聲冷哼從身側響起夹抗,我...
    開封第一講書人閱讀 39,264評論 0 276
  • 序言:老撾萬榮一對情侶失蹤绳慎,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后漠烧,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體杏愤,經(jīng)...
    沈念sama閱讀 45,724評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,900評論 3 336
  • 正文 我和宋清朗相戀三年已脓,在試婚紗的時候發(fā)現(xiàn)自己被綠了珊楼。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,040評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡度液,死狀恐怖厕宗,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情堕担,我是刑警寧澤已慢,帶...
    沈念sama閱讀 35,742評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站霹购,受9級特大地震影響佑惠,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜齐疙,卻給世界環(huán)境...
    茶點故事閱讀 41,364評論 3 330
  • 文/蒙蒙 一兢仰、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧剂碴,春花似錦把将、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,944評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽请垛。三九已至,卻和暖如春洽议,著一層夾襖步出監(jiān)牢的瞬間宗收,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,060評論 1 270
  • 我被黑心中介騙來泰國打工亚兄, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留混稽,地道東北人。 一個月前我還...
    沈念sama閱讀 48,247評論 3 371
  • 正文 我出身青樓审胚,卻偏偏與公主長得像匈勋,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子膳叨,可洞房花燭夜當晚...
    茶點故事閱讀 44,979評論 2 355