今天在群里又看有人問如何設(shè)置 Kubernetes 的探針，感覺要補(bǔ)充的話太多了，結(jié)合我們?cè)谝恍?DevOps 項(xiàng)目中痛苦的體驗(yàn)，今天一勞永逸的全部說完，此外，也為大家展現(xiàn)一下為什么 DevOps 這么難？

探針的作用

從功能上講，探針的作用很簡單，之前我也發(fā)文澄清過許多人的一些概念不清，本文是希望讓運(yùn)維和開發(fā)都能理解，所以會(huì)盡量簡單的表達(dá)。

探針功能是 Kubernetes 提供的一個(gè)偵測(cè)應(yīng)用是否正常運(yùn)行的檢查機(jī)制。最常見的探測(cè)方式是 HTTP 探測(cè)。應(yīng)用需要暴露一個(gè)地址，Kubernetes 會(huì)定期調(diào)用該地址，如果地址返回 200 狀態(tài)碼，則認(rèn)為應(yīng)用正常，否則認(rèn)為應(yīng)用異常。

一般情況下會(huì)需要為應(yīng)用配置兩個(gè)探針，分別是存活（liveness）探針和就緒（readiness）探針。存活探針可以在應(yīng)用有問題時(shí)觸發(fā)重啟，應(yīng)用在重啟后可能可以恢復(fù)正常。而就緒探針，保證應(yīng)用有問題時(shí)切斷流量，避免該應(yīng)用被調(diào)用到：

圖片

如果只是從功能角度看，似乎二者的區(qū)別不大，配置一個(gè)相同的應(yīng)用接口似乎也沒啥問題，那為什么還要設(shè)置兩個(gè)不同的探針呢？“假設(shè)” Kubernetes 的開發(fā)者是理智的，則肯定有原因，這個(gè)原因后面詳細(xì)說，先看看運(yùn)維面臨的問題。

宏觀的意義

運(yùn)維的朋友，尤其是做過微服務(wù)應(yīng)用運(yùn)維的朋友，一定見識(shí)過某個(gè)基礎(chǔ)組件或上游服務(wù)出故障的情況吧？可觀測(cè)做的“到位”，可能是滿大屏的紅色驚嘆號(hào)。《發(fā)布！設(shè)計(jì)與部署穩(wěn)定的分布式系統(tǒng)》書中將這個(gè)穩(wěn)定性反模式叫做“級(jí)聯(lián)效應(yīng)”。

產(chǎn)生級(jí)聯(lián)效應(yīng)的過程，可以用下圖來展示：

圖片

當(dāng)上游的 Pod 不可用時(shí)，其下游的 Pod 也無法工作，然后傳播到所有相關(guān)的 Pod 中。

此時(shí)此刻，如果可觀測(cè)工具將所有的錯(cuò)誤一股腦的拋出來，運(yùn)維人員一定會(huì)感到非常的絕望，一定希望有一個(gè)工具可以告訴他：某個(gè) Pod 本身出問題了，其他 Pod 是因?yàn)橐蕾嚨?Pod 出問題了所以報(bào)錯(cuò)了。這樣才能能專注于解決關(guān)鍵問題。

此外，這種級(jí)聯(lián)反應(yīng)的故障恢復(fù)時(shí)，也往往絕非“病去如抽絲”，可能不斷會(huì)遇到個(gè)別的業(yè)務(wù)問題，有時(shí)運(yùn)維人員需要去手工重啟服務(wù)才能解決。他一定希望：應(yīng)用要是能夠在條件具備時(shí)自動(dòng)恢復(fù)就好了。

沒錯(cuò)，解決這兩個(gè)需求的方法就是探針。

探針如何發(fā)揮作用

這兩個(gè)探針正是 Kubernetes 平臺(tái)與應(yīng)用之間溝通的契約，當(dāng)返回報(bào)錯(cuò)時(shí)，應(yīng)用實(shí)際要表達(dá)的意思和做出的承諾是:

• 存活探針: 我不行了，多試幾次，如果還不行，就干掉我重啟試試。
• 就緒探針：我現(xiàn)在沒法對(duì)外提供服務(wù)，不要將請(qǐng)求轉(zhuǎn)給我?？赡苁俏乙蕾嚨姆?wù)有異常，如果依賴的服務(wù)恢復(fù)，我應(yīng)該也能恢復(fù)。

這樣看，兩個(gè)探針有著明顯的區(qū)別。而這兩個(gè)探針與應(yīng)用配合，是如何解決上一章所說的問題呢？

首先說說應(yīng)用完全hang死的情況。此時(shí)無論是存活探針還是就緒探針，都會(huì)探測(cè)異常，肯定會(huì)觸發(fā)重啟，這種情況在應(yīng)用也沒法做什么預(yù)設(shè)，是探針機(jī)制最立竿見影的一個(gè)情況。

