Fleet架构详解:让海量集群管理成为现实

在业界目前常见的模式是将独立的Kubernetes集群部署到边缘、异构云平台、本地数据中心等,进而能够在一个统一的平台上在边缘、物联网和多云空间中运行应用和服务。此外,还有更复杂的物联网用例,比如在本地和云环境中部署边缘应用。Rancher2.2版本之后开始支持多集群管理,用户可以借助Rancher在多个集群上同时部署和管理应用。但是当涉及到管理海量集群时,多集群管理的功能就稍显吃力。现在Rancher 2.5中引入了fleet,配置可以实现无缝衔接,在这种情况下可以使用部署规范中的配置将集群作为目标。Fleet于去年年初推出,它可以使用户能够像管理一个集群一样轻松地管理海量集群。用户可以从中央Kubernetes集群跨集群部署bundle(资源集合),并使用细粒度的目标/分组配置控制部署。Bundle不仅包括应用部署manifest,还包括任何可以描述为Kubernetes资源的东西。Rancher已经支持通过部署Rancher agent来导入由任何安装工具创建的Kubernetes集群,以实现服务器和集群之间的通信。集群所有者可以在导入的集群上启用监控和日志,启用服务网格Istio,配置流水线,管理访问等。在v2.4.0中增加了将K3s Kubernetes集群导入Rancher的功能,导入的K3s集群可以通过在Rancher UI中编辑K3s集群规范进行升级,该规范提供了从中央控制平面对众多K3s集群的集群级管理。Fleet与Rancher和K3s相结合,在集群和应用部署层面提供了真正的舰队管理。

架构和组件

Fleet有两个主要组件:fleet controller和cluster agent。Fleet-controller和所需的fleet-CRD一起部署在Kubernetes集群上,用户可以从那里在所有已注册的集群上操作deployment(使用传统的API或GitOps),这些集群组成了一个fleet-agent。Fleet足够轻量,因此可以运行在最小的deployment上,甚至在一个单节点集群中fleet也有优势。
图片

Fleet Manager/Controller

Fleet controller是一组跟踪所有相关fleet资源类型的Kubernetes controller,它可以运行在任何标准的Kubernetes集群上。Fleet manager暴露的唯一API是Kubernetes API,并且我们没有为fleet controller定制API。Fleet controller包括fleet管理Kubernetes集群的所需的CRD。
图片
Fleet controller(Kubernetes CRD)资源类型:
图片
Fleet controller-资源类型

Fleet Cluster Agent

fleet-controller与成员集群(member cluster)的所有通信都是通过部署在各自集群上的fleet-agents进行的。每个集群中运行一个cluster agent,负责与fleet-controller对话,所有的fleet-agent都应该能够从fleet-controller(Kubernetes API)拉取和推送更新,因为fleet-controller不会接触到成员集群(只需要连接:agent–>controller),因此所有管理的集群都可以运行在私有网络中(NAT之后)。

集群注册

单个集群上的所有fleet-agent可以使用集群组token安全地注册到fleet-controller,所有注册的集群可以拉取和推送所需的状态,然后再将状态推送回controller。Fleet controller动态地创建服务账户以管理它们的RBAC,然后将token给集群。必须生成一个集群组token才能向fleet controller注册集群。默认情况下,这个token将在1周内到期。该TTL可以更改。生成的集群组token可以在它仍然有效的时候反复使用,以注册新的集群。
图片
集群注册涉及多个controller,为一个集群组创建一个集群组token,一个集群组(包含用一个共同的集群组token注册的集群组)可以包含多个具有不同标签的站点(标签可以用于集群的特定选择)。用户可以通过在bundle中提供所需的配置,将资源部署的集群锁定在ClusterGroup(在集群中的所有单个集群上部署资源)或ClusterSelector(在集群组中的单个集群上部署资源)中。
图片
示例对象:如下所示,为两个集群组的edge-us-east和edge-us-west创建了两个 “clustergrouptokens”。每个集群组由两个具有不同标签的单独集群组成,并使用各自的集群组标记进行注册。
图片

Bundles

Bundle是一个资源的合集,其中包括额外的deployment特定信息,并且可以部署到多个集群。每个Bundle都是一个自定义资源,完全封装了所有的部署规范。Fleet使用bundle将磁盘上的bundle表示为一系列单独的文件,而不是管理一个大的并且嵌套了多个YAML文件的YAML文件,fleet apply将构建bundle资源并将其部署到fleet controller。
图片
Bundle利用多种方式渲染YAML到Kubernetes资源:Kubernetes YAML、Helm或者基于Kustomize的方法,也可以选择将这三种方式结合起来。

Bundle Layout

Bundle layout用于磁盘上供fleet读取命令,同时也是bundle自定义资源中嵌入式资源的预期结构。
图片

Bundle策略

用户可以选择使用常见的Kubernetes YAML、Helm、Kustomize或者三者的某种组合:
图片
Kustomize与Helm和Overlays可以提供一个可以分布在不同区域的配置,而无需改变标准/基础配置。一个将Kubernetes manifest与Kustomize和Overlay结合起来的典型例子如下所示:
图片

配置选项——bundle.yaml

图片

集群目标匹配

图片
同一个命名空间的所有群组中的所有集群都会被考虑,因为bundle将针对所有bundle目标进行评估。目标列表将被逐一评估,第一个匹配的目标将被用于该集群的bundle。如果没有匹配,则不会将该bundle部署到集群中。匹配集群的方法有三种:可以使用集群selector、集群组selector或明确的集群组名称。

简单试用

