建站
咨詢
售后
建站咨詢
新聞中心
今天在群里又看有人問如何設(shè)置 Kubernetes 的探針，感覺要補(bǔ)充的話太多了，結(jié)合我們在一些 DevOps 項(xiàng)目中痛苦的體驗(yàn)，今天一勞永逸的全部說完，此外，也為大家展現(xiàn)一下為什么 DevOps 這么難？
探針的作用
從功能上講，探針的作用很簡單，之前我也發(fā)文澄清過許多人的一些概念不清，本文是希望讓運(yùn)維和開發(fā)都能理解，所以會盡量簡單的表達(dá)。
探針功能是 Kubernetes 提供的一個偵測應(yīng)用是否正常運(yùn)行的檢查機(jī)制。最常見的探測方式是 HTTP 探測。應(yīng)用需要暴露一個地址，Kubernetes 會定期調(diào)用該地址，如果地址返回 200 狀態(tài)碼，則認(rèn)為應(yīng)用正常，否則認(rèn)為應(yīng)用異常。
一般情況下會需要為應(yīng)用配置兩個探針，分別是存活（liveness）探針和就緒（readiness）探針。存活探針可以在應(yīng)用有問題時觸發(fā)重啟，應(yīng)用在重啟后可能可以恢復(fù)正常。而就緒探針，保證應(yīng)用有問題時切斷流量，避免該應(yīng)用被調(diào)用到：
圖片
如果只是從功能角度看，似乎二者的區(qū)別不大，配置一個相同的應(yīng)用接口似乎也沒啥問題，那為什么還要設(shè)置兩個不同的探針呢？“假設(shè)” Kubernetes 的開發(fā)者是理智的，則肯定有原因，這個原因后面詳細(xì)說，先看看運(yùn)維面臨的問題。
宏觀的意義
運(yùn)維的朋友，尤其是做過微服務(wù)應(yīng)用運(yùn)維的朋友，一定見識過某個基礎(chǔ)組件或上游服務(wù)出故障的情況吧？可觀測做的“到位”，可能是滿大屏的紅色驚嘆號?！栋l(fā)布！設(shè)計與部署穩(wěn)定的分布式系統(tǒng)》書中將這個穩(wěn)定性反模式叫做“級聯(lián)效應(yīng)”。
產(chǎn)生級聯(lián)效應(yīng)的過程，可以用下圖來展示：
圖片
當(dāng)上游的 Pod 不可用時，其下游的 Pod 也無法工作，然后傳播到所有相關(guān)的 Pod 中。
此時此刻，如果可觀測工具將所有的錯誤一股腦的拋出來，運(yùn)維人員一定會感到非常的絕望，一定希望有一個工具可以告訴他：某個 Pod 本身出問題了，其他 Pod 是因?yàn)橐蕾嚨?Pod 出問題了所以報錯了。這樣才能能專注于解決關(guān)鍵問題。
此外，這種級聯(lián)反應(yīng)的故障恢復(fù)時，也往往絕非“病去如抽絲”，可能不斷會遇到個別的業(yè)務(wù)問題，有時運(yùn)維人員需要去手工重啟服務(wù)才能解決。他一定希望：應(yīng)用要是能夠在條件具備時自動恢復(fù)就好了。
沒錯，解決這兩個需求的方法就是探針。
探針如何發(fā)揮作用
這兩個探針正是 Kubernetes 平臺與應(yīng)用之間溝通的契約，當(dāng)返回報錯時，應(yīng)用實(shí)際要表達(dá)的意思和做出的承諾是:
- 存活探針: 我不行了，多試幾次，如果還不行，就干掉我重啟試試。
- 就緒探針：我現(xiàn)在沒法對外提供服務(wù)，不要將請求轉(zhuǎn)給我?？赡苁俏乙蕾嚨姆?wù)有異常，如果依賴的服務(wù)恢復(fù)，我應(yīng)該也能恢復(fù)。
這樣看，兩個探針有著明顯的區(qū)別。而這兩個探針與應(yīng)用配合，是如何解決上一章所說的問題呢？
首先說說應(yīng)用完全hang死的情況。此時無論是存活探針還是就緒探針，都會探測異常，肯定會觸發(fā)重啟，這種情況在應(yīng)用也沒法做什么預(yù)設(shè)，是探針機(jī)制最立竿見影的一個情況。
當(dāng)應(yīng)用本身發(fā)生問題時，存活探針應(yīng)該報告異常，從而觸發(fā)重啟。此時，問題的關(guān)鍵是，應(yīng)用如何知道自己存在異常？確實(shí)挺難的，這個探針對應(yīng)的接口應(yīng)該能夠模擬正常業(yè)務(wù)的主要邏輯，而且如果依賴的服務(wù)有問題，而且應(yīng)用能夠處理這個問題，則不應(yīng)該報告異常。
當(dāng)應(yīng)用依賴的服務(wù)出現(xiàn)故障時。我們希望應(yīng)用的存活探針報告正常，而就緒探針報告報告異常。因?yàn)榇藭r存活探針報告異常觸發(fā)了應(yīng)用重啟也解決不了任務(wù)問題，大量的重啟以及相關(guān)的報錯反而會讓運(yùn)維人員感到恐慌。探針這樣工作有一個非常重要的前提條件，那就是應(yīng)用在其依賴服務(wù)恢復(fù)時也能夠自己恢復(fù)。如果應(yīng)用無法自動恢復(fù)，也許我們只能選擇讓存活探針在此時報告異常，運(yùn)維需要面對反復(fù)重啟的無盡惶恐之中。
問題到了開發(fā)這里
道理都懂了，但是該如何解決呢？對運(yùn)維來說意義重大的一個功能，卻必須依靠開發(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í)際上有時這個外部系統(tǒng)的定義未必那么篤定；也可能我們的應(yīng)用無法從某個外部系統(tǒng)的故障中恢復(fù)，所以即使是外部系統(tǒng)，我們可能也會將其納入到 liveness 探針需要檢查的范疇。
而且，很有可能我們不能一次做好這個事情，需要在結(jié)合實(shí)際出現(xiàn)的問題進(jìn)行調(diào)整。如果開發(fā)沒有參與運(yùn)維，或者中間的溝通不暢，亦或者沒把這件是當(dāng)做自己的事情，這個探針的問題未必能簡單的解決。
其實(shí)群里人家問的是探針的參數(shù)問題，但其實(shí)這些參數(shù)只是控制故障能多快的暴露出來，如果應(yīng)用的探針本身就有問題，這些參數(shù)設(shè)置的再精妙都沒有意義。我覺得這是許多團(tuán)隊(duì)的一種工作狀態(tài)：我們部門自己能搞定的盡量不要依賴別的團(tuán)隊(duì)。例如，要是我能找到一個可觀測工具，直接給我定位哪個pod出問題，那我還找什么開發(fā)。
實(shí)際上呢？太難了，做這樣包治百病的工具太難了。不過，根據(jù)許多人的選擇，我們知道這可能比讓 Dev 和 Ops 高效的配合起來更簡單，至少沒那么絕望吧。
謹(jǐn)以本文給大家一個例子，希望大家能夠互相體諒，保持一點(diǎn) DevOps 的精神，高層領(lǐng)導(dǎo)也能意識到這個問題，看看怎么解決。再就是看看平臺工程，是不是可以建設(shè)一個好的平臺，讓開發(fā)能夠更輕松的直面這個問題，畢竟自己寫的程序最了解。
參考
- [1] 鏈?zhǔn)椒磻?yīng)和級聯(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/
分享題目：從Kubernetes的探針到DevOps
本文鏈接：http://m.fisionsoft.com.cn/article/dhsdcsd.html
