本文将於赛後同步刊登於笔者部落格

有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读

更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

对於 Kubernetes 与 Linux Network 有兴趣的可以参阅笔者的线上课程

前言

前篇文章探讨了 ArgoCD 与 KubeStack 这两套截然不同的 GitOps 解决方案，可以观察到 GitOps 就是一个文化与精神，实际的操作与部署方式取决於不同解决方案。

Rancher 本身作为一个 Kubernetes 管理平台，不但可以管理已经存在的 Kubernetes 丛集更可以动态的於不同架构上创建 RKE 丛集。
基於这些功能的基础上，Rancher 要实作 GitOps 似乎会简单一些，毕竟连 Kubernetes 都可以创建了，要部署一些 Controller 到丛集内也不是什麽困难的事情，因此本篇文章就来仔细探讨 Rancher Fleet 这套 Rancher 推出的 GitOps 解决方案。

Rancher Fleet

Rancher Fleet 是 Rancher 於 v2.5 後正式推出的应用程序安装功能，该安装方式不同於 Catalog 以及 v2.5 的 App 专注於单一应用安装，而是更强调如何透过 GitOps 来进行大规模部署。

Fleet 的设计初衷就是希望提供一个大规模的 GitOps 解决方案，大规模可以是大量的 Kubernetes 丛集或是大量的应用程序部署。为了满足这个目标， Fleet 架构设计上就是追求轻量与简单，毕竟 Rancher 拥有另外一套针对物联网环境的轻量级 Kubernetes 丛集，K3s。 因此 Fleet 也希望能够针对 K3s 这种轻量级环境来使用。

Fleet 支援三种不同的格式，分别是原生YAML, Helm 以及 Kustomize，其中最特别的是这些格式还可以互些组合，这意味者使用者可以透过 Helm + Kustomize 来客制化你的应用程序，之後会有文章针对这些使用情境来介绍这类型的用途及好处。

Fleet 的内部逻辑会将所有的应用程序动态的转为使用 Helm 去安装与部署，因此使用者除了透过 Rancher Fleet 之外也可以透过 Helm 的方式去观察与管理这些应用程序，简单来说 Fleet 希望可以让透过使用者简单的安装大规模的应用程序，同时又提供一个良好的介面让使用者可以管理这些应用程序。

下图来自於官方网站，该图呈现了 Fleet 的基本架构与使用概念。图中有非常多的专有名词，了解这些名词会对我们使用 Fleet 有非常大的帮助，因此接下来针对这张图进行详细介绍。

Fleet 与大部分的 Operator 实作方式一样，都是透过 Kubernetes CRD 来自定义相关资源，并且搭配一个主要的 Controller 来处理这些资源的变化，最终提供 GitOPs 的功能，因此图上看到的大部分名词实际上都可以到 Kubernetes 内找到一个对应的 CRD 资源。

Fleet Manager/Fleet Controller:

由於 Fleet 是一个可以管理多个 Kubernetes 丛集的解决方案，其采取的是 Manager/Agent 的架构，所以架构中会有一个 Kubernetes 丛集其扮演者 Fleet Manager 的概念，而被管理的 Kubernetes 丛集则是所谓的 Fleet Agent
上图中的 Fleet Controller Cluster 就是一个拥有 Fleet Manager 的 Kubernetes 丛集，底下三个 Cluster Group 代表的是其里面的所有 Kubernetes 丛集都是 Fleet Agent

Fleet Manager 的概念中，实际上会部署一个名为 Fleet Controller 的 Kubernetes Pod，该服务要负责处理 Fleet Agent 注册的资讯，同时也要协调多个 Fleet Agent 当前的部署状态最後呈现到 UI 中供管理者使用。

Fleet Agent:

每一个想要被管理的 Kubernetes 丛集都被视为 Fleet Agent，实际上需要安装一个名为 Fleet Agent 的 Kubernetes Pod 到丛集中，该 Agent 会负责跟 Fleet Manager 沟通并且注册，确保该丛集之後可以顺利地被 Fleet Manager 给管理。

Single/Multi Cluster Style:

Fleet 的官方网站提及两种不同的部署模式，分别是 Single Cluster Style 以及 Multi Cluster Style
Single Cluster Style 主要是测试使用，该架构下会於一个 Kubernetes 丛集中同时安装 Fleet Agent 与 Fleet Controller，这样就可以於一个 Kubernetes 丛集中去体验看看 Rancher Fleet 带来的基本部署功能。
不过实务上因为会有更多的丛集要管，因此都会采用 Multi Cluster Style，该架构如同上图所示，会有一个集中的 Kubernetes 丛集作为 Fleet Manager，而所有要被管理的 Kubernetes 丛集都会作为 Fleet Agent.

GitRepo:

Fleet 中会有一个名为 GitRepo 的物件专门用来代表各种 Git 的存取资讯，Fleet Manager 会负责去监控欲部署的 Git 专案，接者将这些专案的内容与差异性给部署到被视为 Fleet Agent 的 Kubernetes 丛集。

Bundle

Bundle 可以说是整个 Fleet 中最重要也是最基本的资源，其代表的是一个又一个要被部署的应用程序。
当 Fleet Manager 去扫描 GitRepo 时，就会针对该 GitRepo 中的各种档案(YAML, Helm, Kustomize) 等
产生多个 Bundle 物件。
Bundle 是由一堆 Kubernetes 物件组成的，基本上也就是前篇所探讨的应用程序。举例来说，今天 Git 专案中透过 Helm 的方式描述了三种应用程序，Fleet Manager 扫描该 GitRepo 後就会产生出对应的三个 Bundle 物件。接者 Fleet Manager 就会将该 Bundle 给转送到要部署该应用程序的 Fleet Agent 丛集，最後 Fleet Agent 就会将这些 Bundle 动态的转成 Helm Chart 并且部署到 Kubernetes 丛集。

从上方的架构图来看，可以看到中间的 Fleet Cluster 本身会连接 Git 专案，并且针对这些专案产生出一个又一个 Bundle 资源(Bundle Definition)，接者这些 Bundle 就会被传送到需要部署的 Kubernetes 丛集，该丛集上的 Fleet Agent 就会负责处理这些 Bundle，譬如补上针对自身丛集的客制化设定，最後部署到丛集内。
所以可以看到上图左下方的 Kubernetes 丛集内使用的是 (Bundle with Cluster Specific Configuration) 的字眼，代表这些真正部署到该丛集内的 Bundle 都是由最基本的 Bundle 档案配上每个丛集的客制化内容。

为了让 Fleet 能够尽可能地去管理不同架构的 Kubernetes 丛集， Fleet 跟 Rancher 本身的设计非常类似，都是采取 Agent Pull 的方式。该模式代表的是 Fleet Controller 不会主动的去跟 Fleet Agent 进行连线，而是由 Fleet Agent 主动的去建立连线。
这种架构的好处就是被管理的 Kubernetes 丛集可以将整个网路给隐藏到 NAT 後面，只要确保底层环境有 SNAT 的功能网路可以对外即可。