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