下面的拓扑结构包含三个集群组,每个集群组有两个集群。集群组’edge-us-west’和’edge-us-east’包含了两个集群,每个集群都在跨区域的Vultr上的各个虚拟机上启动K3s。集群组’edge-onprem-arm64’包含两个在树莓派4上运行K3s的集群,这表明成员集群可以在NAT后面运行,并实现私有网络。
图片
基于云的K3s集群:
图片

使用clusterGroupSelector部署Bundle

Bundle配置中的clusterGroupSelector允许用户根据集群组标签或集群组名称来匹配集群。
图片
下面显示的是一个同时使用Helm和Kustomize(包括manifest/模板中的YAML)的示例bundle配置,使用fleet进行部署,fleet使用标签和名称单独选择每个集群组。由于拓扑中每个集群组各有两个集群,因此会在所有集群中创建6个pod,每个集群有一个pod。如下图所示,kustomize目录对每个集群类型都有单独的配置,在这里,它添加了一个带有集群区域的nameprefix。Helm包含一个示例pod-template:’name: application-pod’。bundle.yaml由目标部分的匹配器组成,它使用’clusterGroupSelector'(metadata.label.region)和’clusterGroup'(metadata.name)对集群组进行分组。
图片
如下图所示,每个集群组都有一个独特的名称和标签(本例中为区域)与它们相关联。最初在部署上面的bundle之前,fleet显示所有三个集群组,每个集群上有2个bundle(agent相关的控制平面)一个。
图片
部署bundle ‘target-clustergroups’ 将bundle部署在所有集群上。如下图所示,在fleet输出中,一个bundle被添加到所有集群上,clusters-desired显示所有6个集群都有配置中提供的部署, bundle-deployments显示每个集群都使用唯一的名称(namespace-clustergroup_name-cluster-**)进行bundle部署。
图片
如下图所示,使用配置中的Helm chart 和提供的Kustomize配置为每个pod添加了名称前缀, pod(<region>-application-pod)会被部署到所有集群组(每个组有2个集群)。同样,用户也可以使用clusterGroupSelector根据集群组标签和名称来控制跨越异构环境(边缘站点、云、私有网络中的设备等)的特定集群上的部署。
图片
在目标配置中可以使用 “clusterGroup:{}”来在controller注册的所有集群上部署应用程序。

使用clusterSelector部署Bundles

Bundle配置中的’clusterSelector’允许用户匹配集群组中的单个集群。这个标志使用户能够使用集群注册时提供的标签,唯一地匹配/锁定分布在集群组中的单个集群。
图片
图片
下图所示的是一个同时使用Helm和Kustomize的示例bundle配置(包括manifests/templates中的YAML),这一配置由fleet部署,fleet使用标签单独选择clustergroup的每个集群的部分。如下所示,kustomize目录对每个集群类型都有单独的配置,在这里,它添加了一个带有集群区域的名称前缀。Helm包含一个示例pod-template: ‘name: application-pod’。Bundle.yaml由target部分的matcher组成,这些matcher用’clusterSelector'(metadata.label.env)注册的集群所附加的标签锁定集群。
图片
部署bundle ‘target-clusters’,将bundle部署在3个不同clustergroup的三个集群中。如下所示,一个Bundle只被添加到目标配置中选择的3个集群上,”clusters-desired “显示6个集群中的3个有配置中提供的部署,”bundle-deployments “显示3个集群有一个bundle使用一个独特的名称(namespace-clustergroup_name-cluster-**)部署。
图片
如下图所示,pod(<region>-application-pod)被部署在三个不同集群组的3个集群上。用户可以使用clusterSelector精心挑选 特定/单个 集群来部署资源。
图片
在目标配置中可以使用clusterSelector: {} 来在controller注册的所有集群上部署应用程序。

使用Rancher UI可视化

在Rancher 2.5中,Rancher启用了新的UI界面,用户可以导入fleet-controller集群,然后该dashboard会为fleet提供一个成熟的可视化和编辑功能的用户界面。除了fleet级别的可视化,dashboard还为用户提供了添加监控和日志的选项。K3s集群也可以导入,如下图所示:
图片
Fleet-controller集群:
图片
为所有3个集群组生成token。添加alt text:
图片
3个集群组,每个集群组有2个集群,并部署了ready/desired的bundle状态:
图片
集群组的集群注册请求及其各自的标签:
图片
在集群组下分组的各个集群,以及在集群级部署的bundle的ready/desired状态。
图片
Bundle部署和可用性状态:
图片
由于Fleet是作为标准的Kubernetes API实现的,它应该可以很好地集成到现有的生态系统中。随着多集群应用的部署,人们可以很容易地执行这些标准 “每个集群必须安装多个安全工具 “或 “特定的集群组应该有GDPR启用服务 “或 “集群组中的特定集群应该有一个独特的应用程序 “等。部署在fleet controller集群中的ArgoCD或Flux等工具,可以将Git中的资源复制到fleet controller中,然后由fleet controller管理在agent集群上的部署,从而实现了一个成熟的应用部署流水线,可以遍布10多个至1000多个集群。零售商为每个存在点或每个监控摄像头运行Kubernetes集群,或汽车公司在每辆联网汽车上运行集群,或制造公司在联网工业机器人上运行基于ARM的小尺寸设备上的集群,fleet与Rancher和K3s可以在边缘计算中发挥惊人的作用,将集群管理带到一个全新的规模。
赞(0) 打赏
未经允许不得转载:大咖说Rancher » Fleet架构详解:让海量集群管理成为现实

支付宝扫一扫打赏

img

微信扫一扫打赏

img