我從來都不是一個大賭徒。過去我可能會下一個小賭注來為超級盃增添趣味，但我並沒有那麼投入，但這並不是什麼瘋狂的事情。真正投入資金需要一定程度的確定性，而我在任何體育賽事、選舉結果或未來預測中都很少有這種確定性。科技領域的確定性非常少。工作保障並不是既定的，產業趨勢潮起潮落，你每天使用的工具和技術堆疊很可能會隨著時間的推移而不斷發展。儘管充滿了不確定性，但還是有一些東西你可以安全地押注，但在某些時候，你會遭遇中斷。

從事任何時間的 Kubernetes 工程師都可以證明這個現實。在這種情況下，害怕失敗或執行艱鉅的任務來確保100% 可用性是沒有意義的，如果有任何錯誤和中斷應該被視為學習機會，這對於任何渴望成熟並提供高品質的環境來說都是必要的邪惡以可靠的方式提供服務。

有效處理和消化中斷的最佳方法是系統地進行事後分析。事實證明，這些是我們尋找模式並綜合中斷所提供的經驗教訓的最敏銳的工具。關於 Kubernetes 叢集故障中常見的模式主題，出現了一些模式。

DNS、網路和預設資源分配是一些關鍵的罪魁禍首。

在這篇文章中，我們將分析其中的一些事後分析，並盡力吸收其他人經過艱苦的努力才學到的東西。

故障嚴重程度等級

並非每次中斷都會產生相同的影響，因此我建立了一個非常科學的分類系統來了解每次 Kubernetes 中斷的影響：

🤷 - 有點糟糕：微不足道的 Kubernetes 故障

😅 - 非正式機，但仍然令人煩惱：我們沒有影響任何客戶，但我們學到了教訓

🤬 - 休士頓，我們在生產中遇到了問題：客戶受到影響，職業選擇受到質疑。

在我忘記之前，讓我感謝Glasskube讓我花時間建立這樣的內容。如果這是您第一次聽說我們，我們正在努力Package Manager for Kubernetes 。

如果您願意支持我們完成這項任務，我們將不勝感激

⭐️ GitHub 上的 Star Glasskube 🙏

有點糟糕🤷

如果你不能笑自己，你還能笑誰？

叢集和節點群組

第一個故事來自您謙虛的記者，他最近使用 AWS 控制台啟動了一個測試 Kubernetes 集群，以快速驗證概念。我已經有一段時間沒有使用 EKSCTL 或某種形式的基礎設施即程式碼定義檔來建立叢集了。

因此，我登入並存取 EKS 控制台，命名我的 Kubernetes 集群，然後點擊「建立」。然後，我按照 CLI 說明配置 kubeconfig 檔案並透過終端連接到我新建立的叢集。

由於渴望測試最新版本的 Glasskube，我將其安裝在叢集中。然而，令我驚訝的是 Pod 的安排時間如此之長。現在回想起來，我很尷尬地承認我花了多長時間才意識到我沒有配置節點組，難怪 Pod 沒有被調度。

打電話給消防隊，我忘了加入資源限制。

另一個真實的故事來自另一位Glasskube 成員，由於在本地Minikube 集群中安裝了許多元件（GitLab），他的本地筆記型電腦超載了，筆記型電腦幾乎在他的辦公桌上燒了一個洞，這是一個很好的提醒，要使用資源限制和請求

非正式機，但仍然很煩人😅

轉向一些真實的事件，幸運的是這些事件僅限於不會影響付費客戶的叢集。

事件#1：Venafi 的 Webhooks 無回應

Venafi是機器身分的控制平面，最近被Cyberark收購，Cyberark 在 OPA 方面存在一些問題。完整的屍檢在這裡。

影響：間歇性 API 伺服器逾時導致節點不健康。

涉及：開放策略代理、節點準備

逐場比賽

在計劃的叢集升級期間，儘管有警告並且之前升級成功，但主升級失敗，導致 API 伺服器逾時和節點不穩定。根本原因是 ConfigMap 更新期間逾時，由無回應的OPA Webhook 觸發。刪除 webhook 恢復了服務，此後他們將其限制在特定的命名空間，加入了 OPA 的活性探針，並更新了文件。

他們強調需要 API 回應時間警報、工作負載探測，並可能使用 Helm 圖表進行部署，以避免將來出現類似問題。他們繼續監控功能的改進並透過 Flightdeck 服務提供見解。

學習內容：

• 需要對 API 伺服器回應時間發出警報。

• 增加所有工作負載所需的livenessProbes 。

• 使用套件管理進行更精細的配置。

💡 這事件凸顯了Glasskube旨在解決的用例之一。雖然 Glasskube 尚不支援 OPA 運算符，但我們相信透過強大的 Kubernetes 套件管理器可以避免這個問題。 Glasskube 可輕鬆配置關鍵功能，協助升級，並將 GitOps 方法應用於套件操作員管理，包括回溯和特定命名空間分配。在這裡嘗試一下。

事件#2：當加密貨幣礦工潛入時

