Kubernetes 多集群項目介紹

Kubernetes 從 1.8 版本起就聲稱單集群最多可支持 5000 個節(jié)點和 15 萬個 Pod，實際上應(yīng)該很少有公司會部署如此龐大的一個單集群，很多情況下因為各種各樣的原因我們可能會部署多個集群，但是又想將它們統(tǒng)一起來管理，這時候就需要用到集群聯(lián)邦（Federation）。

集群聯(lián)邦的一些典型應(yīng)用場景：

• 高可用：在多個集群上部署應(yīng)用，可以最大限度地減少集群故障帶來的影響
• 避免廠商鎖定：可以將應(yīng)用負(fù)載分布在多個廠商的集群上并在有需要時直接遷移到其它廠商
• 故障隔離：擁有多個小集群可能比單個大集群更利于故障隔離

Federation v1

最早的多集群項目，由 K8s 社區(qū)提出和維護(hù)。

Federation v1 在 K8s v1.3 左右就已經(jīng)著手設(shè)計（Design Proposal），并在后面幾個版本中發(fā)布了相關(guān)的組件與命令行工具（kubefed），用于幫助使用者快速建立聯(lián)邦集群，并在 v1.6 時，進(jìn)入了 Beta 階段；但 Federation v1 在進(jìn)入 Beta 后，就沒有更進(jìn)一步的發(fā)展，由于靈活性和 API 成熟度的問題，在 K8s v1.11 左右正式被棄用。

v1 的基本架構(gòu)如上圖，主要有三個組件：

• Federation API Server：類似 K8s API Server，對外提供統(tǒng)一的資源管理入口，但只允許使用 Adapter 拓展支持的 K8s 資源
• Controller Manager：提供多個集群間資源調(diào)度及狀態(tài)同步，類似 kube-controller-manager
• Etcd：儲存 Federation 的資源

在 v1 版本中我們要創(chuàng)建一個聯(lián)邦資源的大致步驟如下：把聯(lián)邦的所有配置信息都寫到資源對象 annotations 里，整個創(chuàng)建流程與 K8s 類似，將資源創(chuàng)建到 Federation API Server，之后 Federation Controller Manager 會根據(jù) annotations 里面的配置將該資源創(chuàng)建到各子集群；下面是一個 ReplicaSet 的示例：

這種架構(gòu)帶來的主要問題有兩個：

• 不夠靈活，每當(dāng)創(chuàng)建一種新資源都要新增 Adapter（提交代碼再發(fā)版）；并且對象會攜帶許多 Federation 專屬的 Annotation
• 缺少獨立的 API 對象版本控制，例如 Deployment 在 Kubernetes 中是 GA，但在 Federation v1 中只是 Beta

Federation v2

有了 v1 版本的經(jīng)驗和教訓(xùn)之后，社區(qū)提出了新的集群聯(lián)邦架構(gòu)：Federation v2；Federation 項目的演進(jìn)也可以參考 Kubernetes Federation Evolution 這篇文章。

v2 版本利用 CRD 實現(xiàn)了整體功能，通過定義多種自定義資源（CR），從而省掉了 v1 中的 API Server；v2 版本由兩個組件構(gòu)成：

• admission-webhook 提供了準(zhǔn)入控制
• controller-manager 處理自定義資源以及協(xié)調(diào)不同集群間的狀態(tài)

在 v2 版本中要創(chuàng)建一個聯(lián)邦資源的大致流程如下：

將 Federated Resource 創(chuàng)建到 Host 集群的 API Server 中，之后 controller-manager 會介入將相應(yīng)資源分發(fā)到不同的集群，分發(fā)的規(guī)則等都寫在了這個 Federated Resource 對象里面。

在邏輯上，F(xiàn)ederation v2 分為兩個大部分：configuration（配置）和 propagation（分發(fā)）；configuration 主要包含兩個配置：Cluster Configuration 和 Type Configuration。

Cluster Configuration

用來保存被聯(lián)邦托管的集群的 API 認(rèn)證信息，可通過 kubefedctl join/unjoin 來加入/刪除集群，當(dāng)成功加入時，會建立一個 KubeFedCluster CR 來存儲集群相關(guān)信息，如 API Endpoint、CA Bundle 和 Token 等。后續(xù) controller-manager 會使用這些信息來訪問不同 Kubernetes 集群。

