可能國內(nèi)讀者不太熟悉 Pinterest，但它在美國，可是坐擁 3 億用戶的美版“小紅書”，媲美社媒巨頭！如果你熟悉“小紅書”，那么你就很容易理解 Pinterest 的定位了。在如此龐大體量的 Pinterest，是如何建立 Kubernetes 平臺(tái)的？ 1 為什么選擇 Kubernetes？

在過去的幾年里，有 3 億多 Pinner 在 Pinterest 上保存了超過 2000 億次 Pin，覆蓋了超過 40 億個(gè) Board。為了服務(wù)于這個(gè)龐大的用戶群和內(nèi)容池，我們開發(fā)了數(shù)以千計(jì)的服務(wù)，從少數(shù)幾個(gè) CPU 的微服務(wù)到占用整個(gè)虛擬機(jī)群的巨大整體服務(wù)。還有來自各種不同框架的批處理作業(yè)，它們可以是 CPU、內(nèi)存或 I/O 密集型。

譯注：要理解這段話，譯者有必要在這里簡單介紹一下 Pinterest 及其基本元素。Pinterest 是一個(gè)圖片社交平臺(tái)，堪稱圖片版的 Twitter，用戶可以發(fā)表自己的 Pin，也可以轉(zhuǎn)發(fā)自己喜歡的圖片。Pinterest 采用的是瀑布流的形式展現(xiàn)圖片內(nèi)容，無需用戶翻頁，新的圖片不斷自動(dòng)加載在頁面底端，讓用戶不斷的發(fā)現(xiàn)新的圖片。Pinterest 里面有一些基本元素。如 Pin。Pin 即你在 Pinterest 上發(fā)表的帖子，發(fā)布 Pin 的人統(tǒng)稱被稱為 Pinner。一個(gè) Pin 通常是由一張圖片，一個(gè)到外部網(wǎng)頁的鏈接和幾句簡短的描述組成，并且發(fā)布的時(shí)候需要將其歸類到它所屬的 Board 里。

為了支持這些不同的工作負(fù)載，Pinterest 的基礎(chǔ)架構(gòu)團(tuán)隊(duì)面臨著多種挑戰(zhàn)：

工程師在啟動(dòng)工作負(fù)載時(shí)并沒有統(tǒng)一的體驗(yàn)。無狀態(tài)服務(wù)、有狀態(tài)服務(wù)和批處理作業(yè)由完全不同的技術(shù)棧部署和管理。如此一來，給工程師們帶來了陡峭的學(xué)習(xí)曲線，同時(shí)也給基礎(chǔ)架構(gòu)團(tuán)隊(duì)帶來巨大的維護(hù)和客戶支持負(fù)擔(dān)。

管理自己的虛擬機(jī)群的工程師給 infra 團(tuán)隊(duì)帶來了巨大的維護(hù)負(fù)擔(dān)。操作系統(tǒng)或 AMI 升級(jí)等簡單的操作可能需要耗時(shí)數(shù)周到數(shù)月的時(shí)間才能完成。生產(chǎn)工作負(fù)載在這些過程中也會(huì)遇到干擾，而這些過程本應(yīng)對(duì)生產(chǎn)工作負(fù)載是透明的。

很難在獨(dú)立的管理系統(tǒng)之上構(gòu)建基礎(chǔ)架構(gòu)治理工具。對(duì)我們來說，更難確定哪些機(jī)器的歸屬，以及它們是否可以安全回收。

容器編排系統(tǒng)提供了統(tǒng)一工作負(fù)載管理的方法。它們還為更快的開發(fā)速度和更容易的基礎(chǔ)架構(gòu)治理鋪平了道路，因?yàn)樗羞\(yùn)行的資源都由集中式系統(tǒng)管理。

圖 1：基礎(chǔ)架構(gòu)優(yōu)先級(jí)（服務(wù)可靠性、開發(fā)人員生產(chǎn)力和基礎(chǔ)架構(gòu)效率）

