技術文章 » Karmada大規模測試報告發布：突破100倍叢集規模

Karmada大規模測試報告發布：突破100倍叢集規模

2022-11-10 18:01:29
摘要：在本文中，我們將介紹用於測試的相關指標，如何進行大規模測試，以及我們如何實現大規模的叢集接入。

本文分享自華為雲社群《突破100倍叢集規模！Karmada大規模測試報告發布》，作者：華為云云原生團隊。

摘要

隨著雲原生技術在越來越多的企業和組織中的大規模落地，如何高效、可靠地管理大規模資源池以應對不斷增長的業務挑戰成為了當下雲原生技術的關鍵挑戰。在過去的很長一段時間內，不同廠商嘗試通過客製化Kubernetes原生元件的方式擴充套件單叢集的規模，這在提高規模的同時也引入了複雜的單叢集運維、不清晰的叢集升級路徑等問題。而多叢集技術能在不侵入修改Kubernetes單叢集的基礎上橫向擴充套件資源池的規模，在擴充套件資源池的同時降低了企業的運維管理等成本。

在Karmada的大規模落地程序中，Karmada的可延伸性和大規模逐漸成為社群使用者的新關注點。因此，我們對Karmada開展了大規模環境下的測試工作，以獲取Karmada管理多個Kubernetes叢集的效能基線指標。對於以Karmada為代表的多叢集系統而言，單叢集的規模不是制約它的資源池規模的限制因素。因此，我們參考了Kubernetes的大規模叢集的標準設定和使用者的生產落地實踐，測試了Karmada同時管理100個5k節點和2wPod的Kubernetes叢集的使用者場景。受限於測試環境和測試工具，本次測試並未追求測試到Karmada多叢集系統的上限，而是希望能覆蓋到在生產中大規模使用多叢集技術的典型場景。根據測試結果分析，以Karmada為核心的叢集聯邦可以穩定支援100個大規模叢集，管理超過50萬個節點和200萬個Pod，可以滿足使用者在大規模生產落地的需要。

在本文中，我們將介紹用於測試的相關指標，如何進行大規模測試，以及我們如何實現大規模的叢集接入。

背景

隨著雲原生技術的不斷髮展和使用場景的不斷豐富，多雲、分散式雲逐漸成為引領雲端計算髮展的趨勢。著名分析公司 Flexera 在 2021 的調查報告顯示，超過 93%的企業正同時使用多個雲廠商的服務，一方面受限於 Kubernetes 單叢集的業務承載能力和故障恢復能力，單一的叢集無法適應現有的企業業務，另一方面，在全球化的當下，企業出於避免被單家廠商壟斷的目的，或是出於成本等因素考慮，更傾向於選擇混合雲或者多公有云的架構。與此同時，Karmada 社群的使用者在落地的程序中也提出了多叢集下大規模節點和應用管理的訴求。

Karmada 介紹

Karmada(Kubernetes Armada)是一個 Kubernetes 管理系統，它能夠使你在無需修改應用的情況下跨叢集和跨雲執行你的雲原生應用。通過使用 Kubernetes 原生 API 並在其上提供高階排程功能，Karmada 實現了真正開放的多雲 Kubernetes。

Karmada 旨在為多雲和混合雲場景中的多叢集應用管理提供完全的自動化。它具備集中式多雲管理、高可用性、故障恢復和流量排程等關鍵特性。

Karmada 控制麵包括以下元件:

  • Karmada API Server
  • Karmada Controller Manager
  • Karmada Scheduler

ETCD 儲存了 Karmada 的 API 物件, karmada-apiserver 提供了與所有其他元件通訊的 REST 埠, 之後由 karmada-controller-manager 對你向 karmada-apiserver 提交的 API 物件進行對應的調和操作。

karmada-controller-manager 執行著各種控制器，這些控制器 watch 著 Karmada 的物件，然後傳送請求至成員叢集的 apiserver 來建立常規的 Kubernetes 資源。

多叢集系統資源池規模的維度和閾值

一個多叢集系統的資源池規模不單指叢集數量，即Scalability!=#Num of Clusters, 實際上多叢集資源池規模包含很多維度的測量，在不考慮其他維度的情況下只考慮叢集數量是毫無意義的。