apiVersion:?core.kubefed.io/v1beta1
kind:?KubeFedCluster
metadata:
??creationTimestamp:?"2019-10-24T08:05:38Z"
??generation:?1
??name:?cluster1
??namespace:?kube-federation-system
??resourceVersion:?"647452"
??selfLink:?/apis/core.kubefed.io/v1beta1/namespaces/kube-federation-system/kubefedclusters/cluster1
??uid:?4c5eb57f-5ed4-4cec-89f3-cfc062492ae0
spec:
??apiEndpoint:?https://172.16.200.1:6443
??caBundle:?LS....Qo=
??secretRef:
????name:?cluster1-shb2x
status:
??conditions:
??-?lastProbeTime:?"2019-10-28T06:25:58Z"
????lastTransitionTime:?"2019-10-28T05:13:47Z"
????message:?/healthz?responded?with?ok
????reason:?ClusterReady
????status:?"True"
????type:?Ready
??region:?""

Type Configuration

定義了哪些 Kubernetes API 資源要被用于聯(lián)邦管理；比如說想將 ConfigMap 資源通過聯(lián)邦機(jī)制建立在不同集群上時，就必須先在 Host 集群中，通過 CRD 建立新資源 FederatedConfigMap，接著再建立名稱為 configmaps 的 Type configuration（FederatedTypeConfig）資源，然后描述 ConfigMap 要被 FederatedConfigMap 所管理，這樣 Kubefed controller-manager 才能知道如何建立 Federated 資源，一個示例如下：

apiVersion:?core.kubefed.k8s.io/v1beta1
kind:?FederatedTypeConfig
metadata:
??name:?configmaps
??namespace:?kube-federation-system
spec:
??federatedType:
????group:?types.kubefed.k8s.io
????kind:?FederatedConfigMap
????pluralName:?federatedconfigmaps
????scope:?Namespaced
????version:?v1beta1
??propagation:?Enabled
??targetType:
????kind:?ConfigMap
????pluralName:?configmaps
????scope:?Namespaced
????version:?v1

Federated Resource CRD

其中還有一個關(guān)鍵的 CRD：Federated Resource，如果想新增一種要被聯(lián)邦托管的資源的話，就需要建立一個新的 FederatedXX 的 CRD，用來描述對應(yīng)資源的結(jié)構(gòu)和分發(fā)策略（需要被分發(fā)到哪些集群上）；Federated Resource CRD 主要包括三部分：

• Templates 用于描述被聯(lián)邦的資源
• Placement 用來描述將被部署的集群，若沒有配置，則不會分發(fā)到任何集群中
• Overrides 允許對部分集群的部分資源進(jìn)行覆寫

一個示例如下：

apiVersion:?types.kubefed.k8s.io/v1beta1
kind:?FederatedDeployment
metadata:
??name:?test-deployment
??namespace:?test-namespace
spec:
??template:?#?定義 Deployment 的所有內(nèi)容，可理解成 Deployment 與 Pod 之間的關(guān)聯(lián)。
????metadata:
??????labels:
????????app:?nginx
????spec:
??????...
??placement:
????clusters:
????-?name:?cluster2
????-?name:?cluster1
??overrides:
??-?clusterName:?cluster2
????clusterOverrides:
????-?path:?spec.replicas
??????value:?5

這些 FederatedXX CRD 可以通過 kubefedctl enable 來創(chuàng)建，也可以自己生成/編寫對應(yīng)的 CRD 再創(chuàng)建。

結(jié)合上面介紹了的 Cluster Configuration、Type Configuration 和 Federated Resource CRD，再來看 v2 版本的整體架構(gòu)和相關(guān)概念就清晰很多了：

Scheduling

Kubefed 目前只能做到一些簡單的集群間調(diào)度，即手工指定，對于手工指定的調(diào)度方式主要分為兩部分，一是直接在資源中制定目的集群，二是通過 ReplicaSchedulingPreference 進(jìn)行比例分配。

直接在資源中指定可以通過 clusters 指定一個 cluster 列表，或者通過 clusterSelector 來根據(jù)集群標(biāo)簽選擇集群，不過有兩點要注意：

• 如果 clusters 字段被指定，clusterSelector 將會被忽略
• 被選擇的集群是平等的，該資源會在每個被選中的集群中部署一個無差別副本

