挑战
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 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，它们对我们的组织非常有益。我们能够定制它们，要么是因为我们可以查看源代码，要么是因为它们有扩展点，而且我们能够非常快地从它们中获得价值，而无需在内部改变任何范式。”