挑戰
成立八年後，Pinterest 已發展成擁有 1,000 個微服務、多層基礎設施以及多樣化的設定工具和平臺。2016 年，公司啟動了一個新的計算平臺路線圖，其願景是建立從構思到生產的最快路徑，而無需工程師擔心底層基礎設施。
解決方案
第一階段包括將服務遷移到 Docker 容器。這些服務在 2017 年初投入生產後，團隊開始研究編排，以幫助提高效率並以分散的方式管理它們。在評估了各種解決方案後，Pinterest 選擇了 Kubernetes。
影響
Pinterest 雲和資料基礎設施部門的產品經理 Micheal Benedict 表示：“透過遷移到 Kubernetes，團隊能夠構建按需擴充套件和新的故障轉移策略，此外還簡化了 Jenkins 等複雜基礎設施的整體部署和管理。”“我們不僅縮短了構建時間，還取得了巨大的效率提升。例如，團隊在非高峰時段回收了超過 80% 的容量。結果，Jenkins Kubernetes 叢集現在每天使用的例項小時數比以前的靜態叢集減少了 30%。”
自推出以來，Pinterest 已成為家喻戶曉的品牌，每月活躍使用者超過 2 億，儲存了 1000 億個物件。在其內部，執行著 1000 個微服務和數十萬個數據作業。
隨著這種增長，基礎設施層變得越來越複雜，針對不同工作負載的設定工具和平臺也多種多樣，導致端到端開發人員體驗不一致且複雜，最終導致投入生產的速度變慢。因此，在 2016 年，公司啟動了一個新的計算平臺路線圖，其願景是建立從構思到生產的最快路徑，而無需工程師擔心底層基礎設施。
第一階段涉及遷移到 Docker。“Pinterest 長期以來一直大量執行在虛擬機器上，直接執行在 EC2 例項上，”雲和資料基礎設施部門的產品經理 Micheal Benedict 說。“為了解決軟體打包問題，並避免工程師擁有部分叢集以及此類挑戰，我們標準化了打包機制，然後將其遷移到虛擬機器頂部的容器中。沒有太多劇烈的變化。當時我們不想大動干戈。”
第一個遷移的服務是支援 Pinterest 大部分功能的單一 API 叢集。同時，Benedict 的基礎設施治理團隊建立了成本分攤和容量規劃系統，以分析公司如何使用其在 AWS 上的虛擬機器。“很明顯，我們目前執行在虛擬機器上是不可持續的，”Benedict 說。“很多資源都被低效利用了。有一些效率提升的努力，在一定規模下執行良好，但現在你必須轉向一種更分散的管理方式。所以我們認為編排可以幫助解決這部分問題。”
這導致了路線圖的第二階段。2017 年 7 月，經過八週的評估期，團隊選擇了 Kubernetes 而非其他編排平臺。“Kubernetes 當時缺少一些功能——例如，我們想要在 Kubernetes 上執行 Spark，”Benedict 說。“但我們意識到，我們為嘗試構建這些功能所投入的開發週期非常值得，無論是對 Pinterest 還是對社群來說。我們一直在 Big Data SIG 的討論中。我們意識到，在我們實際生產許多這些功能時，我們將能夠利用社群正在做的事情。”
2018 年初，團隊開始將第一個用例引入 Kubernetes 系統：Jenkins 工作負載。“儘管我們在一天中的某個特定時段進行構建，但我們總是需要分配峰值容量，”Benedict 說。“它們沒有任何自動擴充套件功能，所以容量保持不變。加速構建很困難，因為啟動需要更多時間。考慮到這些擔憂，我們認為這將是我們完美的應用場景。”
他們擴大了叢集，並與一個四人團隊合作，將 Jenkins Kubernetes 叢集投入生產。“我們仍然有我們的靜態 Jenkins 叢集，”Benedict 說，“但在 Kubernetes 上，我們正在進行類似的構建，測試整個管道，準備好工件，然後進行比較，看看這裡構建花了多少時間。SLA 是否正常，生成的工件是否正確，是否存在問題？”
“到目前為止一切順利，”他補充道，“尤其是在我們如何配置 Jenkins 工作負載在 Kubernetes 共享叢集上的靈活性方面。這就是我們一直努力爭取的目標。”
截至 2018 年第一季度末，團隊成功將 Jenkins Master 遷移到 Kubernetes 上原生執行，並協作開發了 Jenkins Kubernetes Plugin 來管理工作器的生命週期。“我們目前正在這個新叢集上構建整個 Pinterest JVM 堆疊（Pinterest 中較大的單體倉庫之一，最近已進行了 bazel 化改造），”Benedict 說。“在高峰期，我們在幾百個節點上執行數千個 Pod。總的來說，透過遷移到 Kubernetes，團隊能夠構建按需擴充套件和新的故障轉移策略，此外還簡化了 Jenkins 等複雜基礎設施的整體部署和管理。我們不僅縮短了構建時間，還取得了巨大的效率提升。例如，團隊在非高峰時段回收了超過 80% 的容量。結果，Jenkins Kubernetes 叢集現在每天使用的例項小時數比以前的靜態叢集減少了 30%。”
Benedict 指出了一個“相當穩健的未來路線圖”。除了 Pinterest 大資料團隊在 Kubernetes 上進行的 Spark 實驗之外，該公司還與 Amazon 的 EKS 團隊合作開發了 ENI/CNI 外掛。
一旦 Jenkins 叢集脫離暗模式並正常執行，Benedict 希望建立最佳實踐，包括建立治理原語（包括與成本分攤系統的整合），然後再遷移下一個服務。“我們有一個健康的用例管道等待上線。在 Jenkins 之後，我們希望啟用對 Tensorflow 和 Apache Spark 的支援。在某個時候，我們計劃遷移公司的單體 API 服務。如果我們遷移並瞭解其中的複雜性，它會增強我們的信心，”Benedict 說。“這將為我們遷移所有其他服務做好準備。”
作為雲原生領域的先驅多年，Pinterest 渴望分享其持續的旅程。“我們有能力在公共雲環境中大規模執行事物，並以許多人可能無法做到的方式進行測試，”Benedict 說。“我們處於一個很好的位置，可以回饋其中一些經驗教訓。”