​多個維度分析k8s多叢集管理工具，到底哪個才真正適合你

專 注 於   雲原生技術   分 享

提 供 優 質 雲原生開發   視 頻 技 術 培 訓

面試技巧 ， 及 技術疑難問題 解答

雲 原 生 技 術 分 享 不 僅 僅 局 限 於 Go 、 Rust 、 Python 、 Istio 、 containerd 、 CoreDNS 、 Envoy 、 etcd 、 Fluentd 、 Harbor 、 Helm 、 Jaeger 、 Kubernetes 、 Open Policy Agent 、 Prometheus 、 Rook 、 TiKV 、 TUF 、 Vitess 、 Arg o 、 Buildpacks 、 CloudEvents 、 CNI 、 Contour 、 Cortex 、 CRI-O 、 Falco 、 Flux 、 gRPC 、 KubeEdge 、 Linkerd 、 NATS 、 Notary 、 OpenTracing 、 Operator  Framework 、 SPIFFE 、 SPIRE   和   Thanos 等

多個維度分析k8s多叢集管理工具，到底哪個才真正適合你

當部署在雲上的服務達到一定水平時，所有公司都應該接受多叢集。根據 VMware 2020 的 Kubernetes 狀態報告， 33% 的 Kubernetes 採用者正在執行 26 個或更多叢集， 20% 正在執行超過 50 個叢集。

http://tanzu.s3.us-east-2.amazonaws.com/campaigns/pdfs/VMware_State_Of_Kubernetes_2020_eBook.pdf

無論是使用 AWS 、 GKE 還是其他雲服務商，無論是否自己搭建 Kubernetes 平臺，無論是否使用自動伸縮功能，你都會發現單個叢集的容量是有限的。 Kubernetes 官方推薦，“最大”的叢集應該是

• 每個節點不超過 110 個 Pod

• 不超過 5000 個節點

• 總共不超過 150000 個 pod

• 總共不超過 300000 個容器

許多人可能認為他們當前的叢集效能非常好，對多叢集的需求還很遙遠。但是，它們很快就會走向多叢集。

動機

我們採用的單個叢集負擔很大：它包含大約 2000 個名稱空間， 3000 個 Pod，但叢集中的大部分資源都是 GCP 相關的，包括 10000 多個 StorageBucket ， 10000 個 IAM 資源，以及相當數量的 Bigtable 和 BigQuery 相關的。與此同時， 50 家運營商正在執行數十個內部或開源控制器。

在效能方面， GKE 自動縮放器目前執行良好。但我們還是開始尋求多叢集策略，將我們的資源和服務遷移到多叢集，以解決以下問題。

可擴充套件性。在部署或升級某個 Operator 時，依賴於該 Operator 的 Pod 必須重啟，造成整個叢集的不穩定性，因為這些 Pod 可能會管理每個 Namespace 中的大量資源。而當 APIServer 無法響應請求時，就會發生錯誤。由於 Kubernetes 的故障重啟機制，所有 Pod 都會在數小時內重複重啟。因此，單個叢集已經無法滿足我們快速升級、引入新使用者、部署新資源的需求。

"error": "Get "http://10.1.1.1:443/apis?timeout=32s": context deadline exceeded
"Failed to get API Group-Resources", "error": "context deadline exceeded"

• 可用性和使用者體驗。作為公司範圍內 CI/CD 管道的一部分，我們的服務將影響幾乎所有正在部署或將要部署的服務，例如 PR 合併或主構建。單個叢集的爆炸半徑太大，如果服務需要緊急部署，需要付出很多努力才能繞過我們的單節點故障。

• 隔離。叢集中的資源可以根據其變化頻率分為兩類：穩定的和不穩定的。我們可以通過將這些穩定的資源（ P99 ）移動到一個相對穩定的環境中來避免它們受到其他 operator 或資源的影響。

• 效能。隨著管理的資源數量增加到 10k ，一些叢集級別的 operator 會遇到各種效能問題。有必要減少他們的 pod 使用開銷並改善使用者體驗。

• 多環境。我們叢集中執行的數十個 operator 超出了我們的管理範圍，大多數 operator 維護者都有自己的釋出和部署許可權。一旦其中一個出現問題，整個叢集將面臨可用性問題。但是，由於當前的測試環境和生產之間的差距很大，因此很難預測生產中可能出現的問題。因此，我們需要一個更安全的解決方案來測試和釋出這些 operator 。

