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

作者 | 王思宇（酒祝）  阿里雲技術專家

**參與阿里巴巴雲原生文末留言互動，即有機會獲得贈書福利及作者答疑！**

# 概念介紹

**原地升級**一詞中，“升級”不難理解，是將應用例項的版本由舊版替換為新版。那麼如何結合 Kubernetes 環境來理解“原地”呢？

我們先來看看 K8s 原生 workload 的釋出方式。這裡假設我們需要部署一個應用，包括 foo、bar 兩個容器在 Pod 中。其中，foo 容器第一次部署時用的映象版本是 v1，我們需要將其升級為 v2 版本映象，該怎麼做呢？

- 如果這個應用使用 Deployment 部署，那麼升級過程中 Deployment 會觸發新版本 ReplicaSet 建立 Pod，並刪除舊版本 Pod。如下圖所示：

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

在本次升級過程中，原 Pod 物件被刪除，一個新 Pod 物件被建立。新 Pod 被排程到另一個 Node 上，分配到一個新的 IP，並把 foo、bar 兩個容器在這個 Node 上重新拉取映象、啟動容器。

- 如果這個應該使用 StatefulSet 部署，那麼升級過程中 StatefulSet 會先刪除舊 Pod 物件，等刪除完成後用同樣的名字在建立一個新的 Pod 物件。如下圖所示：

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

值得注意的是，儘管新舊兩個 Pod 名字都叫 pod-0，但其實是兩個完全不同的 Pod 物件（uid也變了）。StatefulSet 等到原先的 pod-0 物件完全從 Kubernetes 叢集中被刪除後，才會提交建立一個新的 pod-0 物件。而這個新的 Pod 也會被重新排程、分配IP、拉映象、啟動容器。

- 而所謂原地升級模式，就是在應用升級過程中避免將整個 Pod 物件刪除、新建，而是基於原有的 Pod 物件升級其中某一個或多個容器的映象版本：

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

在原地升級的過程中，我們僅僅更新了原 Pod 物件中 foo 容器的 image 欄位來觸發 foo 容器升級到新版本。而不管是 Pod 物件，還是 Node、IP 都沒有發生變化，甚至 foo 容器升級的過程中 bar 容器還一直處於執行狀態。

**總結：這種只更新 Pod 中某一個或多個容器版本、而不影響整個 Pod 物件、其餘容器的升級方式，被我們稱為 Kubernetes 中的原地升級。**

# 收益分析

那麼，我們為什麼要在 Kubernetes 中引入這種原地升級的理念和設計呢？

首先，這種原地升級的模式極大地提升了應用釋出的效率，根據非完全統計資料，在阿里環境下原地升級至少比完全重建升級提升了 80% 以上的釋出速度。這其實很容易理解，原地升級為釋出效率帶來了以下最佳化點：

1. 節省了排程的耗時，Pod 的位置、資源都不發生變化；
2. 節省了分配網路的耗時，Pod 還使用原有的 IP；
3. 節省了分配、掛載遠端盤的耗時，Pod 還使用原有的 PV（且都是已經在 Node 上掛載好的）；
4. 節省了大部分拉取映象的耗時，因為 Node 上已經存在了應用的舊映象，當拉取新版本映象時只需要下載很少的幾層 layer。

其次，當我們升級 Pod 中一些 sidecar 容器（如採集日誌、監控等）時，其實並不希望干擾到業務容器的執行。但面對這種場景，Deployment 或 StatefulSet 的升級都會將整個 Pod 重建，勢必會對業務造成一定的影響。而容器級別的原地升級變動的範圍非常可控，只會將需要升級的容器做重建，其餘容器包括網路、掛載盤都不會受到影響。

最後，原地升級也為我們帶來了叢集的穩定性和確定性。當一個 Kubernetes 叢集中大量應用觸發重建 Pod 升級時，可能造成大規模的 Pod 飄移，以及對 Node 上一些低優先順序的任務 Pod 造成反覆的搶佔遷移。這些大規模的 Pod 重建，本身會對 apiserver、scheduler、網路/磁碟分配等中心元件造成較大的壓力，而這些元件的延遲也會給 Pod 重建帶來惡性迴圈。而採用原地升級後，整個升級過程只會涉及到 controller 對 Pod 物件的更新操作和 kubelet 重建對應的容器。

# 技術背景

