Kubernetes探针踩坑记
1. 荒腔走板
最近一兩個(gè)月生產(chǎn)K8s集群頻繁出現(xiàn)短時(shí)503 Service Temporarily Unavailable,還不能主動(dòng)復(fù)現(xiàn),相當(dāng)郁悶,壓力山大。
HTTP 5xx響應(yīng)狀態(tài)碼用于定義服務(wù)端錯(cuò)誤。
500 Internal Server Error:所請(qǐng)求的服務(wù)器遇到意外的情況并阻止其執(zhí)行請(qǐng)求,通常針對(duì)單個(gè)請(qǐng)求,整個(gè)站點(diǎn)有時(shí)還是提供服務(wù)。
502 Bad Gateway Error 暗示連接鏈路中某個(gè)服務(wù)器下線或者不可用;
503 Service ?Unavailable 意味著托管您的應(yīng)用程序的實(shí)際Web服務(wù)器上存在問(wèn)題。
2. 排查記錄
基本上每隔2-3天出現(xiàn)一次,每次2-3分鐘,此時(shí)整站503;
因?yàn)椴荒苤鲃?dòng)復(fù)現(xiàn),8月26日排查相應(yīng)時(shí)間段的EFK日志: impala連接問(wèn)題,大數(shù)據(jù)運(yùn)維同事排查到webapp發(fā)起impala的請(qǐng)求與impala集群時(shí)鐘未對(duì)齊,導(dǎo)致webapp impalaODBC Driver連不上impala集群;
進(jìn)入k8s集群節(jié)點(diǎn),確實(shí)部分節(jié)點(diǎn)的時(shí)鐘對(duì)齊服務(wù)未啟動(dòng),不定時(shí)出現(xiàn)比北京時(shí)間慢2,3分鐘的情況,這個(gè)確實(shí)可以解釋時(shí)間差導(dǎo)致的impala連接認(rèn)證失敗。
8月26日同步所有k8s節(jié)點(diǎn)的時(shí)鐘,之后接近一周,并未出現(xiàn)問(wèn)題;
9月3日又出現(xiàn)一次短時(shí)503無(wú)服務(wù),EFK日志顯示依舊是impala連接問(wèn)題,此處大數(shù)據(jù)同事未能定位具體原因,暫時(shí)定義為偶發(fā)/抖動(dòng)?
3.思考和推演
故障現(xiàn)場(chǎng)每次只有impala連接問(wèn)題,我也搞不懂impala連接問(wèn)題竟然會(huì)導(dǎo)致webapp service下線。
我們的webapp兼具toB和toC業(yè)務(wù),站點(diǎn)強(qiáng)依賴mongodb、弱依賴于impala:impala即使連不上,只是不能查,站點(diǎn)sso+訂單相關(guān)的寫(xiě)入操作應(yīng)該還可用。
回想起前幾天看到的k8s探針,糟糕,我們的就緒探針好像探測(cè)了impala
// ASP.NetCore上暴露的的探測(cè)邏輯:impala && mongodb services.AddHealthChecks().AddCheck<ImpalaHealthCheck>(nameof(ImpalaHealthCheck),?tags:?new[]?{?"readyz"?}).AddCheck<MongoHealthCheck>(nameof(MongoHealthCheck),?tags:?new[]?{?"readyz"?});app.UseHealthChecks("/readyz",?new?HealthCheckOptions{Predicate?=?(check)?=>?check.Tags.Contains("readyz")});強(qiáng)烈推測(cè):就緒探針3次探測(cè)impala失敗, Pod將會(huì)被標(biāo)記為Unready, 該P(yáng)od將從webapp服務(wù)負(fù)載均衡器移除, 不再分配流量,導(dǎo)致nginx無(wú)實(shí)際意義的后端服務(wù),站點(diǎn)503。
迅速找一個(gè)beta環(huán)境,斷開(kāi)impala連接,驗(yàn)證猜想。
4.問(wèn)題回顧
bugfix不是我正向推斷出來(lái)的,而是純靠經(jīng)驗(yàn)推演出來(lái)的,倒不是有明確推斷思路,也算給大家提前踩坑了。
docker的健康檢查只能探測(cè),Kubernetes存活、就緒探針不僅有探測(cè),還有決策能力。
這里我們的k8s就緒探測(cè)使用策略出現(xiàn)了問(wèn)題:
探測(cè)到webapp弱依賴impala有問(wèn)題,就下線了整個(gè)webapp服務(wù),應(yīng)該只探測(cè)強(qiáng)依賴,強(qiáng)依賴有問(wèn)題,才表明容器未就緒,這也是就緒探針的初衷。
強(qiáng)烈建議根據(jù)webapp結(jié)構(gòu)合理設(shè)置探針和探針參數(shù),避免不切實(shí)際的健康檢查失敗導(dǎo)致的頻繁重啟或服務(wù)下線。
干貨周邊也很重要
?硬核技能k8s初體驗(yàn)
?Docker-HealthCheck指令探測(cè)ASP.NET Core容器健康狀態(tài)
?Kubernetes Liveness and Readiness Probes
總結(jié)
以上是生活随笔為你收集整理的Kubernetes探针踩坑记的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 2招解决并发问题,省几百万设备费用!说穿
- 下一篇: DDD:架构思想的旧瓶新酒?阿里等大厂却