挑战
这个音频流媒体平台于 2008 年推出，目前已在全球拥有超过 2 亿月活跃用户。“我们的目标是赋能创作者，并为我们今天拥有的所有消费者——以及希望未来也会拥有的消费者——提供真正身临其境的聆听体验，”基础设施和运营工程总监 Jai Chakrabarti 说。作为微服务和 Docker 的早期采用者，Spotify 将其容器化微服务运行在其 VM 集群上，并使用名为 Helios 的自研容器编排系统。到 2017 年底，很明显，“让一个小型团队负责这些功能的效率，不如采用由更大社区支持的东西，”他说。
解决方案
“我们看到了围绕 Kubernetes 生成的强大社区，我们希望成为其中的一部分，”Chakrabarti 说。Kubernetes 的功能比 Helios 更丰富。此外，“我们希望从更高的速度和更低的成本中获益，并与行业其他公司在最佳实践和工具方面保持一致。”同时，该团队希望在蓬勃发展的 Kubernetes 社区中贡献自己的专业知识和影响力。迁移将在 Helios 运行的同时进行，可以顺利进行，因为“Kubernetes 非常适合作为 Helios 的补充，现在也作为替代方案，”Chakrabarti 说。
影响
该团队在 2018 年的大部分时间里都致力于解决迁移所需的核心技术问题，该迁移于当年晚些时候开始，并成为 2019 年的一项重点。“我们有一小部分集群已经迁移到 Kubernetes，我们从内部团队那里听到，他们不再需要过多地关注手动容量配置，而是可以花更多时间专注于为 Spotify 提供功能，”Chakrabarti 说。Site Reliability Engineer James Wen 说，目前在 Kubernetes 上运行的最大服务每秒处理约 1000 万个请求，并且从自动伸缩中获益匪浅。此外，他补充说，“以前，团队需要等待一小时才能创建一个新服务并获得一个运行它的生产环境主机，但有了 Kubernetes，他们可以在几秒钟到几分钟内完成。”此外，借助 Kubernetes 的 bin-packing 和多租户功能，CPU 利用率平均提高了两到三倍。
作为微服务和 Docker 的早期采用者，Spotify 自 2014 年以来一直在其 VM 集群上运行容器化微服务。该公司使用名为 Helios 的开源自研容器编排系统，并在 2016-17 年完成了从本地数据中心到 Google Cloud 的迁移。支撑这些决定的理念是，“我们拥有围绕自治团队的文化，超过 200 个自治工程小组正在处理不同部分的工作，他们需要能够快速迭代，”Chakrabarti 说。“因此，对于我们来说，拥有能够让小组快速行动的开发速度工具非常重要。”
但到 2017 年底，很明显，“让一个小型团队负责 Helios 功能的效率，不如采用由更大社区支持的东西，”Chakrabarti 说。“我们看到了围绕 Kubernetes 生成的强大社区，我们希望成为其中的一部分。我们希望从更高的速度和更低的成本中获益，并与行业其他公司在最佳实践和工具方面保持一致。”同时，该团队希望在蓬勃发展的 Kubernetes 社区中贡献自己的专业知识和影响力。
另一个优势是：“Kubernetes 非常适合作为 Helios 的补充，现在也作为替代方案，因此我们可以让它与 Helios 一起运行以降低风险，”Chakrabarti 说。“在迁移过程中，服务同时在这两个系统上运行，因此我们不必将所有鸡蛋放在一个篮子里，直到我们能够在各种负载情况下和压力情况下验证 Kubernetes。”
该团队在 2018 年的大部分时间里都致力于解决迁移所需的核心技术问题。“我们能够使用 Kubernetes API 和 Kubernetes 的可扩展性功能来支持和与我们的遗留基础设施交互，因此集成非常简单轻松，”Site Reliability Engineer James Wen 说。
迁移于当年晚些时候开始，并在 2019 年加速。“我们的重点是无状态服务，一旦我们解决了最后一个剩余的技术障碍，我们希望看到增长，”Chakrabarti 说。“对于有状态服务，我们需要做更多工作。”
到目前为止，Spotify 的一小部分集群（包含超过 150 个服务）已经迁移到 Kubernetes。“我们从客户那里听说，他们不再需要过多地关注手动容量配置，而是可以花更多时间专注于为 Spotify 提供功能，”Chakrabarti 说。Wen 说，目前在 Kubernetes 上运行的最大服务每秒处理超过 1000 万个请求，并且从自动伸缩中获益匪浅。此外，Wen 补充说，“以前，团队需要等待一小时才能创建一个新服务并获得一个运行它的生产环境主机，但有了 Kubernetes，他们可以在几秒钟到几分钟内完成。”此外，借助 Kubernetes 的 bin-packing 和多租户功能，CPU 利用率平均提高了两到三倍。
Chakrabarti 指出，对于 Spotify 查看的所有四个顶级指标（前置时间、部署频率、解决时间和操作负载），“Kubernetes 都产生了影响”。
Kubernetes 早期使用中出现的成功案例之一是一个名为 Slingshot 的工具，它是由一个 Spotify 团队在 Kubernetes 上构建的。“通过一个 pull 请求，它会创建一个临时的暂存环境，并在 24 小时后自动销毁，”Chakrabarti 说。“这一切都是由 Kubernetes 促成的，因此这是一个令人兴奋的例子，说明一旦技术存在并可以使用，人们就开始在它的基础上构建并制作自己的解决方案，甚至超出了我们最初设想的用途。”
Spotify 还开始使用 gRPC 和 Envoy 来替换现有的自研解决方案，就像它对 Kubernetes 所做的那样。“我们创建这些东西是因为我们当时的规模，而且当时没有其他解决方案，”基础设施和运营软件工程师 Dave Zolotusky 说。“但随后社区赶上来并超越了我们，即使对于在如此规模下工作的工具也是如此。”
这两种技术都处于采用的早期阶段，但已经“我们有理由相信 gRPC 将在早期开发过程中产生更重大的影响，因为它可以帮助解决许多问题，例如模式管理、API 设计、奇怪的向后兼容性问题等等，”Zolotusky 说。“因此，我们非常依赖 gRPC 来帮助我们在这一领域。”
随着该团队继续完善 Spotify 的云原生堆栈（接下来是跟踪），它正在使用 CNCF 生态系统作为有用的指南。“我们会看看我们需要解决的问题，如果有很多项目，我们会对其进行同等评估，但项目是 CNCF 项目肯定是有价值的，”Zolotusky 说。
Spotify 到目前为止在 Kubernetes 上的体验证实了这一点。“社区在帮助我们更快、更轻松地解决所有技术问题方面非常有帮助，”Zolotusky 说。“与我们想要联系的任何人都能非常轻松地取得联系，以获取我们正在使用的任何事物的专业知识。这也有助于我们验证我们正在做的一切。”