Kubernetes 发行版领进门，Booking.com 自建平台靠个人
挑战
2016年，Booking.com迁至一个 OpenShift 平台，这一举措让产品开发者能够更加快捷地进入基础设施。但对于开发者来说，因为 Kubernetes 给抽象掉，出现挑战时，基础设施团队就成为“知识瓶颈。”加大支持力度往往不可持续。
解决方案
运行OpenShift一年后，平台团队决定建立自己的 Kubernetes 平台，要求开发者学习 Kubernetes 相关知识，以便日后使用。“这个平台可不能无师自通，”平台 Track B 开发者主管 Ben Tyler 说：“我们从来没说过你闭着眼睛就能使用。开发者需要学习相关知识，我们也会尽全力为开发者提供渠道，保证他们获取知识。”
影响
尽管需要学习过程，新的 Kubernetes 平台的采用呈现很大的增长。使用容器之前，如果开发者了解 Puppet，创建一项新的服务也要几天时间，如果不了解，则需要数周时间。而在新的平台上，10分钟就能搞定。在使用平台的前8个月中，创建的新服务约有500多项。
一些数据
创建新服务的时间
从数天或数周减至10分钟
采用平台的8个月创建了500项新服务
每天发布数百个
Booking.com 和 Kubernetes 渊源已久：2015年，旅游平台上的一个团队在 Mesos 和 Marathon 基础上，构建了一个容器平台原型。
这项技术的强大给他们留下了深刻的印象，但在这个规模上，需要体现企业特点，网站平均每天处理150多万个房间/晚预定，所以团队最终决定采用 OpenShift 平台。
这个平台包裹在类似 Heroku 高级 CLI 界面中，“深受产品开发者青睐，”平台 Track B 开发者主管 Ben Tyler说，“我们能帮他们快速进入基础设施。”
但是，他补充说：“稍微偏离轨道一点，开发者就会不知道如何自救了。”
运行这个平台一年之后，基础设施团队发现平台成了“知识瓶颈”，他说：“多数使用平台的开发者并不知道下面是 Kubernetes。应用程序和平台故障都和类似 Heroku 工具故障非常相似。”
提供必要的支持貌似不可行，也不可持续，平台团队需要一个新的解决方案。在运行 OpenShift 平台过程中积累的 Kubernetes 知识给他们增加了信心，他们想建立一个自己的 Kubernetes 平台，定制化地满足公司的需求。
“说到带入情境，OpenShift 绝对好用。”平台 Track B 高级系统管理员 Eduard Iacoboaia 说，“它能展示这项技术的功能，更方便用户使用。花点时间学习后，我们就明白需要更好地学习 Kubernetes，这样才能充分发掘它的潜力。那时，我们做出了转变，建立了自己的Kubernetes平台。搭建自己的平台，花点时间学习知识，从长期来看，我们是绝对受益的。”
Iacoboaia 的团队定制了很多 OpenShift 工具用于 Booking.com，“这些集成点有些脆弱，”他说，“我们用更多的时间了解 Kubernetes 所有组件，它们的运行方式以及相互作用的方式等。”这项研究引导团队从 OpenShift 的嵌入式 Ansible playbooks 转向 Puppet 部署，后者用于 Booking 其他的基础设施。控制平面也从集群内部转移到了裸机上，因为该公司运行着数万台裸机服务器和用于在裸机上运行应用程序的大型基础设施。（Booking 在其进行计算的多个地区的多个数据中心的多个集群内运行 Kubernetes。）“我们决定尽可能简化这些工具，使用我们最了解的那些，”Iacoboaia 说。
“我们的用户学过 Kubernetes 之后，就成为更为成熟的 Kubernetes 用户了。他们就会给我们施加压力，让我们提供更好更原来的 Kubernetes 体验，这是件好事，给我们提供了超级有益的动力。”
— BOOKING.COM 平台 TRACK B 开发者主管 BEN TYLER
另一个比较大的变化是产品工程师也需要学习掌握 Kubernetes，这样才能参与进来。“这个平台可不能无师自通，” Tyler 说：“我们从来没说过你闭着眼睛就能使用。开发者需要学习相关知识，我们也会尽全力为开发者提供渠道，保证他们获取知识。”这些渠道包括培训、博客文章、视频和 Udemy 课程。
尽管需要学习过程，新的 Kubernetes 平台的采用呈现很大的增长。“我认为我们能够成功是因为我们并没有要求他们掌握一个私有的应用系统，” Tyler 说，“我们让他们学的东西是开源的，知识是可以自由转让的。他们学习 Kubernetes，就是在投资自己的职业发展。”
这个策略非常成功，有一点能够充分证明：在支持频道，用户一旦提出任何问题，就会有产品工程师上线解决。“之前我从来没见过哪个内部社区，能够就某个平台产品提供这样的社区参与式服务，” Tyler 说，“显然在公司外部，已经有了一个生态系统标准，这真是大有用处，所以大家会觉得花时间学习知识、再和别人分享很有价值。这样就能产生巨大的影响。”
还有其他可以量化的证据表明：使用容器之前，如果开发者了解 Puppet，创建一项新的服务也要几天时间，如果不了解，则需要数周时间。而在新的平台上，10分钟就能搞定。“我们提供辅导材料，你跟着教程走，同时跑着代码。然后就到了业务逻辑时间，” Tyler 说，“这样获取资源的时间就大幅度缩短了。”在使用平台的8个月中，创建的新服务约有500多项，每天发布的新服务都能达到上百个。
“说到带入情境，OpenShift 绝对好用。它能展示这项技术的功能，更方便用户使用。花点时间学习后，我们就明白需要更好地了解学习 Kubernetes，这样才能充分发掘它的潜力。那时，我们做出了转变，建立了自己的Kubernetes平台。搭建自己的平台，花点时间学习知识，从长期来看，我们是绝对受益的。”
— BOOKING.COM 平台 TRACK B 高级系统管理员 EDUARD IACOBOAIA
该平台能提供不同的“合同层级” Tyler 描述道，“基础就是 Kubernetes。如果你支持 Kubernetes，就能得到一个 Kubernetes API，就像你能从 GKE 或 AKS 得到的一样。我们尽全力提供相同水准的产品。但在公司内部，我们所做的工作是要创造比基础设施更大的价值，因此我们为我们的主要堆栈 Perl 和 Java 提供了一组基本镜像。”
同时，“我们的用户学过 Kubernetes 之后，就成为更为成熟的 Kubernetes 用户了。他们就会给我们施加压力，让我们提供更好更原来的 Kubernetes 体验，这是件好事，” Tyler 说，“给我们提供了超级有益的动力。”
平台还包括其他 CNCF 技术，诸如 Envoy、Helm、Prometheus 等。Booking.com 的主要服务流量大多通过 Envoy 传输，Prometheus 主要用于监控基础设施组件，Helm 作为打包标准使用。该团队还开发并开源了 Shipper，作为 Kubernetes 的扩展，能加入更复杂的 rollout 策略和多集群编排。
当然，内部也曾经讨论过从头开始完全构建 Kubernetes 平台是否明智的问题。“这并不是我们的核心能力，Kubernetes 和旅游业，相差的确有点远，对吧？” Tyler 说，“但我们可以保证 CNCF 组件运行真的非常好。特别是 Envoy 和 Kubernetes 真让我们受益不少。之所以能够定制它们，是因为我们能看到源代码，也是因为它们都有扩展点，我们不需要改变内部范例，就能实现快速增值。”