智汇华云 | Kubernetes多集群管理方案kubefed原理解析

Kuberes 原生的管理能力目前仍然停留在单集群级别。每一个集群可以稳定地自治运行，却缺乏横贯多个集群的统筹管理能力。Kubefed是开源的多集群管理方案，可应用于突破单集群性能瓶颈、异地多集群、混合云管理等场景。通过CRD+Operator的方式定义一系列自定义联邦资源，并通过自定义Controller实现跨集群资源协调能力。

kubefed简介

1.1 kubfed介绍

Kubefed（Federation v2）即 Kuberes 联邦，是开源的多集群解决方案，目前的版本是 v0.8.1，处于beta阶段。Federation v1版本因为在扩展性、权限管理、架构等方便存在一定缺陷而被废弃。v2版本对v1版本架构进行了优化，使用CRD+operator的方式定义一系列自定义联邦资源，并通过自定义controller实现跨集群资源协调能力。

Kubefed可应用于突破单集群性能瓶颈、控制故障爆炸半径、异地多集群、混合云管理等场景，集群建立联邦后，可以将用户的k8s资源在多集群中分发并管理。

1.2 Kubfed组成

Kubefed组件图

Kubefed所有组件部署在一个集群中，该集群作为Host集群，kubefed通过api访问其他成员集群的kube-apiserver实现对成员集群的管理，kubefed所在集群也可以配置为成员集群。

Kubefed主要由三个组件组成

Kubefed admission webhook提供了准入控制，作用在CR的创建过程的校验阶段

Kubefed controller-managerkubefed控制平面，处理自定义资源以及协调不同集群间的资源状态

Kubfedctl二进制管理工具，实现用户和kubefed的交互，比如集群注册、资源注册等

2 kubefed CRD

2.1 Kubefed CRD介绍

Kubefed通过crd实现了对任意资源的联邦管理，相对于Federation v1需要通过扩展api-server的实现，大大提高了灵活性和扩展性。

Kubefed中CRD API GROUP如下表格所示

2.2 kubefed CRD的交互

CRD组成及交互图

对集群资源联邦化的实现主要是通过两种CRD来完成，分别是 FederatedTypeConfig 和 Federated。

FederatedTypeConfig定义了 Federated和kuberes api资源的关联关系。而 Federated用来定义怎么去联邦化对应的kuberes api资源。

一个典型的deployment的FederatedTypeConfig示例如下

apiVersion: types.kubefed.io/v1beta1

kd: FederatedDeployment

metadata:

name: fed-deploy

namespace: fed-ns

spec:

template:

{deployment-defe}

overrides:

- clusterName: cluster-1

clusterOverrides:

- path: /spec/replicas

value: 10

- path: /spec/template/spec/contaers/0/image

value: ngx:1.17.0-alpe

placement:

clusters:

- name: cluster-1

- name: cluster-2

status:

clusters:

- name: cluster -1

- name: cluster -2

conditions:

- lastTransitionTime: "2021-12-13T09:40:27Z"

status: "True"

type: Propagation

Federated Type CRD包含三个部分

Template:该资源本身的定义，用于集群中该资源的创建

Placement:分发策略，定义该资源部署于哪些集群中

Overrides对template中的字段进行覆盖重写，用于对资源的配置更新。如示例中对名称为cluster-1的member cluster中deployment的副本数和镜像进行了重新配置。Override中未选择的集群使用template的定义，保持不变。

用户通过kubefedctl enable命令生成指定该资源类型的FederatedTypeConfig  CRD，通过 kubefedctl federate或者使用定义好的yaml文件对资源进行联邦部署。

2.3 集群资源调度CRD

RSP（ReplicaSchedulgPreference）可以被视为对用户更友好的分发副本的机制，方便用户定义资源在不同集群的部署策略。用户只需要创建RSP资源和关联的联合资源（仅填充spec.template）可以将副本在各集群之前按照定义策略分发。

RSP模块可以对Federated Type CRD中placement和Overrides字段内容进行重写，rs重写数据来源于用户配置的调度文件。

一个典型的RSP文件定义示例如下，该RSP文件定义了一个deployment应用负载在部署时，各集群的部署策略。

apiVersion: schedulg.kubefed.io/v1alpha1

kd: ReplicaSchedulgPreference

metadata:

name: fed-deploy

namespace: fed-ns

spec:

targetKd: FederatedDeployment

totalReplicas: 20

clusters:

"":

weight: 1

maxReplicas: 15

cluster-1:

weight:

mReplicas: 3

maxReplicas: 10

RSP文件中主要包含推火网以下字段

targetKd定义该RSP文件应用的联邦资源类型，目前仅支持FederatedDeployment和FederatedReplicaSet。

totalReplicas资源的总副本数，各个集群按照用户配置的权重或者比例进行资源计算时，会先根据总数进行计算得到一个初步结果，若集群中配置了最大值或最小值与计算得到的值冲突，则会使用用户配置的最大值或者最小值。实际的总副本数可能会和配置的总副本数不一致。

2.3 kubefed 实现原理

kubefed使用自定义CRD和自定义controller 实现联邦集群的资源管理，原理如下图所示

Kubfed控制面主要由三个自定义controller组成

ClusterController: 集群控制器，用户通过kubefedctl jo/unjo 来加入/删除集群，当成功加入时，会建立一个 KubefedCluster 组件来储存集群相关信息，如 API Endpot、CA Bundle 等。这些信息会被用在 KubeFed Controller 访问各 Kuberes 集群，以确保能够建立 Kuberes API 资源。并定时调用各集群的/healthz接口，维护可用集群列表，用于应用分发前的集群选择与过滤。