Kubernetes 多集群項(xiàng)目介紹

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

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

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

Federation v1

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

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

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

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

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

這種架構(gòu)帶來(lái)的主要問(wèn)題有兩個(gè)：

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

Federation v2

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

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

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

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

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

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

Cluster Configuration

用來(lái)保存被聯(lián)邦托管的集群的 API 認(rèn)證信息，可通過(guò) kubefedctl join/unjoin 來(lái)加入/刪除集群，當(dāng)成功加入時(shí)，會(huì)建立一個(gè) KubeFedCluster CR 來(lái)存儲(chǔ)集群相關(guān)信息，如 API Endpoint、CA Bundle 和 Token 等。后續(xù) controller-manager 會(huì)使用這些信息來(lái)訪問(wèn)不同 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)邦管理；比如說(shuō)想將 ConfigMap 資源通過(guò)聯(lián)邦機(jī)制建立在不同集群上時(shí)，就必須先在 Host 集群中，通過(guò) CRD 建立新資源 FederatedConfigMap，接著再建立名稱為 configmaps 的 Type configuration（FederatedTypeConfig）資源，然后描述 ConfigMap 要被 FederatedConfigMap 所管理，這樣 Kubefed controller-manager 才能知道如何建立 Federated 資源，一個(gè)示例如下：

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

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

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

一個(gè)示例如下：

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 可以通過(guò) kubefedctl enable 來(lái)創(chuàng)建，也可以自己生成/編寫對(duì)應(yīng)的 CRD 再創(chuàng)建。

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

Scheduling

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

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

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

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

如果需要在多個(gè)集群間進(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 是由華為開源的多云容器編排項(xiàng)目，這個(gè)項(xiàng)目是 Kubernetes Federation v1 和 v2 的延續(xù)，一些基本概念繼承自這兩個(gè)版本。

Karmada 主要有三個(gè)組件：

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

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

Karmada 的一些基本概念：

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

Cluster

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

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

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

Propagaion Policy

在 Karmada 中分發(fā)資源到 member 集群需要配置這個(gè)單獨(dú) PropagationPolicy CR；以下面的 nginx 應(yīng)用為例，首先是 Resource Template，這個(gè)就是普通的 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

之后配置一個(gè) PropagationPolicy 來(lái)控制這個(gè) nginx Deployment 資源的分發(fā)策略即可，在下面的示例中，會(huì)將 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)建這兩個(gè)資源后，可以通過(guò) Karmada API Server 查詢到該資源的狀態(tài)：

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

但是注意，這并不代表應(yīng)用運(yùn)行在 Karmada API Server 所在的集群上，實(shí)際上這個(gè)集群上沒有任何工作負(fù)載，只是存儲(chǔ)了這些 Resource Template，實(shí)際的工作負(fù)載都運(yùn)行在上面 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，如果這幾個(gè)篩選項(xiàng)都設(shè)置了，那只有全部條件都滿足的集群才會(huì)被篩選出來(lái)；除了集群親和性，還支持 SpreadConstraints：對(duì)集群動(dòng)態(tài)分組，按 region、zone 和 provider 等分組，可以將應(yīng)用只分發(fā)到某類集群中。

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

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

而這個(gè) ReplicaDivisionPreference 又有兩個(gè)可選值：

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

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

Override Policy

Override Policy 就很簡(jiǎn)單了，通過(guò)增加 OverridePolicy 這個(gè) CR 來(lái)配置不同集群的差異化配置，直接看一個(gè)例子：

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/