JW Player成為比特幣挖礦惡意軟體的目標，請在此處查看完整的事後分析。

影響：非生產集群被比特幣礦工滲透

涉及： Root存取利用

逐場比賽

在 Datadog 向 JW Player 的 DevOps 團隊發出其臨時和開發環境中的平均負載較高的警報後，JW Player 的 DevOps 團隊在其 Kubernetes 叢集上發現了一個加密貨幣挖礦程式。初步調查發現，有一個gcc進程佔用了100%的CPU，經檢查發現該進程是監控工具Weave Scope發起的礦機。該礦工利用了面向公眾的 Weave Scope 負載平衡器，允許在容器中執行命令。

立即採取的行動包括停止 Weave Scope、隔離受影響的節點並將其輪換出去。該事件導致 CPU 使用率較高，但沒有服務中斷或資料外洩。該團隊將 Kubernetes 覆蓋的手動安全群組編輯確定為關鍵問題，並強調需要採取適當的配置實踐來防止此類漏洞。

學習內容：

• 監控負載並不是檢測叢集問題的最佳方法。

• 可能需要falcon或sysdig等工具

• 需要更強大的 Docker 映像和容器掃描。

• 架構的某些區域需要重新檢視。

• 需要更多的跨團隊資料共享和溝通。

事件 #3：GKE 耗盡 IP 位址

影響：高節點數叢集耗盡了 IP 位址，無法調度新的 Pod。

涉及：子網路、每個節點的預設 IP 分配

逐場比賽

當一名團隊成員報告其應用程式的部署時間異常長時，就發生了一起事件。他們很快就發現，雖然一些新部署的 Pod 正在提供流量，但其餘的 Pod 仍處於pending狀態。分析顯示FailedScheduling警告顯示資源不足。儘管部署了叢集自動縮放器，但問題仍然存在，因為他們看到了令人震驚的「0/256 個節點可用」訊息。進一步檢查發現，GKE為每個節點預先分配了110個IP，導致IP消耗意外高。了解這一點後，他們調整了每個節點的 Pod 分配，將整體 IP 使用量減少了 30%。此外，他們還探索了子網擴展和增加節點大小等選項以緩解 IP 耗盡，最終優化節點池實例大小以更好地利用資源。

學習內容：

• 了解 GKE 設定的預設值的重要性。

• 子網路擴充功能是一個可供您使用的實用工具（儘管關於次要範圍的文件不多）。

• 增加節點池執行個體大小也可以完成這項工作（每個節點執行更多 Pod，然後需要更少的節點）。

休士頓，我們的生產遇到問題了🤬

這些類型的中斷會讓 SRE 徹夜難眠，當客戶受到影響並且業務價值岌岌可危時，這些都是最重要的經驗教訓和英雄的誕生地。

事件 #1 Skyscanner 只需要幾個字元就可以關閉他們的網站

在這裡我們看到，針對彈性進行了最佳化的架構仍然容易因為一行程式碼而故障。完整的屍檢在這裡。

影響：全球 Skyscanner 網站和行動應用程式無法存取

涉及： IaC清單

逐場比賽

2021 年 8 月，由於無意中更改了基礎設施配置系統中的根文件，Skyscanner 面臨持續四個多小時的全球中斷。由於缺少{{ }} ，這項變更意外地觸發了全球範圍內關鍵微服務的刪除，導致網站和行動應用程式無法存取。

他們迅速解決了這個問題，利用 GitOps 恢復配置並確定關鍵服務的優先順序。

學習內容：

• 不要進行全域配置部署。

• 需要更徹底的「最壞情況」規劃。

• 驗證備份/復原過程。

• 保持操作手冊最新。

• 超越自動化的潛力。

事件#2 Monzo Bank 的 linkerd 慘敗

英國數位銀行艱難地發現了 Kubernetes 的一個嚴重錯誤。完整的屍檢在這裡。

影響：預付卡和新活期帳戶下降約1.5小時

涉及： Linkerd、kube-apiserver、etcd

逐場比賽：

此事件始於例行部署導致支付處理失敗。嘗試回滾變更未成功，導致內部中斷聲明。工程師發現並重新啟動了不健康的linkerd實例，但kube-apiserver的配置問題導致新的linkerd實例無法啟動，從而將中斷升級為整個平台故障。根本原因可追溯到 Kubernetes 和 etcd 中的錯誤，該錯誤是由最近的叢集重新配置觸發的。這導致linkerd無法接收網路更新，再加上 Kubernetes 和 linkerd 之間的相容性問題。該事件已透過更新 linkerd 並刪除空的 Kubernetes 服務得到解決。

學習內容：

• 需要新版本的 Linkerd。

• k8s bug 需要修復（現已修復）。

• 改進執行狀況檢查、儀表板和警報。

• 改進程序以改善停電期間的內部溝通。

事件 #3 Redis 操作員丟了一個曲線球

Palark 是一家 DevOps 服務供應商，曾試圖保護其 Redis 集群，但最終卻後悔了。這是完整的移植剖析

