Rancher的优势

Rancher是一个开源的企业级多集群Kubernetes管理平台,实现了Kubernetes集群在混合云+本地数据中心的集中部署与管理,以确保集群的安全性,加速企业数字化转型。——Rancher官网

目前已经使用Rancher做自己个人服务的集群管理已经有2年左右了,个人的感觉是非常舒适,且非常贴合我的场景。因此总结一下我自己用Rancher的一些体验。

我目前所使用的版本是: 2.5.7


多集群管理

如上面官网所说,Rancher主打的就是一个多集群管理。而这一点事实上是非常重要的。

由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帮你去创建机器和集群,而这一切都是自动的。

创建一个在DigitalOcean上的集群

如果不能或者不愿意让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的Dashboard

我是把所有的持久化都全部放在Longhorn上,包括数据库。这是出于成本考虑,因为不愿意再花钱买云上的数据库。

但需要注意的是,因为是三个replica,所以带宽压力会非常大。而且读写性能在默认配置下是比较有限的。


内网集群

Rancher的一个亮点是websocket。对于我家里的机器,但我却不需要让Rancher访问到我家里的三台机器,只需要保证家里的三台机器可以访问到Rancher就可以了。

我觉得这其实是个很有用的功能。尤其是在安全要求较高的情况下,集群所在的网络的访问限制较高的时候会非常好用。

可以看到,Rancher管理的这个集群是在内网中

缺点

其实总的来说,没啥太大的缺点。因为本质上Rancher做的工作只是一个多集群管理。所以最不济就只是工具不太好用罢了。

额外的节点

Rancher的master几乎不可避免的需要额外的机器。成本+1。

K8s的知识缺失(个人原因)

由于Rancher已经包装的比较完善,平时基本上不太用的上k8s的操作。导致k8s极其不熟悉。

单点失败(个人原因)

显而易见,Rancher的master会成为整个系统和所有环境的dependence。所以一旦Rancher出现和问题,那基本上所有环境和系统都会失控。

不过Rancher本身其实只是集群管理。因此其实Rancher本身并不阻止用户直接操作k8s的样子。因此,其实提前做好准备,预备一份plan B就行了。

只不过我个人来说,Rancher挂了并不算太可怕的事情,反正可以恢复。所以目前在我的这一套里面,Rancher确实是个单点。


总而言之,个人认为,Rancher是一个非常值得考虑的选择。

展示评论