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