影響：加入副本後的生產 Redis 資料

涉及： Redis算子

逐場比賽

他們遇到了一個涉及眾所周知的記憶體鍵值儲存 Redis 的事件，他們透過Redis Operator安裝該儲存來執行 Redis 故障轉移。最初部署了一個 Redis 副本，後來擴展到兩個副本以增強資料庫可靠性。然而，這個看似微小的變化在部署過程中被證明是災難性的，導致資料遺失。該事件揭露了 Redis Operator 中的缺陷，主要是其readiness probe ，引發了意外的主升級和隨後的資料破壞。使用Redis-memory-analyzer等工具進行進一步分析，揭示了對資料庫大小和元素的洞察，從而幫助開發人員優化資料庫和應用程式程式碼，以防止未來發生事件。

學習內容：

• 使用 Kubernetes Operator 時要非常小心（確保它們成熟且經過充分測試）。

• 他們發現了與 Redis Operators 就緒性探測相關的關鍵錯誤，該錯誤使副本橫向擴展容易導致資料遺失（已修復）。

• Redis-memory-analyzer是Redis資料庫故障排除的最佳工具。

事件 #4 Datadog 的多區域噩夢

多個Datadog區域宕機systemd-networkd強制刪除了容器網路介面 (CNI) 插件管理的路由。完整的屍檢 在這裡。

影響：多個地區的使用者無法存取 API 和平台。

涉及： systemd更新、Cilium

逐場比賽

從 2023 年 3 月 8 日開始，Datadog 經歷了一次影響多個區域的重大中斷，導致用戶無法存取平台、API 和監視器，並影響資料提取。這個問題是由眾多虛擬機器上的 systemd 自動安全性更新觸發的，導致網路中斷，導致數萬個節點離線。恢復涉及恢復運算能力、解決特定於服務的問題以及為客戶提供持續更新。根本原因被確定為允許自動更新的錯誤配置，該更新已停用。

學習內容：

• 更強大的混沌測試。

• 需要在停電期間改善與客戶的溝通

• 停電期間狀態頁面不充分。

• 自動更新本身就有風險，應謹慎使用。

事件#5 Reddit 的圓周率日中斷

Reddit 遭受了快速有機成長的後果，他們面臨著殘酷的現實，即許多關鍵的 Kubernetes 叢集不標準化，很容易出現中斷，這裡是完整的 Pi-Day 中斷事後分析。

影響：嚴重的跨平台中斷持續 314 分鐘

涉及： Calico、Kubernetes版本更新

逐場比賽

2023 年 3 月，Reddit 經歷了一次持續 314 分鐘的嚴重中斷，巧合的是，這發生在圓周率日。嘗試存取網站的用戶要么遇到不堪重負的 Snoo 吉祥物、錯誤訊息，要么看到空的主頁。這次中斷是由 Kubernetes 1.23 升級到 1.24 引發的，這引入了一個以前從未見過的微妙問題。工程團隊近年來一直強調可用性的改進，但發現自己處於一個充滿挑戰的境地，回滾雖然有風險，但卻成為了最佳選擇。

在復原過程中，由於 TLS 憑證和 AWS 容量限制不匹配，因此出現了一些複雜情況，但團隊設法克服了這些挑戰並重新建立了高可用性控制平面。

進一步調查顯示，根本原因與 Calico 過時的路由反射器配置有關，由於刪除了「master」節點標籤，此配置與 Kubernetes 1.24 不相容。

學習內容：

• 出於測試目的改進預生產集群的重要性。

• 需要改進 Kubernetes 元件生命週期管理工具。

• 需要更同質的環境。

• 此外，還需要增加他們的 IaC 和內部技術文件。

結論

正如您所看到的，熵定律很容易適用於 Kubernetes 叢集——破壞它們比讓它們滿意要容易得多。升級、部署、擴展和部署等變更通常會引發中斷，因此您可能傾向於盡量減少中斷。但對於那些努力引領細分市場並滿足不斷變化的客戶需求的組織來說，這不是一個選擇。我們所能期望的最好的結果就是從實踐中學習，並從失敗中學習。從好的方面來說，科技業普遍樂於學習，並能坦然面對失敗（ 在大多數情況下）。事實上，許多大型企業公開分享事後總結供更大的社區學習，這是一種最佳實踐，其基礎是這樣的假設：故障和中斷是「何時」而不是「是否」的問題。保護我們自己的最好方法就是在他們過去後向他們學習。

🫵 那你呢？您是否經歷過任何特別困難的停電並從另一邊講述了這個故事？如果是這樣，請在下面的評論中分享您的經驗。我相信我們很多人都想聽聽這個。

幫助我們製作更多這樣的內容！

在Glasskube，我們在此類內容上投入了大量精力，並next generation package manager for Kubernetes 。

如果您從我們所做的工作中獲得價值，我們將不勝感激

⭐️ GitHub 上的 Star Glasskube 🙏

原文出處：https://dev.to/glasskube/kubernetes-fail-compilation-but-they-keep-getting-worse-12n2