挑戰
在成立八年後，Pinterest 已成長為擁有 1,000 個微服務、多層基礎架構以及多樣化的設定工具和平台。2016 年，公司啟動了邁向新運算平台的藍圖，其願景是創造從構想到生產的最快路徑，而無需工程師擔心底層基礎架構。
解決方案
第一階段涉及將服務遷移到 Docker 容器。一旦這些服務在 2017 年初投入生產，團隊便開始研究協調，以幫助提高效率並以分散式方式管理它們。在評估了各種解決方案後，Pinterest 選擇了 Kubernetes。
影響
Pinterest 雲端和資料基礎架構部門產品經理 Micheal Benedict 表示：「透過遷移到 Kubernetes，團隊除了簡化 Jenkins 等複雜基礎架構的整體部署和管理之外，還能夠建構隨需擴展和新的故障轉移策略。我們不僅看到了縮短的建置時間，還獲得了巨大的效率提升。例如，團隊在非尖峰時段回收了超過 80% 的容量。因此，與先前的靜態叢集相比，Jenkins Kubernetes 叢集現在每天使用的執行個體時數減少了 30%。」
自推出以來，Pinterest 已成為家喻戶曉的名字，擁有超過 2 億月活躍用戶和 1,000 億個已儲存的物件。在其底層，有 1,000 個微服務正在運行，以及數十萬個資料作業。
隨著如此的成長，隨之而來的是多層基礎架構以及適用於不同工作負載的多樣化設定工具和平台，導致端到端開發人員體驗不一致且複雜，最終導致進入生產環境的速度降低。因此，在 2016 年，公司啟動了邁向新運算平台的藍圖，其願景是擁有從構想到生產的最快路徑，而無需工程師擔心底層基礎架構。
第一階段涉及遷移到 Docker。雲端和資料基礎架構部門產品經理 Micheal Benedict 表示：「長期以來，Pinterest 一直大量依賴虛擬機器，直接在 EC2 執行個體上運行。為了解決軟體封裝的問題，並且不讓工程師擁有部分叢集以及這些類型的挑戰，我們標準化了封裝機制，然後將其遷移到 VM 之上的容器。沒有太多劇烈的變化。我們當時不想把事情搞得太複雜。」
遷移的第一個服務是為 Pinterest 大部分功能提供支援的單體式 API 叢集。同時，Benedict 的基礎架構治理團隊建構了費用分攤和容量規劃系統，以分析公司如何使用其在 AWS 上的虛擬機器。Benedict 表示：「很明顯，以我們目前的工作量，在 VM 上運行是不可持續的。許多資源未被充分利用。過去曾進行過提高效率的努力，在一定規模下效果良好，但現在您必須轉向更分散式的方式來管理。因此，我們認為協調可以幫助解決這個問題。」
這促成了藍圖的第二階段。2017 年 7 月，經過八週的評估期後，團隊選擇了 Kubernetes 而不是其他協調平台。Benedict 表示：「當時 Kubernetes 缺少某些東西，例如，我們想要在 Kubernetes 上運行 Spark。但我們意識到，即使嘗試建構它，我們投入的開發週期也完全值得這個結果，無論是對 Pinterest 還是社群而言。我們一直在 Big Data SIG 中參與這些對話。我們意識到，等到我們將其中許多東西投入生產時，我們就能夠利用社群正在做的事情。」
在 2018 年初，團隊開始將其第一個用例加入 Kubernetes 系統：Jenkins 工作負載。Benedict 表示：「儘管我們的建置工作發生在一天中的特定時段，但我們始終需要分配尖峰容量。它們沒有任何自動擴展功能，因此容量保持不變。加速建置很困難，因為擴展需要更多時間。因此，考慮到這些類型的顧慮，我們認為這將是一個非常適合我們處理的用例。」
他們擴展了叢集，並與一個四人團隊合作，使 Jenkins Kubernetes 叢集準備好投入生產。Benedict 表示：「我們仍然有靜態 Jenkins 叢集，但在 Kubernetes 上，我們正在進行類似的建置、測試整個管線、準備好成品，並僅進行比較以查看，在這裡建置花了多少時間。SLA 是否正常，產生的成品是否正確，那裡是否有問題？」
他補充說：「到目前為止，一切都很好，特別是在我們如何在 Kubernetes 共享叢集上配置 Jenkins 工作負載方面的彈性。這正是我們努力爭取的勝利。」
到 2018 年第一季末，團隊成功地將 Jenkins Master 遷移到在 Kubernetes 上原生運行，並合作開發了 Jenkins Kubernetes 外掛程式 以管理工作節點的生命週期。Benedict 表示：「我們目前正在這個新叢集上建構整個 Pinterest JVM 堆疊（Pinterest 較大的單體式儲存庫之一，最近已 bazel 化）。在尖峰時段，我們在數百個節點上運行數千個 Pod。總體而言，透過遷移到 Kubernetes，團隊除了簡化 Jenkins 等複雜基礎架構的整體部署和管理之外，還能夠建構隨需擴展和新的故障轉移策略。我們不僅看到了縮短的建置時間，還獲得了巨大的效率提升。例如，團隊在非尖峰時段回收了超過 80% 的容量。因此，與先前的靜態叢集相比，Jenkins Kubernetes 叢集現在每天使用的執行個體時數減少了 30%。」
Benedict 指出，未來將有一個「相當穩健的藍圖」。除了 Pinterest 大數據團隊在 Kubernetes 上進行 Spark 實驗外，公司還與 Amazon 的 EKS 團隊合作開發了 ENI/CNI 外掛程式。
一旦 Jenkins 叢集啟動並運作並退出暗模式，Benedict 希望建立最佳實務，包括在遷移下一個服務之前，先建立治理基本要素（包括與費用分攤系統的整合）。Benedict 表示：「我們有一個健康的用例管線需要加入。在 Jenkins 之後，我們希望啟用對 Tensorflow 和 Apache Spark 的支援。在某個時候，我們的目標是遷移公司的單體式 API 服務。如果我們遷移了它並了解了圍繞它的複雜性，這將建立我們的信心。它為我們遷移所有其他服務奠定了基礎。」
在成為雲原生先驅多年之後，Pinterest 渴望分享其持續進行的旅程。Benedict 表示：「我們有能力在公有雲環境中大規模運行事物，並以許多人可能無法做到的方式進行測試。我們處於一個很好的位置，可以回饋一些這些經驗。」