我們將一個多叢集的資源池規模按優先順序描述為以下所示的三個維度：

  1. Num of Clusters: 叢集數量是衡量一個多叢集系統資源池規模和承載能力最直接且最重要的維度，在其餘維度不變的情況下系統能接入的叢集數量越多，說明系統的資源池規模越大，承載能力越強。
  2. Num of Resources(API Objects): 對於一個多叢集系統的控制面來說，儲存並不是無限制的，而在控制面建立的資源物件的數量和總體大小受限於系統控制面的儲存，也是制約多叢集系統資源池規模的重要維度。這裡的資源物件不僅指下發到成員叢集的資源模板，而且還包括叢集的排程策略、多叢集服務等資源。
  3. Cluster Size: 叢集規模是衡量一個多叢集系統資源池規模不可忽視的維度。一方面，叢集數量相等的情況下，單個叢集的規模越大，整個多叢集系統的資源池越大。另一方面，多叢集系統的上層能力依賴系統對叢集的資源畫像，例如在多叢集應用的排程過程中，叢集資源是不可或缺的一個因素。綜上所述，單叢集的規模與整個多叢集系統息息相關，但單叢集的規模同樣不是制約多叢集系統的限制因素。使用者可以通過優化原生的Kubernetes元件的方式來提升單叢集的叢集規模，達到擴大整個多叢集系統的資源池的目的，但這不是衡量多叢集系統效能的關注點。本次測試中，社群參考了kubernetes的大規模叢集的標準設定以及測試工具的效能，制定了測試叢集的規模，以貼切實際生產環境中的單叢集設定。在叢集的標準設定中，Node與Pod毫無疑問是其中最重要的兩個資源，Node是計算、儲存等資源的最小載體，而Pod數量則代表著一個叢集的應用承載能力。事實上，單叢集的資源物件也包括像service，configmap，secret這樣的常見資源。這些變數的引入會使得測試過程變得更復雜，所以這次測試不會過多關注這些變數。
  • Num of Nodes
  • Num of Pods

對於多叢集系統而言想要無限制地擴充套件各個維度而且又滿足 SLIs/SLOs 各項指標顯然是不可能實現的。各個維度不是完全獨立的，某個維度被拉伸相應的其他維度就要被壓縮，可以根據使用場景進行調整。以 Clusters 和 Nodes 兩個維度舉例，在 100 叢集下將單叢集的 5k 節點拉伸到 10k node 的場景或者在單叢集規格不變的同時擴充套件叢集數量到 200 叢集，其他維度的規格勢必會受到影響。如果各種場景都進行測試分析工作量是非常巨大的，在本次測試中，我們會重點選取典型場景設定進行測試分析。在滿足 SLIs/SLOs 的基礎上，實現單叢集支援 5k 節點，20k pod規模的100數量的叢集接入和管理。

SLIs/SLOs

可延伸性和效能是多叢集聯邦的重要特性。作為多叢集聯邦的使用者，我們期望在以上兩方面有服務質量的保證。在進行大規模效能測試之前，我們需要定義測量指標。在參考了 Kubernetes 社群的 SLI(Service Level Indicator)/SLO(Service Level Objectives)和多叢集的典型應用，Karmada 社群定義了以下 SLI/SLO 來衡量多叢集聯邦的服務質量。

  • API Call Latency
  • Resource Distribution Latency
  • Cluster Registration Latency
  • Resource usage

Note:

  1. 上述指標不考慮控制面和成員叢集的網路波動。同時，單叢集內的 SLO 不會考慮在內。
  2. 資源使用量是一個對於多叢集系統非常重要的指標，但是不同多叢集系統提供的上層服務不同，所以對各個系統來說資源的要求也會不同。我們不對這個指標進行強制的限制。
  3. 叢集註冊時延是從叢集註冊到控制面到叢集在聯邦側可用的時延。它在某種程度上取決於控制面如何收整合員叢集的狀態。

測試工具

ClusterLoader2

