挑战
音频流媒体平台 Spotify 于 2008 年推出，现已发展成为拥有全球超过 2 亿月活跃用户的平台。"我们的目标是赋能创作者，并为我们现有的以及未来的所有用户提供真正沉浸式的听音体验，" 工程、基础设施和运营总监 Jai Chakrabarti 说。Spotify 是微服务和 Docker 的早期采用者，已使用自研的容器编排系统 Helios 将微服务容器化并运行在其虚拟机集群上。到 2017 年底，"由一个小团队负责功能开发，其效率显然不如采用一个由庞大社区支持的系统，" 他说，这一点变得清晰起来。
解决方案
Chakrabarti 说："我们看到了围绕 Kubernetes 成长起来的令人惊叹的社区，我们希望成为其中的一员。" Kubernetes 比 Helios 功能更丰富。此外，"我们希望从提升的速度和降低的成本中获益，并在最佳实践和工具方面与行业其他企业保持一致。" 同时，团队也希望在蓬勃发展的 Kubernetes 社区中贡献其专业知识和影响力。这次迁移将与 Helios 并行运行，可以顺利进行，因为 "Kubernetes 可以很好地补充 Helios，现在则可以完全替代 Helios，" Chakrabarti 说。
成效
团队在 2018 年花费了大量时间解决迁移所需的核心技术问题，迁移工作于当年年末开始，是 2019 年的主要工作重点。Chakrabarti 说："我们一小部分虚拟机集群已经迁移到 Kubernetes，从我们的内部团队那里听到的反馈是，他们减少了手动容量配置的工作量，有更多时间专注于为 Spotify 交付功能。" 站点可靠性工程师 James Wen 说，目前运行在 Kubernetes 上的最大服务作为一个聚合服务，每秒处理约 1000 万个请求，并极大地受益于自动扩缩容。此外，他补充说："以前，团队创建新服务并获取可在生产环境中运行的操作主机需要等待一小时，但使用 Kubernetes 后，他们可以在几秒到几分钟内完成。" 另外，借助 Kubernetes 的资源高效利用和多租户能力，CPU 利用率平均提高了两到三倍。
Spotify 是微服务和 Docker 的早期采用者，自 2014 年以来就已将微服务容器化并运行在其虚拟机集群上。公司使用了一个名为 Helios 的开源自研容器编排系统，并在 2016-17 年完成了从本地数据中心到 Google Cloud 的迁移。Chakrabarti 说，支撑这些决策的基础是，"我们拥有围绕自治团队的文化，有超过 200 个自治的工程小队负责不同的工作，他们需要能够快速迭代。" "因此，拥有能够让小队快速行动的开发者速度工具对我们来说非常重要。"
但到 2017 年底，Chakrabarti 说，"由一个小团队负责 Helios 的功能开发，其效率显然不如采用一个由庞大社区支持的系统，"这一点变得清晰起来。"我们看到了围绕 Kubernetes 成长起来的令人惊叹的社区，我们希望成为其中的一员。我们希望从提升的速度和降低的成本中获益，并在最佳实践和工具方面与行业其他企业保持一致。" 同时，团队也希望在蓬勃发展的 Kubernetes 社区中贡献其专业知识和影响力。
Chakrabarti 说，另一个好处是："Kubernetes 可以很好地补充 Helios，现在则可以完全替代 Helios，因此我们可以让它与 Helios 并行运行以降低风险。" "在迁移期间，服务同时在两者上运行，这样我们就无需孤注一掷，直到我们能够在各种负载和压力条件下验证 Kubernetes 为止。"
团队在 2018 年花费了大量时间解决迁移所需的核心技术问题。站点可靠性工程师 James Wen 说："我们能够利用许多 Kubernetes API 和 Kubernetes 的可扩展性特性来支持并与我们的遗留基础设施对接，因此集成过程简单直接。"
迁移工作于当年年末开始，并在 2019 年加速进行。Chakrabarti 说："我们的重点主要放在无状态服务上，一旦我们解决了最后一个技术阻碍，我们希望迁移速度能因此加快。" "对于有状态服务，我们还需要做更多工作。"
到目前为止，Spotify 一小部分虚拟机集群（包含 150 多个服务）已迁移到 Kubernetes。Chakrabarti 说："我们从我们的客户（内部团队）那里听到的反馈是，他们减少了手动容量配置的工作量，有更多时间专注于为 Spotify 交付功能。" Wen 说，目前运行在 Kubernetes 上的最大服务作为一个聚合服务，每秒处理超过 1000 万个请求，并极大地受益于自动扩缩容。另外，Wen 补充说："以前，团队创建新服务并获取可在生产环境中运行的操作主机需要等待一小时，但使用 Kubernetes 后，他们可以在几秒到几分钟内完成。" 此外，借助 Kubernetes 的资源高效利用和多租户能力，CPU 利用率平均提高了两到三倍。
Chakrabarti 指出，对于 Spotify 关注的所有四个关键指标——交付周期、部署频率、解决时间和运维负载——"Kubernetes 都产生了积极影响"。
在 Kubernetes 早期阶段取得的一个成功案例是一个名为 Slingshot 的工具，由 Spotify 团队基于 Kubernetes 构建。Chakrabarti 说："通过一个拉取请求，它可以创建一个临时暂存环境，该环境会在 24 小时后自行销毁。" "这完全依靠 Kubernetes 实现，这是一个激动人心的例子，展示了当技术普及可用后，人们如何在它之上进行构建，并打造出自己的解决方案，甚至超出了我们最初设想的初始目的。"
与使用 Kubernetes 一样，Spotify 也开始使用 gRPC 和 Envoy，替换现有的自研解决方案。软件工程师、基础设施和运营工程师 Dave Zolotusky 说："我们当时处于那种规模，没有其他现成的解决方案，所以我们自己创建了这些东西。" "但后来社区赶上来并超越了我们，即使是对于适用于那种规模的工具也是如此。"
Zolotusky 说，这两项技术都处于早期采用阶段，但我们已经有理由相信 gRPC 在早期开发阶段会产生更重大的影响，通过帮助解决许多问题，例如模式管理、API 设计、奇怪的向后兼容性问题等等。"因此，我们正大力依赖 gRPC 在这方面提供帮助。"
随着团队继续完善 Spotify 的云原生技术栈——下一步是分布式追踪——他们正在使用 CNCF 技术全景图作为有用的指南。Zolotusky 说："我们会查看需要解决的问题，如果有一系列项目，我们会对它们进行同等评估，但项目本身是 CNCF 项目这一点无疑是有价值的。"
Spotify 迄今为止在 Kubernetes 方面的经验证实了这一点。Zolotusky 说："社区在帮助我们更快、更轻松地掌握和运用这些技术方面给予了极大帮助。" "令人惊讶地容易联系到任何我们想联系的人，以获取我们在使用的任何技术方面的专业知识。这也有助于我们验证正在做的一切。"