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