今天在群里又看有人問如何設置 Kube.NETes 的探針，感覺要補充的話太多了，結合我們在一些 DevOps 項目中痛苦的體驗，今天一勞永逸的全部說完，此外，也為大家展現一下為什么 DevOps 這么難？
探針的作用
從功能上講，探針的作用很簡單，之前我也發文澄清過許多人的一些概念不清，本文是希望讓運維和開發都能理解，所以會盡量簡單的表達。
探針功能是 Kubernetes 提供的一個偵測應用是否正常運行的檢查機制。最常見的探測方式是 HTTP 探測。應用需要暴露一個地址，Kubernetes 會定期調用該地址，如果地址返回 200 狀態碼，則認為應用正常，否則認為應用異常。
一般情況下會需要為應用配置兩個探針，分別是存活（liveness）探針和就緒（readiness）探針。存活探針可以在應用有問題時觸發重啟，應用在重啟后可能可以恢復正常。而就緒探針，保證應用有問題時切斷流量，避免該應用被調用到：
圖片
如果只是從功能角度看，似乎二者的區別不大，配置一個相同的應用接口似乎也沒啥問題，那為什么還要設置兩個不同的探針呢？“假設” Kubernetes 的開發者是理智的，則肯定有原因，這個原因后面詳細說，先看看運維面臨的問題。
宏觀的意義
運維的朋友，尤其是做過微服務應用運維的朋友，一定見識過某個基礎組件或上游服務出故障的情況吧？可觀測做的“到位”，可能是滿大屏的紅色驚嘆號。《發布！設計與部署穩定的分布式系統》書中將這個穩定性反模式叫做“級聯效應”。
產生級聯效應的過程，可以用下圖來展示：
圖片
當上游的 Pod 不可用時，其下游的 Pod 也無法工作，然后傳播到所有相關的 Pod 中。
此時此刻，如果可觀測工具將所有的錯誤一股腦的拋出來，運維人員一定會感到非常的絕望，一定希望有一個工具可以告訴他：某個 Pod 本身出問題了，其他 Pod 是因為依賴的 Pod 出問題了所以報錯了。這樣才能能專注于解決關鍵問題。
此外，這種級聯反應的故障恢復時，也往往絕非“病去如抽絲”，可能不斷會遇到個別的業務問題，有時運維人員需要去手工重啟服務才能解決。他一定希望：應用要是能夠在條件具備時自動恢復就好了。
沒錯，解決這兩個需求的方法就是探針。
探針如何發揮作用
這兩個探針正是 Kubernetes 平臺與應用之間溝通的契約，當返回報錯時，應用實際要表達的意思和做出的承諾是:
- 存活探針: 我不行了，多試幾次，如果還不行，就干掉我重啟試試。
- 就緒探針：我現在沒法對外提供服務，不要將請求轉給我。可能是我依賴的服務有異常，如果依賴的服務恢復，我應該也能恢復。
這樣看，兩個探針有著明顯的區別。而這兩個探針與應用配合，是如何解決上一章所說的問題呢？
首先說說應用完全hang死的情況。此時無論是存活探針還是就緒探針，都會探測異常，肯定會觸發重啟，這種情況在應用也沒法做什么預設，是探針機制最立竿見影的一個情況。
當應用本身發生問題時，存活探針應該報告異常，從而觸發重啟。此時，問題的關鍵是，應用如何知道自己存在異常？確實挺難的，這個探針對應的接口應該能夠模擬正常業務的主要邏輯，而且如果依賴的服務有問題，而且應用能夠處理這個問題，則不應該報告異常。
當應用依賴的服務出現故障時。我們希望應用的存活探針報告正常，而就緒探針報告報告異常。因為此時存活探針報告異常觸發了應用重啟也解決不了任務問題，大量的重啟以及相關的報錯反而會讓運維人員感到恐慌。探針這樣工作有一個非常重要的前提條件，那就是應用在其依賴服務恢復時也能夠自己恢復。如果應用無法自動恢復，也許我們只能選擇讓存活探針在此時報告異常，運維需要面對反復重啟的無盡惶恐之中。
問題到了開發這里
道理都懂了，但是該如何解決呢？對運維來說意義重大的一個功能，卻必須依靠開發人員來完成。首先，需要開發人員理解上述過程，這也是編寫本文的目的之一，然后就是去實現了。
盡管像 Spring 這樣的開發框架，已經提供了探針相關的功能，開發可能配置一下就能完成，但實際情況往往并不簡單。例如 spring 文檔說了：
The “liveness” Probe should not depend on health checks for external systems.
意思就是 liveness 探針不應當依賴外部系統的狀態，但實際上有時這個外部系統的定義未必那么篤定；也可能我們的應用無法從某個外部系統的故障中恢復，所以即使是外部系統，我們可能也會將其納入到 liveness 探針需要檢查的范疇。
而且，很有可能我們不能一次做好這個事情，需要在結合實際出現的問題進行調整。如果開發沒有參與運維，或者中間的溝通不暢，亦或者沒把這件是當做自己的事情，這個探針的問題未必能簡單的解決。
其實群里人家問的是探針的參數問題，但其實這些參數只是控制故障能多快的暴露出來，如果應用的探針本身就有問題，這些參數設置的再精妙都沒有意義。我覺得這是許多團隊的一種工作狀態：我們部門自己能搞定的盡量不要依賴別的團隊。例如，要是我能找到一個可觀測工具，直接給我定位哪個pod出問題，那我還找什么開發。
實際上呢？太難了，做這樣包治百病的工具太難了。不過，根據許多人的選擇，我們知道這可能比讓 Dev 和 Ops 高效的配合起來更簡單，至少沒那么絕望吧。
謹以本文給大家一個例子，希望大家能夠互相體諒，保持一點 DevOps 的精神，高層領導也能意識到這個問題，看看怎么解決。再就是看看平臺工程，是不是可以建設一個好的平臺，讓開發能夠更輕松的直面這個問題，畢竟自己寫的程序最了解。
參考
- [1] 鏈式反應和級聯故障: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] 探針對于伸縮的意義和一些參數說明https://yylives.cc/2023/02/25/kubernetes-probes-and-why-they-matter-for-autoscaling/
