![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/59ef8579ed094be3a9b2d29f5984d422.png)

作者 | 張翼飛  阿里雲技術專家
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/0OLdyVwg4Nsw0Xvvg8if5w)

> 導讀：眾所周知，Kubernetes 是雲原生領域的基石，作為容器編排的基礎設施，被廣泛應用在 Serverless 領域。彈效能力是 Serverless 領域的核心競爭力，本次分享將重點介紹基於 Kubernetes 的 Serverless 服務中，如何最佳化 Pod 建立效率，提升彈性效率。

# Serverless 計算簡介
 
在進入主題之前，先簡單回顧下 Serverless 計算的定義。

從維基百科可以瞭解到，Serverless 計算是雲端計算的一種形態，由雲廠商管理伺服器，向使用者動態分配機器資源，基於實際使用的資源量計費。

使用者構建和執行服務時，不用考慮伺服器，降低了使用者管理伺服器的負擔。在業務高峰期透過平臺的彈效能力自動擴容例項，在業務低峰期自動縮容例項，降低資源成本。

# Serverless 計算平臺
 
下述是當前常見的 Serverless 計算產品的架構。
 
![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/5e65606ba1774c3fb048d890733d090a.jpg)

整個產品架構通常會有管控平面和資料平面兩層，管控平面服務開發者，管理應用生命週期，滿足開發者對應用管理的需求，資料平面服務應用的訪問方，如開發者業務的使用者，滿足應用的流量管理和訪問訴求。

管控平面通常採用 Kubernetes 做資源管理和排程，master 通常是 3 節點，滿足對高可用的需求，節點透過內網 SLB 訪問 K8s master。

在節點層面，通常會有兩種型別的節點：

- 一種是執行 kubelet 的節點，如裸金屬伺服器、虛擬機器等，這類節點上會執行安全容器作為 Pod 執行時，每個 Pod 擁有獨立的 kernel，降低共享宿主機 kernel 帶來的安全風險。同時會透過雲產品 VPC 網路或其他網路技術，在資料鏈路層隔離租戶的網路訪問。透過 安全容器+二層網路隔離，單個節點上可以提供可靠的多租執行環境。

- 還有一種是虛擬節點，透過 VirtualKubelet 銜接 K8s 和彈性例項。彈性例項是雲產品中類似虛擬機器的一種輕量資源形態，提供無限資源池的容器組服務，該容器組的概念對應 K8s 中的 Pod 概念。AWS 提供有 Fargate 彈性例項，阿里雲提供有 ECI 彈性例項。

Serverless 產品會提供基於 K8s 的 PaaS 層，負責向開發者提供部署、開發等相關的服務，遮蔽 K8s 相關的概念，降低開發者開發、運維應用的成本。

在資料平面，使用者可透過 SLB 實現對應用例項的訪問。PaaS 層也通常會在該平面提供諸如流量灰度、A/B 測試等流量管理服務，滿足開發者對流量管理的需求。

彈效能力是 Serverless 計算平臺的核心競爭力，需要滿足開發者對 Pod 規模 的訴求，提供類似無限資源池的能力，同時還要滿足建立 Pod 效率的訴求，及時響應請求。

Pod 規模可透過增加 IaaS 層資源來滿足，接下來重點介紹提升 Pod 建立效率的技術。

# Pod 建立相關場景
 
先了解下 Pod 建立相關的場景，這樣可以更有效透過技術滿足業務訴求。

業務中會有兩種場景涉及到 Pod 建立：

- 第一種是建立應用，這個過程會先經過排程，決策最適合 Pod 的節點，然後在節點上建立 Pod。
- 第二種是升級應用，在這個過程中，通常是不斷進行 建立新 Pod 和 銷燬舊 Pod。

Serverless 服務中，開發者關心的重點在於應用的生命週期，尤其是建立和升級階段，Pod 建立效率會影響這兩個階段的整體耗時，進而影響開發者的體驗。面對突發流量時，建立效率的高低會對開發者服務的響應速度產生重要影響，嚴重者會使開發者的業務受損。

面對上述業務場景，接下來重點分析如何提升 Pod 建立效率。

# 建立 Pod 流程
 
