挑戰
此音訊串流平台於 2008 年推出，現已成長至全球超過 2 億月活躍用戶。「我們的目標是賦能創作者，並為我們現有的所有消費者，以及我們未來有望擁有的消費者，提供真正身歷其境的聆聽體驗，」工程、基礎設施和營運總監 Jai Chakrabarti 表示。身為微服務和 Docker 的早期採用者，Spotify 已將容器化的微服務在其 VM 叢集中運行，並採用名為 Helios 的自家容器編排系統。他表示：「到了 2017 年底，我們清楚意識到，由一個小團隊開發這些功能，不如採用由更大的社群支援的技術來得有效率。」
解決方案
Chakrabarti 表示：「我們看到了 Kubernetes 周圍蓬勃發展的驚人社群，並希望成為其中的一份子。」Kubernetes 的功能比 Helios 更豐富。此外，「我們希望從更高的速度和更低的成本中獲益，並在最佳實務和工具方面與業界保持一致。」同時，團隊也希望在蓬勃發展的 Kubernetes 社群中貢獻其專業知識和影響力。Chakrabarti 表示，遷移將與 Helios 同時運行，可以順利進行，因為「Kubernetes 非常適合作為 Helios 的補充，現在則成為替代品。」
影響
團隊在 2018 年的大部分時間都在解決遷移所需的核心技術問題，遷移於當年稍晚開始，並成為 2019 年的重點工作。「我們叢集的一小部分已遷移至 Kubernetes，我們從內部團隊聽到的一些反饋是，他們不再需要專注於手動容量配置，而有更多時間專注於為 Spotify 交付功能，」Chakrabarti 表示。網站可靠性工程師 James Wen 表示，目前在 Kubernetes 上運行的最大服務，作為一個彙總服務，每秒處理約 1 千萬個請求，並從自動擴展中獲益良多。他補充說：「以前，團隊需要等待一個小時才能創建新服務並獲得一個可運行的主機來在生產環境中運行，但使用 Kubernetes，他們可以在幾秒鐘或幾分鐘內完成。」此外，憑藉 Kubernetes 的資源最佳化配置和多租戶功能，CPU 使用率平均提高了兩到三倍。
身為微服務和 Docker 的早期採用者，自 2014 年以來，Spotify 已將容器化的微服務在其 VM 叢集中運行。該公司使用名為 Helios 的開源自家容器編排系統，並在 2016-17 年完成了從內部部署資料中心到 Google Cloud 的遷移。Chakrabarti 表示，在這些決策的背後，「我們擁有一種圍繞自主團隊的文化，超過 200 個自主工程團隊致力於處理不同的部分，他們需要能夠快速迭代。因此，對我們來說，擁有可讓團隊快速行動的開發人員加速工具非常重要。」
但是到了 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 上運行的最大服務，作為一個彙總服務，每秒處理超過 1 千萬個請求，並從自動擴展中獲益良多。此外，Wen 補充說：「以前，團隊需要等待一個小時才能創建新服務並獲得一個可運行的主機來在生產環境中運行，但使用 Kubernetes，他們可以在幾秒鐘或幾分鐘內完成。」此外，憑藉 Kubernetes 的資源最佳化配置和多租戶功能，CPU 使用率平均提高了兩到三倍。
Chakrabarti 指出，對於 Spotify 關注的所有四個頂級指標 — 前置時間、部署頻率、解決時間和營運負載 —「Kubernetes 都產生了影響。」
Kubernetes 早期的一個成功案例是一個名為 Slingshot 的工具，該工具由 Spotify 團隊在 Kubernetes 上建構。「透過提取請求，它可以創建一個臨時的預演環境，該環境會在 24 小時後自動銷毀，」Chakrabarti 表示。「這一切都由 Kubernetes 促成，這是一個令人興奮的例子，說明一旦技術問世並準備就緒，人們就會開始在其基礎上進行建構，並打造自己的解決方案，甚至超出我們最初設想的目的。」
Spotify 也開始使用 gRPC 和 Envoy，以取代現有的自家解決方案，就像 Kubernetes 一樣。「我們創建這些東西是因為我們當時的規模，而且沒有其他現有的解決方案，」基礎設施和營運軟體工程師 Dave Zolotusky 表示。「但是後來社群趕上了我們，甚至超越了我們，即使是對於在該規模下運作的工具也是如此。」
這兩項技術都處於早期採用階段，但 Zolotusky 表示，「我們已經有理由相信，gRPC 將在早期開發階段產生更顯著的影響，它可以幫助解決許多問題，例如架構管理、API 設計、奇怪的向後相容性問題等等。因此，我們正在大力依賴 gRPC 來幫助我們解決這方面的問題。」
隨著團隊繼續完善 Spotify 的雲原生堆疊 — 追蹤是下一步 — 它們正在使用 CNCF landscape 作為有用的指南。「我們會查看需要解決的問題，如果有很多專案，我們會以同等的方式評估它們，但專案成為 CNCF 專案絕對具有價值，」Zolotusky 表示。
Spotify 迄今為止在 Kubernetes 方面的經驗證實了這一點。Zolotusky 表示：「社群在幫助我們更快、更輕鬆地完成所有技術工作方面，提供了極大的幫助。」「與我們想聯絡的任何人取得聯繫，以獲得有關我們正在處理的任何事情的專業知識，都出乎意料地容易。它也幫助我們驗證了我們正在做的所有事情。」