挑战
作为全球最大的资产管理公司，贝莱德 采用了一种高度受控的静态部署方案，多年来一直具有良好的可伸缩性。但在其数据科学部门，需要更动态地访问资源。贝莱德产品部门（负责公司投资管理平台）董事总经理 Michael Francis 表示：“我们希望让每位投资者都能进行数据科学研究，包括使用 Python notebook，甚至更高级的功能，例如基于 Spark 的 MapReduce 引擎。” 他说：“在用户桌面上管理复杂的 Python 安装非常困难，因为最终每个人的环境都略有不同。我们有现有的环境可以实现这些功能，但我们需要使其真实、可扩展、可伸缩。按需启动、拆除并使其更具动态性，这对我们来说是一个关键的思考过程。问题与其说我们必须解决核心生产问题，不如说我们如何扩展它？我们如何发展？”
解决方案
借鉴去年使用 Docker 环境进行试点时获得的经验，Francis 组建了一个由 20 人组成的跨部门团队，利用 Kubernetes 构建了一个投资者研究 Web 应用，目标是在一个季度内将其投入生产。
影响
Francis 说：“我们的目标是：如何快速为人们提供工具，而无需在他们的桌面上安装？” 团队在 100 天内达到了目标。Francis 对结果很满意，他说：“随着时间的推移，我们将把这套基础设施用于许多其他应用工作负载。这不仅限于数据科学；而是需要这种动态性的应用。但我认为我们离做出 [大规模] 决策还有 6-12 个月的时间。我们需要获得在生产环境中运行该系统的经验，需要了解故障模式以及如何最好地管理运维问题。有趣的是，仅仅拥有这项技术正在改变我们的开发人员开始思考未来开发的方式。”
贝莱德产品部门员工在 2017 年的管理目标之一是“构建炫酷的东西”。在董事总经理 Michael Francis 的领导下，一个由 20 人组成的跨部门团队做到了这一点：他们推出了一个完整的生产环境 Kubernetes 集群，并在其上发布了一个新的投资者研究 Web 应用。在 100 天内。
对于一家全球最大的资产管理公司来说，“仅仅采购设备有时就需要 100 天，更不用说从概念到交付了，”高级系统管理员 Karl Wieman 说。“这是一个激进的计划。但它改变了一切。” 事实上，该项目实现了两个目标：它解决了一个业务问题（创建所需的 Web 应用），同时提供了 Kubernetes 的真实生产经验，这是公司渴望探索的一种云原生技术。Francis 说：“问题与其说我们必须解决核心生产问题，不如说我们如何扩展它？我们如何发展？” 除了交付应用之外，该项目的最终成功在于“我们成功地将一种全新的思维过程整合到一个我们不想改变的受控基础设施中”。
毕竟，在成立的三十年中，贝莱德已经“建立了非常完善的计算资源管理环境，”Francis 说。“我们在机器上管理大型集群流程，因此我们对主要生产流程进行了大量的编排和管理，其概念非常像云。我们能够以高度受控的静态部署方案来管理它们，这为我们带来了巨大的可伸缩性。”
尽管这对核心生产很有效，但公司发现一些数据科学工作负载需要更动态地访问资源。Francis 说：“这是一个非常突发性的过程。” 他是公司 Aladdin 投资管理平台部门的数据负责人。
Aladdin 连接了实时资金管理所需的人员、信息和技术，既在内部使用，也作为平台出售给其他资产管理公司和保险公司。Francis 说：“我们希望让每位投资者都能进行数据科学研究，包括使用 Python notebook，甚至更高级的功能，例如基于 Spark 的 MapReduce 引擎。” 但“在用户桌面上管理复杂的 Python 安装非常困难，因为最终每个人的环境都略有不同。Docker 让我们能够简化这种环境。”
尽管如此，挑战依然存在。Francis 说：“如果你有一个共享集群，就会出现这种‘群集风暴’问题，即每个人都想同时做同样的事情。” “你可以设置限制，但你需要构建一个基础设施来为我们的流程定义限制，而 Python notebook 并不是为此设计的。我们有现有的环境可以实现这些功能，但我们需要使其真实、可扩展、可伸缩。按需启动、拆除并使其更具动态性，这对我们来说是一个关键的思考过程。”
Francis 的团队由来自技术、基础设施、生产运维、开发和信息安全部门的经理组成，他们能够全面地看待问题，并提出适合贝莱德的解决方案。Francis 说：“我们最初的设想是使用 Ansible 构建所有东西，并使用完全不同的分布式环境来运行。” “这绝对是错误的。如果作为开发团队单干并开发这个解决方案，那会是一个完全不同的产品。而且会非常昂贵。我们就不会考虑在现有的编排系统下运行。因为我们不理解它。运维和基础设施的人员才理解。拥有一个多学科团队让我们能够找到正确的解决方案，这意味着我们最终构建的东西远没有我们最初想象的那么多。”
为了寻找一种可以按用户级别管理使用情况的解决方案，Francis 的团队倾向于红帽的 OpenShift Kubernetes 产品。公司之前已经尝试过其他云原生环境，但团队喜欢 Kubernetes 是开源的，并且 Francis 说：“我们觉得从长远来看，风向正吹向 Kubernetes。” “通常我们选择我们认为在未来 5-10 年内以某种形式存在的技术。而现在，在这个领域，Kubernetes 感觉就是那个会留下来的。” 生产运维副总裁 Uri Morris 补充道：“当你看到非谷歌的 Kubernetes 提交者数量超过谷歌提交者时，这就是动力的一个指标。”
一旦做出决定，主要的挑战是如何让 Kubernetes 在贝莱德现有框架内工作。项目经理 Michael Maskallis 说：“这关乎如何运营、管理和支持这样一个平台，并将其附加到我们现有的技术平台之上。我们现有的所有控制措施、变更管理流程、软件开发生命周期、入职流程——我们如何才能做到所有这些？”
第一个（预期的）障碍是解决贝莱德公司防火墙后的问题。Francis 说：“我们的挑战之一是大多数开源软件中都没有防火墙。” “因此，几乎所有安装脚本都会以某种奇怪的方式失败，并且下载软件包不一定能成功。” 团队在使用 Minikube 时遇到了这类问题，并向开源项目反馈了一些小的改进。
关于服务发现也有问题。Francis 说：“你可以把 Aladdin 看作是一个服务云，服务之间有 API，这使我们能够快速构建应用。它全部运行在专有消息总线上，这为我们带来了各种优势，但同时，这如何在第三方 [平台] 中发挥作用？”
他们不得不解决的另一个问题是，在贝莱德现有的系统中，消息协议在不同的开发、测试和生产环境中具有不同的实例。虽然 Kubernetes 支持更偏向 DevOps 的模式，但这并不适合贝莱德。Francis 说：“我认为我们非常自豪的是，在这个 [新] 基础设施中，我们推送到生产环境的能力仍然快得令人难以置信，但我们已经建立了控制点，并且不必中断一切。” “这项开发的大部分成本在于思考如何最好地利用我们的内部工具。所以它比我们最初想象的要便宜。”
例如，该项目利用了与消息总线相关的工具。Morris 说：“Kubernetes 集群与我们内部消息平台通信的方式是通过一个网关程序，这个网关程序已经内置了检查和限制功能。我们可以利用它们来控制和潜在地限制来自 Kubernetes 非常弹性基础设施对生产基础设施的请求。我们将继续朝这个方向发展。从运维角度来看，这使得我们能够根据需要进行伸缩。”
解决方案还需要与贝莱德的集中式运维支持团队结构互补。Morris 解释说：“Kubernetes 的核心基础设施组件连接到我们现有的编排框架中，这意味着我们支持团队中的任何人都可以使用现有的运维工具来控制和查看集群。这意味着我不需要雇佣更多的人。”
确定了这些要点后，团队为项目制定了一个流程：Maskallis 说：“我们首先将其部署到开发环境，然后迁移到测试环境，最终按照顺序部署到两个生产环境。” “这极大地推动了我们的学习曲线。我们有所有这些移动的部件：基础设施端的软件组件、与 Kubernetes 直接相关的软件组件、与我们在贝莱德这里运行的其他环境的互联互通，以及如何连接所有这些部分。如果遇到问题，我们就解决它们，然后将其复制到不同的环境，直到最终达到我们的生产环境，这个特定的集群应该驻留在那里。”
团队每周与所有成员（他们分布在世界各地）举行一个小时的工作会议，以及专注于特定技术细节的小组讨论或深度会议。可能的解决方案会向团队汇报，并在下一周进行讨论。副总裁兼软件开发工程师 Fouad Semaan 说：“我认为让这次实验成功的是，人们不得不努力学习，并与他人分享经验。” 然后，Francis 说：“我们给了我们的工程师空间，让他们做他们擅长的事情。这并非自上而下的方式。”
他们遵循一个关键原则：保持专注，避免范围蔓延。这意味着他们不会使用 Kubernetes 和 Docker 核心之外的功能。但如果有实际需求，他们会自己构建这些功能。幸运的是，Francis 说：“由于开发的快速性，我们原本以为必须自己构建的许多功能已经集成到核心产品中。[软件包管理器 Helm 就是一个例子]。人们遇到的问题都很相似。”
在 100 天结束时，该应用已经在贝莱德内部用户中上线并运行。最初的 30 个用户容量在几个小时内就达到了上限，并迅速增加到 150 个。Francis 说：“人们立刻都开始使用了。” 在该项目的下一阶段，他们计划扩大集群容量。
更重要的是，他们现在拥有了 Kubernetes 的生产经验，并可以继续在此基础上发展——以及一套完整的推广新应用的框架。Francis 说：“随着时间的推移，我们将把这套基础设施用于许多其他应用工作负载。这不仅限于数据科学；而是需要这种动态性的应用。” “它是我们核心生产流程迁移到的正确位置吗？也许是。我们还没有到可以说‘是’或‘否’的阶段，但我们觉得，以某种形式和规模获得 Kubernetes 的真实生产经验将使我们能够理解这一点。我认为我们离做出 [大规模] 决策还有 6-12 个月的时间。我们需要获得在生产环境中运行该系统的经验，需要了解故障模式以及如何最好地管理运维问题。”
对于考虑开展类似项目的其他大公司，Francis 说承诺和奉献精神是关键：“我们从第一天起就获得了 [高级管理层] 的批准，并承诺我们能够找到合适的人。如果我必须找出能让像这样复杂的事情成功的原因，我会说是那些能够真正推动它的经验丰富的人员起了巨大的作用。” 他补充道：“我想告诉像我们这样的其他企业，你们实际上可以将 Kubernetes 集成到现有的、精心编排的系统中。你们不必放弃现有的一切。使用 Kubernetes 让一个复杂的问题变得简单多了。”