整體分析下 Pod 建立的階段，按照影響 Pod 建立效率的優先順序來依次解決。

這是簡化後的建立 Pod 流程：

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/369fa25edfad4a5db20b1210d4a3ac8a.jpg)

當有 Pod 建立請求時，先進行排程，為 Pod 選取最合適的節點。在節點上，先進行拉取映象的操作，映象在本地準備好後，再進行建立容器組的操作。在拉取映象階段，又依次分為下載映象和解壓映象兩個步驟。

我們針對兩種型別的映象進行了測試，結果如下：

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/4f912b676ef64859aa4b1731cba25832.jpg)

從測試結果可看到，解壓映象耗時在整個拉取映象過程中的佔比不容忽視，對於解壓前 248MB 左右的 golang:1.10 映象，解壓映象耗時竟然佔到了拉取映象耗時的 77.02%，對於節解壓前 506MB 左右的 hadoop namenode 映象，解壓映象耗時和下載映象耗時各佔 40% 和 60% 左右，即對於拉取映象過程的總耗時也不容忽視。

接下來就分別針對上述過程的不同節點進行最佳化處理，分別從上述整個流程、解壓映象、下載映象等方面進行探討。
 
# 拉取映象效率提升
 
## 映象預熱
 
可以快速想到的方法是進行映象預熱，在 Pod 排程到節點前預先在節點上準備好映象，將拉取映象從建立 Pod 的主鏈路中移除，如下圖：

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/cccac471e0a349229f8fe4102b83d376.jpg)

可以在排程前進行全域性預熱，在所有節點上行提前拉取映象。也可以在排程過程中進行預熱，在確定排程到的
節點後，在目標節點上拉取映象。

兩種方式無可厚非，可根據叢集實際情況進行選擇。

社群裡 OpenKruise 專案即將推出映象預熱服務，可以關注下。下述是該服務的使用方式：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/81762663991d40c48353086ed2369f14.png)

透過 ImagePullJob CRD 下發映象預熱任務，指定目標映象和節點，可配置拉取的併發度、Job 處理的超時時間以及 Job Object 自動回收的時間。若是私有映象，可指定拉取映象時的 secret 配置。ImagePullJob 的 Events 會提鏡任務的狀態資訊，可考慮適當增大 Job Object 自動回收的時間，便於透過 ImagePullJob Events 檢視任務的處理狀態。
 
## 提升解壓效率
 
從剛才看到的拉取映象的資料來看，解壓映象耗時會佔拉取映象總耗時很大的比例，測試的例子最大佔比到了 77%，所以需要考慮如何提升解壓效率。

先回顧下 docker pull 的技術細節：

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/ac8cd95d417142988416ed574ca3f4f8.jpg)

在 docker pull 時，整體會進行兩個階段：

- 並行下載 image 層
- 拆解 image 層

在解壓 image 層時，預設採用的 gunzip。

再簡單瞭解下 docker push 的過程：

- 先對 image 層進行打包操作，這個過程中會透過 gzip 進行壓縮。
- 然後並行上傳。

gzip/gunzip 是單執行緒的壓縮/解壓工具，可考慮採用 pigz/unpigz 進行多執行緒的壓縮/解壓，充分利用多核優勢。

containerd 從 1.2 版本開始支援 pigz，節點上安裝 unpigz 工具後，會優先用其進行解壓。透過這種方法，可透過節點多核能力提升映象解壓效率。

這個過程也需要關注 下載/上傳 的併發度問題，docker daemon 提供了兩個引數來控制併發度，控制並行處理的映象層的數量，--max-concurrent-downloads 和 --max-concurrent-uploads。預設情況下，下載的併發度是 3，上傳的併發度是 5，可根據測試結果調整到合適的值。

使用 unpigz 後的解壓映象效率：

![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/ccc6c8a52f9e4a7ca2a964496b474cac.jpg)

在相同環境下，golang:1.10 映象解壓效率提升了 35.88%，hadoop namenode 映象解壓效率提升了 16.41%。

## 非壓縮映象
 