spec:
??placement:
????clusters:
????-?name:?cluster2
????-?name:?cluster1
????clusterSelector:
??????matchLabels:
????????foo:?bar

如果需要在多個集群間進(jìn)行區(qū)別調(diào)度的話就需要引入 ReplicaSchedulingPreference 進(jìn)行按比例的調(diào)度了：

apiVersion:?scheduling.kubefed.io/v1alpha1
kind:?ReplicaSchedulingPreference
metadata:
??name:?test-deployment
??namespace:?test-ns
spec:
??targetKind:?FederatedDeployment
??totalReplicas:?9
??clusters:
????A:
??????minReplicas:?4
??????maxReplicas:?6
??????weight:?1
????B:
??????minReplicas:?4
??????maxReplicas:?8
??????weight:?2

totalReplicas 定義了總副本數(shù)，clusters 描述不同集群的最大/最小副本以及權(quán)重。

目前 ReplicaSchedulingPreference 只支持 deployments 和 replicasets 兩種資源。

Karmada

Karmada 是由華為開源的多云容器編排項目，這個項目是 Kubernetes Federation v1 和 v2 的延續(xù)，一些基本概念繼承自這兩個版本。

Karmada 主要有三個組件：

• Karmada API Server：本質(zhì)就是一個普通的 K8s API Server，綁定了一個單獨的 etcd 來存儲那些要被聯(lián)邦托管的資源
• Karmada Controller Manager：多個 controller 的集合，監(jiān)聽 Karmada API Server 中的對象并與成員集群 API server 進(jìn)行通信
• Karmada Scheduler：提供高級的多集群調(diào)度策略

和 Federation v1 類似，我們下發(fā)一個資源也是要寫入到 Karmada 自己的 API Server 中，之前 controller-manager 根據(jù)一些 policy 把資源下發(fā)到各個集群中；不過這個 API Server 是 K8s 原生的，所以支持任何資源，不會出現(xiàn)之前 Federation v1 版本中的問題，然后聯(lián)邦托管資源的分發(fā)策略也是由一個單獨的 CRD 來控制的，也不需要配置 v2 中的 Federated Resource CRD 和 Type Configure。

Karmada 的一些基本概念：

• 資源模板（Resource Template）：Karmada 使用 K8s 原生 API 定義作為資源模板，便于快速對接 K8s 生態(tài)工具鏈
• 分發(fā)策略（Propagaion Policy）：Karmada 提供獨立的策略 API，用來配置資源分發(fā)策略
• 差異化策略（Override Policy）：Karmada 提供獨立的差異化 API，用來配置與集群相關(guān)的差異化配置，比如配置不同集群使用不同的鏡像

Cluster

Cluster 資源記錄的內(nèi)容和 Federation v2 類似，就是訪問被納管集群的一些必要信息：API Endpoint、CA Bundle 和訪問 Token。

spec:
??apiEndpoint:?https://172.31.165.66:55428
??secretRef:
????name:?member1
????namespace:?karmada-cluster
??syncMode:?Push

但是有一個不一樣的點是，Karmada 的 Cluster 資源有兩種 sync 模式：Push 和 Pull；Push 就是最普通、最常見的方式，host 集群的 Karmada 組件會負(fù)責(zé)同步并更新這類集群的狀態(tài)；Pull 模式的 member 集群上會運行一個 karmada-agent 組件，這個組件會負(fù)責(zé)收集自己的狀態(tài)并且更新 host 集群的相應(yīng)的 Cluster 資源狀態(tài)。

Propagaion Policy

在 Karmada 中分發(fā)資源到 member 集群需要配置這個單獨 PropagationPolicy CR；以下面的 nginx 應(yīng)用為例，首先是 Resource Template，這個就是普通的 K8s Deployment：

apiVersion:?apps/v1
kind:?Deployment
metadata:
??name:?nginx
??labels:
????app:?nginx
spec:
??replicas:?2
??selector:
????matchLabels:
??????app:?nginx
??template:
????metadata:
??????labels:
????????app:?nginx
????spec:
??????containers:
??????-?image:?nginx
????????name:?nginx

之后配置一個 PropagationPolicy 來控制這個 nginx Deployment 資源的分發(fā)策略即可，在下面的示例中，會將 nginx 應(yīng)用按 1:1 的權(quán)重比分發(fā)到 member1 和 member2 集群中：