ClusterLoader2 是一款開源 Kubernetes 叢集負載測試工具，該工具能夠針對 Kubernetes 定義的 SLIs/SLOs 指標進行測試，檢驗叢集是否符合各項服務質量標準。此外 ClusterLoader2 為叢集問題定位和叢集效能優化提供視覺化資料。ClusterLoader2 最終會輸出一份 Kubernetes 叢集效能報告，展示一系列效能指標測試結果。然而，在 Karmada 效能測試的過程中，由於 ClusterLoader2 是一個為 Kubernetes 單叢集客製化的測試工具，且在多叢集場景下它不能獲取到所有叢集的資源， 因此我們只用 ClusterLoader2 來分發被 Karmada 管理的資源。

Prometheus

Prometheus 是一個開源的用於監控和告警的工具, 它包含資料收集、資料包告、資料視覺化等功能。在分析了 Clusterloader2 對各種監控指標的處理後，我們使用 Prometheus 根據具體的查詢語句對控制面的指標進行監控。

Kind

Kind 是一個是用容器來執行 Kubernetes 本地叢集的工具。為了測試 Karmada 的應用分發能力，我們需要一個真實的單叢集控制面來管理被聯邦控制面分發的應用。Kind 能夠在節約資源的同時模擬一個真實的叢集。

Fake-kubelet

Fake-kubelet 是一個能模擬節點且能維護虛擬節點上的 Pod 的工具。與 Kubemark 相比，fake-kubelet 只做維護節點和 Pod 的必要工作。它非常適合模擬大規模的節點和 Pod 來測試控制面的在大規模環境下的效能。

測試叢集部署方案

Kubernetes 控制面部署在單 master 的節點上。etcd，kube-apiserver，kube-scheduler 和 kube-controller 以單範例的形式部署。Karmada 的控制面元件部署在這個 master 節點上。他們同樣以單範例的形式部署。所有的 Kubernetes 元件和 Karmada 元件執行在高效能的節點上，且我們不對他們限制資源。我們通過 kind 來模擬單 master 節點的叢集，通過 fake-kubelet 來模擬叢集中的工作節點。

測試環境資訊

控制面作業系統版本

Ubuntu 18.04.6 LTS (Bionic Beaver)

Kubernetes 版本

Kubernetes v1.23.10

Karmada 版本

Karmada v1.3.0-4-g1f13ad97

Karmada 控制面所在的節點設定

  • CPU
Architecture:        x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order:          Little Endian
CPU(s): 64
On-line CPU(s) list: 0-63
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6266C CPU @ 3.00GHz
Stepping: 7
CPU MHz: 3000.000
BogoMIPS: 6000.00
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 30976K
NUMA node0 CPU(s): 0-31
NUMA node1 CPU(s): 32-63
  • 記憶體
Maximum Capacity: 512 GB
  • 磁碟
Disk /dev/vda: 200 GiB, 214748364800 bytes, 419430400 sectors

元件引數設定

  • karmada-apiserver
--max-requests-inflight=2000
--max-mutating-requests-inflight=1000
  • karmada-aggregated-server
--kube-api-qps=200
--kube-api-burst=400
  • karmada-scheduler
--kube-api-qps=200
--kube-api-burst=400
  • karmada-controller-manager
--kube-api-qps=200
--kube-api-burst=400
  • karmada-agent
--kube-api-qps=40
--kube-api-burst=60
  • karmada-etcd
--quota-backend-bytes=8G

測試執行

在使用 Clusterloader2 進行效能測試之前，我們需要自己通過組態檔定義效能測試策略。我們使用的組態檔如下：

unfold me to see the yaml

name: test
namespace:
   number: 10
tuningSets:
 - name: Uniformtinyqps
 qpsLoad:
 qps: 0.1
 - name: Uniform1qps
 qpsLoad:
 qps: 1
steps:
 - name: Create deployment
     phases:
 - namespaceRange:
             min: 1
             max: 10
 replicasPerNamespace: 20
 tuningSet: Uniformtinyqps
 objectBundle:
 - basename: test-deployment
 objectTemplatePath: "deployment.yaml"
 templateFillMap:
                  Replicas: 1000
 - namespaceRange:
             min: 1
             max: 10
 replicasPerNamespace: 1
 tuningSet: Uniform1qps
 objectBundle:
 - basename: test-policy
 objectTemplatePath: "policy.yaml"
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{.Name}}
  labels:
    group: test-deployment