通常內網的頻寬足夠大，是否有可能省去 解壓縮/壓縮 的邏輯，將拉取映象的耗時集中在下載映象方面？即適量增大下載耗時，縮短解壓耗時。

再回顧下 docker pull/push 的流程，在 unpack/pack 階段，可以考慮將 gunzip 和 gzip 的邏輯去掉：
 
![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/e21be3391cb84dc280205c22f0b22552.jpg)

對於 docker 映象，若 docker push 時的映象是非壓縮的，則 docker pull 時是無需進行解壓縮操作，故要實現上述目標，就需要在 docker push 時去掉壓縮邏輯。

docker daemon 暫時不支援上述操作，我們對 docker 進行了一番修改，在上傳映象時不進行壓縮操作，測試結果如下：

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/9e430f2bdb9744469dc2a7a095eae28b.jpg)

這裡重點關注解壓映象耗時，可看到 golang:1.10 映象解壓效率提升了 50% 左右，hadoop namenode 映象解壓效率替身掛了 28% 左右。在拉取映象總耗時方面，該方案有一定的效果。
 
## 映象分發
 
小規模叢集中，提升拉取映象效率的重點需要放在提升解壓效率方面，下載映象通常不是瓶頸。而在大規模叢集中，由於節點數眾多，中心式的 Image Registry 的頻寬和穩定性也會影響拉取映象的效率，如下圖：

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/6ff3cc65e18d4b0dbc91d564898c1d58.jpg)

下載映象的壓力集中在中心式的 Image Registry 上。

這裡介紹一種基於 P2P 的映象分發系統來解決上述問題，以 CNCF 的 DragonFly 專案為例：
 
![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/a1782ca60c414b138d86d53704f78f0a.jpg)

這裡有幾個核心元件：

### ClusterManager

它本質上是一箇中心式的 SuperNode，在 P2P 網路中作為 tracker 和 scheduler 協調節點的下載任務。同時它還是一個快取服務，快取從 Image Registry 中下載的映象，降低節點的增加對 Image Registry 帶來的壓力。

### Dfget

它既是節點上下載映象的客戶端，同時又充當向其他節點提供資料的能力，可以將本地已有的映象資料按需提供給其他節點。

### Dfdaemon

在每個節點上有個 Dfdaemon 元件，它本質上是一個 proxy，對 docker daemon 的拉取映象的請求實現透明代理服務，使用 Dfget 下載映象。

透過 P2P 網路，中心式的 Image Registry 資料被快取到 ClusterManager 中，ClusterManager 協調節點對映象的下載需求，將下載映象的壓力分攤到叢集節點上，叢集節點既是映象資料的拉取方，又是映象資料的提供方，充分利用內網頻寬的能力進行映象分發。

## 按需載入映象
 
除了上述介紹到的方法，是否還有其他最佳化方法？

當前節點上建立容器時，是需要先把映象全部資料拉取到本地，然後才能啟動容器。再考慮下啟動虛擬機器的過程，即使是幾百 GB 的虛擬機器映象，啟動虛擬機器也通常是在秒級別，幾乎感受不到虛擬機器映象大小帶來的影響。

那麼容器領域是否也可以用到類似的技術？

再看一篇發表在 usenix 上的題為《Slacker: Fast Distribution with Lazy Docker Containers》 的 paper 描述：

> Our analysis shows that pulling packages accounts for 76% of container start time, but only 6.4% of  
> that data is read.

該 paper 分析，在映象啟動耗時中，拉取映象佔比 76%，但是在啟動時，僅有 6.4% 的資料被使用到，即映象啟動時需要的映象資料量很少，需要考慮在映象啟動階段按需載入映象，改變對映象的使用方式。

對於「Image 所有 layers 下載完後才能啟動映象」，需要改為啟動容器時按需載入映象，類似啟動虛擬機器的方式，僅對啟動階段需要的資料進行網路傳輸。

但當前映象格式通常是 tar.gz 或 tar，而 tar 檔案沒有索引，gzip 檔案不能從任意位置讀取資料，這樣就不能滿足按需拉取時拉取指定檔案的需求，映象格式需要改為可索引的檔案格式。

Google 提出了一種新的映象格式，stargz，全稱是 seeable tar.gz。它相容當前的映象格式，但提供了檔案索引，可從指定位置讀取資料。

