早在我加入 urb-it 之前，他們就決定使用 Kubernetes 作為其雲原生戰略的基石。 這種選擇背後有兩個原因：使用 Kubernetes 來滿足快速擴充套件的期望，以及利用其容器編排功能為應用程式提供更動態、更有彈性和更高效的環境。 同時，Kubernetes 與我們的微服務架構非常契合。
早期決策
該公司很早就決定選擇 Kubernetes，因為初創公司（或任何公司）都對它有很深的依賴性，並且需要學習很多技術知識。 除此之外，我們是否遇到了只有 kubernetes 才能解決的問題？
有人可能會爭辯說，我們可以從乙個相當大的單體開始，在擴充套件和其他問題變得更加明顯之前不要轉向 Kubernetes（或其他工具）。 此外，Kubernetes 當時仍處於開發的早期階段。 但是，讓我們下次深入研究。
8年生產經驗
我們已經在生產環境中執行 Kubernetes 超過 8 年了（每個 Kubernetes 都有乙個單獨的集群），在此期間我們做出了不同的決定。 有些錯誤僅僅是由於“運氣不好”，而另一些錯誤則是由於部分（如果不是完全）未能理解底層技術。 Kubernetes 很強大，但它也很複雜。
由於沒有任何大規模執行 Kubernetes 的經驗，我們不得不迎接挑戰。
從 AWS 上的自託管遷移到 Azure （AKS） 上的託管。
在最初的幾年裡，我們在 AWS 上執行了乙個自我管理的集群。 如果我沒記錯的話，我們最初沒有選擇使用 Azure Kubernetes Service （AKS）、Google Kubernetes Engine （GKE）、Amazon Elastic Kubernetes Service （EKS），因為它們當時沒有官方託管解決方案。 正是在 Amazon Web Services （AWS） 自託管平台上，我們經歷了 UBB-IT 歷史上第一次也是最可怕的集群崩潰，稍後會詳細介紹。
由於我們是乙個小團隊，因此要完全掌握我們需要的所有新功能是具有挑戰性的。 同時，管理自託管集群需要持續的關注和維護，這增加了我們的工作量。
當託管解決方案正式發布時，我們花時間評估了 AKS、GKE 和 EKS。 在我們看來，所有這些解決方案都比我們自己管理它們好幾倍，我們可以很容易地預見到遷移帶來的快速投資回報。
當時，我們平台的 50% 是.NET、50% Python，並且已在使用 Azure 服務匯流排、Azure SQL Server 和其他 Azure 服務。 因此，將群集遷移到 Azure 的好處是顯而易見的，我們不僅能夠更輕鬆地整合這些服務，而且還能夠利用 Azure 主幹網路基礎結構，並節省與離開外部網路和 VNET 相關的成本（這在混合 AWS 和 Azure 設定中是無法避免的）。 此外，我們的許多工程師都熟悉 Azure 及其生態系統，學習曲線較低。
作為獎勵，當我們在 AKS 上進行初始設定時，我們不必為控制平面節點（主節點）付費，從而節省了節點費用。
在 2018 年冬天，我們進行了遷移，儘管多年來我們遇到了 AKS 問題，但我們並不後悔這次遷移。
群集崩潰
在使用 AWS 進行自託管時，我們經歷了大規模的集群崩潰，導致我們的大多數系統和產品出現故障。 根 CA 證書、etcd 證書和 API 伺服器證書都已過期，導致集群停止工作並變得無法管理。 當時，Kube-AWS 對解決方案的支援非常有限。 儘管我們請來了一位專家來指導我們，但我們最終不得不從頭開始重建整個集群。
我們認為每個 git 儲存庫中都有所有權和頭盔圖表，但令人驚訝的是，並非所有服務都是如此。 最重要的是，庫中沒有用於建立群集的任何配置的儲存。 我們正在與時間賽跑，以重建集群並填充我們所有的服務和產品。 其中一些服務需要重新設計 helm 圖表以建立缺少的配置。 有時 dev1 會問 dev2：“你還記得這個服務應該有多少 CPU 或 RAM，或者它應該有什麼樣的網路和埠訪問嗎？ “更不用說記住什麼鑰匙了，它們已經隨風消失了。
我們花了幾天時間重新啟動集群並使其啟動並執行。 退一步說，這不是我們最自豪的時刻。
由於積極主動的溝通，我們沒有通過使用透明度、誠實和保留客戶關係等措施來失去任何業務或客戶。
群集崩潰
你可能會猜到：第二次崩潰不可能是由證書引起的，你一定從第一次崩潰中吸取了教訓，對吧？ 沒錯，但不完全是。
不幸的是，在為崩潰 1 重新建立集群時，我們使用的特定版本的 kube-aws 存在問題。 建立新集群時，它不會將 etcd 證書的到期日期設定為我們提供的到期日期，而是使用預設的一年期限。 因此，在第一次集群崩潰整整一年後，證書過期了，我們又經歷了一次集群崩潰。 這一次恢復起來要容易得多，我們不必重建一切，但這仍然是乙個地獄般的週末。
注1：其他公司也和我們一樣受到此漏洞的影響，但這並沒有幫助我們的客戶......
注2：我們原計畫在一年後更新所有證書，但為了給自己留有餘地，我們將到期日期設定為兩年（如果我沒記錯的話）。 因此，雖然我們計畫更新證書，但錯誤比我們領先一步。
自 2018 年以來，我們沒有發生過集群崩潰......希望我沒有烏鴉的喙。
經驗 教訓
1.Kubernetes 很複雜您需要對 Kubernetes 的基礎設施和運營方面感興趣並願意參與的工程師。
在我們的案例中，我們需要一些工程師在日常工作之外處理 Kubernetes，在必要時作為“首選專家”解決問題。 正如您可能想象的那樣，特定於 Kubernetes 的任務的工作負載各不相同，從幾周幾乎沒有到沒有，到幾周的高度集中（例如在集群公升級期間）。
不可能在整個團隊中輪換工作，而且技術太複雜了，無法每隔一周在工作之間“來回跳躍”。 當然，每個人都需要知道如何使用它（包括部署、除錯等），但要在更具挑戰性的領域脫穎而出，專門的學習時間是必不可少的。 此外，擁有一位有遠見和專注戰略的領導者也很重要。
2.Kubernetes 證書由於兩次證書過期而經歷過集群崩潰，因此精通 Kubernetes 內部證書及其到期日期的詳細資訊至關重要。
3.保持 kubernetes 和 helm 更新一旦你落後了，使用這兩個工具的成本就會增加，問題就會出現。 我們總是等待幾個月才能公升級到最新版本，以檢視其他使用者在使用新版本時會遇到哪些問題。 但即使我們保持版本更新，我們也會受到各種新版本 Kubernetes 和 Helm 的影響（Kubernetes API 從 Alfa 到 Beta 和 Beta 到 10等），並面臨大量耗時的配置檔案和圖表重寫工作。我知道 Simon 和 Martin 喜歡 Ingress 的所有變體。
4.集中式舵手圖表說到舵圖表，我們厭倦了每次版本更改都必須更新七十多個圖表，因此我們採用了更通用的“一張地圖”方法。 使用集中式 helm chart 有利有弊，但最終這種方法更符合我們的需求。
5.災難恢復計畫我怎麼強調都不為過：如果需要，請確保您有辦法重新建立集群。 是的，您可以單擊使用者介面來建立新集群，但這種方法無法大規模使用，或者時間至關重要。
有不同的方法可以解決這個問題，從簡單的 shell 指令碼到更高階的方法，如使用 terraform（或類似）。 Crossplane 還可用於管理基礎設施，即 （IAC） 等。 對於我們來說，由於團隊的頻寬有限，我們選擇儲存和使用 shell 指令碼。 無論選擇哪種方法，請確保不時測試該過程，以確保可以在需要時重新建立群集。
6.備份金鑰制定關鍵的備份和儲存策略。 如果集群消失，則所有金鑰都將丟失。 相信我，我們已經親身經歷過這種情況，當你有多個不同的微服務和外部依賴項時，需要很多時間才能恢復正常。
7.與供應商無關與“全部投注”。最初，在遷移到 AKS 後，我們盡量不將群集繫結到供應商，這意味著我們將繼續將其他服務用於容器登錄檔、身份驗證、金鑰庫等。 這個想法是，有一天我們可以輕鬆地遷移到另乙個託管解決方案。 雖然與商無關是個好主意，但對我們來說，機會成本很高。 一段時間後，我們決定全面使用與 AKS 相關的 Azure 產品，例如容器登錄檔、安全掃瞄、身份驗證等。 對我們來說，這改善了開發人員體驗，簡化了安全性（使用 Azure Entra ID 進行集中訪問管理）等，從而縮短了上市時間並降低了成本（產生優勢）。
8.客戶資源定義是的，我們全面使用 Azure 產品，但我們的指導原則是儘量減少自定義資源定義，而是使用內建的 Kubernetes 資源。 但是，也有一些例外，例如 Traefik，因為 Ingress API 不能滿足我們的所有需求。
9.安全見下文。
10.可觀察性見下文。
11.在已知峰值期間進行預縮放即使使用自動縮放器，我們有時也會縮放得太慢。 利用流量資料和常識（我們是一家物流公司，節假日有高峰），我們在高峰前一天手動放大集群（replicaset），然後在高峰後的第二天縮小規模（慢慢縮小以應對可能的第二波高峰）。
12.集群中的無人機我們將無人機構建系統保留在舞台集群中，這是好事也是壞事。 因為在同乙個集群中，它易於擴充套件和使用; 但是，如果你同時構建太多，它幾乎會消耗你所有的資源，導致 Kubernetes 急於啟動新節點。 最好的解決方案可能是使其成為乙個純粹的 SaaS 解決方案，而不必擔心產品本身的託管和維護。
13.選擇正確的節點型別選擇節點型別非常具體，但根據節點型別，AKS 會保留大約 10-30% 的可用記憶體（用於 AKS 內部服務）。 因此，我們發現使用更少但更大的節點型別是有益的。 此外，由於我們在很多服務上執行.NET，因此需要選擇具有高效、高容量 IO 的節點型別。 (..NET 經常將 JIT 和日誌寫入磁碟，如果這需要網路訪問，則速度會變慢。 我們還確保節點磁碟快取的大小至少與配置的節點磁碟的總大小相同，以避免再次發生網路跳轉。
14.預留例項您可能會認為這種方法有點違背雲的靈活性，但對我們來說，將關鍵例項保留一兩年可以節省大量成本。 在許多情況下，與“現收現付”方法相比，我們可以節省 50%-60%，這是相當可觀的。
15.k9s對於想要比 kubectl 更高抽象級別的使用者來說，這是乙個很好的工具。
可觀察性
1.監測確保在一段時間內跟蹤記憶體、CPU 等，以便觀察集群的執行狀況，並確定新功能是提高還是降低集群效能。 這樣可以更輕鬆地為不同的 Pod 查詢和設定“正確”的限制（找到正確的平衡很重要，因為如果記憶體不足，Pod 將被殺死）。
2.警報完善警報系統需要乙個過程，但最終我們將所有警報都定向到 Slack 頻道。 當群集未按預期執行或出現意外問題時，很容易獲取資訊。
3.伐木將所有日誌整合到乙個位置，以及強大的跟蹤 ID 策略（例如 OpenTelemetry 或類似軟體），對於任何微服務架構都至關重要。 我們花了兩三年時間才到達那裡。 如果我們早點實施它，我們將節省大量時間。
安全
Kubernetes 中的安全問題是乙個巨大的話題，我強烈建議深入研究它們以了解所有細微差別（例如，請參閱 NSA、CISA 的 Kubernetes 強化指南）。 以下是我們從經驗中得出的一些結論，但請注意，這些並非詳盡無遺。
1.存取控制簡而言之，Kubernetes 的預設限制並不過分。 因此，我們投入了大量時間來收緊訪問許可權，並實現 Pod 和容器的最小許可權原則。 此外，由於存在特定漏洞，非特權攻擊者可能會將其許可權提公升為 root 許可權，從而規避 Linux 命名空間限制，在某些情況下，甚至會逃避容器以獲取主機節點上的 root 訪問許可權。 這不是一件好事。
您應該設定唯讀根檔案系統、禁用服務帳戶令牌自動掛載、禁用許可權提公升、放棄所有不必要的功能等。 在我們的特定設定中，我們使用 Azure Policy 和 Gatekeeper 來確保不部署不安全的容器。
在 AKS 的 Kubernetes 設定中，我們利用基於角色的訪問控制 （RBAC） 的強大功能來進一步加強安全性和訪問管理。
2.容器漏洞有很多好的工具可以掃瞄和驗證容器和 Kubernetes 的其他部分。 我們使用 Azure Defender 和 Azure Defender for Containers 來滿足我們的一些需求。
注意：與其陷入“分析癱瘓”，即試圖找到具有各種花哨功能的完美工具，不如選擇乙個工具並直接進入。
多年實踐的長期設定
1.部署像許多其他公司一樣，我們使用 Helm 來管理和簡化在 Kubernetes 上部署和打包應用程式。 因為我們很久以前就開始使用 helm，而且它最初是.NET GO j**a Python PHP 是混合的，所以我不記得我重寫了多少次 helm 圖表。
2.可觀察性我們開始使用 loggly 和 fluentd 進行集中式日誌記錄，但幾年後，我們切換到 Elastic 和 Kibana（ELK 堆疊）。 對我們來說，使用 Elastic 和 Kibana 更方便，因為它們的可用性更廣，而且在我們的設定中更便宜。
3.容器登錄檔我們從碼頭開始，這是乙個很好的產品。 但隨著遷移到 Azure，使用 Azure 容器登錄檔變得很自然，因為它是整合的，因此對我們來說是乙個更“本機”的解決方案。 （隨後，我們還將容器放在 Azure 安全顧問下）。
4.管道從一開始，我們就使用無人機來建造貨櫃。 一開始，支援容器和 Docker 的 CI 系統並不多，而且它們不提供 ** 配置。 多年來，無人機為我們提供了很好的服務。 在 Harness 收購 Drone 後，它變得有點混亂，但在我們屈服並遷移到高階版本後，我們擁有了我們需要的所有功能。
遊戲規則的改變者
在過去的幾年裡，Kubernetes 改變了我們的遊戲規則。 它釋放了使我們能夠更高效地擴充套件（以應對流量波動）、優化基礎設施成本、改善開發人員體驗以及更輕鬆地測試新想法的功能，從而大大縮短了新產品和服務的上市時間和盈利時間。
我們開始使用 Kubernetes 的時間有點太早了，在我們真正遇到它可以解決的問題之前。 但從長遠來看，尤其是近年來，它已被證明對我們具有重要價值。
結論
回顧這八年的經歷，我們有很多故事要分享，其中許多故事已經消失在記憶中。 我希望你發現形成的過程、所犯的錯誤以及在此過程中吸取的經驗教訓對你有所幫助。
感謝您的閱讀。 特別感謝 Matin、Simon 和 Niklas 對本文的寶貴意見。
作者丨Anders J nsson Compilation丨onehunnit**丨mediumcom/@.anders/learnings-from-our-8-years-of-kubernetes-in-production-two-major-cluster-crashes-ditching-self-0257c09d36cd*本文由DBAPLUS社群編譯，如有需要**，請獲得授權並註明出處！ 歡迎廣大技術人員投稿，投稿郵箱：editor@dbapluscn