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

作者 | 王思宇（酒祝）
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/teL4k8_egS9fgFPH7a70Zg)

# 前言
[OpenKruise](https://github.com/openkruise/kruise) 是阿里雲開源的雲原生應用自動化管理套件，也是當前託管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 專案。它來自阿里巴巴多年來容器化、雲原生的技術沉澱，是阿里內部生產環境大規模應用的基於 Kubernetes 之上的標準擴充套件元件，也是緊貼上游社群標準、適應網際網路規模化場景的技術理念與最佳實踐。

OpenKruise 在 2021.3.4 釋出了最新的 v0.8.0 版本（[ChangeLog](https://github.com/openkruise/kruise/blob/master/CHANGELOG.md)），其中一個主要變動是新增了 **映象預熱 **能力。本文由《透過 OpenKruise 實現大規模叢集 映象預熱&部署釋出加速實踐》分享整理為文字，為大家介紹我們所提供的映象預熱能力的需求來源、實現方式以及使用場景。

# 背景：為什麼映象預熱能力是必要的
“映象” 也算是 Docker 為容器領域帶來的一大創新。在 Docker 之前，雖然 Linux 已經提供了 cgroup 隔離，儘管阿里巴巴從 2011 年已經逐漸基於 LXC 開始容器化，但都缺乏映象這種對執行環境的封裝。不過呢，儘管映象為我們帶來了諸多好處，但不可否認在實際場景中我們也面臨各種各樣拉映象帶來的問題，其中最常見的一點就是拉映象的耗時。

我們過去聽到過很多使用者對容器化的期待和認識，比如 “極致彈性”、“秒級擴容”、“高效釋出” 等等，但結合 Kubernetes 中一個標準的 Pod 建立過程來看，和使用者的期望還是有一定差距的（假設 Pod 中包含 sidecar、app 兩個容器）：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/87cbbc4936ad46278d6907de8a1329bb.png)

正常來說，對於小規模叢集中排程、分配/掛載遠端盤、分配網路等操作耗時較小，對於大規模叢集需要做一定最佳化，但都還在可控的範圍內。然而對於拉映象的耗時，在大規模彈性的叢集中則尤為棘手，即使採用了 P2P 等技術手段來最佳化，對於一個較大的業務映象還是可能需要較長的時間來拉取，與使用者所期望的擴容、釋出速度不符。

而我們如果能做到將 sidecar 容器的映象、以及業務容器的基礎映象提前在節點上拉取好，則 Pod 建立過程可以大幅縮短，其中拉映象的耗時甚至能最佳化 70% 以上：

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

而 Kubernetes 自身是沒有提供任何面向映象的操作能力的，圍繞 Kubernetes 的生態來看，目前也沒有比較成熟的規模化映象預熱產品。這是我們在 OpenKruise 中提供映象預熱的原因，並且這套映象預熱能力已經在阿里巴巴內部的雲原生環境大面積落地，在後文的實踐中也會簡單介紹我們的基本用法。

# OpenKruise 是如何實現映象預熱的
OpenKruise 實現映象預熱的原理，要先從它的執行架構看起：

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

從 v0.8.0 開始，安裝了 Kruise 之後，有兩個在 kruise-system 名稱空間下的元件：kruise-manager 與 kruise-daemon。前者是一個由 Deployment 部署的中心化元件，一個 kruise-manager 容器（程式）中包含了多個 controller 和 webhook；後者則由 DaemonSet 部署到叢集中的節點上，透過與 CRI 互動來繞過 Kubelet 完成一些擴充套件能力（比如拉取映象、重啟容器等）。

因此，Kruise 會為每個節點（Node）建立一個同名對應的自定義資源：NodeImage，而每個節點的 NodeImage 裡寫明瞭在這個節點上需要預熱哪些映象，因此這個節點上的 kruise-daemon 只要按照 NodeImage 來執行映象的拉取任務即可：

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

如上圖所示，我們在 NodeImage 中能指定要拉取的映象名、tag、拉取的策略，比如單次拉取的超時、失敗重試次數、任務的 deadline、TTL 時間等等。

有了 NodeImage，我們也就擁有了最基本的映象預熱能力了，不過還不能完全滿足大規模場景的預熱需求。在一個有 5k 個節點的叢集中，要使用者去一個個更新 NodeImage 資源來做預熱顯然是不夠友好的。因此，Kruise 還提供了一個更高抽象的自定義資源 ImagePullJob：

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

如上圖所示，在 ImagePullJob 中使用者可以指定一個映象要在哪些範圍的節點上批次做預熱，以及這個 job 的拉取策略、生命週期等。一個 ImagePullJob 建立後，會被 kruise-manager 中的 imagepulljob-controller 接收到並處理，將其分解並寫入到所有匹配節點的 NodeImage 中，以此來完成規模化的預熱。

整體的流程如下：

![6.png](https://ucc.alicdn.com/pic/developer-ecology/4bae03266b5b483bb437a0ddf2a25aca.png)

而有了映象預熱能力後，我們怎麼去使用它，或者說什麼場景下需要來使用呢？接下來我們介紹下映象預熱在阿里巴巴中的幾種常見使用方式。

# 常見的映象預熱使用方式有哪些

### 1. 基礎映象 – 叢集維度預熱
最常見的預熱場景，是在整個叢集維度持續預熱一些基礎映象：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: base-image-job
spec:
  image: xxx/base-image:latest
  parallelism: 10
  completionPolicy:
    type: Never
  pullPolicy:
    backoffLimit: 3
    timeoutSeconds: 300
```

如上述 ImagePullJob 有幾個特徵：

1. 不配置 selector 規則，即預設整個叢集維度預熱
   1. 存量的節點上統一預熱
   1. 後續新增（匯入）的節點上也會立即自動做預熱
2. 採用 Never 的 completionPolicy 策略來長期執行
   1. Never 策略表明這個 job 持續做預熱，不會結束（除非被刪除）
   1. Never 策略下，ImagePullJob 每隔 24h 左右會觸發在所有匹配的節點上重試拉取一次，也就是每天都會確保一次映象存在

根據我們的經驗，一個叢集中預熱基礎映象的 ImagePullJob 在 10~30 個左右，具體視叢集以及業務場景而定。

### 2. sidecar 映象 – 叢集維度預熱
我們同樣也可以對一些 sidecar 的映象做預熱，尤其是那些基本上每個業務 Pod 中都會帶有的基礎 sidecar：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: sidecar-image-job
spec:
  image: xxx/sidecar-image:latest
  parallelism: 20
  completionPolicy:
    type: Always
    activeDeadlineSeconds: 1800
    ttlSecondsAfterFinished: 300
  pullPolicy:
    backoffLimit: 3
    timeoutSeconds: 300
```

如上述 ImagePullJob 有幾個特徵：

1. 不配置 selector，預設整個叢集維度預熱，這一點與基礎映象類似
1. 採用 Always 策略一次性預熱
   1. 所有節點做一次預熱
   1. 整個 job 預熱超時時間 30min
   1. job 完成後過 5min 自動刪除

當然，這裡的 sidecar 預熱也可以配置為 Never 策略，視場景而定。以我們的經驗來看，尤其在 sidecar 做版本迭代、映象升級的時候，提前做一次規模化的映象預熱，可以大幅提升後續 Pod 擴容、釋出的速度。

### 3. 特殊業務映象 – 資源池維度預熱
對於一些多租的 Kubernetes 叢集中會存在多個不同的業務資源池，其中可能需要將一些特定的業務映象按資源池維度來預熱：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: ImagePullJob
metadata:
  name: serverless-job
spec:
  image: xxx/serverless-image:latest
  parallelism: 10
  completionPolicy:
    type: Never
  pullPolicy:
    backoffLimit: 3
    timeoutSeconds: 300
  selector:
    matchLabels:
      resource-pool: serverless
```

如上述 ImagePullJob 有幾個特徵：

1. 採用 Never 策略長期預熱
1. 指定 selector 預熱範圍，是匹配 resource-pool=serverless 標籤的節點

當然，這裡只是以資源池為例，使用者可以根據自身的場景來定義在哪些節點上預熱某種映象。

# 版本前瞻：原地升級與預熱的結合
最後，再來介紹下 OpenKruise 的下個版本（v0.9.0）中，我們會基於當前的映象預熱實現怎樣的增強能力呢？

之前對 OpenKruise 瞭解過的同學一定知道，我們提供的一大特性就是 “原地升級”，即打破了 Kubernetes 原生 workload 釋出時必須將 Pod 刪除、重建的模式，支援在原 Pod 上只更新其中某個容器的映象。對原地升級原理感興趣的同學可以讀這篇文章：《[揭秘：如何為 Kubernetes 實現原地升級？](https://mp.weixin.qq.com/s/CNLf8MHYGs_xeD4PxChR4A)》。

由於原地升級避免了 Pod 刪除、重建的過程，它本身已經能為我們帶來了如下的好處：

- 節省了**排程**的耗時，Pod 的位置、資源都不發生變化
- 節省了**分配網路**的耗時，Pod 還使用原有的 IP
- 節省了**分配、掛載遠端盤**的耗時，Pod 還使用原有的 PV（且都是已經在 Node 上掛載好的）
- 節省了**大部分拉取映象**的耗時，因為節點上已經存在了應用的舊映象，當拉取新版本映象時只需要下載少數的幾層 layer
- 原地升級 Pod 中某個容器時，其他容器**保持正常執行**，網路、儲存均不受影響

其中，“節省了大部分拉取映象的耗時” 後，只需要下載新映象上層的部分 layer 即可。而我們有沒有可能把這個映象拉取時間徹底最佳化掉呢？答案是肯定的。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/016a255cbde147dca77fd21de0c04ce5.png)

如上圖所示，在下個版本中 OpenKruise 的 CloneSet 將支援釋出過程自動映象預熱。當使用者還在灰度升級第一批 Pod 的時候，Kruise 會提前在後續 Pod 所在節點上把新版本的映象預熱好。這樣一來，在後續批次的 Pod 做原地升級時候，新映象都已經在節點上準備好了，也就節省了真正釋出過程中的拉映象耗時。

當然，這種 “釋出+預熱” 的模式也只適用於 OpenKruise 的原地升級場景。對於原生 workload 如 Deployment 而言，由於釋出時 Pod 是新建出來的，我們無法提前預知到它會被排程到的節點，自然也就沒辦法提前把映象預熱好了。

如果大家對 OpenKruise 專案感興趣，有任何希望交流的話題，歡迎大家訪問 [OpenKruise 官網](https://openkruise.io/en-us/)、[GitHub](https://github.com/openkruise/kruise)！

OpenKruise 如何實現 K8s 社群首個規模化映象預熱能力

相關文章