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

探針的作用

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

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

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

圖片

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

宏觀的意義

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

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

圖片

當上游的 Pod 不可用時，其下游的 Pod 也無法工作，然后傳播到所有相關的 Pod 中。

此時此刻，如果可觀測工具將所有的錯誤一股腦的拋出來，運維人員一定會感到非常的絕望，一定希望有一個工具可以告訴他：某個 Pod 本身出問題了，其他 Pod 是因為依賴的 Pod 出問題了所以報錯了。這樣才能能專注于解決關鍵問題。

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

沒錯，解決這兩個需求的方法就是探針。

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

這兩個探針正是 Kubernetes 平臺與應用之間溝通的契約，當返回報錯時，應用實際要表達的意思和做出的承諾是:

• 存活探針: 我不行了，多試幾次，如果還不行，就干掉我重啟試試。
• 就緒探針：我現(xiàn)在沒法對外提供服務，不要將請求轉(zhuǎn)給我。可能是我依賴的服務有異常，如果依賴的服務恢復，我應該也能恢復。

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

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

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

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

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

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

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

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

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

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

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

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

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

參考

• [1] 鏈式反應和級聯(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] 探針對于伸縮的意義和一些參數(shù)說明https://yylives.cc/2023/02/25/kubernetes-probes-and-why-they-matter-for-autoscaling/