在阿里巴巴內部，絕大部分電商應用在雲原生環境都統一用原地升級的方式做釋出，而這套支援原地升級的控制器就位於 [OpenKruise](https://github.com/openkruise/kruise) 開源專案中。

也就是說，阿里內部的雲原生應用都是統一使用 OpenKruise 中的擴充套件 workload 做部署管理的，而並沒有採用原生 Deployment/StatefulSet 等。<br>
<br>那麼 OpenKruise 是如何實現原地升級能力的呢？在介紹原地升級實現原理之前，我們先來看一些原地升級功能所依賴的原生 Kubernetes 功能：

## 背景 1：Kubelet 針對 Pod 容器的版本管理

每個 Node 上的 Kubelet，會針對本機上所有 Pod.spec.containers 中的每個 container 計算一個 hash 值，並記錄到實際建立的容器中。

如果我們修改了 Pod 中某個 container 的 image 欄位，kubelet 會發現 container 的 hash 發生了變化、與機器上過去建立的容器 hash 不一致，而後 kubelet 就會把舊容器停掉，然後根據最新 Pod spec 中的 container 來建立新的容器。

**這個功能，其實就是針對單個 Pod 的原地升級的核心原理。**

## 背景 2：Pod 更新限制

在原生 kube-apiserver 中，對 Pod 物件的更新請求有嚴格的 [validation 校驗邏輯](https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/validation/validation.go#L3729)：

```
// validate updateable fields:
// 1.  spec.containers[*].image
// 2.  spec.initContainers[*].image
// 3.  spec.activeDeadlineSeconds
```

簡單來說，對於一個已經建立出來的 Pod，在 Pod Spec 中只允許修改 containers/initContainers 中的 image 欄位，以及 activeDeadlineSeconds 欄位。對 Pod Spec 中所有其他欄位的更新，都會被 kube-apiserver 拒絕。

## 背景 3：containerStatuses 上報

kubelet 會在 pod.status 中上報 containerStatuses，對應 Pod 中所有容器的實際執行狀態：

```
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
status:
  containerStatuses:
  - name: nginx
    image: nginx:mainline
    imageID: docker-pullable://nginx@sha256:2f68b99bc0d6d25d0c56876b924ec20418544ff28e1fb89a4c27679a40da811b
```

絕大多數情況下，spec.containers[x].image 與 status.containerStatuses[x].image 兩個映象是一致的。

但是也有上述這種情況，kubelet 上報的與 spec 中的 image 不一致（spec 中是 nginx:latest，但 status 中上報的是 nginx:mainline）。

這是因為，kubelet 所上報的 image 其實是從 CRI 介面中拿到的容器對應的映象名。而如果 Node 機器上存在多個映象對應了一個 imageID，那麼上報的可能是其中任意一個：

```
$ docker images | grep nginx
nginx            latest              2622e6cca7eb        2 days ago          132MB
nginx            mainline            2622e6cca7eb        2 days ago
```

因此，一個 Pod 中 spec 和 status 的 image 欄位不一致，並不意味著宿主機上這個容器執行的映象版本和期望的不一致。

## 背景 4：ReadinessGate 控制 Pod 是否 Ready

在 Kubernetes 1.12 版本之前，一個 Pod 是否處於 Ready 狀態只是由 kubelet 根據容器狀態來判定：如果 Pod 中容器全部 ready，那麼 Pod 就處於 Ready 狀態。

但事實上，很多時候上層 operator 或使用者都需要能控制 Pod 是否 Ready 的能力。因此，Kubernetes 1.12 版本之後提供了一個 readinessGates 功能來滿足這個場景。如下：

```
apiVersion: v1
kind: Pod
spec:
  readinessGates:
  - conditionType: MyDemo
status:
  conditions:
  - type: MyDemo
    status: "True"
  - type: ContainersReady
    status: "True"
  - type: Ready
    status: "True"
```

目前 kubelet 判定一個 Pod 是否 Ready 的兩個前提條件：

1. Pod 中容器全部 Ready（其實對應了 ContainersReady condition 為 True）；
2. 如果 pod.spec.readinessGates 中定義了一個或多個 conditionType，那麼需要這些 conditionType 在 pod.status.conditions 中都有對應的 status: "true" 的狀態。

只有滿足上述兩個前提，kubelet 才會上報 Ready condition 為 True。

# 實現原理

瞭解了上面的四個背景之後，接下來分析一下 OpenKruise 是如何在 Kubernetes 中實現原地升級的原理。

## 1. 單個 Pod 如何原地升級？

由“背景 1”可知，其實我們對一個存量 Pod 的 spec.containers[x] 中欄位做修改，kubelet 會感知到這個 container 的 hash 發生了變化，隨即就會停掉對應的舊容器，並用新的 container 來拉映象、建立和啟動新容器。

由“背景 2”可知，當前我們對一個存量 Pod 的 spec.containers[x] 中的修改，僅限於 image 欄位。

因此，得出第一個實現原理：**對於一個現有的 Pod 物件，我們能且只能修改其中的 spec.containers[x].image 欄位，來觸發 Pod 中對應容器升級到一個新的 image。

## 2. 如何判斷 Pod 原地升級成功？

接下來的問題是，當我們修改了 Pod 中的 spec.containers[x].image 欄位後，如何判斷 kubelet 已經將容器重建成功了呢？

由“背景 3”可知，比較 spec 和 status 中的 image 欄位是不靠譜的，因為很有可能 status 中上報的是 Node 上存在的另一個映象名（相同 imageID）。

因此，得出第二個實現原理：**判斷 Pod 原地升級是否成功，相對來說比較靠譜的辦法，是在原地升級前先將 status.containerStatuses[x].imageID 記錄下來。在更新了 spec 映象之後，如果觀察到 Pod 的 status.containerStatuses[x].imageID 變化了，我們就認為原地升級已經重建了容器。**

但這樣一來，我們對原地升級的 image 也有了一個要求：**不能用 image 名字（tag）不同、但實際對應同一個 imageID 的映象來做原地升級，否則可能一直都被判斷為沒有升級成功（因為 status 中 imageID 不會變化）。**

當然，後續我們還可以繼續最佳化。OpenKruise 即將開源映象預熱的能力，會透過 DaemonSet 在每個 Node 上部署一個 NodeImage Pod。透過 NodeImage 上報我們可以得知 pod spec 中的 image 所對應的 imageID，然後和 pod status 中的 imageID 比較即可準確判斷原地升級是否成功。

## 3. 如何確保原地升級過程中流量無損？

在 Kubernetes 中，一個 Pod 是否 Ready 就代表了它是否可以提供服務。因此，像 Service 這類的流量入口都會透過判斷 Pod Ready 來選擇是否能將這個 Pod 加入 endpoints 端點中。

由“背景 4”可知，從 Kubernetes 1.12+ 之後，operator/controller 這些元件也可以透過設定 readinessGates 和更新 pod.status.conditions 中的自定義 type 狀態，來控制 Pod 是否可用。

因此，得出第三個實現原理：**可以在 pod.spec.readinessGates 中定義一個叫 InPlaceUpdateReady 的 conditionType。**

在原地升級時：

1. **先將 pod.status.conditions 中的 InPlaceUpdateReady condition 設為 "False"，這樣就會觸發 kubelet 將 Pod 上報為 NotReady，從而使流量元件（如 endpoint controller）將這個 Pod 從服務端點摘除；**
2. **再更新 pod spec 中的 image 觸發原地升級。**

**原地升級結束後，再將 InPlaceUpdateReady condition 設為 "True"，使 Pod 重新回到 Ready 狀態。**

另外在原地升級的兩個步驟中，第一步將 Pod 改為 NotReady 後，流量元件非同步 watch 到變化並摘除端點可能是需要一定時間的。因此我們也提供優雅原地升級的能力，即透過 gracePeriodSeconds 配置在修改 NotReady 狀態和真正更新 image 觸發原地升級兩個步驟之間的靜默期時間。

## 4. 組合釋出策略

原地升級和 Pod 重建升級一樣，可以配合各種釋出策略來執行：

- partition：如果配置 partition 做灰度，那麼只會將 replicas-partition 數量的 Pod 做原地升級；
- maxUnavailable：如果配置 maxUnavailable，那麼只會將滿足 unavailable 數量的 Pod 做原地升級；
- maxSurge：如果配置 maxSurge 做彈性，那麼當先擴出來 maxSurge 數量的 Pod 之後，存量的 Pod 仍然使用原地升級；
- priority/scatter：如果配置了釋出優先順序/打散策略，會按照策略順序對 Pod 做原地升級。

# 總結

如上文所述，[OpenKruise](https://github.com/openkruise/kruise) 結合 Kubernetes 原生提供的 kubelet 容器版本管理、readinessGates 等功能，實現了針對 Pod 的原地升級能力。

而原地升級也為應用釋出帶來大幅的效率、穩定性提升。值得關注的是，隨著叢集、應用規模的增大，這種提升的收益越加明顯。正是這種原地升級能力，在近兩年幫助了阿里巴巴超大規模的應用容器平穩遷移到了基於 Kubernetes 的雲原生環境，而原生 Deployment/StatefulSet 是完全無法在這種體量的環境下鋪開使用的。（歡迎加入釘釘交流群：23330762）

# - 贈書福利 -

![尾圖.png](https://ucc.alicdn.com/pic/developer-ecology/26c6256a8e664a12894077b8346dea2b.png)

6 月 19 日 12：00 前在【阿里巴巴雲原生公眾號】留言區**提出你的疑問**，精選留言點贊第 1 名將免費獲得此書，屆時我們還會請本文作者針對留言點贊前 5 名的問題進行答疑！

# 課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲端計算的新正規化——Serverless。

點選即可免費觀看課程：[https://developer.aliyun.com/learning/roadmap/serverless](https://developer.aliyun.com/learning/roadmap/serverless)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490783&idx=1&sn=9ae8b44605e6808d80be9d6924a140db&chksm=fae51710cd929e0653dc0b90269772280df9a201315709bc93d62c2a4cfe719a164921469b5e&token=1148911636&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

揭秘：如何為 Kubernetes 實現原地升級

相關文章