本文作者为美国著名分析师James Governor。James Governor是RedMonk的首席分析师和创始人。他负责领导企业应用程序领域的相关分析报道，为客户提供应用程序开发、集成中间件和系统管理等问题的分析和建议。James Governor有十多年的从业经验，他的分析与观点常被美国和欧洲的媒体引用，他还曾任BBC等媒体机构的特邀行业专家。
Rancher Labs 于6月28日在旧金山举办了分析者大会。Rancher Labs在美国已拥有200多家付费企业客户，考虑Rancher产品的下载使用量，以及Rancher Labs只是一个成立短短4年的初创公司，这个付费客户数已经非常可观。此次分析者大会上，有13位客户代表进行了发言分享。整场分享没有在市场宣传上做大动作，而是密切关注于技术层面的干货输出。每一位发言人都提供了很有意思的技术见解。
K8S平台的强大功能VS简易性
Rancher Labs CEO及联合创始人梁胜博士首先针对“平台的强大功能性VS.简易性”之间的取舍及对比展开了完整有力的讨论 。虽说AWS在推出伊始也很简单，但不可否认，AWS如今已变成了一个完整、功能强大的平台，拥有一系列先进功能来与传统企业供应商（如VMware）相抗衡。
正因如此，那些想使用开源产品（如原生Kubernetes平台）来避免技术锁定的用户，正面临“开源开放VS.方便强大”这个进退两难、难以抉择的困境。通常情况下，用户会选择“便捷”这一属性，这也是AWS如今能垄断市场的原因之一。
“做一个管理平台，仅仅是‘能在多云环境下均可使用’，这一特性是远远不够的，用户需要的是一个比让他们自己直接使用多云更优的解决方案。”梁胜博士表示，“为了推动用户对多种云的使用，市场期待比AWS更优的产品。”
这正是对Rancher以及业里其他玩家的挑战。只提供可移植性是不足够的——跨平台体验需要更好的表现方式。
当下市场广泛接受的一个观点是，我们需要云基础设施以及微服务更多地为用户服务，而不是要用户小心翼翼地去维护基础设施——粗暴点说，即虚拟机和容器需要是短暂且可抛弃的。在持续部署和应用镜像扩容的年代，服务是很难持续的。不断修修补补打补丁的方式，终将会被不可变基础架构取代。
最初当Docker腾飞时，Rancher Labs结合其自身一贯的简易、灵活的理念，创建了自己的容器编排和管理平台，称之为Cattle。Cattle能在开发人员的笔记本电脑上构建及管理Docker镜像，这一特性帮助Rancher 1.6赢得了业界的“易于部署和管理”的赞誉。
但在2017年，Kubernetes逐步赢得了容器编排工具之战，成为了标准的容器服务编排环境。Rancher Labs极具前瞻性地对Rancher产品做了重大升级转向，新推出的Rancher 2.0延续了Cattle一贯的简洁易用的特性，但成为了完全基于Kubernetes的平台。Rancher的这一决策也充分证明了我们前文所说的“灵活性”的理念。虽说不少客户认为 Cattle比Docker Swarm、Apache Mesos或Kubernetes更简单、更易于使用、甚至可能更适合他们的需求，但在2.0产品上他们不得不放弃对Cattle的使用。Rancher并不是唯一作出这样决策的公司 ——例如，Docker公司原本拥有自己的编排工具Swarm，但也在不久后宣布拥抱Kubernetes；Mesosphere现在也支持DC / OS上的Kubernetes。
Kubernetes不是哪家公司的竞争对手，当下情况是，业界各公司正处于Kubernetes这一环境中在进行竞争。
Rancher的此次大会可能是最具说服力、最具参考价值的，因为客户的紧张感暴露无遗。客户在一定程度产生了认识失调。一方面他们想继续使用Rancher的Cattle编排调度工具，另一方面他们意识到Kubernetes的势头不可抵挡。同时对于Rancher来说，从研发团队的角度看，标准化Kubernetes总是比支持多个第三方协调引擎更容易。
因此，对于Rancher 2.0而言，它的工作主要是通过CLI、UI、Compose等，来为运行在Kubernetes pod上的容器提供Rancher UX和API。原生支持Kubernetes，意味着对于那些想要使用Kubectl、Helm chart的公司而言，所有常见的Kubernetes工具都可以用了。
Rancher还计划通过Prometheus（用于监控和指标）以及RBAC（基于角色的访问控制）等工具提供更好的集成。 Rancher拥有自己的身份验证模型，并支持SAML、LDAP和Microsoft Azure Active Directory。用户可以设置警报和阈值——例如，如果etcd内存消耗超过70％，它会通过Slack通知团队。
Rancher首席架构师Darren Shepherd对功能性与简易性的理解略有不同，他在大会上表示Rancher正在开发的一个名为Rio的新项目——基于Kubernetes，拥有用户熟悉的、简单的Docker 1.11.x 风格的UX，拥有端到端的服务，包括构建、运行时、日志、监控与无服务器架构。
我在大会上询问了Rancher Labs团队如何达到产品、服务和技术支持间的平衡。 Rancher联合创始人兼销售副总裁Shannon Williams说：“客户使用Kubernetes之后，我们需要为客户提供的服务大部分都是培训。 然而AWS、VMware它们都不需要这样做。 如果产品易于使用，技术浪潮中并不需要这么多培训”。

