挑战
2016 年，Booking.com 迁移到了 OpenShift 平台，这使得产品开发人员能够更快地访问基础设施。但由于 Kubernetes 对开发人员来说是抽象的，因此当出现挑战时，基础设施团队成为了“知识瓶颈”。试图扩展这种支持是不可持续的。
解决方案
在使用 OpenShift 一年后，平台团队决定构建自己的原生 Kubernetes 平台，并要求开发人员学习一些 Kubernetes 才能使用它。“这不是一个神奇的平台，”B 平台跟踪部门的首席开发人员 Ben Tyler 说。“我们不是说你可以闭着眼睛使用它。开发人员需要学习一些东西，我们会尽一切努力确保他们能够获得这些知识。”
影响
尽管存在学习曲线，但新 Kubernetes 平台的采用率大幅上升。在使用容器之前，如果开发人员了解 Puppet，创建一个新服务可能需要几天时间，否则可能需要几周时间。在新的平台上，只需 10 分钟。在最初的 8 个月里，平台上构建了大约 500 个新服务。
他们对该技术提供的功能印象深刻，但需要在其规模上提供企业级功能（该网站平均每天处理超过 150 万个房间预订），因此该团队决定采用 OpenShift 平台。
这个平台包装在 Heroku 风格的高级 CLI 界面中，“在我们的产品开发人员中非常受欢迎，”B 平台跟踪部门的首席开发人员 Ben Tyler 说。“我们为他们提供了更快地访问基础设施的途径。”
但他补充说，“任何时候出现问题，开发人员都没有任何必要的知识来自己解决。”
在使用这个平台一年后，基础设施团队发现它已经成为“知识瓶颈，”他说。“大多数使用它的开发人员不知道它底层是 Kubernetes。应用程序故障和平台故障看起来都像是该 Heroku 风格工具的故障。”
扩展必要的支持似乎不可行或不可持续，因此平台团队需要一个新的解决方案。他们在使用 OpenShift 平台时获得的 Kubernetes 知识使他们有信心构建自己的原生 Kubernetes 平台并对其进行定制以满足公司需求。
"对于进入 Kubernetes 领域，OpenShift 绝对非常有帮助，”B 平台跟踪部门的高级系统管理员 Eduard Iacoboaia 说。“它向你展示了该技术的功能，并且使用起来很容易。在我们使用它一段时间后，我们意识到我们需要更好地学习 Kubernetes 才能充分利用它的潜力。在那时，我们开始构建自己的 Kubernetes 平台。我们通过采取这一步并投入时间来学习 Kubernetes 知识，在长期内肯定获益匪浅。”
Iacoboaia 的团队已经定制了许多 OpenShift 工具，使它们能够在 Booking.com 上运行，并且“这些集成点有点脆弱，”他说。“我们花费了更多时间来理解 Kubernetes 的所有组件，它们的工作原理以及它们如何相互作用。”这项研究促使团队从 OpenShift 内置的 Ansible playbook 切换到 Puppet 部署，后者被用于 Booking 的其余基础设施。控制平面也从集群内部移到了裸机上，因为该公司运行着数万台裸机服务器以及用于在裸机上运行应用程序的大型基础设施。（Booking 在多个数据中心运行着多个 Kubernetes 集群，跨越其拥有计算资源的各个区域。）“我们决定尽可能保持简单，并使用我们最熟悉的工具，”Iacoboaia 说。
另一个重大变化是产品工程师必须学习 Kubernetes 才能加入。 “这不是一个神奇的平台，”Tyler 说。“我们不是说你可以闭着眼睛使用它。开发人员需要学习一些东西，我们会尽一切努力确保他们能够获得这些知识。”其中包括培训、博客文章、视频和 Udemy 课程。
尽管存在学习曲线，但新 Kubernetes 平台的采用率大幅上升。“我认为我们能够成功达成这种交易的原因是，我们没有要求他们学习专有的应用程序系统，”Tyler 说。“我们要求他们学习一些开源的东西，这些知识是可以转化的。他们通过学习 Kubernetes 来投资自己的职业生涯。”
一个明确的成功迹象是，在支持渠道中，当用户有疑问时，其他产品工程师会跳出来做出回应。“我以前从未见过内部围绕特定平台产品进行这种社区参与，”Tyler 说。“它对外部生态系统标准的可见性非常有帮助，因此人们会感受到投资该知识并与他人分享的价值，这非常强大。”
也有其他可量化的证据：在使用容器之前，如果开发人员了解 Puppet，创建一个新服务可能需要几天时间，否则可能需要几周时间。在新的平台上，只需 10 分钟。“我们有一个教程。你按照教程操作。你的代码正在运行。然后，就该进行业务逻辑了，”Tyler 说。“获得资源访问权限的时间大大减少了。”在平台上最初的 8 个月里，构建了大约 500 个新服务，每天有数百次发布。
该平台提供不同的“契约层，”Tyler 说。“在最底层，它只是 Kubernetes。如果你是一个专业的 Kubernetes 用户，这里有一个 Kubernetes API，就像你在 GKE 或 AKS 上得到的一样。我们试图成为同等层次上的提供商。但我们在公司内部的全部工作是比单纯的原生基础设施提供更大的价值，因此我们为我们的主要堆栈（Perl 和 Java）提供一组基本镜像。”
并且“随着我们的用户学习 Kubernetes 并成为更熟练的 Kubernetes 用户，他们会施加压力让我们提供更好的，更原生的 Kubernetes 体验，这很棒，”Tyler 说。“这是一个非常健康的动态。”
该平台还包含其他 CNCF 技术，例如 Envoy、Helm 和 Prometheus。Booking.com 的大部分关键服务流量通过 Envoy 路由，Prometheus 主要用于监控基础设施组件。Helm 被用作打包标准。该团队还开发并开源了 Shipper，它是 Kubernetes 的扩展，用于添加更复杂的推出策略和多集群编排。
当然，内部也有一些关于从头开始构建 Kubernetes 平台的明智性的讨论。“这并不是我们的核心能力——Kubernetes 和旅游，它们有点分隔开，对吧？”Tyler 说。“但我们在 CNCF 组件上押了几个注，对我们来说效果很好。尤其是 Envoy 和 Kubernetes，对我们组织非常有利。我们能够对其进行定制，要么是因为我们可以查看源代码，要么是因为它们有扩展点，我们能够很快地从中获得价值，而不必改变任何内部范式。”