速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

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

  • 2021-04-06
  • 本文字数:4234 字

    阅读完需:约 14 分钟

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 可以在边缘计算中发挥惊人的作用,将集群管理带到一个全新的规模。


原文链接:

https://itnext.io/fleet-management-of-kubernetes-clusters-at-scale-ranchers-fleet-de161cc52325


本文转载自:RancherLabs(ID:RancherLabs)

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

2021-04-06 13:003666

评论

发布
暂无评论
发现更多内容

C语言编程:入门指南(一周内学懂)

计算机与AI

c

“让专业的人做专业的事”,畅捷通与阿里云的云原生故事

阿里巴巴中间件

云计算 云原生

阿里P8大牛亲自讲解!6年菜鸟开发面试字节跳动安卓研发岗,成功收获美团,小米安卓offer

欢喜学安卓

android 程序员 面试 移动开发

Serverless 在 SaaS 领域的最佳实践

阿里巴巴中间件

阿里巴巴 中间件

架构设计大作业 2

仲夏

十大经典排序算法最强总结(含Java、Python码实现)

Java 面试 算法

低代码旋风将席卷整个IT业界,带来应用开发的新革命和新里程!

J2PaaS低代码平台

史上最全面‘java监听器’解读,读完就能用进项目

Java架构师迁哥

百分点智能对话技术探索实践

DataFunTalk

AI

重庆打造区块链产业高地

CECBC

区块链

五步带你探究爬虫爬取视频弹幕背后的真相,附爬虫实现源码

小Q

学习 编程 架构 面试 python 爬虫

工具词典:中立观点

lidaobing

维基百科 28天写作

ReactNative | 通过文件下载/打开需求,聊聊使用三方库

梁龙先森

大前端 技术方案 React Native

IPFS系统APP软件开发

系统开发

我对2021的期待,从合上这份2020日历开始

脑极体

网络模拟器:Cisco Packet Tracer 设备登陆实验

2020盘点之手机失窃事件复盘分析

石君

信息安全 资金安全 手机失窃

云原生架构-静态代码扫描SonarQube超时

云原生实验室

DevOps 云原生 jenkins SonarQube Pipeli

腾讯T2手把手教你!字节跳动历年校招Android面试真题解析,含BATJM大厂

欢喜学安卓

android 程序员 面试 移动开发

全面 Severless 化只需要 7天!看南瓜电影的云上升级

阿里巴巴中间件

阿里巴巴 中间件

架构革新路漫漫,京东智联云自研服务器设计细节探秘

京东科技开发者

服务器 数据中心 IDC

打通经济命脉,区块链助力实体商超变革

CECBC

区块链

阿里P8大牛亲自讲解!Android高级工程师面试实战,Android岗

欢喜学安卓

android 程序员 面试 移动开发

美团面试:为什么就能直接调用userMapper接口的方法?

田维常

美团

小说内容理解

DataFunTalk

AI 推荐系统

甲方日常 77

句子

工作 随笔杂谈 日常

天下武功,唯”拆“不破之架构篇二 | 技术人应知的创新思维模型 (9)

Alan

架构 技术 技术人应知的创新思维模型 七日更 28天写作

58同城风控平台演进

DataFunTalk

架构 中台

时空大数据与智能技术的时代共舞,百度地图给2020的答案

脑极体

2020H1中国AI云服务市场规模增长远超预期;C++20 标准正式发布

京东科技开发者

云计算 AI IoT

Head First设计模式

田维常

Fleet架构详解:让海量集群管理成为现实_架构_Rancher_InfoQ精选文章