Kubernetes探針踩坑記

作者：小碼甲 2020-09-15 08:46:26

云計(jì)算 最近一兩個(gè)月生產(chǎn)K8s集群頻繁出現(xiàn)短時(shí)503 Service Temporarily Unavailable，還不能主動(dòng)復(fù)現(xiàn)，相當(dāng)郁悶，壓力山大。

讓客戶(hù)滿(mǎn)意是我們工作的目標(biāo)，不斷超越客戶(hù)的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶(hù)，將通過(guò)不懈努力成為客戶(hù)在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名申請(qǐng)、網(wǎng)頁(yè)空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、平輿網(wǎng)站維護(hù)、網(wǎng)站推廣。

本文轉(zhuǎn)載自微信公眾號(hào)「Dotnet Plus」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Dotnet Plus公眾號(hào)。

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ù)器下線(xiàn)或者不可用;
• 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下線(xiàn)。

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

回想起前幾天看到的k8s探針，糟糕，我們的就緒探針好像探測(cè)了impala

  
 
 
 

   
  
  
  
// ASP.NetCore上暴露的的探測(cè)邏輯：impala && mongodb 
   
  
  
  
services.AddHealthChecks() 
   
  
  
  
       .AddCheck(nameof(ImpalaHealthCheck), tags: new[] { "readyz" }) 
   
  
  
  
       .AddCheck(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弱依賴(lài)impala有問(wèn)題，就下線(xiàn)了整個(gè)webapp服務(wù)，應(yīng)該只探測(cè)強(qiáng)依賴(lài)，強(qiáng)依賴(lài)有問(wèn)題，才表明容器未就緒，這也是就緒探針的初衷。

當(dāng)前名稱(chēng)：Kubernetes探針踩坑記
路徑分享：http://uogjgqi.cn/article/dpcpses.html