溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Kubernetes踩坑舉例分析

發(fā)布時間:2021-12-14 14:12:16 來源:億速云 閱讀:233 作者:iii 欄目:大數(shù)據(jù)

這篇文章主要介紹“Kubernetes踩坑舉例分析”,在日常操作中,相信很多人在Kubernetes踩坑舉例分析問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”Kubernetes踩坑舉例分析”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!

1. 荒腔走板

最近一兩個月生產(chǎn)K8s集群頻繁出現(xiàn)短時503 Service Temporarily Unavailable,還不能主動復(fù)現(xiàn),相當(dāng)郁悶,壓力山大。Kubernetes踩坑舉例分析

HTTP 5xx響應(yīng)狀態(tài)碼用于定義服務(wù)端錯誤。

  • 500 Internal Server Error:所請求的服務(wù)器遇到意外的情況并阻止其執(zhí)行請求,通常針對單個請求,整個站點(diǎn)有時還是提供服務(wù)。
  • 502 Bad Gateway Error 暗示      連接鏈路中某個服務(wù)器下線或者不可用;
  • 503 Service  Unavailable 意味著托管您的應(yīng)用程序的實(shí)際Web服務(wù)器上存在問題。
 

2. 排查記錄

Kubernetes踩坑舉例分析  
  • 基本上每隔2-3天出現(xiàn)一次,每次2-3分鐘,此時整站503;
  • 因?yàn)椴荒苤鲃訌?fù)現(xiàn),8月26日排查相應(yīng)時間段的EFK日志:     impala連接問題,大數(shù)據(jù)運(yùn)維同事排查到     webapp發(fā)起impala的請求與impala集群時鐘未對齊,導(dǎo)致webapp impalaODBC Driver連不上impala集群;

進(jìn)入k8s集群節(jié)點(diǎn),確實(shí)部分節(jié)點(diǎn)的時鐘對齊服務(wù)未啟動,不定時出現(xiàn)比北京時間慢2,3分鐘的情況,這個確實(shí)可以解釋時間差導(dǎo)致的impala連接認(rèn)證失敗。

  • 8月26日同步所有k8s節(jié)點(diǎn)的時鐘,之后接近一周,并未出現(xiàn)問題;
  • 9月3日又出現(xiàn)一次短時503無服務(wù),EFK日志顯示依舊是     impala連接問題,此處大數(shù)據(jù)同事未能定位具體原因,暫時定義為     偶發(fā)/抖動?     Kubernetes踩坑舉例分析
 

3.思考和推演

故障現(xiàn)場每次只有impala連接問題,我也搞不懂impala連接問題竟然會導(dǎo)致webapp service下線。

我們的webapp兼具toB和toC業(yè)務(wù),站點(diǎn)強(qiáng)依賴mongodb、弱依賴于impala:impala即使連不上,只是不能查,站點(diǎn)sso+訂單相關(guān)的寫入操作應(yīng)該還可用。

回想起前幾天看到的k8s探針,糟糕,我們的就緒探針好像探測了impala

// ASP.NetCore上暴露的的探測邏輯: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)烈推測:就緒探針3次探測impala失敗, Pod將會被標(biāo)記為Unready, 該P(yáng)od將從webapp服務(wù)負(fù)載均衡器移除, 不再分配流量,導(dǎo)致nginx無實(shí)際意義的后端服務(wù),站點(diǎn)503。

迅速找一個beta環(huán)境,斷開impala連接,驗(yàn)證猜想。

Kubernetes踩坑舉例分析  
 

4.問題回顧

bugfix不是我正向推斷出來的,而是純靠經(jīng)驗(yàn)推演出來的,倒不是有明確推斷思路,也算給大家提前踩坑了。

docker的健康檢查只能探測,Kubernetes存活、就緒探針不僅有探測,還有決策能力。

這里我們的k8s就緒探測使用策略出現(xiàn)了問題:
探測到webapp弱依賴impala有問題,就下線了整個webapp服務(wù),應(yīng)該只探測強(qiáng)依賴,強(qiáng)依賴有問題,才表明容器未就緒,這也是就緒探針的初衷。

強(qiáng)烈建議根據(jù)webapp結(jié)構(gòu)合理設(shè)置探針和探針參數(shù),避免不切實(shí)際的健康檢查失敗導(dǎo)致的頻繁重啟或服務(wù)下線。

到此,關(guān)于“Kubernetes踩坑舉例分析”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注億速云網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章!

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI