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

作者 | 酒祝  阿里雲技術專家、墨封  阿里雲開發工程師

直播完整影片回顧：[https://www.bilibili.com/video/BV1mK4y1t7WS/](https://www.bilibili.com/video/BV1mK4y1t7WS/)

**關注“阿里巴巴雲原生”公眾號，後臺回覆 “528” 即可下載 PPT**

5 月 28 日，我們發起了第 3 期 SIG Cloud-Provider-Alibaba 網研會直播。本次直播主要介紹了阿里經濟體大規模應用上雲過程中遇到的核心部署問題、採取的對應解決方案，以及這些方案沉澱為通用化能力輸出開源後，如何幫助阿里雲上的使用者提升應用部署釋出的效率與穩定性。

本文彙集了此次直播完整影片回顧及資料下載，並整理了直播過程中收集的問題和解答，希望能夠對大家有所幫助~

![講師圖片.jpg](https://ucc.alicdn.com/pic/developer-ecology/3f50328cdcad4c7093d74ee0fe885570.jpg)

# 前言

隨著近年來 Kubernetes 逐漸成為事實標準和大量應用的雲原生化，我們往往發現 Kubernetes 的原生 workload 對大規模化應用的支援並不十分“友好”。如何在 Kubernetes 上為應用提供更加完善、高效、靈活的部署釋出能力，成為了我們探索的目標。

本文將會介紹在阿里經濟體全面接入雲原生的過程中，我們在應用部署方面所做的改進最佳化、實現功能更加完備的增強版 workload、並將其開源到社群，使得現在每一位 Kubernetes 開發者和阿里雲上的使用者都能很便捷地使用上阿里巴巴內部雲原生應用所統一使用的部署釋出能力。

- **第一期網研會回顧**：[Kubernetes SIG-Cloud-Provider-Alibaba 首次網研會（含 PPT 下載）](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247489370&idx=1&sn=a0ada070f012549fbfb4719ca1e43f78&chksm=fae51c95cd929583398619213f4b969db193f3bc1cbbd3ff6981d8845af5a98d23c6f0c58274&scene=21#wechat_redirect)
- **第二期網研會回顧**：[在生產環境中，阿里雲如何構建高效能雲原生容器網路？（含 PPT 下載）](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490131&idx=1&sn=806f5d48686a6b1b4051c568f9e9e37a&chksm=fae5119ccd92988a716232936fc2d8c4494d61e990221e599adf95af0eb972e9646bb53c84a2&scene=21#wechat_redirect)

# 阿里應用場景與原生 workloads

阿里巴巴容器化道路的起步在國內外都是比較領先的。容器這個技術概念雖然出現得很早，但一直到 2013 年 Docker 產品出現後才逐漸為人所熟知。而阿里巴巴早在 2011 年就開始發展了基於 LXC 的容器技術，經過了幾代的系統演進，如今阿里巴巴有著超過百萬的容器體量，這個規模在世界範圍內都是頂尖的。

隨著雲技術發展和雲原生應用的興起，我們近兩年間逐步將過去的容器遷到了基於 Kubernetes 的雲原生環境中。而在這其中，我們遇到了不少應用部署方面的問題。首先對於應用開發者來說，他們對遷移到雲原生環境的期望是：

- 面向豐富業務場景的策略功能
- 極致的部署釋出效率
- 執行時的穩定性和容錯能力

阿里的應用場景非常複雜，基於 Kubernetes 之上生長著很多不同的 PaaS 二層，比如服務於電商業務的運維中臺、規模化運維、中介軟體、Serverless、函式計算等，而每個平臺都對部署、釋出要求各有不同。

我們再來看一下 Kubernete 原生所提供的兩種常用 workload 的能力：

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

簡單來說，Deployment 和 StatefulSet 在一些小規模的場景下是可以 work 的；但到了阿里巴巴這種應用和容器的規模下，如果全量使用原生 workload 則是完全不現實的。目前阿里內部容器叢集上的應用數量超過十萬、容器數量達到百萬，有部分重點核心應用甚至單個應用下就有上萬的容器。再結合上圖的問題，我們會發現不僅針對單個應用的釋出功能不足，而且當釋出高峰期大量應用同時在升級時，超大規模的 Pod 重建也成為一種“災難”。

# 阿里自研的擴充套件 workloads

針對原生 workload 遠遠無法滿足應用場景的問題，我們從各種複雜的業務場景中抽象出共通的應用部署需求，據此開發了多種擴充套件 workload。在這些 workload 中我們做了大幅的增強和改進，但同時也會嚴格保證功能的通用化、不允許將業務邏輯耦合進來。

這裡我們重點介紹一下 CloneSet 與 Advanced StatefulSet。在阿里內部雲原生環境下，幾乎全量的電商相關應用都統一採用 CloneSet 做部署釋出，而中介軟體等有狀態應用則使用了 Advanced StatefulSet 管理。

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

Advanced StatefulSet 顧名思義，是原生 StatefulSet 的增強版，預設行為與原生完全一致，在此之外提供了原地升級、並行釋出（最大不可用）、釋出暫停等功能。而 CloneSet 則對標原生 Deployment，主要服務於無狀態應用，提供了最為全面豐富的部署釋出策略。

## 原地升級

CloneSet、Advanced StatefulSet 均支援指定 Pod 升級方式：

1. ReCreate：重建 Pod 升級，和原生 Deployment/StatefulSet 一致；
2. InPlaceIfPossible：如果只修改 image 和 metadata 中的 labels/annotations 等欄位，則觸發 Pod 原地升級；如果修改了其他 template spec 中的欄位，則退化到 Pod 重建升級；
3. InPlaceOnly：只允許修改 image 和 metadata 中的 labels/annotations 等欄位，只會使用原地升級。

所謂原地升級，就是在升級 template 模板的時候，workload 不會把原 Pod 刪除、新建，而是直接在原 Pod 物件上更新對應的 image 等資料。

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

如上圖所示，在原地升級的時候 CloneSet 只會更新 Pod spec 中對應容器的 image，而後 kubelet 看到 Pod 中這個容器的定義發生了變化，則會把對應的容器停掉、拉取新的映象、並使用新映象建立啟動容器。另外可以看到在過程中，這個 Pod 的 sandbox 容器以及其他本次未升級的容器還一直處於正常執行狀態，只有需要升級的容器會受到影響。

原地升級給我們帶來的好處實在太多了：

- 首先就是釋出效率大大提升了，根據非完全統計資料，在阿里環境下原地升級至少比完全重建升級提升了 80% 以上的釋出速度：不僅省去了排程、分配網路、分配遠端盤的耗時，連拉取新映象的時候都得益於 node 上已有舊映象、只需要拉取較少的增量 layer）；
- IP 不變、升級過程 Pod 網路不斷，除本次升級外的其他容器保持正常執行；
- Volume 不變，完全複用原容器的掛載裝置；
- 保障了叢集確定性，使排布拓撲能透過大促驗證。

後續我們將會有專文講解阿里在 Kubernetes 之上做的原地升級，意義非常重大。如果沒有了原地升級，阿里巴巴內部超大規模的應用場景幾乎是無法在原生 Kubernetes 環境上完美落地的，我們也鼓勵每一位 Kubernetes 使用者都應該“體驗”一下原地升級，它給我們帶來了不同於 Kubernetes 傳統釋出模式的變革。

## 流式+分批發布

前一章我們提到了，目前 Deployment 支援 maxUnavailable/maxSurge 的流式升級，而 StatefulSet 支援 partition 的分批升級。但問題在於，Deployment 無法灰度分批，而 StatefulSet 則只能一個一個 Pod 序列釋出，沒辦法並行的流式升級。

首先要說的是，我們將 maxUnavailable 引入了 Advanced StatefulSet。原生 StatefulSet 的 one by one 釋出，大家其實可以理解為一個強制 maxUnavailable=1 的過程，而 Advanced StatefulSet 中如果我們配置了更大的 maxUnavailable，那麼就支援並行釋出更多的 Pod 了。

然後我們再來看一下 CloneSet，它支援原生 Deployment 和 StatefulSet 的全部發布策略，包括 maxUnavailable、maxSurge、partition。那麼 CloneSet 是如何把它們結合在一起的呢？我們來看一個例子：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
# ...
spec:
  replicas: 5          # Pod 總數為 5
  updateStrategy:
    type: InPlaceIfPossible
    maxSurge: 20%      # 多擴出來 5 * 20% = 1 個 Pod (rounding up)
    maxUnavailable: 0  # 保證釋出過程 5 - 0 = 5 個 Pod 可用
    partition: 3       # 保留 3 箇舊版本 Pod （只發布 5 - 3 = 2 個 Pod）
```

針對這個副本數為 5 的 CloneSet，如果我們修改了 template 中的 image，同時配置：maxSurge=20%  maxUnavailable=0  partition=3。當開始釋出後：

1. 先擴出來 1 個新版本的 Pod，5 個存量 Pod 保持不動；
2. 新 Pod ready 後，逐步把舊版本 Pod 做原地升級；
3. 直到剩餘 3 箇舊版本 Pod 時，因為滿足了 partition 終態，會把新版本 Pod 再刪除 1 個；
4. 此時 Pod 總數仍然為 5，其中 3 箇舊版本、1 個新版本。

如果我們接下來把 partition 調整為 0，則 CloneSet 還是會先擴出 1 個額外的新版 Pod，隨後逐漸將所有 Pod 升級到新版，最終再次刪除一個 Pod，達到 5 個副本全量升級的終態。

## 釋出順序可配置

對於原生的 Deployment 和 StatefulSet，使用者是無法配置釋出順序的。Deployment 下的 Pod 釋出順序完全依賴於它修改 ReplicaSet 後的擴縮順序，而 StatefulSet 則嚴格按照 order 的反序來做一一升級。

但在 CloneSet 和 Advanced StatefulSet 中，我們增加了釋出順序的可配置能力，使使用者可以定製自己的釋出順序。目前可以透過以下兩種釋出優先順序和一種釋出打散策略來定義順序：

- 優先順序(1)：按給定 label key，在釋出時根據 Pod labels 中這個 key 對應的 value 值作為權重：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
  # ...
  updateStrategy:
    priorityStrategy:
      orderPriority:
        - orderedKey: some-label-key
```

- 優先順序(2)：按 selector 匹配計算權重，釋出時根據 Pod 對多個 weight selector 的匹配情況計算權重總和：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
  # ...
  updateStrategy:
    priorityStrategy:
      weightPriority:
      - weight: 50
        matchSelector:
          matchLabels:
            test-key: foo
      - weight: 30
        matchSelector:
          matchLabels:
            test-key: bar
```

- 打散：將匹配 key-value 的 Pod 打散到不同批次中釋出：

```yaml
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
  # ...
  updateStrategy:
    scatterStrategy:
    - key: some-label-key
      value: foo
```

可能有同學會問為什麼要配置釋出順序呢？比如 zookeeper 這類應用在釋出時，需要先把所有非主節點升級，最後再升級主節點，這樣才能保證在整個釋出過程中只會發生一次切主。這時使用者就可以透過流程打標、或者寫一個 operator 自動為 zookeeper 的 Pod 打上節點職責的標籤，而後配置非主節點的釋出權重較大，使得釋出時能夠儘量減少切主的次數。

## sidecar 容器管理

輕量化容器也是阿里巴巴在雲原生階段的一次重大改革，過去阿里的容器絕大多數都是以“富容器”的方式執行的，所謂“富容器”即在一個容器中既執行業務、也跑著各種各樣的外掛和守護程式。而在雲原生時代，我們在逐漸把原先“富容器”中的旁路外掛拆分到獨立的 sidecar 容器中，使主容器逐漸迴歸業務自身。

這裡對於拆分的好處就不贅述了，我們來看下另一個問題，就是拆分之後這些 sidecar 容器如何做管理呢？最直觀的方式是在每個應用的 workload 中顯示去定義 Pod 中需要的 sidecar，但這樣帶來的問題很多：

1. 當應用和 workload 數量眾多時，我們很難統一的 sidecar 增減管理；
2. 應用開發者不知道（甚至也不關心）自己的應用需要配置哪些 sidecar 容器；
3. 當 sidecar 映象需要升級時，要把所有應用的 workload 全部升級一遍，很不現實。

因此，我們設計了 SidecarSet，將 sidecar 容器的定義與應用 workload 解耦。應用開發者們不再需要再關心自己的 workload 中需要寫哪些 sidecar 容器，而透過原地升級， sidecar 維護者們也可以自主地管理和升級 sidecar 容器。

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

# 開放能力應用

到了這裡，大家是不是對阿里巴巴的應用部署模式有了一個基本的瞭解呢？其實上述的能力都已經開源到了社群，我們的專案就叫做 [OpenKruise](https://github.com/openkruise/kruise)，目前它已經提供了 5 種擴充套件 workload：

- [CloneSet](https://github.com/openkruise/kruise/blob/master/docs/concepts/cloneset/README.md)：提供了更加高效、確定可控的應用管理和部署能力，支援優雅原地升級、指定刪除、釋出順序可配置、並行/灰度釋出等豐富的策略，可以滿足更多樣化的應用場景；
- [Advanced StatefulSet](https://github.com/openkruise/kruise/blob/master/docs/concepts/astatefulset/README.md)：基於原生 [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) 之上的增強版本，預設行為與原生完全一致，在此之外提供了原地升級、並行釋出（最大不可用）、釋出暫停等功能；
- [SidecarSet](https://github.com/openkruise/kruise/blob/master/docs/concepts/sidecarSet/README.md)：對 sidecar 容器做統一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器；
- [UnitedDeployment](https://github.com/openkruise/kruise/blob/master/docs/concepts/uniteddeployment/README.md)：透過多個 subset workload 將應用部署到多個可用區；
- [BroadcastJob](https://github.com/openkruise/kruise/blob/master/docs/concepts/broadcastJob/README.md)：配置一個 job，在叢集中所有滿足條件的 Node 上都跑一個 Pod 任務。

此外，我們還有更多的擴充套件能力還在開源的路上！近期，我們會將內部的 Advanced DaemonSet 開放到 OpenKruise 中，它在原生 DaemonSet 的 maxUnavailable 之上，額外提供瞭如分批、selector 等釋出策略，分批的功能使 DaemonSet 在釋出的時候能夠只升級其中部分 Pod，而 selector 更是允許釋出的時候指定先在符合某些標籤的 node 上升級，這為我們在大規模叢集中升級 DaemonSet 帶來了灰度能力和穩定性的保障。

而後續，我們還計劃將阿里巴巴內部擴充套件的 HPA、排程外掛等通用化能力開放出來，讓每一位 Kubernetes 開發者和阿里雲上的使用者都能很便捷地使用上阿里內部開發應用的雲原生增強能力。

最後，我們也歡迎每一位雲原生愛好者來共同參與 OpenKruise 的建設。與其他一些開源專案不同，OpenKruise 並不是阿里內部程式碼的復刻；恰恰相反，OpenKruise Github 倉庫是阿里內部程式碼庫的 upstream。因此，每一行你貢獻的程式碼，都將執行在阿里內部的所有 Kubernetes 叢集中、都將共同支撐了阿里巴巴全球頂尖規模的應用場景！

# Q & A

**Q1：**目前阿里最大規模的業務 pod 數量有多少，釋出一次需要多少時間？
**A1：**這個只能透露數量目前最大規模的單個應用下數量是以萬為單位的，一次釋出時間要看具體分批灰度的時長了。如果分批較多、觀察時間較長的話，可能是會持續一兩週的。

**Q2：**pod 的資源 request 和 limit 是怎麼配置的？request 和 limit 是什麼比例來配置？過多的 request 造成浪費，過少可能會導致熱點 node 負載超高。
**A2：**這個主要還是根據應用的需求來定的，目前大部分線上應用都是 1:1 的關係，部分離線和job 型別的會配置 request>limit。

**Q3：**kruise 升級問題，升級 kurise apiversion 版本的情況下，原有的版本的部署如何升級？
**A3：**目前 kruise 中資源的 apiVersion 還都是統一的。我們計劃在今年下半年將部分較為成熟的 workload 進行版本升級，使用者在自己的 K8s 叢集內升級後，存量的舊版本資源會自動透過 conversion 升級到新版本。

**Q4：**OpenKruise 有提供 go-client 嗎？
**A4：**目前提供兩個方式：1. 引入 github.com/openkruise/kruise/pkg/client 包，下面有生成好的 clientset / informer / lister 等工具；2. 使用 controller-runtime 的使用者（包括 kubebuilder、operator-sdk），直接引入 github.com/openkruise/kruise-api 輕量化依賴，然後加到 scheme 裡就能直接用了。

**Q5：**阿里 K8s 版本升級是如何做的？
**A5：**阿里集團內部使用 Kube-On-Kube 的架構進行大規模的 Kubernetes 叢集管理，用一個元 K8s 叢集管理成百上千個業務 K8s 叢集。其中元叢集版本較為穩定，業務叢集會進行頻繁升級，業務叢集的升級流程事實上就是對元叢集中的 workloads（原生 workloads 以及 kruise workloads） 進行版本或配置升級，與正常情況我們對業務 workloads 的升級流程相似。

**Q6：**這個灰度之後,流量是怎麼切的？
**A6：**在原地升級前，kruise 會先透過 readinessGate 將 Pod 置為 not-ready，此時 endpoint 等控制器會感知到並把 Pod 從端點摘掉。然後 kruise 更新 pod image 觸發容器重建，完成後再把 Pod 改為 ready。

**Q7：**daemonset 的分批是透過類似 deployment 的暫停功能實現的麼？統計已經發布數量然後暫停，然後繼續，然後再暫停。
**A7：**總體過程上類似，升級過程中對新舊版本進行統計並判斷是否已達到指定終態。但相比 deployment，daemonset 需要處理比較複雜的邊界情況（例如初次釋出時叢集中並沒有指定的 Pod），具體細節可以持續關注我們即將開源的程式碼。

**Q8：**多叢集的釋出頁面上怎麼開始釋出的？
**A8：**直播中演示的是一個 demo 的釋出系統結合 Kruise Workloads 的例子，從互動上是透過使用者選擇對應的叢集，點選開始執行進行釋出；從實現上實際是對新版本的 YAML 與叢集中的 YAML 計算 diff 後 Patch 進叢集，再操作 DaemonSet 的控制欄位（partition / paused 等），控制灰度程式。

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

如何為雲原生應用帶來穩定高效的部署能力？

相關文章