Rancher是一个开源的企业级多集群Kubernetes管理平台，实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理，以确保集群的安全性，加速企业数字化转型。——Rancher官网
目前已经使用Rancher做自己个人服务的集群管理已经有2年左右了，个人的感觉是非常舒适，且非常贴合我的场景。因此总结一下我自己用Rancher的一些体验。
我目前所使用的版本是: 2.5.7
多集群管理
如上面官网所说，Rancher主打的就是一个多集群管理。而这一点事实上是非常重要的。
爆炸半径
把鸡蛋放进一个篮子里始终不是我的做事风格，我一向倾向于狡兔三窟。
在真实的场景中往往会发生各种各样的预料不到的状况。即使我线上的机器分散在两个不同的区域，而且配置了3个etcd节点和3个control plane节点。集群仍然并不100%的可靠。
在这2年左右的时间里，曾经出现过我自己失误导致过一次集群重建。还有一次由于云提供商的问题，导致集群长达4个小时无法操作。（建议把我自己开除，并且换个云提供商）
面对这些人祸与天灾，我很庆幸我没有把所有东西放在同一个集群里。这也是为什么我的网络那一套伪·CDN不考虑纳入集群管理的理由，同时也是为什么我OpenLDAP的迁移为什么会发生在比较后期的原因之一。
因此，缩小爆炸半径是多集群以及多集群管理带来的好处。
专群专用
我的两个集群一个在我家里，一个在云上。显然，这两个集群的物理条件相差甚远，而对这两个集群的期望也是完全不一样的。
云上的集群主要运行的是我财政系统自动化的那一套东西，以及以Jenkins为首的各种基础设施。其任务相对专一，而且也不会有很多的改动。
相比之下家里的集群就显得“多才多艺”。一方面，绝大多数.pub的服务都是由家里的集群提供的。另一方面，为云上的那一套提供了一个测试环境。最后家里的集群也是家庭网络中心，是CCTV、DNS等服务的提供者。
显而易见，家里的集群的可靠性要求是远低于云上集群的。因此总体来说，云上的集群的各种规则也比家里的集群严格的多。
我是通过“专群专用”来减少我自己的运维压力，毕竟不是所有服务都是第一优先级。处于人力的限制，只有部分服务是出错时立刻修复。
成本低
我曾经也是手搭k8s，直接写yml，直到我我接触了Rancher。在那之后，我知道我可能一辈子也学不会k8s了。因为，Rancher把成本降的太低了。
Rancher自身搭建
Rancher的搭建是非常简单且轻松的。在规模不大，对Rancher本身的可用性要求没有到非常高的话（Rancher master down不会导致所管理的k8s down掉），搭建只需要一键就可以了。
docker run -d --restart=unless-stopped -p 443:443 -v /data/rancher:/var/lib/rancher --privileged rancher/rancher:latest
我自己是没有做HA，直接就是-v映射出来。依靠S3和Rancher master所在的instance的备份来保证安全的。
自动k8s搭建
Rancher已经提供了各大常见云厂商的Driver。大多数情况，只需要提供一个相关云厂商的token给Rancher即可。Rancher会用你的token帮你去创建机器和集群，而这一切都是自动的。
如果不能或者不愿意让Rancher管理node时，也可以通过“半自动”的方式搭建集群。
只需要在每个Node上跑：sudo docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.5.7 --server https://your-domain --token your-token --ca-checksum your-checksum --worker即可。
此处记得把--worker换成想要的职责。
总之，有了Rancher之后，光论起一个集群来说，成本几乎为0。
持久化
我是选择了Rancher的Apps里的Longhorn来做集群的数据持久化。由于是Rancher自家的产品，因此搭建非常方便，一键式的部署。
Longhorn默认是一个卷做成三个replica。扩容、备份也基本是一键式的。总体来说，可靠且易用。也能通过一个dashboard清楚的知道集群的磁盘和卷的情况。
我是把所有的持久化都全部放在Longhorn上，包括数据库。这是出于成本考虑，因为不愿意再花钱买云上的数据库。
但需要注意的是，因为是三个replica，所以带宽压力会非常大。而且读写性能在默认配置下是比较有限的。
内网集群
Rancher的一个亮点是websocket。对于我家里的机器，但我却不需要让Rancher访问到我家里的三台机器，只需要保证家里的三台机器可以访问到Rancher就可以了。
我觉得这其实是个很有用的功能。尤其是在安全要求较高的情况下，集群所在的网络的访问限制较高的时候会非常好用。
缺点
其实总的来说，没啥太大的缺点。因为本质上Rancher做的工作只是一个多集群管理。所以最不济就只是工具不太好用罢了。
额外的节点
Rancher的master几乎不可避免的需要额外的机器。成本+1。
K8s的知识缺失（个人原因）
由于Rancher已经包装的比较完善，平时基本上不太用的上k8s的操作。导致k8s极其不熟悉。
单点失败（个人原因）
显而易见，Rancher的master会成为整个系统和所有环境的dependence。所以一旦Rancher出现和问题，那基本上所有环境和系统都会失控。
不过Rancher本身其实只是集群管理。因此其实Rancher本身并不阻止用户直接操作k8s的样子。因此，其实提前做好准备，预备一份plan B就行了。
只不过我个人来说，Rancher挂了并不算太可怕的事情，反正可以恢复。所以目前在我的这一套里面，Rancher确实是个单点。
总而言之，个人认为，Rancher是一个非常值得考虑的选择。