1. 荒腔走板
最近一兩個月生產(chǎn)K8s集群頻繁出現(xiàn)短時503 Service Temporarily Unavailable,還不能主動復現(xiàn),相當郁悶,壓力山大。
HTTP 5xx響應狀態(tài)碼用于定義服務端錯誤。
500 Internal Server Error:所請求的服務器遇到意外的情況并阻止其執(zhí)行請求,通常針對單個請求,整個站點有時還是提供服務。 502 Bad Gateway Error 暗示連接鏈路中某個服務器下線或者不可用; 503 Service Unavailable 意味著托管您的應用程序的實際Web服務器上存在問題。
2. 排查記錄
基本上每隔2-3天出現(xiàn)一次,每次2-3分鐘,此時整站503; 因為不能主動復現(xiàn),8月26日排查相應時間段的EFK日志: impala連接問題,大數(shù)據(jù)運維同事排查到webapp發(fā)起impala的請求與impala集群時鐘未對齊,導致webapp impalaODBC Driver連不上impala集群;
進入k8s集群節(jié)點,確實部分節(jié)點的時鐘對齊服務未啟動,不定時出現(xiàn)比北京時間慢2,3分鐘的情況,這個確實可以解釋時間差導致的impala連接認證失敗。
8月26日同步所有k8s節(jié)點的時鐘,之后接近一周,并未出現(xiàn)問題; 9月3日又出現(xiàn)一次短時503無服務,EFK日志顯示依舊是impala連接問題,此處大數(shù)據(jù)同事未能定位具體原因,暫時定義為偶發(fā)/抖動?
3.思考和推演
故障現(xiàn)場每次只有impala連接問題,我也搞不懂impala連接問題竟然會導致webapp service下線。
我們的webapp兼具toB和toC業(yè)務,站點強依賴mongodb、弱依賴于impala:impala即使連不上,只是不能查,站點sso+訂單相關的寫入操作應該還可用。
回想起前幾天看到的k8s探針,糟糕,我們的就緒探針好像探測了impala
//ASP.NetCore上暴露的的探測邏輯:impala&&mongodbservices.AddHealthChecks().AddCheck(nameof(ImpalaHealthCheck),tags:new[]{readyz}).AddCheck(nameof(MongoHealthCheck),tags:new[]{readyz});app.UseHealthChecks(/readyz,newHealthCheckOptions{Predicate=(check)=>check.Tags.Contains(readyz)});
強烈推測:就緒探針3次探測impala失敗, Pod將會被標記為Unready, 該Pod將從webapp服務負載均衡器移除, 不再分配流量,導致nginx無實際意義的后端服務,站點503。
迅速找一個beta環(huán)境,斷開impala連接,驗證猜想。
4.問題回顧
bugfix不是我正向推斷出來的,而是純靠經(jīng)驗推演出來的,倒不是有明確推斷思路,也算給大家提前踩坑了。
docker的健康檢查只能探測,Kubernetes存活、就緒探針不僅有探測,還有決策能力。
這里我們的k8s就緒探測使用策略出現(xiàn)了問題:
探測到webapp弱依賴impala有問題,就下線了整個webapp服務,應該只探測強依賴,強依賴有問題,才表明容器未就緒,這也是就緒探針的初衷。
網(wǎng)頁題目:Kubernetes探針踩坑記
網(wǎng)頁地址:http://www.rwnh.cn/article34/cggppe.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供品牌網(wǎng)站建設、用戶體驗、微信小程序、網(wǎng)站內(nèi)鏈、手機網(wǎng)站建設、Google
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)