五分钟 k8s 实战-应用探针
今天進(jìn)入 kubernetes 的運(yùn)維部分(并不是運(yùn)維 kubernetes,而是運(yùn)維應(yīng)用),其實(shí)日常我們大部分使用 kubernetes 的功能就是以往運(yùn)維的工作,現(xiàn)在云原生將運(yùn)維和研發(fā)關(guān)系變得更緊密了。
今天主要講解 Probe 探針相關(guān)的功能,探針最實(shí)用的功能就是可以控制應(yīng)用優(yōu)雅上線。
就緒探針
舉個(gè)例子,當(dāng)我們的 service 關(guān)聯(lián)了多個(gè) Pod 的時(shí)候,其中一個(gè) Pod 正在重啟但還沒達(dá)到可以對外提供服務(wù)的狀態(tài),這時(shí)候如果有流量進(jìn)入。
那這個(gè)請求肯定就會出現(xiàn)異常,從而導(dǎo)致問題,所以我們需要一個(gè)和 kubernetes 溝通的渠道,告訴它什么時(shí)候可以將流量放進(jìn)來。
比如如圖所示的情況,紅色 Pod 在未就緒的時(shí)候就不會有流量。
使用就緒探針就可以達(dá)到類似的效果:
livenessProbe:
failureThreshold: 3
httpGet:
path: /ping
port: 8081
scheme: HTTP
periodSeconds: 3
successThreshold: 1
timeoutSeconds: 1
這個(gè)配置也很直接:
- 配置一個(gè) HTTP 的 ping 接口
- 每三秒檢測一次
- 失敗 3 次則認(rèn)為檢測失敗
- 成功一次就認(rèn)為檢測成功
但沒有配置就緒探針時(shí),一旦 Pod 的
Endpoint加入到 service 中(Pod 進(jìn)入Running狀態(tài)),請求就有可能被轉(zhuǎn)發(fā)過來,所以配置就緒探針是非常有必要的。
啟動探針
而啟動探針往往是和就緒探針搭配干活的,如果我們一個(gè) Pod 啟動時(shí)間過長,比如超過上面配置的失敗檢測次數(shù),此時(shí) Pod 就會被 kubernetes 重啟,這樣可能會進(jìn)入無限重啟的循環(huán)。
所以啟動探針可以先檢測一次是否已經(jīng)啟動,直到啟動成功后才會做后續(xù)的檢測。
startupProbe:
failureThreshold: 30
httpGet:
path: /ping
port: 8081
scheme: HTTP
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 1
我這里兩個(gè)檢測接口是同一個(gè),具體得根據(jù)自己是實(shí)際業(yè)務(wù)進(jìn)行配置;
比如應(yīng)用端口啟動之后并不代表業(yè)務(wù)已經(jīng)就緒了,可能某些基礎(chǔ)數(shù)據(jù)還沒加載到內(nèi)存中,這個(gè)時(shí)候就需要自己寫其他的接口來配置就緒探針了。
所有關(guān)于探針相關(guān)的日志都可以在 Pod 的事件中查看,比如如果一個(gè)應(yīng)用在啟動的過程中頻繁重啟,那就可以看看是不是某個(gè)探針檢測失敗了。
存活探針
存活探針往往是用于保證應(yīng)用高可用的,雖然 kubernetes 可以在 Pod 退出后自動重啟,比如 Pod OOM;但應(yīng)用假死他是檢測不出來的。
為了保證這種情況下 Pod 也能被自動重啟,就可以配合存活探針使用:
livenessProbe:
failureThreshold: 3
httpGet:
path: /ping
port: 8081
scheme: HTTP
periodSeconds: 3
successThreshold: 1
timeoutSeconds: 1
一旦接口響應(yīng)失敗,kubernetes 就會嘗試重啟。
總結(jié)
以上探針配置最好是可以在研效平臺可視化配置,這樣維護(hù)起來也比較簡單。
探針是維護(hù)應(yīng)用健康的必要手段,強(qiáng)烈推薦大家都進(jìn)行配置。
本文的所有源碼在這里可以訪問:
https://github.com/crossoverJie/k8s-combat
總結(jié)
以上是生活随笔為你收集整理的五分钟 k8s 实战-应用探针的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 强化学习(四) - 蒙特卡洛方法(Mon
- 下一篇: Flask Session 登录认证模块