執行 Kubernetes 叢集故障分析案例!

語言: CN / TW / HK

最近看到了一份收集Kubernetes故障案例的資料,資料由ZalandoTech的高階首席工程師Henning Jacobs加以維護。這個由社群驅動的專案全面介紹了Kubernetes反模式以及為何導致Kubernetes執行錯誤的原因。

k8s.af上的案例由工程師和實施者編寫,描述了許多糟糕的經歷:比如 導致高延遲的CPU限制、阻止自動擴充套件的IP上限、應用程式日誌丟失、pod被終止、502 錯誤、部署緩慢和生產環境故障等。

願通過分析這些失敗案例,大家可以學會如何更好地配置和改進K8s環境。

01

CPU限制導致高延遲

設定CPU限制是把雙刃劍。您不想浪費計算資源,然而設定人為限制又可能導致容器耗盡所有可用的CPU。這可能會導致一連串連鎖反應事件,從而導致效能停滯、其他元件停運。

為了遏制容器,Kubernetes使用完全公平的排程程式配額(CFS Quota),以防止超出CPU限制。遺憾的是,Kubernetes中過於嚴格的遏制會導致效能問題。

Buffer的故事就是一個例子。在人為遏制導致效能不佳後,基礎架構團隊最終決定為面向使用者的例項 取消CPU限制和遏制 針對每個節點分配合適的CPU ,留出>20%的餘量。這麼一來,該團隊將所有容器的容器延遲至少縮短了一半。至於主登入頁面,最終結果是快了22倍。

Buffer基礎架構工程師Eric Khun寫道:“我們在改用微服務架構的過程中不斷反覆試驗。即使在執行k8s幾年後,我們仍在學習其奧祕。”

應謹慎對待取消CPU限制。 相反,Khun建議“升級核心版本,而不是消除CPU限制。如果您的目標是力求低延遲,應取消CPU限制,但在這麼做時要非常小心。”他建議設定適當的CPU請求,並使用Datadog之類的解決方案,新增監控機制。

02

應用程式日誌丟失

日誌記錄對於診斷錯誤和修復問題至關重要。 但是如果您的應用程式未生成日誌,會發生什麼?

PrometheusKube講述了一個奇怪的故障案例——有一天,某個節點莫名其妙地停止傳送日誌。工作團隊使用fluent-bit來發送日誌,注意到Elasticsearch未滿足某些請求。

團隊在開啟除錯日誌功能後決定部署Fluentd,隨後慢慢部署Fluentd,逐個節點地替換fluent-bit。團隊稱:“Kubernetes讓您可以快速迭代部署新軟體,這點很出色。”在編輯另一個配置後,他們終於能夠準確無誤地傳送日誌了。

PrometheusKube建議基於流量進行監控,並使用黑盒監控方法來發現類似的情況。

03

自動擴充套件因IP上限而受阻

雲原生架構的優點在於能夠快速高效地擴充套件。彈性計算模式可幫助應用程式自動響應新需求。然而,如果計算環境無法建立新的IP地址,就無法進行自動擴充套件。

Love Holidays的DevOps負責人Dmitri Lerko在個人部落格中描述了這種情形。有人反映部署緩慢後, L ove Holidays團隊立即瞭解問題。後來發現,通常需要幾分鐘來部署的應用程式卻需要幾小時。叢集中的一半pod像往常一樣順暢執行,而另一半陷入掛起狀態。它們是如何用完IP地址的?

結果查明,預設情況下,谷歌Kubernetes引擎(GKE)使用的IP地址比預期的要多得多。Lerko說:“GKE為每個節點分配256個IP地址,這意味著如果執行256個節點,就連像/16這樣的大型子網也會很快耗盡地址資源。”為了避免類似問題,Lerko建議減少每個節點的最大Pod數量,並考慮使用子網擴充套件以擴大可用IP的範圍,或增加現有節點的大小。

04

負載均衡系統配置錯誤導致完全中斷

生產環境中斷、停運、甚至生產環境部分中斷都會大大影響使用者體驗,並抑制業務增長。為DevOps Hof撰稿的Marcel Juhnke描述了在GKE中將工作負載從一個節點池遷移到另一個節點池時,錯誤配置如何導致某個叢集中的入站(ingress)完全中斷。解決這種情況只需刪除舊的nginx-ingress-controller pod。不過Juhnke說:“在進行可能影響任何流量的變更之前,務必要仔細檢視文件。”

05

Kubernetes開發叢集上驚現加密貨幣挖礦軟體

隨著加密貨幣價值越來越高,黑客們伺機尋找易受攻擊的計算能力,以竊取加密貨幣。JW Player DevOps團隊的Brian Choy寫道,JW Player就遇到了這檔事。

在收到負載增加的大量自動警報後,DevOps團隊深入挖掘,結果發現了一個程序在CPU利用率100%的狀態下執行, 這非常可疑。簡而言之,黑客利用了Kubernetes監控工具Weave Scope存在的漏洞,該漏洞暴露了面向公眾的負載均衡系統安全組和儀表板。利用該資訊,黑客進而訪問了JW Player的Kubernetes節點上的根目錄。

雖然這次洩密事件沒有影響任何生產服務,但確實浪費了計算能力;至少可以說,這令人震驚。團隊立即刪除了部署的Weave Scope,進行更新,並改進RBAC許可權以限制Weave Scope的訪問,最終解決了問題。

該團隊還在考慮採用更深入的監控,用於行為分析、異常及入侵檢測。Choy稱,他們還在研究服務網格方案,比如Linkerd和Istio,以保護端到端流量。

參考:https://www.kubernetes.org.cn/9795.html

推薦閱讀 點選標題可跳轉

《Docker是什麼?》

《Kubernetes是什麼?》

《Kubernetes和Docker到底有啥關係?》

《教你如何快捷的查詢選擇網路倉庫映象tag》

《Docker映象進階:瞭解其背後的技術原理》

《教你如何修改執行中的容器埠對映》

《k8s學習筆記:介紹&上手》

《k8s學習筆記:縮擴容&更新》

《Docker 基礎用法和命令幫助》

《在K8S上搭建Redis叢集》

《灰度部署、滾動部署、藍綠部署》

《PM2實踐指南》

《Docker垃圾清理》

《Kubernetes(k8s)底層網路原理刨析》

《容器環境下Node.js的記憶體管理》

《MySQL 快速建立千萬級測試資料》

《Linux 與 Unix 到底有什麼不同?》

《淺談幾種常見 RAID 的異同》

《Git 筆記-程式設計師都要掌握的 Git》

《老司機必須懂的MySQL規範》

《Docker中Image、Container與Volume的遷移》

《漫畫|如何用Kubernetes搞定CICD》

《寫給前端的Docker實戰教程》

《Linux 作業系統知識地圖2.0,我看行》

《16個概念帶你入門 Kubernetes》

《程式設計師因接外包坐牢456天,長文敘述心酸真實經歷》

《IT 行業老鳥,有話對你說》

《HTTPS 為什麼是安全的? 說一下他的底層實現原理?

免責宣告:本文內容來源於網路,所載內容僅供參考。轉載僅為學習和交流之目的,如無意中侵犯您的合法權益,請及時聯絡Docker中文社群!