apiVersion:?policy.karmada.io/v1alpha1
kind:?PropagationPolicy
metadata:
??name:?nginx-propagation
spec:
??resourceSelectors:
????-?apiVersion:?apps/v1
??????kind:?Deployment
??????name:?nginx
??placement:
????clusterAffinity:
??????clusterNames:
????????-?member1
????????-?member2
????replicaScheduling:
??????replicaDivisionPreference:?Weighted
??????replicaSchedulingType:?Divided
??????weightPreference:
????????staticWeightList:
??????????-?targetCluster:
??????????????clusterNames:
????????????????-?member1
????????????weight:?1
??????????-?targetCluster:
??????????????clusterNames:
????????????????-?member2
????????????weight:?1

在 Karmada API Server 中創(chuàng)建這兩個資源后，可以通過 Karmada API Server 查詢到該資源的狀態(tài)：

$ kubectl get deploy
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   2/2     2            2           51s

但是注意，這并不代表應(yīng)用運行在 Karmada API Server 所在的集群上，實際上這個集群上沒有任何工作負(fù)載，只是存儲了這些 Resource Template，實際的工作負(fù)載都運行在上面 PropagationPolicy 配置的 member1 和 member2 集群中，切換到 member1/member2 集群中可以看到：

$ kubectl get deploy
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           6m26s

$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-6799fc88d8-7cgfz   1/1     Running   0          6m29s

分發(fā)策略除了上面最普通的指定集群名稱外也支持 LabelSelector、FieldSelector 和 ExcludeClusters，如果這幾個篩選項都設(shè)置了，那只有全部條件都滿足的集群才會被篩選出來；除了集群親和性，還支持 SpreadConstraints：對集群動態(tài)分組，按 region、zone 和 provider 等分組，可以將應(yīng)用只分發(fā)到某類集群中。

針對有 replicas 的資源（比如原生的 Deployment 和 StatefulSet），支持在分發(fā)資源到不同集群的時候按要求更新這個副本數(shù)，比如 member1 集群上的 nginx 應(yīng)用我希望有 2 個副本，member2 上的只希望有 1 個副本；策略有很多，首先是 ReplicaSchedulingType，有兩個可選值：

• Duplicated：每個候選成員集群的副本數(shù)都是一樣的，從原本資源那里面復(fù)制過來的，和不設(shè)置 ReplicaSchedulingStrategy 的效果是一樣的
• Divided：根據(jù)有效的候選成員集群的數(shù)量，將副本分成若干部分，每個集群的副本數(shù)由 ReplicaDivisionPreference 決定

而這個 ReplicaDivisionPreference 又有兩個可選值：

• Aggregated：在考慮集群可用資源的情況下，將這些副本調(diào)度到盡量少的集群上，如果一個集群就能容納所有副本，那只會調(diào)度到這一個集群上，其它集群上也會存在相應(yīng)的資源，不過副本數(shù)是 0
• Weighted：根據(jù) WeightPreference 來劃分副本數(shù)，這個 WeightPreference 就很簡單了，直接指定每個集群的權(quán)重是多少

完整和詳細(xì)的結(jié)構(gòu)可以參考 Placement 的 API 定義。

Override Policy

Override Policy 就很簡單了，通過增加 OverridePolicy 這個 CR 來配置不同集群的差異化配置，直接看一個例子：

apiVersion:?policy.karmada.io/v1alpha1
kind:?OverridePolicy
metadata:
??name:?example-override
??namespace:?default
spec:
??resourceSelectors:
????-?apiVersion:?apps/v1
??????kind:?Deployment
??????name:?nginx
??targetCluster:
????clusterNames:
??????-?member1
????labelSelector:
??????matchLabels:
????????failuredomain.kubernetes.io/region:?dc1
??overriders:
????plaintext:
??????-?path:?/spec/template/spec/containers/0/image
????????operator:?replace
????????value:?'dc-1.registry.io/nginx:1.17.0-alpine'
??????-?path:?/metadata/annotations
????????operator:?add
????????value:
??????????foo:?bar

?參考鏈接

• https://blog.ihypo.net/15716465002689.html
• https://blog.ihypo.net/15718231244282.html
• https://jimmysong.io/kubernetes-handbook/practice/federation.html
• https://support.huaweicloud.com/productdesc-mcp/mcp_productdesc_0001.html

原文鏈接：https://xinzhao.me/posts/kubernetes-multi-cluster-projects/