spec:
  replicas: {{.Replicas}}
  selector:
 matchLabels:
      app: fake-pod
  template:
    metadata:
      labels:
        app: fake-pod
    spec:
      affinity:
 nodeAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 nodeSelectorTerms:
 - matchExpressions:
 - key: type
                    operator: In
                    values:
 - fake-kubelet
      tolerations:
 - key: "fake-kubelet/provider"
            operator: "Exists"
            effect: "NoSchedule"
      containers:
 - image: fake-pod
          name: {{.Name}}
# policy.yaml
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: test
spec:
 resourceSelectors:
 - apiVersion: apps/v1
      kind: Deployment
  placement:
 replicaScheduling:
 replicaDivisionPreference: Weighted
 replicaSchedulingType: Divided

Kubernetes 資源詳細的設定如下表所示：

詳細的測試方法和過程，可以參考

https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/docs/GETTING_STARTED.md[1]

測試結果

APIResponsivenessPrometheus:

Cluster Registration Latency:

Note: Karmada 的 Pull 模式適合用於私有云的場景。與 Push 模式相比，成員叢集會執行一個名為 karmada-agent 的元件。它會從控制面拉取使用者提交的應用，並執行在成員叢集中。在 Pull 模式叢集註冊的過程中，它會包含安裝 karmada-agent 的時間。如果 karmada-agent 的映象已經準備完畢的話，它很大程度上取決於單叢集內 Pod 啟動的時延。這裡不過多討論 Pull 模式的註冊時延。

Resource Distribution Latency:

Push Mode

Etcd latency:

Resource Usage:

Pull Mode

Etcd latency:

Resource Usage:

成員叢集中的 karmada-agent 消耗了 40m CPU(cores)和 266Mi Memory(bytes)。

結論與分析

在以上的測試結果中，API呼叫時延和資源分發時延均符合上述定義的SLIs/SLOs。在整個過程中，系統消耗的資源在一個可控制的範圍。因此，Karmada能穩定支撐100個大規模叢集，並且管理超過500,000個節點和2,000,000個的pods。在生產中，Karmada能有效支援數以百計的大規模的叢集。接下來，我們會具體分析每個測試指標的資料。

關注點分離：資源模板和策略

Karmada 使用 Kubernetes 原生 API 來表達叢集聯邦資源模板，使用可複用的策略 API 來表達叢集的排程策略。它不僅可以讓 Karmada 能夠輕鬆整合 Kubernetes 的生態, 同時也大大減少了控制面的資源數量。基於此，控制面的資源數量不取決於整個多叢集系統叢集的數量，而是取決於多叢集應用的數量。

Karmada 的架構整合了 Kubernetes 架構的簡潔性和擴充套件性。Karmada-apiserver 作為控制面的入口與 Kubernetes 的 kube-apiserver 類似。你可以使用單叢集設定中所需的引數優化這些元件。

在整個資源分發過程中，API 呼叫時延在一個合理的範圍。

叢集註冊與資源分發

在 Karmada 1.3 版本中，我們提供了基於 Bootstrap tokens 註冊 Pull 模式叢集的能力。這種方式不僅可以簡化叢集註冊的流程，也增強了叢集註冊的安全性。現在無論是 Pull 模式還是 Push 模式，我們都可以使用 karmadactl 工具來完成叢集註冊。與 Push 模式相比，Pull 模式會在成員叢集執行一個名為 karmada-agent 的元件。

叢集註冊時延包含了控制面收整合員叢集狀態所需的時間。在叢集生命週期管理的過程中，Karmada 會收整合員叢集的版本，支援的 API 列表以及叢集是否健康的狀態資訊。此外，Karmada 會收整合員叢集的資源使用量，並基於此對成員叢集進行建模，這樣排程器可以更好地為應用選擇目標叢集。在這種情況下，叢集註冊時延與叢集的規模息息相關。上述指標展示了加入一個 5,000 節點的叢集直至它可用所需的時延。你可以通過關閉叢集資源建模[2]來使叢集註冊時延與叢集的大小無關，在這種情況下，叢集註冊時延這個指標將小於 2s。

