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

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

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

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

Rancher

Rancher 是一个由 Rancher Labs 的公司所维护的 Kubernetes 相关开源专案，Rancher Lab 於 2020 年底被 Suse 据传已 600万 ~ 700万美金左右收购，因此如果目前搜寻
Rancher 相关的资源有时候会看到跟 Suse 这间公司有关的消息就不要太意外。

简单来说，Rancher 是一个 Kubernetes 管理平台，希望能够让团队用更简单及有效率的方式去管理各式各样的 Kubernetes 丛集，其支援几种不同方式

1. Rancher 自行维护的 Kubernetes 版本，Rancher Kubernetes Engine(RKE)
2. 各大公有云所提供的 Kubernetes 服务，如 AKS, EKS 以及 GKE
3. 任何使用者自己创建的 Kubernetes 丛集

除了上述 Kubernetes 丛集外， Rancher 也支援众多公有云平台来简化整个部署流程，譬如可以让公有云自动创建 VM 并且於 VM 上创建 RKE 丛集，而且这些 VM
还可以根据不同的需求设定不同的能力，譬如某些节点设定 4c8g(4vCPU, 8G Memory)，某些给予 16c32g，同时有些专门当 worker，有些可以当 etcd/control plan等不同角色。

注: 不同来源的 Kubernetes 丛集功能上会有些许差异，详细可以参阅官网介绍，RKE 跟 EKS/GKE 於 2.5.8 版本则拥有全部的操作能力，但是 AKS 或是其他使用者自行架设的 Kubernetes 丛集会有些功能没办法使用。

有些人会好奇，如果自己都已经有方式去架设跟管理自己的 Kubernetes 丛集，那为什麽还需要使用 Rancher 的管理平台?
就如同 Kubernetes 一样，要不要导入 Rancher 也是要评估的，我认为符合下列情况的团队其实并不一定要使用 Rancher，譬如

1. 云端环境直接采用 Kubernetes 服务，如 EKS/AKS/GKE
2. 直接寻找系统整合商购买 Kubernetes 服务
3. 没有地端(On-premises)环境需求
4. 公司不太想要使用开源专案，希望专案都要有人员提供技术服务

如果团队都没有符合上述需求时，其实可以评估看看是否要导入 Rancher
导入的第一个问题就是导入 Rancher 能够带来什麽好处?，为什麽要使用 Rancher?

我个人认为 Rancher 对於团队带来的好处有

1. 很轻松地去架设一套 RKE 的环境，虽然本身是 Rancher 所维护的版本，但是大部分情况跟原生 Kubernetes 使用起来没有差异。
2. 如果团队同时有地端跟云端的混合环境，可以透过 Rancher 方便管理多套 Kubernetes
3. 如果今天地端环境本身拥有网路防火墙限制，导致想要从外部使用 Kubectl 来存取与管理该地端上的 Kubernetes 丛集会有困难时，使用 Rancher 能够轻松地处理这个问题。
4. Rancher 提供的 Dashboard 提供满多讯息，可以一目明了目前所有 Kubernetes 丛集的健康状态，非工程人员也可以容易阅读
5. Rancher 本身支援不同的认证机制，可以跟团队本身使用的认证服务整合，直接透过现有的状态来认证与授权，管理上非常方便

有了上述功能後，来看一下从官方所节录的架构图，来看看导入 Rancher 後对於整个团队有什麽变化?

上图分成三个部分，左边代表 DevOps Team，中间是 Rancher 管理平台，右边则是公司的 IT Team.
Rancher平台(中间)

1. Rancher 本身管理多套 Kubernetes 丛集，譬如图中的 GKE/EKS，甚至可以跟 VMware 整合，将 RKE 安装到产生的 VM 上
2. 如果已经跟公有云平台串接完毕(API)，则可以透过 Rancher 的介面自动创立相关 VM 并且直接再上面创建 RKE 丛集，因此可以很方便根据需求创立 Dev/Staging/QA/Prod 等不同用途的 Kubernetes 丛集

IT Team(右边)

1. IT Team 对於公司内的环境会有比较不同的需求，譬如帐号认证授权，安全政策等
2. IT 直接将 Rancher 与团队内的身份机制整合，可以让每个不同的 Kubernetes 都拥有不同的存取权限，譬如 QA Team 的人只拥有 QA 丛集的完全存取权限，而 Dev Team 的人可以存取 Dev 丛集，DevOps Team 的人则可以对所有丛集都有权限。
3. 可以直接於 Rancher 本身设定相关的安全政策，这些安全政策会直接套用到所有托管的 Kubernetes 丛集内。
4. Rancher 其实也有实作 Terraform 的介面，所以 IT Team 是可以直接透过 Terraform 使用 Infrastructure as Code 的概念来维护 Rancher，这样就可以很简单与快速的维护与创建各种丛集。

DevOps Team(左边)

1. DevOps Team 使用 IT Team 设定好的身份帐号来存取相关 Kubernetes 丛集
2. Rancher 也提供 KUBECONFIG 供使用者透过 kubectl/helm 等工具使用，也可以将此资讯整合到 CI/CD 流程来达成自动部署。
3. Rancher 也提供应用程序部署的相关机制让使用者可以方便地管理 Kubernetes 上的应用
4. Rancher 整合的 Monitoring/Logging/Alert 功能让使用者用起来很简单。
5. Rancher Fleet 使用 GitOps 的方式简化了部署流程，使用者只需要更新 Git Repo 就可以顺利更新自己的应用程序，甚至本身对於 Kubernetes 底层不太熟悉都能够顺利部署进去

当然上述架构只是一个范例，实际上更有可能是 DevOps Team 而非 IT Team 需要维护 Rancher 本身，这部分完全是取决於团队的分工与组成。

版本选择

目前主流的 Rancher 版本是 v2.5 系列，如果还没有使用过 Rancher 的读者建议都直接使用 v2.5 系列版本，主要是 v2.5 相对於前版有很多重大修改，譬如

1. Monitoring 功能的改进，v2.5 以前是用 Rancher 自行整合的 Prometheus/Grafana，所以使用者要客制化上会相对麻烦。 v2.5 整个架构都改成基於 Prometheus Operator 的做法，因此如果本来就熟悉 Prometheus Operator 的使用者可以更容易的使用 Rancher Monitoring 来加上自己想要的功能。
2. Rancher 的 UI 也有大幅度的改动，过往浏览观察 Cluster 的介面称为 Cluster Manager，而新版的 Cluster Explorer 将会是未来维护的主要功能
3. 整合 Rancher Fleet 来提供基於 GitOps 的部署方式，之後的章节会详细介绍如何使用 Rancher Fleet 来管理多丛集的应用程序
4. 提升与 AWS EKS 的整合，可以将已经创立的 EKS 直接整合到 Rancher 让管理员用一个 Rancher 去管理多个 Kubernetes

目前 v2.6 版本还在积极开发中，目前已知 2.6 也在努力提升与 AKS/GKE 的整合。
同时 Rancher v2.5 之後 Rancher 本身的安装方式也都转移到 Helm3，因此如果需要从旧版 Rancher 转移到新版 Rancher 时，有可能会遇到 Helm 转移的问题
所以新的使用者都强烈建议直上 v2.5，而不要再尝试旧版了。

下篇文章将详细介绍 Rancher 的架构，看完该架构会更加理解到底 Rancher 扮演何种角色。