从小做起，在Kubernetes集群上尝试一些服务，然后转向更复杂的工作负载和自助服务迁移。
拥有1.7亿活跃用户和2500万首歌曲，Spotify是当前全球最大的音乐流媒体订阅服务提供商。截止2018年第一季度，拥有7000多万付费用户。与此同时，苹果音乐的用户才5000万（包括付费用户和试用用户）。而Spotify每天10亿次播放的背后则依靠一个缓慢转型的数字基础设施。
Spotify于2014年开源了其内部容器编排服务Helios。经过数年的使用后，Spotify决定从Helios转换到Kubernetes——这是发布不久就成为编排平台事实标准的另一种编排服务。
受到大量开发者支持，Kubernetes拥有一个巨大的生态系统，而根据Spotify的现场可靠性工程师James Wen的说法，即使对于像Spotify这样的企业，试图通过尚未被广泛采用的内部系统实现功能平等也很困难。
很明显，Spotify需要一个可托管的解决方案，而不是从头开始运维集群。通过迁移到Kubernetes，Spotify将受益于：
——云原生的“魔力”，如自动伸缩、更好的资源利用和自我修复
——开发人员不再需要做太多的容量规划
——专有技术较少
——更快的试验和运维
Spotify是怎么做的（现在仍在做）
尽管有一个明确的目标，即在Kubernetes上运行所有无状态服务，但Wen和他的同事们不能一次性将所有服务和团队迁移到Kubernetes。Spotify处于集中运维和团队自治之间——每个团队都对特定服务负有运维责任，而在整个业务中都有一套共同的流程，这与Netflix的“Paved Road”类似。
根据Wen的说法，Spotify决定从小做起，尝试在一个Kubernetes集群上运行一个服务，然后用数天时间在共享集群上迁移多达三个服务。通过一次只迁移几个服务，这一转换只会影响几个团队。
Spotify通过命名空间设置权限，因此开发人员不会破坏其他团队空间中的资源和资源配额，也就没有一个团队可能会占用太多资源和开发人员文档来在三个团队之间进行通信。
试验阶段完成后，Spotify进入alpha阶段，要求研发团队自愿选择他们有兴趣在Kubernetes上运行的服务。Wen和他的团队帮助将服务和管道迁移到Kubernetes。
在这个阶段，即使这些测试在运维上有问题也没关系。这些服务仍在Helios和Kubernetes上运行，如果发生事故，Spotify可能会停止在Kubernetes上的运行而聚焦于Helios。
在alpha阶段的第二部分，Spotify在共享集群上运行了两个复杂的高流量服务。此举要求他们以细粒度的级别了解网络设置，使他们能够尝试自动伸缩，并为其他团队将来迁移服务提供参考点和信心。
Spotify目前正处于自助式迁移的beta阶段，其中希望转移到Kubernetes的团队可以按照文档部分或完全迁移到Kubernetes。现在有些服务完全关闭了Helios，只能在Kubernetes上运行。
在GA阶段，Spotify的任何新服务都将仅部署在Kubernetes上，并为开发人员提供工具，如一键式迁移工具、垂直自动伸缩、自定义指标自动伸缩、IT常规控制和迁移跟踪。
Spotify用一个road团队帮助转换团队从裸机迁移到Google Cloud Platform，熟悉Kubernetes的工程师将执行类似的操作并帮助开发人员和团队进行迁移。
经验和教训
在转换过程中，Spotify能够在Kubernetes之上构建自定义扩展，例如准入控制器、资源标签和元数据以及由Netflix开发的面向软件更改的开源交付平台Spinnaker。
展望未来，该公司仍然需要应对一些挑战，包括集群管理、各地区的多集群运维以及构建对数据作业、机器学习工作负载和GPU工作负载的支持。
一路走来，Spotify已经吸取了一些经验教训，使未来的项目更容易一些。Wen表示，在引入具有大型生态系统的外部系统时，仔细考虑和谨慎地选择术语是非常重要的。 “过载的”术语可能会导致团队之间的沟通障碍。
通过稳步提高目标而不是单一的单体迁移来逐步推进，Spotify稳步增加范围和复杂性，并以可控的速度处理未知因素，鼓舞了开发人员的士气。而且，最重要的是，正在进行迁移的公司需要与其他公司和同行讨论基础设施解决方案。
原文链接：
https://www.ciodive.com/news/how-spotify-is-migrating-from-an-in-house-docker-orchestration-platform-to/525465/