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

• 高可用：在多個(gè)集群上部署應(yīng)用，可以最大限度地減少集群故障帶來的影響
• 避免廠商鎖定：可以將應(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 成熟度的問題，在 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)帶來的主要問題有兩個(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)了整體功能，通過定義多種自定義資源（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

用來保存被聯(lián)邦托管的集群的 API 認(rèn)證信息，可通過 ??kubefedctl join/unjoin?? 來加入/刪除集群，當(dāng)成功加入時(shí)，會(huì)建立一個(gè) ??KubeFedCluster?? CR 來存儲(chǔ)集群相關(guān)信息，如 API Endpoint、CA Bundle 和 Token 等。后續(xù) controller-manager 會(huì)使用這些信息來訪問不同 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ī)制建立在不同集群上時(shí)，就必須先在 Host 集群中，通過 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，用來描述對(duì)應(yīng)資源的結(jié)構(gòu)和分發(fā)策略（需要被分發(fā)到哪些集群上）；Federated Resource CRD 主要包括三部分：

• Templates 用于描述被聯(lián)邦的資源
• Placement 用來描述將被部署的集群，若沒有配置，則不會(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 可以通過 ??kubefedctl enable <target kubernetes API type>?? 來創(chuàng)建，也可以自己生成/編寫對(duì)應(yīng)的 CRD 再創(chuàng)建。

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

Scheduling

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

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

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

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 來存儲(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è)集群中；不過這個(gè) API Server 是 K8s 原生的，所以支持任何資源，不會(huì)出現(xiàn)之前 Federation v1 版本中的問題，然后聯(lián)邦托管資源的分發(fā)策略也是由一個(gè)單獨(dú)的 CRD 來控制的，也不需要配置 v2 中的 Federated Resource CRD 和 Type Configure。

Karmada 的一些基本概念：

• 資源模板（Resource Template）：Karmada 使用 K8s 原生 API 定義作為資源模板，便于快速對(duì)接 K8s 生態(tài)工具鏈
• 分發(fā)策略（Propagaion Policy）：Karmada 提供獨(dú)立的策略 API，用來配置資源分發(fā)策略
• 差異化策略（Override Policy）：Karmada 提供獨(dú)立的差異化 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

但是有一個(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?? 來控制這個(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è)資源后，可以通過 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ì)被篩選出來；除了集群親和性，還支持 ??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ù)制過來的，和不設(shè)置??ReplicaSchedulingStrategy?? 的效果是一樣的
• ??Divided??：根據(jù)有效的候選成員集群的數(shù)量，將副本分成若干部分，每個(gè)集群的副本數(shù)由??ReplicaDivisionPreference?? 決定

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

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

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

Override Policy

Override Policy 就很簡(jiǎn)單了，通過增加 ??OverridePolicy?? 這個(gè) CR 來配置不同集群的差異化配置，直接看一個(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