多叢集拯救一切，大大減輕現有 APIServer 的壓力，加快我們新功能的升級和部署，減少對使用者的影響，縮小爆炸半徑，提升使用者體驗。

此外，“不要把雞蛋放在一個籃子裡”似乎也是雲戰略的趨勢。在 VMware 最新的 2021 年報告中， 36% 的使用者已經在推動多雲戰略，這也是許多公司的計劃。

http://tanzu.vmware.com/content/ebooks/the-state-of-kubernetes-2021

由於與 GCP 深度繫結，我們更接近多雲戰略是明智的，部署多叢集將是第一步。

如何設定多叢集

我們的研究從 CNCF 中可以支援和滿足我們需求的現有工具開始。除了上面列出的痛苦之外，我們現在應該專注於我們實際需要的東西。

• 叢集部署，可以快速部署多個叢集，解決網路問題。

• Cluster Discovery ，當用戶資源分散到多個叢集時，搜尋當前需要執行的叢集的中心服務。它還應該提供類似於一致性雜湊的功能，以避免在叢集隨後增加時將資源重新部署到不同的叢集。
• GCP 資源和自定義 CRD 支援。對於 Google Config Connector 定義的那些 GCP 資源，以及公司內部 CRD 定義的資源，我們需要更多的支援。

http://cloud.google.com/config-connector/docs/overview

同時，我們也需要適應很多地方的多叢集變化。

根據 CI/CD 中的當前請求對資源進行分組。有時，我們需要同時在多個叢集上啟動操作。

• 確保每個 operator 都支援多叢集。
• 為使用者提供 UX 或 CLI 工具來發現他們的 CLI 操作資源。考慮到所有這些需求，讓我們看看社群中的使用者如何實現多叢集，採用哪些策略，使用哪些工具。

戰略

通常有兩種多叢集策略，以 Kubernetes 為中心和以網路為中心。

• 以 Kubernetes 為中心，管理多個叢集，通過在多個叢集上構建控制平面層來分發和排程資源管理請求，這些叢集相互隔離，每個叢集管理不同的資源。

• 以網路為中心，通過網路配置實現不同叢集之間的通訊，實現資源複製，保持每個叢集上的資源一致。

您可能會發現這兩種策略類似於克服我們在資料庫中遇到的瓶頸的傳統方法。確切地！以 Kubernetes 為中心就像 master-master 模式，依賴於資料庫中介軟體（控制平面）來處理和分發請求，而以 network-centric 是 master-slave 模式，主從之間的通訊最終保持資料一致.

在我們的案例中，以網路為中心的策略並不適用，但以 Kubernetes 為中心的策略可以減輕每個叢集的負擔。

工具

來自雲提供商的那些工具，例如 GKE 的多叢集支援，已經過時了。它們基本上是以網路為中心的，並伴隨著兩個主要問題。

• 不那麼開源，難以定製或二次開發。

• 與雲提供商本身高度耦合，不利於未來的多雲或混合雲戰略。

現在看看我們可以選擇社群中哪些流行的工具。

Kubefed

這個流行的多叢集工具有兩個版本， v1 kube-federation （已經放棄）和 v2 kubefed 。

從 kubefed 的整體架構可以看出，它本質上是由兩個 CRDType Configuration 和, 組成的， Cluster Configuration 並通過 CRD 各自的控制器和准入 webhook 來實現這兩個主要功能。

• 跨叢集分佈。通過抽象、 和三個概念 Templates ，可以將資源（如）部署到不同的叢集，實現多叢集擴充套件。 PlacementOverridesDeployment
• 排程 clusterSelector ，用和實現資源排程 ReplicaSchedulingPreference 。此外， kubefed 還支援高可用、更輕鬆的資源遷移、多雲和混合雲部署等諸多特性。

然而，它不是我們要找的那個。

• 對於大多數開發人員來說，它是一個複雜的工具，學習曲線陡峭。

