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

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

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

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

概念探讨

Rancher 作为一个 Kubernetes 管理平台，提供不同的方式将 Kubernetes 丛集给汇入到 Rancher 管理平台中，不论是已经创立的 Kubernetes 或是先透过 Rancher 创造 RKE 接者汇入到 Rancher 中。

但是 Kubernetes 终究只是一个容器管理平台，前述介绍的各种机制或是 Rancher 整合的功能都是辅助 Kubernetes 的维护，对於团队最重要的还是产品本身，产品可能是由数个应用程序所组合而成，而每个应用程序可能对应到 Kubernetes 内又是多种不同的物件，譬如 Deployment, Service, StorageClass 等。
接下来会使用应用程序这个词来代表多个 Kubernetes 内的资源集合。

过往探讨到部署应用程序到 Kubernetes 丛集内基本上会分成两个方向来探讨

1. 如何定义与管理应用程序供团队使用
2. 部署应用程序给到 Kubernetes 丛集的流程

定义与管理应用程序

Kubernetes 的物件基本上可以透过两种格式来表达，分别是 JSON 与 YAML，不过目前主流还是以 YAML 为主。
这意味这一个最简单管理应用程序的方式就是使用一堆 YAML 档案，档案内则是各种 Kubernetes 的物件。

这些应用程序本身还需要考虑到下列使用情境

1. 该应用程序会不会需要跨团队使用
2. 该应用程序是否需要针对不同环境有不同的参数
3. 该应用程序本身有没有其他相依性，譬如部署 A 应用程序会需要先部署 B 应用程序
4. ...等

上述的这些使用情境是真实存在的，而为了解决这些问题，大部分情况下都不会使用纯 YAML 档案来管理应用程序，譬如想要让一个 Service 针对不同环境有不同设定就不太好处理，除了准备多个几乎一样的档案外几乎没有办法。
目前主流的管理方式有 Helm, Kustomize，其余的还有 ksonnet 等。
不同解决方案都采用不同的形式来管理与部署应用程序，举例来说
使用 Helm 的使用者可以采用下列不同方式来安装应用程序

1. helm install
2. helm template | kubectl apply -

而使用 kustomize 的使用者则可以使用

1. kustomize ...
2. kubectl -k ...

因为 kubectl 目前已经内建 kustomize 的功能，所以直接使用 kustomize 指定或是 kubectl 都可以。
当团队选择好如何管理与部署这些应用程序後，下一个问题就是如何部署这些 Helm/Kustomize 物件到 Kubernetes 丛集。

部署流程

基本上所有的部署都以自动化为目标去探讨，当然这并不代表手动部署就没有其价值，毕竟在自动化部署有足够的信心前，团队也必定会经历过各式各样的手动部署，甚至很多自动化的撰写与开发也是都仰赖手动部署的经验。

从 Rancher 的角度来看，自动化部署有三种不同的方式

1. Kubeconfig
2. Rancher Catalog
3. Rancher Fleet

下面稍微探讨一下这三者的概念与差异。

Kubeconfig

一个操作 Kubernetes 最简单的概念就是直接使用 kubectl/helm 等指令进行控制，而 Rancher 也有针对每个帐户提供可存取 Kubernetes 丛集所要使用的 KUBECONFIG。

假设团队已经完成 CI/CD 的相关流程，就可以於该流程中透过该 KUBECONFIG 来得到存取该 Kubernetes 的权限，接者使用 Helm/Kubectl 等功能来部署应用程序到丛集中。

基本上使用这种方式没有什麽大问题，毕竟 RKE 也是一个 Kubernetes 丛集，所以如果团队已经有现存的解决方案是透过这种类型部署的话，继续使用这种方式没有任何问题。

Rancher Catalog

Rancher 本身有一个名为 catalog 的机制用来管理要部署到 Rancher 内的应用程序，这些应用程序必须要基於 Helm 来管理。

其底层背後也是将 Helm 与 Helm values 转换为 YAML 档案然後送到 Kubernetes 中。
这种作法跟第一种最大的差异就是，所有的安装与管理中间都多了一层 Rancher Catalog 的管理。

CI/CD 流程要存取时就不是针对 Kubernetes 丛集去使用，也不需要取得 KUBECONFIG。
相反的需要取得 Rancher API Token，让你 CI/CD 内的脚本有能力去呼叫 Rancher，要求 Rancher 去帮忙创建，管理，删除不同的 Catalog。

这种方式只限定於 Rancher 管理的丛集，所以如果团队中不是每个丛集都用 Rancher 管理，那这种方式就不推荐使用，否则只会让系统混乱。

Rancher Fleet

Rancher Fleet 是 Rancher v2.5 正式推出的功能，其替代了过往的 Rancher pipeline(前述文章没有探讨，因为基本上要被淘汰了)的部署方式。

Fleet 是一个基於 GitOps 策略的大规模 Kubernetes 应用部署解决方案，基於 Rancher 的架构使得 Fleet 可以很轻松的存取所有 Rancher 控管的 Kubernetes 丛集，同时 GitOps 的方式让开发者可以简单的一口气将应用程序更新到多个 Kubernetes 丛集。

接下来的文章就会从 Rancher Catalog 出发，接者探讨 GitOps 与 Rancher Fleet 的使用方式。