挑戰
音訊流媒體平臺 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 說道。“與我們想聯絡的任何人取得聯絡都出乎意料地容易，以獲取我們正在從事的任何事情的專業知識。它也幫助我們驗證了我們所做的一切。”