• 不支援自定義分發策略，無法滿足我們隔離不同穩定性資源的需求。例如， ReplicaSchedulingPreference 只能支援 Deployments 和 Replicasets 。
• 它不支援自定義 CRD 。我們需要額外的努力來管理來自 Config Connector .

Gitops

Gitops 已經是非常流行的 CI/CD 標準，用於將 Kubernetes 資源部署到叢集，例如 FluxCD 、 Fleet 和 ArgoCD ，其中大部分都支援多叢集。這是我們可以依靠的嗎？

FluxCD 支援多叢集和多租戶，使用 kustomization 和 helm 新增新叢集，並且支援資源隔離。

經過評估，它也不是那個。

• 沒有動態分佈。資源分配需要通過類似的方式提前注入 go template ，而不是動態分配。而我們自己的 CI/CD 工具也無法與之無縫整合。

• 副作用。 helm 申請的開銷 kustomize 太高了。這些缺點是其他 Gitops 共有的，也是不適用的。

Karmada

Karmada 來自 CNCF 沙箱，支援多叢集和多雲策略。

它的設計部分繼承自 kubefed v1 和 v2 ，與 APIServer 、 Scheduler 和 controller-manager 構成一個控制平面，並通過兩個 crd PropagationPolicy 和 OverridePolicy 實現資源排程和分發。

Karmada 有很多優點，包括但不限於，

• 叢集管理。統一的 API 支援叢集註冊和生命週期管理。

• 宣告性資源排程。支援自定義排程策略，根據標籤和狀態動態排程資源到合適的叢集。

• Karmada 的主要優勢在於原生 Kubernetes 資源處理，但它天生不支援 CRD 。

對於 Kubernetes 原生資源， Karmada 知道如何解析它們，但對於 CRD 定義的自定義資源（或通過聚合 apiserver 之類的擴充套件），由於缺乏對資源結構的瞭解，只能將其視為普通資源。因此，高階排程演算法不能用於它們。

即需要 Resource Interpreter 開發來實現動態排程等功能。我們不選擇它的最大原因。

http://github.com/karmada-io/karmada/blob/master/docs/userguide/customizing-resource-interpreter.md

我們自己的方式

意識到我們正在以一種非常“獨特”的方式使用 Kubernetes ，這與社群中的大多數場景不同，我們決定定製自己的實現來完全滿足我們的需求。

從當前的單叢集過渡到多叢集，沒有太多事情要做。

• 叢集管理。我們已經使用 terraform 建立了當前叢集，因此我們可以 terraform 在解決網路問題並擁有足夠的 IP 後快速建立其他叢集。

• 排程。當我們決定根據名稱空間將資源分配到不同的叢集時，我們需要一箇中央排程服務：當傳入一個名稱空間時，該服務可以返回相應的叢集上下文，以便我們可以將資源部署到 CI/CD 服務。該服務還應支援 GRPC ，以與公司內部的分銷策略相統一。

• Golang 支援。我們有很多自研的 operator ，所以 operator 的維護者需要 Golang 包的支援。當然，這是一個不錯的選擇，因為他們可以通過 RPC 介面獲取叢集資訊。

• 自動化。使用單個叢集，我們通過 CLI 或簡單的指令碼手動完成叢集的構建、安裝工具、安裝和部署各種 operator 。現在有了多叢集，當手動一個一個地部署叢集似乎效率低下且容易出錯時，我們需要升級。因此，自動化相關的工具和完整的指令碼是必要的。

• 命令列工具。我們希望為使用者提供與單叢集場景相同的多叢集體驗，他們可以登入到我們的叢集來檢視他們的資源。為此，我們需要實現一個 kubectl 外掛來封裝相關邏輯，只要使用者通過名稱空間， kubectl 請求就可以轉發到相應的上下文中。

基本上，從單叢集到多叢集的架構變化如下。

正如所見，它比任何現有工具都更有效，並且更適合我們當前的情況。

結束

這是對我們遇到的問題、我們進行的討論以及在實施多叢集過程中引發的思考的回顧。我們沒有使用社群中的任何工具，但我們確實通過研究它們的功能、優缺點為自己鋪平了道路。

希望它也能為您提供多叢集實施的全景圖，並在您處於十字路口時有意義。

謝謝閱讀！ 多個維度分析k8s多叢集管理工具，到底哪個才真正適合你