作者 | 張翼飛? 阿里云技術專家
來源|阿里巴巴云原生公眾號

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

Serverless?計算簡介

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

從維基百科可以了解到，Serverless 計算是云計算的一種形態，由云廠商管理服務器，向用戶動態分配機器資源，基于實際使用的資源量計費。

用戶構建和運行服務時，不用考慮服務器，降低了用戶管理服務器的負擔。在業務高峰期通過平臺的彈性能力自動擴容實例，在業務低峰期自動縮容實例，降低資源成本。

Serverless?計算平臺

下述是當前常見的?Serverless?計算產品的架構。
?

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

管控平面通常采用 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 流程：

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

我們針對兩種類型的鏡像進行了測試，結果如下：

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

接下來就分別針對上述過程的不同節點進行優化處理，分別從上述整個流程、解壓鏡像、下載鏡像等方面進行探討。

拉取鏡像效率提升

鏡像預熱

可以快速想到的方法是進行鏡像預熱，在 Pod 調度到節點前預先在節點上準備好鏡像，將拉取鏡像從創建 Pod 的主鏈路中移除，如下圖：

可以在調度前進行全局預熱，在所有節點上行提前拉取鏡像。也可以在調度過程中進行預熱，在確定調度到的
節點后，在目標節點上拉取鏡像。

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

社區里 OpenKruise 項目即將推出鏡像預熱服務，可以關注下。下述是該服務的使用方式：

通過 ImagePullJob CRD 下發鏡像預熱任務，指定目標鏡像和節點，可配置拉取的并發度、Job 處理的超時時間以及 Job Object 自動回收的時間。若是私有鏡像，可指定拉取鏡像時的 secret 配置。ImagePullJob 的 Events?會提鏡任務的狀態信息，可考慮適當增大 Job Object 自動回收的時間，便于通過 ImagePullJob Events 查看任務的處理狀態。

提升解壓效率

從剛才看到的拉取鏡像的數據來看，解壓鏡像耗時會占拉取鏡像總耗時很大的比例，測試的例子最大占比到了?77%，所以需要考慮如何提升解壓效率。

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

在 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 后的解壓鏡像效率：

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

非壓縮鏡像

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

再回顧下 docker pull/push 的流程，在 unpack/pack 階段，可以考慮將 gunzip 和 gzip 的邏輯去掉：
?

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

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

這里重點關注解壓鏡像耗時，可看到 golang:1.10 鏡像解壓效率提升了 50% 左右，hadoop namenode 鏡像解壓效率替身掛了 28% 左右。在拉取鏡像總耗時方面，該方案有一定的效果。

鏡像分發

小規模集群中，提升拉取鏡像效率的重點需要放在提升解壓效率方面，下載鏡像通常不是瓶頸。而在大規模集群中，由于節點數眾多，中心式的 Image Registry 的帶寬和穩定性也會影響拉取鏡像的效率，如下圖：

下載鏡像的壓力集中在中心式的 Image Registry 上。

這里介紹一種基于 P2P 的鏡像分發系統來解決上述問題，以 CNCF 的 DragonFly 項目為例：
?

這里有幾個核心組件：

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 遠程存儲層，如下圖所示：

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

當 containerd 通過 remote snapshotter 創建容器時，省去了拉取鏡像的階段，對于啟動過程中需要的文件，可對 stargz 格式的鏡像數據發起 HTTP Range GET 請求，拉取目標數據。

阿里云實現了名為 DADI 的加速器，類似上述的思想，目前應用在了阿里云容器服務，實現了 3.01s 啟動 ?
10000 個容器，完美杜絕了冷啟動的漫長等待。感興趣的讀者也參考該文章：https://developer.aliyun.com/article/742103

原地升級

上述都是針對創建 Pod 過程提供的技術方案，對于升級場景，在現有的技術下，是否有效率提升的可能性？是否可以達到下述效果，即免去創建 Pod 的過程，實現 Pod 原地升級？

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

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

OpenKruise 項目中的 CloneSet Controller 提供了上述能力：

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

小結

從業務場景出發，我們了解了提升 Pod 創建效率帶來收益的場景。然后通過分析 Pod 創建的流程，針對不同的階段做相應的優化，有的放矢。

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

作者簡介

張翼飛，就職于阿里云容器服務團隊，主要專注?Serverless?領域的產品研發。

**Serverless 對春聯領雙肩包活動開始啦！**云開發平臺與函數計算聯合推出新年活動，極速遷移和部署春聯神器等應用，領阿里云定制牛年背包和代金券。新老用戶均可參加！參加鏈接：https://workbench.aliyun.com/activities/niu

總結

以上是生活随笔為你收集整理的Serverless 场景下 Pod 创建效率优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。