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