Pinterest 的云管理平臺(tái)團(tuán)隊(duì)早在 2017 年就開始了在 Kubernetes 的旅程。到 2017 年上半年，我們將大部分生產(chǎn)工作負(fù)載進(jìn)行了容器化（包括核心 API 和 Web 服務(wù)器集群）。然后，通過構(gòu)建產(chǎn)品集群并在其上運(yùn)行實(shí)際工作負(fù)載，來對(duì)不同的容器編排系統(tǒng)進(jìn)行廣泛的評(píng)估。到 2017 年底，我們決定沿著 Kubernetes 的道路走下去，因?yàn)樗哂徐`活性，而且還有廣泛的社區(qū)支持。

到目前為止，我們已經(jīng)基于 Kops 構(gòu)建了自己的集群引導(dǎo)工具，并將現(xiàn)有的基礎(chǔ)架構(gòu)組件集成到 Kubernetes 集群中，如網(wǎng)絡(luò)、安全性、指標(biāo)、日志記錄、身份管理和流量等。我們還引入了 Pinterest 特定的自定義資源來模擬我們的獨(dú)特工作負(fù)載，同時(shí)對(duì)開發(fā)人員隱藏運(yùn)行時(shí)的復(fù)雜性。我們現(xiàn)在工作的重點(diǎn)是集群穩(wěn)定性、可擴(kuò)展性和客戶支持。

2 Kubernetes：Pinterest 選擇的路

運(yùn)行 Kubernetes 來支持 Pinterest 這樣規(guī)模的工作負(fù)載，同時(shí)又要讓它成為我們工程師喜愛的平臺(tái)，真的是一個(gè)很大的挑戰(zhàn)。

作為一個(gè)大型組織，我們?cè)诨A(chǔ)架構(gòu)工具上投入了大量資金，例如處理證書和密鑰分發(fā)的安全工具、支持服務(wù)注冊(cè)和發(fā)現(xiàn)的流量組件，以及提供日志和指標(biāo)的可見性組件。這些組件都是基于艱難的經(jīng)驗(yàn)教訓(xùn)上構(gòu)建的，因此我們希望將它們整合到 Kubernetes 內(nèi)，而不是“重新發(fā)明輪子”。這一做法也使得遷移變得更加容易，因?yàn)槲覀兊膬?nèi)部應(yīng)用已經(jīng)獲得了所需的支持。

另一方面，Kubernetes 本機(jī)工作負(fù)載模型（如部署、作業(yè)和守護(hù)進(jìn)程集）并不足以為我們自己的工作負(fù)載進(jìn)行建模。可用性問題是采用 Kubernetes 的巨大障礙。例如，我們?cè)?jīng)聽到服務(wù)開發(fā)人員抱怨丟失或錯(cuò)誤配置的原因“擾亂”了他們的終端。我們還看到批處理作業(yè)用戶使用模板工具生成數(shù)百個(gè)同一作業(yè)規(guī)范的副本，最終導(dǎo)致了調(diào)試噩夢(mèng)。

對(duì)工作負(fù)載的運(yùn)行時(shí)支持也在不斷發(fā)展，因此在同一個(gè) Kubernetes 集群上支持不同版本將會(huì)變得異常困難。想象一下，如果我們需要面對(duì)許多版本的運(yùn)行時(shí)，客戶支持的復(fù)雜性，以及為它們進(jìn)行升級(jí)或修補(bǔ) bug 該有多大的困難。

3 Pinterest 自定義資源和控制器

為了讓我們的工程師更容易地采用 Kubernetes，并使基礎(chǔ)架構(gòu)開發(fā)更快速、更順暢，我們?cè)O(shè)計(jì)了自己的自定義資源（Custom Resource Definitions，CRD）

CRD 提供了以下功能：

將各種本機(jī) Kubernetes 資源捆綁在一起，使它們作為單一工作負(fù)載進(jìn)行工作。例如，PinterestService 資源將部署、服務(wù)、入口和應(yīng)用配置管理組合在一起，因此服務(wù)開發(fā)人員無需擔(dān)心為他們的服務(wù)設(shè)置 DNS。

為應(yīng)用程序注入必要的運(yùn)行時(shí)支持。用戶只需關(guān)注自己業(yè)務(wù)邏輯的容器規(guī)范即可，而 CRD 控制器將必要的邊車容器（sidecar）、初始容器、環(huán)境變量和卷（volume）注入到它們的容器節(jié)點(diǎn)（pod）規(guī)格中。這為應(yīng)用工程師帶來了開箱即用的體驗(yàn)。

CRD 控制器還可以對(duì)本機(jī)資源進(jìn)行生命周期管理，并處理可見性和可調(diào)試性。這包括但不限于協(xié)調(diào)所需的規(guī)格和實(shí)際規(guī)格、CRD 狀態(tài)更新和事件記錄。如果沒有 CRD 的話，應(yīng)用工程師必須管理更多的資源，而且這個(gè)過程已經(jīng)被證明很容易出錯(cuò)。下面是 PinterestService 和由控制器轉(zhuǎn)換的本機(jī)資源的示例：

圖 2：CRD 到本機(jī)資源。左邊是用戶編寫的 Pinterest CR，右邊是控制器生成的本機(jī)資源定義。

如圖所示，為了支持用戶的容器，我們需要插入一個(gè)初始容器和幾個(gè)邊車容器，以保證安全性、可見性和網(wǎng)絡(luò)流量。此外，我們?cè)谂幚碜鳂I(yè)中引入了應(yīng)用配置管理模板和 PVC 模板支持，以及許多環(huán)境變量來跟蹤身份、資源利用率和垃圾收集。

難以想象工程師會(huì)愿意在沒有 CRD 支持的情況下手工編寫這些配置文件，更不用說維護(hù)和調(diào)試配置了。

4 應(yīng)用程序部署工作流

圖 3：Pinterest CRD 概述

圖 3 展示了如何將 Pinterest 自定義資源部署到 Kubernetes 集群：

開發(fā)人員通過命令行界面（CLI）和用戶界面（UI）與我們的 Kubernetes 集群進(jìn)行交互。

CLI/UI 工具從 Artifactory 檢索工作流配置 YAML 文件和其他構(gòu)件屬性（如版本 ID），并將它們發(fā)送到作業(yè)提交服務(wù)。這樣可以確保只向 Kubernetes 集群提交已審查和已登錄的工作負(fù)載。

作業(yè)提交服務(wù)是各種計(jì)算平臺(tái)（包括 Kubernetes）的“網(wǎng)關(guān)”。用戶身份驗(yàn)證、配額強(qiáng)制和部分 Pinterest CRD 配置驗(yàn)證都在這里進(jìn)行。

一旦 CRD 通過了作業(yè)提交服務(wù)驗(yàn)證，它就會(huì)被發(fā)送到 Kubernetes API。

我們的 CRD 控制器監(jiān)視所有自定義資源上的事件。它將 CR 轉(zhuǎn)換為 Kubernetes 本機(jī)資源，將必要的邊車容器添加到用戶定義的容器節(jié)點(diǎn)中，設(shè)置適當(dāng)?shù)沫h(huán)境變量，并執(zhí)行其他必要的內(nèi)務(wù)處理工作，以確保用戶的應(yīng)用程序容器具有足夠的基礎(chǔ)架構(gòu)支持。

然后，CRD 控制器將生成的本機(jī)資源寫回 Kubernetes API 中，以便調(diào)度器（scheduler）可以提取這些資源并開始運(yùn)行。

注意：這是新的基于 Kubernetes 的計(jì)算平臺(tái)的早期采用者使用的預(yù)發(fā)布部署工作流。我們正對(duì)這一體驗(yàn)進(jìn)行改進(jìn)，使其與我們新的 CI/CD 平臺(tái)完全繼承，以避免暴露過多 Kubernetes 具體的細(xì)節(jié)。我們期待在即將發(fā)布的博文《為 Pinterest 構(gòu)建 CI/CD 平臺(tái)》中分享我們的動(dòng)機(jī)、進(jìn)展和后續(xù)影響。

5 自定義資源類型

基于 Pinterest 的具體需求，我們?cè)O(shè)計(jì)了以下適合不同工作流的 CRD：

PinterestService是長期運(yùn)行的無狀態(tài)服務(wù)。許多核心系統(tǒng)都基于一組此類服務(wù)。

PinterestJobSet為運(yùn)行到完成的批處理作業(yè)建模。Pinterest 中一個(gè)非常常見的模式是，多個(gè)作業(yè)并行運(yùn)行相同的容器，每個(gè)作業(yè)都只占用工作負(fù)載的一小部分，而不依賴于彼此。

PinterestCronJob被據(jù)用輕量級(jí)周期性工作負(fù)載的團(tuán)隊(duì)廣泛采用。PinterestCronJob 是圍繞本機(jī) cron 作業(yè)的包裝器，支持 Pinterest 特有的安全性、流量、日志和指標(biāo)等。

PinterestDaemon僅限于與基礎(chǔ)架構(gòu)相關(guān)的守護(hù)進(jìn)程。隨著我們?cè)诩荷咸砑痈嗟闹С?，PinterestDaemon 的家族仍在增長。

PinterestTrainingJob封裝了 TensorFlow 和 PyTorch 作業(yè)，提供了與所有其他 CRD 相同級(jí)別的運(yùn)行時(shí)支持。由于 Pinterest 大量使用 TensorFlow 和其他機(jī)器學(xué)習(xí)框架，因此圍繞他們構(gòu)建專門的 CRD 是有意義的。

我們還有正在構(gòu)建的PinterestStatefulSet，將很快被用于存儲(chǔ)和其他有狀態(tài)系統(tǒng)。

6 運(yùn)行時(shí)支持

當(dāng)應(yīng)用程序容器節(jié)點(diǎn)在 Kubernetes 上啟動(dòng)時(shí)，它會(huì)自動(dòng)獲得一個(gè)證書標(biāo)識(shí)自己。此證書用于通過 mTLS 訪問機(jī)密存儲(chǔ)或與其他服務(wù)進(jìn)行通信。同時(shí)，配置管理初始容器和守護(hù)進(jìn)程將確保在應(yīng)用程序容器啟動(dòng)之前就下載好所有必需的依賴項(xiàng)。當(dāng)應(yīng)用程序容器準(zhǔn)備就緒時(shí)，流量邊車容器和守護(hù)進(jìn)程將會(huì)向容器節(jié)點(diǎn)注冊(cè)到 Zookeeper，以便讓客戶端可以發(fā)現(xiàn)它。甚至在容器節(jié)點(diǎn)啟動(dòng)之前，網(wǎng)絡(luò)守護(hù)進(jìn)程就已經(jīng)為容器節(jié)點(diǎn)設(shè)置好了網(wǎng)絡(luò)。

以上就是服務(wù)工作負(fù)載的典型運(yùn)行時(shí)支持的示例。其他工作負(fù)載類型可能需要稍微不同的支持，但他們都是以容器節(jié)點(diǎn)級(jí)邊車容器、節(jié)點(diǎn)級(jí)守護(hù)進(jìn)程集或虛擬機(jī)級(jí)守護(hù)進(jìn)程的形式出現(xiàn)的。我們確保所有這些應(yīng)用程序都是由基礎(chǔ)架構(gòu)團(tuán)隊(duì)部署，以便它們?cè)谒袘?yīng)用程序之間保持一致，從而極大減少我們的維護(hù)和客戶支持的負(fù)擔(dān)。

7 測試與質(zhì)量保證

我們?cè)诒緳C(jī) Kubernetes 測試基礎(chǔ)上構(gòu)建了一個(gè)端到端的測試管道。這些測試部署到所有的集群。這個(gè)管道在到達(dá)生產(chǎn)集群之前就已經(jīng)經(jīng)歷了多次回歸。

除了測試基礎(chǔ)架構(gòu)之外，還有監(jiān)視和報(bào)警系統(tǒng)，這些系統(tǒng)持續(xù)監(jiān)控系統(tǒng)組件的健康狀態(tài)、資源利用率和其他關(guān)鍵指標(biāo)，在需要人工干預(yù)時(shí)通知我們。

8 備選方案

我們考慮了一些自定義資源的備選方案，比如變異許可控制器和模板系統(tǒng)。但是，所有的備選方案都存在重大問題，因此我們選擇了 CRD 的路徑。

變異許可控制器以用于注入邊車容器、環(huán)境變量和其他運(yùn)行時(shí)支持。然而，它很難講資源捆綁在一起以及管理它們的生命周期，而 CRD 則需要協(xié)調(diào)、狀態(tài)更新和生命周期管理功能。

模板系統(tǒng)（如 Helm charts）也被廣泛用于啟動(dòng)具有類似配置的應(yīng)用程序。但是，我們的工作負(fù)載過于多樣化，無法通過模板進(jìn)行管理。我們還需要支持持續(xù)部署，這在使用模板時(shí)很容易出錯(cuò)。

9 未來的工作

目前，我們?cè)谒械?Kubernetes 集群上運(yùn)行混合工作負(fù)載。為了支持不同大小和類型的工作負(fù)載，我們正在開展一下方面的工作：

集群聯(lián)邦（Cluster Federation）將大型應(yīng)用程序分布在不同的集群上，以實(shí)現(xiàn)可擴(kuò)展性和穩(wěn)定性。

集群穩(wěn)定性、可擴(kuò)展性和可見性，確保應(yīng)用程序到達(dá)其服務(wù)級(jí)別協(xié)議。

資源和配額管理，以確保應(yīng)用程序不會(huì)相互干擾，集群規(guī)模得到控制。

新的 CI/CD 平臺(tái)，支持 Kubernetes 上的應(yīng)用程序部署。