最近一兩個月生産k8s叢集頻繁出現短時503 service temporarily unavailable，還不能主動複現，相當郁悶，壓力山大。
http 5xx響應狀态碼用于定義服務端錯誤。 500 internal server error：所請求的伺服器遇到意外的情況并阻止其執行請求，通常針對單個請求，整個站點有時還是提供服務。 502 bad gateway error 暗示連接配接鍊路中某個伺服器下線或者不可用； 503 service unavailable 意味着托管您的應用程式的實際web伺服器上存在問題。
基本上每隔2-3天出現一次，每次2-3分鐘，此時整站503；
因為不能主動複現，8月26日排查相應時間段的efk日志: <code>impala連接配接問題</code>，大資料運維同僚排查到webapp發起impala的請求與impala叢集時鐘未對齊，導緻webapp impalaodbc driver連不上impala叢集；
進入k8s叢集節點，确實部分節點的時鐘對齊服務未啟動，不定時出現比中原標準時間慢2,3分鐘的情況，這個确實可以解釋時間差導緻的impala連接配接認證失敗。
8月26日同步所有k8s節點的時鐘，之後接近一周，并未出現問題；
9月3日又出現一次短時503無服務，efk日志顯示依舊是<code>impala連接配接問題</code>，此處大資料同僚未能定位具體原因，暫時定義為偶發/抖動？
故障現場每次隻有impala連接配接問題，我也搞不懂impala連接配接問題竟然會導緻webapp service下線。
我們的webapp兼具tob和toc業務，站點強依賴mongodb、弱依賴于impala：impala即使連不上，隻是不能查，站點sso+訂單相關的寫入操作應該還可用。
回想起前幾天看到的k8s探針，糟糕，我們的就緒探針好像探測了impala
強烈推測:就緒探針3次探測impala失敗, pod将會被标記為unready, 該pod将從webapp服務負載均衡器移除, 不再配置設定流量，導緻nginx無實際意義的後端服務，站點503。
迅速找一個beta環境，斷開impala連接配接，驗證猜想。
bugfix不是我正向推斷出來的，而是純靠經驗推演出來的，倒不是有明确推斷思路，也算給大家提前踩坑了。
docker的健康檢查隻能探測，kubernetes存活、就緒探針不僅有探測，還有決策能力。
這裡我們的k8s就緒探測使用政策出現了問題：
探測到webapp弱依賴impala有問題，就下線了整個webapp服務，應該隻探測強依賴，強依賴有問題，才表明容器未就緒，這也是就緒探針的初衷。
強烈建議根據webapp結構合理設定探針和探針參數，避免不切實際的健康檢查失敗導緻的頻繁重新開機或服務下線。
硬核技能k8s初體驗
docker-healthcheck指令探測asp.net core容器健康狀态
kubernetes liveness and readiness probes