本文作者为美国著名分析师 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/
评论