客户对于K8S与Rancher的想法
客户对此说了什么？这里有一系列的观点。
Sling TV目前正在VMware上运行容器，并希望通过采用原生的Kubernetes避免未来技术锁定的风险。 它计划将容器从VMware迁移到AWS，因此可移植性是他们非常看重的特性。 正因如此，他们选择了可以纳管兼容不同基础架构容器服务的Rancher。
Toyota Connected是一个很有趣的案例，一部分原因是因为与其他客户不同，丰田直接选用Rancher 2.0，而不是1.6或更早的版本。 也就是说，它因为选择Kubernetes而选择了Rancher，而不是因为摒弃Kubernetes而选择了Rancher。
Toyota Connected高级开发与运维工程师Ross Edmond说：“Kubernetes并不完美，但我们坚信它有着非凡的持久力、未来发展会越来越好，一是因为它的功能非常强大，二是因为它可以让用户进行很多拓展，从而进行长期的、可持续性的探索。”
丰田公司所有出售的凯美瑞车型的“主机（head unit）”（也就是仪表板中带有无线功能、蓝牙、网络等的部分）都将运行在Kubernetes上。 丰田公司希望通过Kubernetes的灵活性加快公司的软件开发速度，并使用各种堆栈（例如，丰田用Java和Elixir编写软件，而这需要Erlang虚拟机）。

丰田凯美瑞的远程信息中包含超过100个微服务。在启动时，该服务需要能够支持1500万辆汽车。HA配置中的集群目前为20到30个节点。Kubernetes这一最初是用于管理Google服务器群的开源软件，如今已经开始服务于汽车仪表盘，这真的让人感到难以置信。
Edmond继续说：“Rancher Kubernetes Engine（RKE）不再需要用户‘自带容器’。它与底层基础设施并无绑定。使用RKE大大降低了我们使用其他云的启动成本。”
国家能源研究科学计算中心（NERSC）是美国能源部的一部分，也是另一个精彩的案例——实现了在Cray超级计算机上运行Docker。它使用容器进行计算工作——一个NERSC开源项目Shifter将Docker镜像随时转换为Cray超级计算环境中的非特权用户——那有9000个节点。 NERSC还以更传统的方式为应用程序开发工作流程提供容器。它选择Rancher进行身份验证、CLI、管理工具和策略实施。
总而言之，与容器生态系统中的其他参与者一样，Rancher现在专注于优化改善Kubernetes的易用性 。Kubernetes将成为未来几年的基础设施的重要角色。这次活动让我深刻地认同 Rancher在这方面有很好的基础，而这势必会在将来帮其赢得更多的新客户。
英文原文：
https://redmonk.com/jgovernor/2018/06/28/rancher-labs-treating-cattle-like-cattle/