如果你最近对容器领域有所关注的话，想必你已经发现了，最近这段时间里，与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产品一路走来的的进步与完善离不开用户的支持与反馈，我们重视每一个人的每一条意见，请随时分享你的经验，让我们做得更好。
原文来源：Rancher Labs
本文出自 “12452495” 博客，请务必保留此出处http://12462495.blog.51cto.com/12452495/1972777