Kubernetes 故障排除三板斧：理解、管理和預(yù)防
Kubernetes 生態(tài)系統(tǒng)充斥著各種工具，例如監(jiān)控、可觀察性、跟蹤、日志記錄等，但一般很難真正理解故障排除與這些工具有何聯(lián)系。
當(dāng)故障發(fā)生時(shí)，我們要掌握是從哪里發(fā)生，了解所面臨的問題，解決眼前的問題，然后修復(fù)根本原因。隨著系統(tǒng)規(guī)模的擴(kuò)大，這一切會(huì)變得越來越復(fù)雜。
一名從事現(xiàn)代、復(fù)雜、分布式系統(tǒng)工作的軟件工程師，會(huì)經(jīng)常發(fā)現(xiàn)，每次出現(xiàn)問題或故障時(shí)，都需要了解引發(fā)問題的原因以及是誰造成的，但是，這并不是一件容易的事。更難的，是弄清楚幕后發(fā)生了什么，以及如何防止它再次發(fā)生。一般，我們會(huì)這樣思考：
究竟發(fā)生了什么？ 哪些事情是相關(guān)的？ 什么與我們?cè)噲D排除故障的特定癥狀相關(guān)？ 我們?nèi)绾未_定根本原因？ 最終，我們還要確保將來不再發(fā)生此問題或類似問題？
本文中，我們將之簡(jiǎn)化為3個(gè)步驟：
理解 管理 預(yù)防
我將深入探討如何實(shí)施好這三個(gè)步，以及它們?nèi)绾螏椭覀儗?duì) Kubernetes 進(jìn)行故障排除。我還將回顧哪些生態(tài)系統(tǒng)工具適合哪個(gè)步，以更好地掌握或使用那些工具。
1第一步：理解
毫不奇怪，這是重要的一步。理解系統(tǒng)資源，通常使你能夠了解發(fā)生了什么、出了什么問題以及我們接下來應(yīng)該做什么。
為了嘗試了解故障原因，開發(fā)人員將首先分析系統(tǒng)最近的修改以及可能導(dǎo)致此故障發(fā)生的更改。當(dāng)然，這說起來容易做起來難。在復(fù)雜的分布式系統(tǒng)，尤其是基于 Kubernetes 的系統(tǒng)中，這意味著大量使用 kubectl 來對(duì)部署日志、跟蹤和指標(biāo)進(jìn)行故障排除，驗(yàn)證 pod 健康狀況和資源上限，以及服務(wù)連接，以及其他常見的 pod 錯(cuò)誤，檢查 YAML 配置文件，驗(yàn)證第三方工具和集成等等。這可能是一行代碼、一行配置的更改，觸發(fā)了故障。
下圖一張圖，可以幫助我們?cè)谂懦?K8s 系統(tǒng)進(jìn)行故障時(shí)，縮小問題的范圍。
圖片來源??：?有關(guān) Kubernetes 部署故障排除的指南[1]
網(wǎng)上的也有一份國人中文版的 Kubernetes 故障排除指南，供參考
可在?公眾號(hào)?內(nèi)回復(fù)『Kubernetes故障排除』獲取高清原圖
接下來，我們將查看事件：系統(tǒng)中實(shí)際發(fā)生了什么 – 系統(tǒng)是否過載？是否丟失了數(shù)據(jù)？是否存在服務(wù)中斷？這與系統(tǒng)的初始變化有何關(guān)系？
然后，我們查看一下我們創(chuàng)建的指標(biāo)、儀表板和數(shù)據(jù)，以基于數(shù)據(jù)源對(duì)問題進(jìn)行某種理解。是否不止一個(gè)系統(tǒng)表現(xiàn)相同？影響兩個(gè)系統(tǒng)的服務(wù)之一是否存在依賴性？最后，我們能否從看似相似的先前事件中學(xué)到一些東西，讓我們對(duì)我們現(xiàn)在正在經(jīng)歷的事情有所了解？
僅就某些情況而言，下面是你需要使用的一些工具的列表，以便對(duì)系統(tǒng)中發(fā)生的事情有一個(gè)基本的了解。
監(jiān)控工具：Datadog、Dynatrace、Grafana Labs、New Relic
可觀察性工具：Lightstep、Honeycomb
實(shí)時(shí)調(diào)試工具：OzCode、Rookout
日志工具：Splunk、LogDNA、Logz.io
2第二步：管理
在當(dāng)今的微服務(wù)架構(gòu)中，很多時(shí)候相互依賴的服務(wù)由不同的團(tuán)隊(duì)管理。發(fā)生故障時(shí)，解決問題的關(guān)鍵之一是團(tuán)隊(duì)之間的溝通與協(xié)作。
根據(jù)潛在問題的類型，你可能想要采取的操作，包括像重啟系統(tǒng)這樣簡(jiǎn)單的操作，或者更’嚴(yán)厲’的措施，例如版本回滾或恢復(fù)最近的配置，直到更清楚地了解潛在問題。最終，你可能需要采取主動(dòng)措施，如增加內(nèi)存上限或機(jī)器數(shù)量的形式增加容量。但是，所有這些都不應(yīng)該是你實(shí)時(shí)嘗試和弄清楚的。今天有很多工具，從 Jenkins 到 ArgoCD，云提供商的專有工具，甚至更多的 kubectl 來采取這些行動(dòng)和措施。
一旦更好地理解了潛在問題，補(bǔ)救就不應(yīng)該是主要是反復(fù)試驗(yàn)的臨時(shí)操作，或者存在于當(dāng)前團(tuán)隊(duì)和實(shí)踐中的記錄。根據(jù)公司的技術(shù)堆棧和可能的根本原因，應(yīng)使用定制的運(yùn)行手冊(cè)來管理任何給定的事件，并針對(duì)每種警報(bào)提供具體的任務(wù)和操作。
團(tuán)隊(duì)中的每一位工程師，無論是高級(jí)還是初級(jí)，都可以利用這一份友好的運(yùn)行手冊(cè)來實(shí)時(shí)排除故障。
此階段的工具包將包括以下一些內(nèi)容：
事件管理：PagerDuty，Kintaba
項(xiàng)目管理：Jira、Monday、Trello
CI/CD 管理：ArgoCD、Jenkins
3最后一個(gè)步：預(yù)防
預(yù)防可能是最重要的步，以確保類似事件不再發(fā)生。防止類似問題的方法是根據(jù)每個(gè)事件創(chuàng)建定義明確的策略和規(guī)則。在“理解”階段要采取哪些行動(dòng)，我們?nèi)绾巫羁焖俚刈R(shí)別問題并將問題上報(bào)給相關(guān)團(tuán)隊(duì)？
我們?nèi)绾挝韶?zé)任，確保團(tuán)隊(duì)之間無摩擦的溝通和協(xié)作？這包括手頭任務(wù)和操作的完全透明度，以及進(jìn)度的實(shí)時(shí)更新。每種警報(bào)和事件的任務(wù)的規(guī)范順序是什么？
一旦我們弄清楚了上述所有內(nèi)容，我們就可以開始考慮如何自動(dòng)化和協(xié)調(diào)這些事件，并盡可能接近傳說中的“自我修復(fù)”系統(tǒng)。
這一步的特點(diǎn)是通過不斷將系統(tǒng)推向極限，從而創(chuàng)建更具彈性和適應(yīng)變化的系統(tǒng)的工具。例如：
Chaos Engineering:?Gremlin、Chaos Monkey、ChaosIQ
Auto Remediation：Shoreline、OpsGenie
4一步都不能少
我們相信，通過以上三步的結(jié)合，可以將故障排除與監(jiān)控、可觀察性、跟蹤等區(qū)別開來。然而，可能最重要的是深入到系統(tǒng)和流程中，以防止它們?cè)俅伟l(fā)生。
我們都見過這個(gè)表情包：
或者這個(gè)：
它們?nèi)匀槐粡V泛使用并如此受歡迎的原因是，即使我們?cè)凇癉evOps 工具”方面取得了巨大進(jìn)步后，對(duì)于實(shí)時(shí)的問題或故障，很多時(shí)候依然捉襟見肘。
因此，我建議將應(yīng)用程序和運(yùn)維數(shù)據(jù)集中到一個(gè)平臺(tái)中，使團(tuán)隊(duì)成員能夠真正了解他們的系統(tǒng)，并最終了解對(duì)復(fù)雜系統(tǒng)出現(xiàn)的警報(bào)如何采取行動(dòng)。當(dāng)我們將最好的開發(fā)人員和運(yùn)維人員結(jié)合在一起時(shí)，我們可以通過更好地合作來更快地解決故障。
譯文鏈接??:?https://dzone.com/articles/the-three-pillars-of-kubernetes-troubleshooting[2]
原文鏈接??:?https://www.kubernetes.org.cn/9578.html
參考資料
Kubernetes部署故障排除指南:?https://learnk8s.io/troubleshooting-deployments
[2]譯文鏈接??:?https://dzone.com/articles/the-three-pillars-of-kubernetes-troubleshooting
本文轉(zhuǎn)載自：「云原生生態(tài)圈」，原文：https://tinyurl.com/4t62bkb4，版權(quán)歸原作者所有。
有收獲，點(diǎn)個(gè)在看?
