Kubernetes多集群管理方案kubefed原理解析 | 您所在的位置:网站首页 › crd原理 › Kubernetes多集群管理方案kubefed原理解析 |
1. kubefed简介1.1 kubfed介绍 Kubefed(Federation v2)即 Kubernetes 联邦,是开源的多集群解决方案,目前的版本是 v0.8.1,处于beta阶段。Federation v1版本因为在扩展性、权限管理、架构等方便存在一定缺陷而被废弃。v2版本对v1版本架构进行了优化,使用CRD+operator的方式定义一系列自定义联邦资源,并通过自定义controller实现跨集群资源协调能力。 Kubefed可应用于突破单集群性能瓶颈、控制故障爆炸半径、异地多集群、混合云管理等场景,集群建立联邦后,可以将用户的k8s资源在多集群中分发并管理。 1.2 Kubfed组成![]() Kubefed所有组件部署在一个集群中,该集群作为Host集群,kubefed通过api访问其他成员集群的kube-apiserver实现对成员集群的管理,kubefed所在集群也可以配置为成员集群。 Kubefed主要由三个组件组成: Kubefed admission webhook:提供了准入控制,作用在CR的创建过程的校验阶段 Kubefed controller-manager:kubefed控制平面,处理自定义资源以及协调不同集群间的资源状态 Kubfedctl:二进制管理工具,实现用户和kubefed的交互,比如集群注册、资源注册等 2 kubefed CRD2.1 Kubefed CRD介绍Kubefed通过crd实现了对任意资源的联邦管理,相对于Federation v1需要通过扩展api-server的实现,大大提高了灵活性和扩展性。 Kubefed中CRD API GROUP如下表格所示: API GROUP 用途 备注 core.kubefed.io 集群信息、联邦资源信息、kubefed配置等 kubefedclusters.core.kubefed.io kubefedconfigs.core.kubefed.io propagatedversions.core.kubefed.io … types.kubefed.io 被联邦的kubernetes api/crd资源定义 federatedclusterroles.types.kubefed.io federatedconfigmaps.types.kubefed.io federatedingresses.types.kubefed.io federatedserviceaccounts.types.kubefed.io .. scheduling.kubefed.io 副本编排策略 replicaschedulingpreferences.scheduling.kubefed.io multiclusterdns.kubefed.io 跨集群服务发现配置 v0.7.0 版本后移除,kubefed专注于跨集群资源管理,该功能可由其他第三方工具(service meshes)实现。#issue1284 2.2 kubefed CRD的交互![]() 对集群资源联邦化的实现主要是通过两种CRD来完成,分别是 FederatedTypeConfig 和 Federated 。 FederatedTypeConfig定义了 Federated 和kubernetes api资源的关联关系。而 Federated 用来定义怎么去联邦化对应的kubernetes api资源。 一个典型的deployment的FederatedTypeConfig示例如下: apiVersion: types.kubefed.io/v1beta1 kind: FederatedDeployment metadata: name: fed-deploy namespace: fed-ns spec: template: {deployment-define} overrides: - clusterName: cluster-1 clusterOverrides: - path: /spec/replicas value: 10 - path: /spec/template/spec/containers/0/image value: nginx:1.17.0-alpine 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: PropagationFederated Type CRD包含三个部分: Template:该资源本身的定义,用于集群中该资源的创建 Placement:分发策略,定义该资源部署于哪些集群中 Overrides:对template中的字段进行覆盖重写,用于对资源的配置更新。如示例中对名称为cluster-1的member cluster中deployment的副本数和镜像进行了重新配置。Override中未选择的集群使用template的定义,保持不变。 用户通过kubefedctl enable 命令生成指定该资源类型的FederatedTypeConfig CRD,通过 kubefedctl federate 或者使用定义好的yaml文件对资源进行联邦部署。 2.3 集群资源调度CRDRSP(ReplicaSchedulingPreference)可以被视为对用户更友好的分发副本的机制,方便用户定义资源在不同集群的部署策略。用户只需要创建RSP资源和关联的联合资源(仅填充spec.template)可以将副本在各集群之前按照定义策略分发。 RSP模块可以对Federated Type CRD中placement和Overrides字段内容进行重写,rs重写数据来源于用户配置的调度文件。 一个典型的RSP文件定义示例如下,该RSP文件定义了一个deployment应用负载在部署时,各集群的部署策略。 apiVersion: scheduling.kubefed.io/v1alpha1 kind: ReplicaSchedulingPreference metadata: name: fed-deploy namespace: fed-ns spec: targetKind: FederatedDeployment totalReplicas: 20 clusters: "*": weight: 1 maxReplicas: 15 cluster-1: weight: minReplicas: 3 maxReplicas: 10RSP文件中主要包含以下字段: targetKind:定义该RSP文件应用的联邦资源类型,目前仅支持FederatedDeployment和FederatedReplicaSet。 totalReplicas:资源的总副本数,各个集群按照用户配置的权重或者比例进行资源计算时,会先根据总数进行计算得到一个初步结果,若集群中配置了最大值或最小值与计算得到的值冲突,则会使用用户配置的最大值或者最小值。因此实际的总副本数可能会和配置的总副本数不一致。 2.3 kubefed 实现原理kubefed使用自定义CRD和自定义controller 实现联邦集群的资源管理,原理如下图所示: ![]() Kubfed控制面主要由三个自定义controller组成: ClusterController: 集群控制器,用户通过kubefedctl join/unjoin 来加入/删除集群,当成功加入时,会建立一个 KubefedCluster 组件来储存集群相关信息,如 API Endpoint、CA Bundle 等。这些信息会被用在 KubeFed Controller 访问各 Kubernetes 集群,以确保能够建立 Kubernetes API 资源。并定时调用各集群的/healthz接口,维护可用集群列表,用于应用分发前的集群选择与过滤。 FederateTypeConfigController:联邦资源控制器,用于管理各集群间资源分发与状态监控。联邦资源控制器会为每种联邦资源类型创建一个资源分发控制器,和状态收集控制器,实现该类资源的联邦功能。StatusController和SyncController 都使用了FederatedInformer用来感知所有member cluster中某中联邦资源的变更。如果变更则从HostCluster中获取最新的资源定义同步到各memberCluster中。 SchedulerManage:调度控制器,用于创建适用于ReplicaSet和Deployment的RSPController,RSPController。当用户创建RSP资源后,RSP Controller 会收到通知,匹配对应 namespace/name 的 FederatedDeployment 与 FederatedReplicaSet 是否存在,若存在的话,会根据rsp中设定的策略计算出每个集群预期的副本数,之后覆写 Federated 资源中的 spec.overrides 内容以重新定义每个集群的副本数,最后再由 KubeFed Sync Controller 来同步至每个集群。 3 总结Kubefed通过crd与自定义controller实现了对任意资源的联邦,并支持用户自定义调度策略,易于扩展和维护。 目前多集群管理除了kubefed项目还有华为推出的karmada、阿里和redhat推出的OCM(open cluster management)项目,相对于karmada部署资源时host cluster上必须要部署,kubefed可以选择不部署在host cluster,减少了控制面所在集群的负担,但在资源管理和资源调度上karmada比kubefed有优势。另外kubefed相对于ocm,联邦化资源会产生较多的crd,在维护各集群中crd的api版本增加了负担。因此需要用户根据实际使用场景选择合适的多集群管理方案。 4 参考资料https://github.com/kubernetes-sigs/kubefed https://github.com/kubernetes-sigs/kubefed/blob/master/docs/userguide.md https://github.com/kubernetes-sigs/kubefed/issues/1284 https://techblog.cisco.com/blog/multi-cloud-fedv2/ https://blog.ihypo.net/15718231244282.html |
CopyRight 2018-2019 实验室设备网 版权所有 |