當(dāng)應(yīng)用本身發(fā)生問題時(shí)，存活探針應(yīng)該報(bào)告異常，從而觸發(fā)重啟。此時(shí)，問題的關(guān)鍵是，應(yīng)用如何知道自己存在異常？確實(shí)挺難的，這個(gè)探針對(duì)應(yīng)的接口應(yīng)該能夠模擬正常業(yè)務(wù)的主要邏輯，而且如果依賴的服務(wù)有問題，而且應(yīng)用能夠處理這個(gè)問題，則不應(yīng)該報(bào)告異常。

當(dāng)應(yīng)用依賴的服務(wù)出現(xiàn)故障時(shí)。我們希望應(yīng)用的存活探針報(bào)告正常，而就緒探針報(bào)告報(bào)告異常。因?yàn)榇藭r(shí)存活探針報(bào)告異常觸發(fā)了應(yīng)用重啟也解決不了任務(wù)問題，大量的重啟以及相關(guān)的報(bào)錯(cuò)反而會(huì)讓運(yùn)維人員感到恐慌。探針這樣工作有一個(gè)非常重要的前提條件，那就是應(yīng)用在其依賴服務(wù)恢復(fù)時(shí)也能夠自己恢復(fù)。如果應(yīng)用無法自動(dòng)恢復(fù)，也許我們只能選擇讓存活探針在此時(shí)報(bào)告異常，運(yùn)維需要面對(duì)反復(fù)重啟的無盡惶恐之中。

問題到了開發(fā)這里

道理都懂了，但是該如何解決呢？對(duì)運(yùn)維來說意義重大的一個(gè)功能，卻必須依靠開發(fā)人員來完成。首先，需要開發(fā)人員理解上述過程，這也是編寫本文的目的之一，然后就是去實(shí)現(xiàn)了。

盡管像 Spring 這樣的開發(fā)框架，已經(jīng)提供了探針相關(guān)的功能，開發(fā)可能配置一下就能完成，但實(shí)際情況往往并不簡單。例如 spring 文檔說了：

The “l(fā)iveness” Probe should not depend on health checks for external systems.

意思就是 liveness 探針不應(yīng)當(dāng)依賴外部系統(tǒng)的狀態(tài)，但實(shí)際上有時(shí)這個(gè)外部系統(tǒng)的定義未必那么篤定；也可能我們的應(yīng)用無法從某個(gè)外部系統(tǒng)的故障中恢復(fù)，所以即使是外部系統(tǒng)，我們可能也會(huì)將其納入到 liveness 探針需要檢查的范疇。

而且，很有可能我們不能一次做好這個(gè)事情，需要在結(jié)合實(shí)際出現(xiàn)的問題進(jìn)行調(diào)整。如果開發(fā)沒有參與運(yùn)維，或者中間的溝通不暢，亦或者沒把這件是當(dāng)做自己的事情，這個(gè)探針的問題未必能簡單的解決。

其實(shí)群里人家問的是探針的參數(shù)問題，但其實(shí)這些參數(shù)只是控制故障能多快的暴露出來，如果應(yīng)用的探針本身就有問題，這些參數(shù)設(shè)置的再精妙都沒有意義。我覺得這是許多團(tuán)隊(duì)的一種工作狀態(tài)：我們部門自己能搞定的盡量不要依賴別的團(tuán)隊(duì)。例如，要是我能找到一個(gè)可觀測(cè)工具，直接給我定位哪個(gè)pod出問題，那我還找什么開發(fā)。

實(shí)際上呢？太難了，做這樣包治百病的工具太難了。不過，根據(jù)許多人的選擇，我們知道這可能比讓 Dev 和 Ops 高效的配合起來更簡單，至少?zèng)]那么絕望吧。

謹(jǐn)以本文給大家一個(gè)例子，希望大家能夠互相體諒，保持一點(diǎn) DevOps 的精神，高層領(lǐng)導(dǎo)也能意識(shí)到這個(gè)問題，看看怎么解決。再就是看看平臺(tái)工程，是不是可以建設(shè)一個(gè)好的平臺(tái)，讓開發(fā)能夠更輕松的直面這個(gè)問題，畢竟自己寫的程序最了解。

參考

• [1] 鏈?zhǔn)椒磻?yīng)和級(jí)聯(lián)故障:https://www.bilibili.com/video/BV13Q4y1K7FU/
• [2] 2.9.2. Application lifecycle and Probes states:https://docs.spring.io/spring-boot/docs/2.4.1/reference/html/production-ready-features.html#production-ready-kubernetes-probes-external-state
• [3] 探針對(duì)于伸縮的意義和一些參數(shù)說明https://yylives.cc/2023/02/25/kubernetes-probes-and-why-they-matter-for-autoscaling/