多年來，Pinterest 的 300 億用戶在超過 200 億個圖板上創建了超過 4 億個圖釘。 為了服務這群用戶和龐大的內容庫，該入口網站開發了數千種服務，從可由幾個 CPU 處理的微服務，到在整個虛擬機群上運行的巨型整體服務。 然後公司的目光落在了k8s上的時刻到來了。 為什麼“立方體”在 Pinterest 上看起來不錯？ 您將從我們最近翻譯的一篇文章中了解這一點 .
因此，有數億用戶和數千億個 pin。 為了服務這群用戶和龐大的內容庫，我們開發了數千種服務，從可以由幾個 CPU 處理的微服務，到在整個虛擬機器群上運行的巨型整體服務。 此外，我們還有各種可能也需要 CPU、記憶體或 I/O 存取的框架。
在維護這個工具庫時，開發團隊面臨許多挑戰：
- 工程師沒有統一的方式來運作生產環境。 無狀態服務、有狀態服務以及正在積極開發的專案是基於完全不同的技術堆疊。 這導致為工程師創建了完整的培訓課程，也使我們的基礎設施團隊的工作變得嚴重複雜化。
- 擁有自己的虛擬機群的開發人員給內部管理員帶來了巨大的負擔。 因此，更新作業系統或 AMI 等簡單操作需要數週甚至數月的時間。 這導致在看似絕對日常的情況下工作量增加。
- 在現有解決方案之上創建全球基礎設施管理工具存在困難。 由於找到虛擬機器的所有者並不容易，因此情況變得更加複雜。 也就是說，我們不知道是否可以安全地提取此容量以在我們基礎設施的其他部分中運作。
容器編排系統是統一工作負載管理的一種方式。 它們為提高開發速度並簡化基礎設施管理打開了大門，因為專案中涉及的所有資源均由集中式系統管理。
圖 1：基礎設施優先順序（可靠性、開發人員生產力和效率）。
Pinterest 的雲端管理平台團隊在 8 年發現了 K2017s。 到 2017 年上半年，我們已經記錄了大部分生產能力，包括 API 和所有 Web 伺服器。 隨後，我們對用於編排容器解決方案、建立叢集並使用它們的各種系統進行了徹底的評估。 2017 年底，我們決定使用 Kubernetes。 它非常靈活並且得到了開發者社群的廣泛支持。
到目前為止，我們已經基於 Kops 建立了自己的叢集啟動工具，並將現有的基礎設施元件（例如網路、安全性、指標、日誌記錄、身分管理和流量）遷移到 Kubernetes。 我們也為我們的資源實作了一個工作負載建模系統，其複雜性對開發人員來說是隱藏的。 現在我們的重點是確保叢集的穩定性、擴展叢集並連接新客戶端。
Kubernetes：Pinterest 方式
在 Pinterest 規模上開始使用 Kubernetes 作為我們的工程師喜歡的平台會遇到很多挑戰。
作為一家大公司，我們在基礎設施工具上投入了大量資金。 範例包括處理憑證處理和金鑰分發的安全工具、流量控制元件、服務發現系統、可見性元件以及日誌和指標排程元件。 收集所有這些都是有原因的：我們經歷了正常的嘗試和錯誤路徑，因此我們希望將所有這些設備整合到 Kubernetes 上的新基礎設施中，而不是在新平台上重新發明舊輪子。 這種方法總體上簡化了遷移，因為所有應用程式支援都已經存在，不需要從頭開始建立。
另一方面，Kubernetes 本身的負載預測模型（例如部署、作業和守護程序集）對於我們的專案來說還不夠。 這些可用性問題是遷移到 Kubernetes 的巨大障礙。 例如，我們聽到服務開發人員抱怨登入設定遺失或不正確。 我們也遇到了模板引擎的錯誤使用，當使用相同的規範和任務創建數百個副本時，這導致了噩夢般的調試問題。
在同一個叢集中維護不同的版本也非常困難。 想像一下，如果您需要在同一運行時環境的多個版本中同時工作，並處理所有問題、錯誤和更新，那麼客戶支援會多麼複雜。
Pinterest 用戶屬性和控制器
為了讓我們的工程師更輕鬆地實施 Kubernetes，並簡化和加速我們的基礎設施，我們開發了自己的自訂資源定義 (CRD)。
CRD 提供以下功能：
- 組合不同的本機 Kubernetes 資源，使它們作為單一工作負載運作。 例如，PinterestService 資源包括部署、登入服務和設定對應。 這讓開發者不用擔心設定DNS。
- 實施必要的應用程式支援。 使用者只需要根據自己的業務邏輯專注於容器規範，而 CRD 控制器則實現所有必要的 init 容器、環境變數和 pod 規範。 這為開發人員提供了根本不同的舒適度。
- CRD 控制器還管理本機資源的生命週期並提高偵錯可用性。 這包括協調期望和實際規格、更新 CRD 狀態和維護事件日誌等。 如果沒有 CRD，開發人員將被迫管理多個資源，這只會增加出錯的可能性。
以下是 PinterestService 和由我們的控制器管理的內部資源的範例：
正如您在上面看到的，為了支援自訂容器，我們需要整合一個 init 容器和幾個附加元件來提供安全性、可見性和網路流量。 此外，我們創建了配置映射模板並實現了對批次作業的 PVC 模板的支持，以及追蹤多個環境變數以追蹤身分、資源消耗和垃圾收集。
很難想像開發人員會在沒有 CRD 支援的情況下手動編寫這些配置文件，更不用說進一步維護和調試配置了。
應用程式部署工作流程
上圖展示如何將 Pinterest 自訂資源部署到 Kubernetes 叢集：
- 開發人員透過 CLI 和使用者介面與我們的 Kubernetes 叢集進行互動。
- CLI/UI 工具從 Artifactory 檢索工作流程設定 YAML 檔案和其他建置屬性（相同版本 ID），然後將它們提交至作業提交服務。 此步驟可確保僅將生產版本交付至叢集。
- JSS 是各種平台（包括 Kubernetes）的閘道。 這裡對使用者進行身份驗證，發放配額，並部分檢查 CRD 的配置。
- JSS端檢查CRD後，將訊息傳送到k8s平台API。
- 我們的 CRD 控制器監視所有使用者資源上的事件。 它將 CR 轉換為原生 k8s 資源，添加必要的模組，設定適當的環境變量，並執行其他支援工作，以確保容器化的使用者應用程式擁有足夠的基礎設施支援。
- 然後，CRD 控制器將接收的資料傳遞給 Kubernetes API，以便調度程式處理並投入生產。
注意：此預發布部署工作流程是為新 k8s 平台的第一批使用者建立的。 我們目前正在完善此流程，以與我們的新 CI/CD 完全整合。 這意味著我們無法告訴您與 Kubernetes 相關的所有內容。 我們期待在下一篇部落格文章「為 Pinterest 建立 CI/CD 平台」中分享我們的經驗和團隊在這個方向上的進展。
特殊資源類型
根據 Pinterest 的具體需求，我們開發了以下 CRD 以適應不同的工作流程：
- PinterestService 是已經運行很長時間的無狀態服務。 我們的許多核心系統都是基於一組此類服務。
- PinterestJobSet 模擬全週期批次作業。 Pinterest 上的一個常見場景是多個作業並行運行相同的容器，而不考慮其他類似的進程。
- PinterestCronJob 廣泛與小型週期性負載結合使用。 這是本機 cron 與 Pinterest 支援機制一起工作的包裝器，負責安全、流量、日誌和指標。
- PinterestDaemon 包含基礎設施守護程式。 隨著我們為集群提供更多支持，這個家族不斷壯大。
- PinterestTrainingJob 擴展到 Tensorflow 和 Pytorch 進程，提供與所有其他 CRD 相同等級的執行時間支援。 由於 Pinterest 積極使用 Tensorflow 和其他機器學習系統，因此我們有理由圍繞它們建立單獨的 CRD。
我們也正在開發 PinterestStatefulSet，它將很快適用於資料倉儲和其他有狀態系統。
運行時支援
當應用程式 Pod 在 Kubernetes 上運作時，它會自動接收一個憑證來識別自己。 此憑證用於存取秘密儲存或透過 mTLS 與其他服務進行通訊。 同時，容器初始化配置器和守護程序將在運行容器化應用程式之前下載所有必需的依賴項。 當一切準備就緒後，流量邊車和守護程式將向我們的 Zookeeper 註冊模組的 IP 位址，以便用戶端可以發現它。 所有這一切都將起作用，因為網路模組是在應用程式啟動之前配置的。
以上是工作負載運行時支援的典型範例。 其他類型的工作負載可能需要稍微不同的支持，但它們都以 Pod 級 sidecar、節點級或虛擬機級守護程序的形式出現。 我們確保所有這些都部署在管理基礎架構內，並且在應用程式之間保持一致，這最終顯著減輕了技術工作和客戶支援的負擔。
測試和品質保證
我們在現有 Kubernetes 測試基礎架構之上建立了端到端測試管道。 這些測試適用於我們所有的叢集。 我們的管道在成為產品集群的一部分之前經歷了多次修改。
除了測試系統之外，我們還有監控和警報系統，可以持續監控系統組件的狀態、資源消耗和其他重要指標，僅在需要人為幹預時通知我們。
替代品
我們研究了自訂資源的一些替代方案，例如突變存取控制器和模板系統。 然而，它們都面臨著巨大的營運挑戰，因此我們選擇了 CRD 路線。
使用突變准入控制器來引入 sidecar、環境變數和其他運行時支援。 然而，它面臨著各種問題，例如資源綁定和生命週期管理，而這些問題在 CRD 中不會出現。
注： Helm 圖表等模板系統也廣泛用於運行具有類似配置的應用程式。 然而，我們的工作應用程式過於多樣化，無法使用範本進行管理。 而且在持續部署的過程中，使用模板時也會出現太多的錯誤。
即將進行的工作
我們目前正在處理所有叢集之間的混合負載。 為了支援不同類型和規模的此類流程，我們在以下領域開展工作：
- 叢集集合將大型應用程式分佈在不同的叢集中，以實現可擴展性和穩定性。
- 確保叢集穩定性、可擴展性和可見性，以建立應用程式連接和 SLA。
- 管理資源和配額，使應用程式不會相互衝突，並且叢集的規模由我們控制。
- 一個新的 CI/CD 平台，用於在 Kubernetes 上支援和部署應用程式。
來源： www.habr.com