挑战
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 平台，并根据公司的需求进行定制。
“对于进入这个领域来说，OpenShift 确实非常有帮助，”B 平台高级系统管理员 Eduard Iacoboaia 说。“它向你展示了这项技术能做什么，并让你很容易上手。在花了一些时间之后，我们意识到需要更好地学习 Kubernetes，才能充分发挥其潜力。那时，我们转向构建自己的 Kubernetes 平台。从长远来看，我们肯定会因为迈出这一步并投入时间来获取这些知识而受益。”
Iacoboaia 的团队为了让 OpenShift 的工具在 Booking.com 运行，定制了很多内容，而“那些集成点有点脆弱，”他说。“我们花了更多的时间来理解 Kubernetes 的所有组件，它们如何工作，以及它们如何相互作用。” 这项研究促使团队从 OpenShift 内置的 Ansible playbooks 转向了 Puppet 部署，因为 Booking 的其余基础设施都使用 Puppet。控制平面也从集群内部移到了裸机上，因为公司运行着数万台裸机服务器和一套庞大的在裸机上运行应用程序的基础设施。（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，对我们的组织非常有益。我们能够对它们进行定制，要么是因为我们可以查看源代码，要么是因为它们有扩展点，我们能够很快从中获得价值，而无需改变任何内部的范式。”