立方體、元集群、蜂巢、資源分佈
米。 1. 阿里雲上的 Kubernetes 生態
自2015年以來，阿里雲Kubernetes容器服務（ACK）一直是阿里雲中成長最快的雲端服務之一。 它為眾多客戶提供服務，也支援阿里巴巴的內部基礎設施和公司的其他雲端服務。
與世界一流雲端供應商提供的類似容器服務一樣，我們的首要任務是可靠性和可用性。 因此，為數以萬計的 Kubernetes 叢集創建了一個可擴展且全球可存取的平台。
在這篇文章中，我們將分享我們在雲端基礎架構上管理大量 Kubernetes 叢集的經驗，以及底層平台的架構。
條目
Kubernetes 已成為雲端中各種工作負載的事實上的標準。 如圖所示。 如上所述，現在越來越多的阿里雲應用程式運行在 Kubernetes 叢集上：有狀態和無狀態應用程序，以及應用程式管理器。 對於建置和維護基礎設施的工程師來說，Kubernetes 管理一直是一個有趣且嚴肅的討論主題。 當談到像阿里雲這樣的雲端供應商時，擴充問題就凸顯出來了。 如何管理如此規模的 Kubernetes 叢集？ 我們已經介紹了管理 1 個節點的大型 Kubernetes 叢集的最佳實務。 當然，這是一個有趣的縮放問題。 但還有另一個尺度：數量 集群本身.
我們已經與許多 ACK 用戶討論過這個主題。 他們中的大多數人選擇運行數十個（如果不是數百個）中小型 Kubernetes 叢集。 這樣做有充分的理由：限制潛在的損害、為不同的團隊分離叢集、建立用於測試的虛擬叢集。 如果 ACK 旨在透過此使用模型為全球受眾提供服務，則它必須可靠且有效率地管理跨 20 多個區域的大量叢集。
米。 2.管理海量Kubernetes叢集的問題
管理如此規模的集群的主要挑戰是什麼？ 如圖所示，有四個問題需要處理：
- 異質性
ACK 應支援各種類型的集群，包括標準、無伺服器、Edge、Windows 等。 不同的叢集需要不同的選項、元件和託管模型。 有些客戶需要針對其具體情況進行客製化方面的協助。
- 各種簇大小
叢集的大小各不相同，從幾個節點和幾個 Pod 到數萬個節點和數千個 Pod。 資源需求也有很大差異。 資源分配不當會影響效能甚至導致故障。
- 不同版本
Kubernetes 發展得非常快。 每隔幾個月就會發布新版本。 客戶總是願意嘗試新功能。 因此，他們希望將測試負載放在新版本的 Kubernetes 上，將生產負載放在穩定版本上。 為了滿足這項要求，ACK必須持續向客戶提供新版本的Kubernetes，同時保持穩定的版本。
- 安全合規性
集群分佈在不同的區域。 因此，它們必須遵守各種安全要求和官方法規。 例如，歐洲的集群必須符合 GDPR，而中國的金融雲必須有額外的保護層。 這些要求是強制性的，忽視它們是不可接受的，因為這會對雲端平台的客戶造成巨大的風險。
ACK平台旨在解決上述大部分問題。 目前可靠且穩定地管理全球超過10萬個Kubernetes集群。 讓我們看看這是如何實現的，包括通過一些關鍵的設計/架構原則。
設計
立方體和蜂窩體
與集中式層次結構不同，基於單元的架構通常用於將平台擴展到單一資料中心之外或擴大災難復原的範圍。
阿里雲中的每個區域由多個可用區（AZ）組成，通常對應於一個特定的資料中心。 在一個大的區域（例如黃州），往往有數千個 Kubernetes 用戶端叢集運行 ACK。
ACK 使用 Kubernetes 本身來管理這些 Kubernetes 叢集，這意味著我們有一個運行的 Kubernetes 元叢集來管理客戶端 Kubernetes 叢集。 這種架構也稱為「kube-on-kube」（KoK）。 KoK 架構簡化了客戶端叢集的管理，因為叢集部署簡單且確定。 更重要的是，我們可以重複使用原生 Kubernetes 功能。 例如，透過部署來管理API伺服器，使用etcd操作符來管理多個etcd。 這樣的遞歸總是能帶來特別的樂趣。
根據客戶端數量，在一個區域內部署多個 Kubernetes 元叢集。 我們將這些稱為元簇細胞。 為了防止整個可用區發生故障，ACK 支援在單一區域內進行多主部署：元叢集將 Kubernetes 用戶端叢集主元件分佈在多個可用區中並同時運行，即以多主模式運行。 為了確保master的可靠性和效率，ACK優化了組件的放置，並確保API伺服器和etcd彼此靠近。
此模型可讓您有效率、靈活、可靠地管理 Kubernetes。
元集群資源規劃
正如我們已經提到的，每個區域中的元集群數量取決於客戶端數量。 但什麼時候增加新的元集群呢？ 這是一個典型的資源規劃問題。 通常，當現有元集群耗盡其所有資源時，通常會建立一個新的元集群。
我們以網路資源為例。 在 KoK 架構中，客戶端叢集中的 Kubernetes 元件被部署為元叢集中的 Pod。 我們用 （圖3）是阿里雲開發的一款用於容器網路管理的高效能插件。 它提供了豐富的安全策略，並允許您透過阿里雲彈性網路介面（ENI）連接到客戶的虛擬私有雲（VPC）。 為了有效地跨元叢集中的節點、pod 和服務分配網路資源，我們必須仔細監控它們在虛擬私有雲元叢集中的使用情況。 當網路資源耗盡時，就會創造一個新的小區。
為了確定每個元叢集中客戶端叢集的最佳數量，我們還考慮了成本、密度要求、資源配額、可靠性要求和統計資料。 創建新元集群的決定是根據所有這些資訊做出的。 請注意，小集群未來可能會大幅擴展，因此即使集群數量不變，資源消耗也會增加。 我們通常會為每個集群的成長留出足夠的可用空間。
米。 3. Terway網路架構
跨客戶端叢集擴展嚮導元件
嚮導組件有不同的資源需求。 它們取決於叢集中節點和 Pod 的數量、與 APIServer 互動的非標準控制器/操作器的數量。
在 ACK 中，每個 Kubernetes 用戶端叢集的大小和執行階段要求都不同。 沒有用於放置嚮導組件的通用配置。 如果我們錯誤地為大型客戶端設定了較低的資源限制，那麼其叢集將無法應對負載。 如果為所有叢集設定保守的較高限制，則會浪費資源。
為了在可靠性和成本之間找到微妙的權衡，ACK 使用類型系統。 即，我們定義三種類型的群集：小型、中型和大型。 每種類型都有單獨的資源分配設定檔。 根據嚮導組件的負載、節點數量等因素來決定類型。 集群類型可能會隨著時間而改變。 ACK 持續監控這些因素並可以相應地向上/向下鍵入。 一旦叢集類型發生更改，資源分配就會自動更新，只需最少的使用者乾預。
我們正在努力透過更細粒度的擴展和更精確的類型更新來改進這個系統，以便這些變化更順利地發生並具有更大的經濟意義。
米。 4.智慧多段式切換
客戶端集群的大規模演變
前面的部分介紹了管理大量 Kubernetes 叢集的一些方面。 然而，還有一個問題需要解決：集群的演化。
Kubernetes 是雲端世界的「Linux」。 它不斷更新並變得更加模組化。 我們必須不斷向客戶提供新版本、修復漏洞並更新現有集群，以及管理大量相關元件（CSI、CNI、設備插件、調度程序插件等）。
我們以 Kubernetes 元件管理為例。 首先，我們開發了一個集中式系統來註冊和管理所有這些連接的元件。
米。 5. 靈活的可插拔組件
在繼續之前，您需要確保更新成功。 為此，我們開發了一個用於檢查組件功能的系統。 檢查在更新之前和之後執行。
米。 6. 集群組件初步檢查
為了快速可靠地更新這些元件，持續部署系統支援部分推進（灰階）、暫停和其他功能。 標準 Kubernetes 控制器不太適合這種用例。 因此，為了管理叢集組件，我們開發了一套專門的控制器，包括插件和輔助控制模組（sidecar管理）。
例如，BroadcastJob 控制器旨在更新每台工作電腦上的元件或檢查每台電腦上的節點。 Broadcast 作業在叢集中的每個節點上執行一個 pod，類似 DaemonSet。 然而，DaemonSet 總是讓 pod 保持長時間運行，而 BroadcastJob 則讓它崩潰。 廣播控制器也會在新加入的節點上啟動 Pod，並使用必要的元件初始化節點。 2019 年 XNUMX 月，我們開放了 OpenKruise 自動化引擎的原始碼，我們自己在公司內部使用該引擎。
米。 7.OpenKurise組織Broadcast任務在所有節點上的執行
為了幫助客戶選擇正確的叢集配置，我們還提供了一組預先定義的設定文件，包括 Serverless、Edge、Windows 和 Bare Metal 設定檔。 隨著業務範圍的擴大和客戶需求的成長，我們將添加更多個人資料以簡化繁瑣的設定流程。
米。 8. 先進且靈活的叢集配置，適用於各種場景
跨資料中心的全局可觀測性
如下圖所示。 9.阿里雲容器雲端服務已在全球二十個地區部署。 鑑於這種規模，ACK 的關鍵目標之一是輕鬆監控正在運行的叢集的狀態，以便如果客戶端叢集遇到問題，我們可以快速回應該情況。 換句話說，您需要提出一個解決方案，使您能夠有效且安全地從所有區域的客戶端叢集即時收集統計數據，並直觀地呈現結果。
米。 9.阿里雲容器服務全球二十個地區部署
與許多 Kubernetes 監控系統一樣，我們使用 Prometheus 作為主要工具。 對於每個元集群，Prometheus 代理程式收集以下指標：
- 作業系統指標，例如主機資源（CPU、記憶體、磁碟等）和網路頻寬。
- 元叢集和客戶端叢集管理系統的指標，例如 kube-apiserver、kube-controller-manager 和 kube-scheduler。
- 來自 kubernetes-state-metrics 和 cadvisor 的指標。
- etcd 指標，例如磁碟寫入時間、資料庫大小、節點之間連接的吞吐量等。
使用典型的多層聚合模型收集全域統計資料。 每個元集群的監控資料首先在每個區域進行聚合，然後發送到顯示整體情況的中央伺服器。 一切都透過聯邦機制進行。 每個資料中心中的 Prometheus 伺服器從該資料中心收集指標，中央 Prometheus 伺服器負責聚合監控資料。 AlertManager 連接到中央 Prometheus，如有必要，透過釘釘、電子郵件、簡訊等發送警報。 視覺化 - 使用 Grafana。
圖10中，監控系統可分為三個層次：
- 邊界水平
離中心最遠的層。 Prometheus 邊緣伺服器在每個元叢集中運行，從同一網路域內的元叢集和用戶端叢集收集指標。
- 級聯級
Prometheus級聯層的作用是收集多個區域的監控資料。 這些伺服器在更大的地理單元層面上運行，例如中國、亞洲、歐洲和美洲。 隨著叢集的成長，可以劃分區域，然後每個新的大區域中都會出現一個級聯級的Prometheus伺服器。 透過此策略，您可以根據需要順利擴展。
- 中央層面
中央Prometheus伺服器連接所有級聯伺服器並進行最終的資料聚合。 為了可靠性，兩個中央 Prometheus 實例在不同的區域中啟動，連接到相同的級聯伺服器。
米。 10.基於Prometheus聯邦機制的全域多層級監控架構
總結
基於 Kubernetes 的雲端解決方案不斷改變我們的產業。 阿里雲容器服務提供安全、可靠和高效能的託管——它是最好的 Kubernetes 雲端託管之一。 阿里雲端團隊堅信開源原則和開源社群。 我們一定會繼續分享我們在營運和管理雲端技術領域的知識。
來源： www.habr.com