挑战
这个音频流媒体平台成立于 2008 年，目前在全球拥有超过 2 亿月活跃用户。 “我们的目标是赋能创作者，并为我们今天拥有的所有消费者以及未来希望拥有的消费者提供真正身临其境的聆听体验，”基础设施和运营工程总监 Jai Chakrabarti 说道。 作为微服务和 Docker 的早期采用者，Spotify 已将其在虚拟机集群上运行的微服务容器化，并使用名为 Helios 的自主研发容器编排系统。 到 2017 年底，很明显，“让一个小团队来开发这些功能并不像采用一个由更大社区支持的东西那样高效，”他说道。
解决方案
“我们看到了 Kubernetes 周围发展起来的惊人社区，我们希望成为其中的一员，”Chakrabarti 说道。 Kubernetes 比 Helios 功能更丰富。 此外，“我们希望从更高的速度和更低的成本中获益，并与业界其他公司在最佳实践和工具方面保持一致。” 与此同时，该团队希望在蓬勃发展的 Kubernetes 社区中贡献自己的专业知识和影响力。 迁移工作可以与 Helios 并行进行，并且可以顺利进行，因为“Kubernetes 非常适合作为 Helios 的补充，现在是替代品，”Chakrabarti 说道。
影响
该团队在 2018 年的大部分时间里都在解决迁移所需的核心技术问题，迁移工作于当年晚些时候开始，并且是 2019 年的一项重点工作。 “我们的一小部分集群已迁移到 Kubernetes，我们从内部团队那里听到的一些消息是，他们不再需要专注于手动容量配置，而是有更多时间专注于为 Spotify 交付功能，”Chakrabarti 说道。 网站可靠性工程师 James Wen 表示，目前在 Kubernetes 上运行的最大服务作为一个聚合服务每秒处理大约 1000 万个请求，并且极大地受益于自动扩展。 此外，他还补充道，“以前，团队必须等待一个小时才能创建新服务并获得一个可操作的主机来在生产环境中运行它，但使用 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 说道。 Wen 表示，目前在 Kubernetes 上运行的最大服务作为一个聚合服务每秒处理超过 1000 万个请求，并且极大地受益于自动扩展。 此外，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 说道。 “与我们想联系的任何人取得联系，以获得我们正在处理的任何事情的专业知识，都非常容易。 它帮助我们验证了我们正在做的所有事情。”