Rancher 2.0 的第一印象

如果你最近对容器领域有所关注的话,想必你已经发现了,最近这段时间里,与Kubernetes相关的技术在快速、大量地涌现。因此,再增加一个,可能也不会让人有多新奇。不过,Rancher近期发布的新版产品还是值得你来了解一番的。Rancher Labs的研发团队一直在研究一些新的想法,我认为这将会对我们所有人对Kubernetes(K8s)的想法产生深刻影响。我会在这篇博客中说说我最感兴趣的三个方面。

首先,Rancher 2.0可以使用docker-compose来部署K8s的pods、services和ingress。Docker通过组件化的方式极大地优化了用户体验。我喜欢它的直观和简洁,这对于没有时间在容器上过多钻研、只需要完成工作的人来说,易于上手的它是一个绝佳的选择。另外,K8s的资源清单功能十分强大,且具有不错的扩展性。然而,这项功能实际使用起来并不方便,多数情况下(特别是对企业而言)投入产出比并不大。而Rancher 2.0很好地解决了这一困境,对于K8s新手而言,他们可以通过Rancher使用docker-compose来部署他们的应用程序,而对喜欢原生的k8s资源清单功能的用户来说,他们也能继续用他们原先的方式使用k8s。

K8s在世界各地势头正猛,我想我们还没有时间停下来,去评估一个组织内的工程师(并非容器的爱好者)实际上是否真的向往K8s的用户体验。因为在我的经验中,这种大范围的推广,既可以产生技术,也可能会破坏技术。一段时间过后,当热潮退去,如果用户并没有对此产生兴趣,那么这项技术就很可能会成为一个只能被束之高阁、无法落地的技术——特别是在一开始它是以提高开发人员生产力为卖点。

第二,Rancher 2.0利用了K8s的成熟特性。你肯定听说过“不要重造轮子”的格言,可“重造轮子”的事情却又总在科技公司重演。所幸我们的研发团队意识到我们可以依靠K8s的API实现新功能,而无需自己从头构建。我坚信这样会使得软件开发得更好,因为你不必冒着重蹈覆辙的风险,而只需专注于解决新问题。这样的想法来源于我个人和其他人的经验,比如Joel Spolsky的有关重写软件的理解。

那么Rancher 2.0中有哪些有关使用K8s特性的例子呢?其一,我们通过扩展现有的K8s结构(如命名空间和RBAC)来实现多租户模型。Federation也是我们在决定利用K8s实现之前自己做的事情。指标和监控也是受益于和K8s有许多集成关联的Heapster和InfluxDB。而上述这些仅仅是我们在Rancher中使用K8s技术的几个亮点而已。

最后,我对K8s将在Rancher Labs未来的影响很是期待。自从我们首次在容器生态系统中提供解决方案之后,我们尝试过支持所有的编排调度框架(k8s、Mesos、Swarm),给我们的用户提供尽可能多的选择。这在当时编排框架“三足鼎立”的阶段是一个创举,整个实现的过程对Rancher Labs的研发而言也实属不易。而我一直想知道如果我们把精力放在这些技术中的其中某一项上,Rancher会是什么样子。令我高兴的是,业界已经逐渐将K8s视为编排调度框架的主流选择,这样我们就能够集中我们的精力,不必担心因多样性而出现用户群体有限的问题。

我希望上述的理由能够让你有兴趣去了解Rancher 2.0。作为开源产品,Rancher产品一路走来的的进步与完善离不开用户的支持与反馈,我们重视每一个人的每一条意见,请随时分享你的经验,让我们做得更好。

    原文作者:RancherLabs
    原文地址: https://segmentfault.com/a/1190000011571670
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