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