傳統的 .tar.gz 檔案是這樣生成的: Gzip(TarF(file1) + TarF(file2) + TarF(file3) + TarFooter))。分別對每個檔案進行打包，然後對檔案組進行壓縮操作。

stargz 檔案做了這樣的創新：Gzip(TarF(file1)) + Gzip(TarF(file2)) + Gzip(TarF(file3_chunk1)) + Gzip(F(file3_chunk2)) + Gzip(F(index of earlier files in magic file), TarFooter)。針對每個檔案進行打包和壓縮操作，同時形成一個索引檔案，和 TarFooter 一起進行壓縮。

這樣就可以透過索引檔案快速定位要拉取的檔案的位置，然後從指定位置拉取檔案。

然後在 containerd 拉取映象環節，對 containerd 提供一種 remote snapshotter，在建立容器 rootfs 層時，不透過先下載映象層再構建的方式，而是直接 mount 遠端儲存層，如下圖所示：

![12.jpg](https://ucc.alicdn.com/pic/developer-ecology/e1bb8b2e8c2f4394ab07f5dd052efc65.jpg)

要實現這樣的能力，一方面需要修改 containerd 當前的邏輯，在 filter 階段識別遠端映象層，對於這樣的映象層不進行 download 操作，一方面需要實現一個 remote snapshotter，來支援對於遠端層的管理。

當 containerd 透過 remote snapshotter 建立容器時，省去了拉取映象的階段，對於啟動過程中需要的檔案，可對 stargz 格式的映象資料發起 HTTP Range GET 請求，拉取目標資料。

阿里雲實現了名為 DADI 的加速器，類似上述的思想，目前應用在了阿里雲容器服務，實現了 3.01s 啟動  
10000 個容器，完美杜絕了冷啟動的漫長等待。感興趣的讀者也參考該文章：[https://developer.aliyun.com/article/742103](https://developer.aliyun.com/article/742103)
 
# 原地升級
 
上述都是針對建立 Pod 過程提供的技術方案，對於升級場景，在現有的技術下，是否有效率提升的可能性？是否可以達到下述效果，即免去建立 Pod 的過程，實現 Pod 原地升級？

![13.jpg](https://ucc.alicdn.com/pic/developer-ecology/f608b87deacb4f97ae006fa7ffcda230.jpg)

在升級場景中，佔比較大的場景是僅升級映象。針對這種場景，可使用 K8s 自身的 patch 能力。透過 patch image，Pod 不會重建，僅目標 container 重建，這樣就不用完整經過 排程+新建 Pod 流程，僅對需要升級的容器進行原地升級。

在原地升級過程中，藉助 K8s readinessGates 能力，可以控制 Pod 優雅下線，由 K8s Endpoint Controller 主動摘除即將升級的 Pod，在 Pod 原地升級後加入升級後的 Pod，實現升級過程中流量無損。

OpenKruise 專案中的 CloneSet Controller 提供了上述能力：

![14.png](https://ucc.alicdn.com/pic/developer-ecology/a976533e4b6546b2b22fe52fc859162c.png)

開發者使用 CloneSet 宣告應用，用法類似 Deployment。在升級映象時，由 CloneSet Controller 負責執行 patch 操作，同時確保升級過程中業務流量無損。

# 小結
 
從業務場景出發，我們瞭解了提升 Pod 建立效率帶來收益的場景。然後透過分析 Pod 建立的流程，針對不同的階段做相應的最佳化，有的放矢。

透過這樣的分析處理流程，使得可以有效透過技術滿足業務需求。

# 作者簡介
張翼飛，就職於阿里雲容器服務團隊，主要專注 Serverless 領域的產品研發。

**Serverless 對春聯領雙肩包活動開始啦！**雲開發平臺與函式計算聯合推出新年活動，極速遷移和部署春聯神器等應用，領阿里雲定製牛年揹包和代金券。新老使用者均可參加！參加連結：[https://workbench.aliyun.com/activities/niu](https://workbench.aliyun.com/activities/niu)

Serverless 場景下 Pod 建立效率最佳化

相關文章