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

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

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

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

前言

前篇文章探讨了基本的 GitOps 概念，GitOps 本身没有严谨明确的实作与定义，所以任何宣称符合 GitOps 工作流程的解决方案其实作方式与使用方有可能并不相同。

本文将探讨数个常见的 GitOps 解决方案，针对其基本概念进行研究，一旦对这些解决方案都有了基本认知後，就可以更快的理解 Rancher Fleet 这套由 Rancher v2.5 後主推的 GitOps 解决方案是什麽，该怎麽使用。

KubeStack

GitOps 并不是专属於 Kubernetes 的产物，任何架构与专案都有机会采用 GitOps 的概念来实作。
KubeStack 是目前极为少数非 Kubernetes 应用程序的 GitOps 解决方案，官网宣称是一个专注於 Infrastructure 的 GitOps 框架。该架构基於 Terraform 去发展，因此 KubeStack 的使用者实际上还是撰写 Terraform ，使用 Terraform 的语言。 KubeStack 针对 Terraform 发展了两套不同的 Terraform Module，分别是 Cluster Module 以及 Cluster Service Module。

Cluster Module 让使用者可以方便的去管理 Kubernetes 丛集，该丛集可以很轻松的去指定想要建立於哪种云端架构上，透过 KubeStack 使用者也可以很容易的针对不同地区不管云端架构来搭建多套的 Kubernetes 丛集。
其实整体概念满类似 Rancher 的，只不过这边是依赖 Terraform 来管理与多个云端架构的整合，同时 Kubernetes 丛集也会采用原生版本或是 Kubernetes 管理服务的版本。

Cluster Service Module 目的是用来创造 Kubernetes 相关资源，所以使用上会先透过 Cluster Module 创建 Kubernetes 丛集，接者透过 Cluster Service Module 部署相关服务。
Cluster Service Module 的目的并不是部署各种团队的商业逻辑服务，相反的，其目的是则是部署前置作业，任何真正部署前需要用到的服务都会透过这个 Module 来处理。预设情况下 KubeStack 有提供 Catalog 清单来提供预设提供的服务，包含了

1. ArgoCD/Flux
2. Cert-Manager
3. Sealed Secrets
4. Nginx Ingress
5. Tekton
6. PostgreSQL Operator
7. Prometheus Operator

而前述两个则是针对 kubernetes 应用程序的 GitOps 解决方案。

KubeStack 的使用方式是采用前述探讨的第一种实作，团队需要准备一个专属的 CI/CD Pipeline，其内透过呼叫 Terraform 的方式来完成整个更新的流程，对於 KubeStack 有兴趣的可以参阅其官网。

ArgoCD/Flux

探讨到开源且针对 Kubernetes 应用程序部署的解决方案时，目前最知名的莫过於 ArgoCD 以及 Flux。

ArgoCD 本身的生态系非常丰富，该品牌底下有各式各样不同的专案，专注於不同功能，而这些功能又有机会彼此互相整合，譬如

1. ArgoCD
2. Argo Workflow
3. Argo RollOut

ArgoCD 是专注於 GitOps 的解决方案， Argo Workflow 是套 Multi-Stage 的 pipeline 解决方案，而 Argo Rollout 则是希望能够针对 Kubernetes 提供不同策略的部署方式，譬如蓝绿部署，金丝雀部署等，这些都是 Kubernetes 原生不方便实作的策略。

ArgoCD 采用的是第二种实作方式，需要於 Kubernetes 内安装 ArgoCD 解决方案，该解决方案大致上会於丛集内安装

1. Argo API Server
2. Argo Controller
3. Dex Server
4. Repository Service

以下架构图来自於官方网站

Argo Controller/Repository Service 是整个 GitOps 的核心功能，能够侦测 Git 专案的变动并且基於这些变动去比较当前 Kubernetes 内的即时状态是否符合 Git 内的期望状态，并且尝试更新以符合需求。
Argo API Server 则是提供一层 API 介面，让外界使用者可以使用不同方式来操作 ArgoCD 解决方案，譬如 CLI, WebUI 等。

ArgoCD 安装完毕後就会提供一个方式去存取其管理网页，大部分的使用者都会透过该管理网页来操作整个 ArgoCD，该介面的操作符合不同需求的使用者，譬如 PM 想要理解当前专案部署状态或是开发者想要透过网页来进行一些部署操作都可以透过该网页完成。
为了让 ArgoCD 可以更容易的支援不同帐户的登入与权限管理，其底层会预先安装 Dex 这套 OpenID Connector 的解决方案，使用者可以满容易地将 LDAP/OAuth/Github 等帐号群组与 ArgoCD 整合，接者透过群组的方式来进行权限控管。

应用程序的客制化也支援不少，譬如原生的 YAML，Helm, Kustomize 等，这意味者大部分的 kubernetes 应用程序都可以透过 ArgoCD 来部署。

ArgoCD 大部分的使用者一开始都会使用其 UI 进行操作与设定，但是这种方式基本上与 Rancher 有一样的问题

1. UI 提供的功能远少於 API 本身，UI 不能 100% 发挥 ArgoCD 的功能
2. 设定不易保存，不容易快速复制一份一样的 ArgoCD 解决方案，特别是当有灾难还原需求时。

举例来说，ArgoCD 可以管理多套 Kubernetes 丛集，这意味你可以於丛集(A)中安装 ArgoCD，透过其管理丛集B,C,D。
管理的功能都可以透过网页的方式来操作，但是要如何让 ArgoCD 有能力去存取丛集 B,C,D，相关设定则没辨法透过网页操作，必须要透过 CLI 或是修改最初部署 ArgoCD时的 YAML 档案。

ArgoCD 实际上於 Kubernetes 内新增了不少 CRD(Custom Resource Definition)，使用者於网页上的所有设定都会被转换为一个又一个的 Kubernetes 物件，而且 ArgoCD 本身的部署也是一个又一个 YAML 档案，因此实务上解决设定不易保存的方式就是 「让 ArgoCD 透过 GitOps 的方式来管理 ArgoCD」

该工作流程如下(范例)

1. 将所有对 ArgoCD 的设定与操作以 YAML 的形式保存於一个 Git 专案中
2. 使用官方 Helm 的方式去安装最乾净的 ArgoCD
3. 於 ArgoCD 的网页上新增一个应用程序，该应用程序目标是来自(1)的 Git 专案
4. ArgoCD 会将(1)内的 Git 内容都部署到 Kubernetes 中
5. ArgoCD 网页上就会慢慢看到所有之前设定的内容

如果对於 ArgoCD 有兴趣的读者可以参考我开设的线上课程kubernetes 实作手册： GitOps 版控整合篇
，该课程中会实际走过一次 ArgoCD 内的各种操作与注意事项，并且最後也会探讨 ArgoCD 与 Argo Rollout 如何整合让部署团队可以用金丝雀等方式来部署应用程序。

下篇文章就会回到 Rancher 专案身上，来探讨 Rancher Fleet 是什麽，其基本元件有哪些，接者会详细的介绍 Rancher Fleet 的用法。