不論是 Push 模式還是 Pull 模式，Karmada 都以一個很快的速度來下發資源到成員叢集中。唯一的區別在於 karmada-controller-manager 負責所有 Push 模式叢集的資源分發，而 karmada-agent 只負責它所在那一個 Pull 模式叢集。因此, 在高並行條件下發資源的過程中，Pull 在相同設定條件下會比 Push 模式更快。你也可以通過調整 karmada-controller-manager 的--concurrent-work-syncs的引數來調整同一時間段內並行 work 的數量來提升效能。

Push 模式和 Pull 模式的資源使用量對比

在 Karmada 1.3 版本中，我們做了許多工作來減少 Karmada 管理大型叢集的資源使用量。現在我們很高興宣佈，相比於 1.2 版本，Karmada 1.3 在大規模場景下減少了 85% 的記憶體消耗和 32% 的 CPU 消耗。總的來說, Pull 模式在記憶體使用上有明顯的優勢，而在其他資源上相差的不大。

在 Push 模式中，控制面的資源消耗主要集中在 karmada-controller-manager，而 karmada-apiserver 的壓力不大。

從 karmada-apiserver 的 qps 以及 karmada-etcd 的請求時延我們可以看出 karmada-apiserver 的請求量保持在一個較低的水平。在 Push 模式中，絕大多數的請求來自 karmada-controller-manager。你可以設定--kube-api-qps and --kube-api-burst這兩個引數來控制請求數在一個確定的範圍內。

在 Pull 模式中，控制面的資源消耗主要集中在 karmada-apiserver，而不是 karmada-controller-manager。

從 karmada-apiserver 的 qps 以及 karmada-etcd 的請求時延我們可以看出 karmada-apiserver 的請求量保持在一個較高的水平。在 Pull 模式中，每個成員叢集的 karmada-agent 需要維持一個與 karmada-apiserver 通訊的長連線。我們很容易得出：在下發應用至所有叢集的過程中 karmada-apiserver 的請求總量是是 karmada-agent 中設定的 N 倍(N=#Num of clusters)。因此，在大規模 Pull 模式叢集的場景下，我們建議增加 karmada-apiserver 的--max-requests-inflight以及--max-mutating-requests-inflight引數的值，和 karmada-etcd 的--quota-backend-bytes引數的值來提升控制面的吞吐量。

現在 Karmada 提供了叢集資源模型[3]的能力來基於叢集空閒資源做排程決策。在資源建模的過程中，它會收集所有叢集的節點與 Pod 的資訊。這在大規模場景下會有一定的記憶體消耗。如果你不使用這個能力，你可以關閉叢集資源建模[4]來進一步減少資源消耗。

總結與展望

根據測試結果分析，Karmada可以穩定支援100個大規模叢集，管理超過50萬個節點和200萬個Pod。

在使用場景方面，Push模式適用於管理公有云上的Kubernetes叢集，而Pull模式相對於Push模式涵蓋了私有云和邊緣相關的場景。在效能和安全性方面，Pull模式的整體效能要優於Push模式。每個叢集由叢集中的karmada-agent元件管理，且完全隔離。但是，Pull模式在提升效能的同時，也需要相應提升karmada-apiserver和karmada-etcd的效能，以應對大流量、高並行場景下的挑戰。具體方法請參考kubernetes對大規模叢集的優化。一般來說，使用者可以根據使用場景選擇不同的部署模式，通過引數調優等手段來提升整個多叢集系統的效能。

由於測試環境和測試工具的限制，本次測試尚未測試到Karmada多叢集系統的上限，同時多叢集系統的效能測試仍處於方興未艾的階段，下一步我們將繼續優化多叢集系統的測試工具，系統性地整理測試方法，以覆蓋更大的規模和更多的場景。

參考資料

[1]https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/docs/GETTING_STARTED.md: https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/docs/GETTING_STARTED.md

[2]關閉叢集資源建模: https://karmada.io/docs/next/userguide/scheduling/cluster-resources#disable-cluster-resource-modeling

[3]叢集資源模型: https://karmada.io/docs/next/userguide/scheduling/cluster-resources

[4]關閉叢集資源建模: https://karmada.io/docs/next/userguide/scheduling/cluster-resources#disable-cluster-resource-modeling

 

點選關注，第一時間瞭解華為雲新鮮技術~