如何為云原生應用帶來穩(wěn)定高效的部署能力？

作者 | 酒祝  阿里云技術(shù)專家、墨封  阿里云開發(fā)工程師

直播完整視頻回顧：https://www.bilibili.com/video/BV1mK4y1t7WS/

關(guān)注“阿里巴巴云原生”公眾號，后臺回復 “528” 即可下載 PPT

5 月 28 日，我們發(fā)起了第 3 期 SIG Cloud-Provider-Alibaba 網(wǎng)研會直播。本次直播主要介紹了阿里經(jīng)濟體大規(guī)模應用上云過程中遇到的核心部署問題、采取的對應解決方案，以及這些方案沉淀為通用化能力輸出開源后，如何幫助阿里云上的用戶提升應用部署發(fā)布的效率與穩(wěn)定性。

本文匯集了此次直播完整視頻回顧及資料下載，并整理了直播過程中收集的問題和解答，希望能夠?qū)Υ蠹矣兴鶐椭鷡

前言

隨著近年來 Kubernetes 逐漸成為事實標準和大量應用的云原生化，我們往往發(fā)現(xiàn) Kubernetes 的原生 workload 對大規(guī)?；瘧玫闹С植⒉皇帧坝押谩?。如何在 Kubernetes 上為應用提供更加完善、高效、靈活的部署發(fā)布能力，成為了我們探索的目標。

本文將會介紹在阿里經(jīng)濟體全面接入云原生的過程中，我們在應用部署方面所做的改進優(yōu)化、實現(xiàn)功能更加完備的增強版 workload、并將其開源到社區(qū)，使得現(xiàn)在每一位 Kubernetes 開發(fā)者和阿里云上的用戶都能很便捷地使用上阿里巴巴內(nèi)部云原生應用所統(tǒng)一使用的部署發(fā)布能力。

• 第一期網(wǎng)研會回顧：Kubernetes SIG-Cloud-Provider-Alibaba 首次網(wǎng)研會（含 PPT 下載）

• 第二期網(wǎng)研會回顧：在生產(chǎn)環(huán)境中，阿里云如何構(gòu)建高性能云原生容器網(wǎng)絡？（含 PPT 下載）

阿里應用場景與原生 workloads

阿里巴巴容器化道路的起步在國內(nèi)外都是比較領先的。容器這個技術(shù)概念雖然出現(xiàn)得很早，但一直到 2013 年 Docker 產(chǎn)品出現(xiàn)后才逐漸為人所熟知。而阿里巴巴早在 2011 年就開始發(fā)展了基于 LXC 的容器技術(shù)，經(jīng)過了幾代的系統(tǒng)演進，如今阿里巴巴有著超過百萬的容器體量，這個規(guī)模在世界范圍內(nèi)都是頂尖的。

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

• 面向豐富業(yè)務場景的策略功能

• 極致的部署發(fā)布效率

• 運行時的穩(wěn)定性和容錯能力

阿里的應用場景非常復雜，基于 Kubernetes 之上生長著很多不同的 PaaS 二層，比如服務于電商業(yè)務的運維中臺、規(guī)模化運維、中間件、Serverless、函數(shù)計算等，而每個平臺都對部署、發(fā)布要求各有不同。

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

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

阿里自研的擴展 workloads

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

這里我們重點介紹一下 CloneSet 與 Advanced StatefulSet。在阿里內(nèi)部云原生環(huán)境下，幾乎全量的電商相關(guān)應用都統(tǒng)一采用 CloneSet 做部署發(fā)布，而中間件等有狀態(tài)應用則使用了 Advanced StatefulSet 管理。

Advanced StatefulSet 顧名思義，是原生 StatefulSet 的增強版，默認行為與原生完全一致，在此之外提供了原地升級、并行發(fā)布（最大不可用）、發(fā)布暫停等功能。而 CloneSet 則對標原生 Deployment，主要服務于無狀態(tài)應用，提供了最為全面豐富的部署發(fā)布策略。

原地升級

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

1. ReCreate：重建 Pod 升級，和原生 Deployment/StatefulSet 一致；

2. InPlaceIfPossible：如果只修改 image 和 metadata 中的 labels/annotations 等字段，則觸發(fā) Pod 原地升級；如果修改了其他 template spec 中的字段，則退化到 Pod 重建升級；

3. InPlaceOnly：只允許修改 image 和 metadata 中的 labels/annotations 等字段，只會使用原地升級。

所謂原地升級，就是在升級 template 模板的時候，workload 不會把原 Pod 刪除、新建，而是直接在原 Pod 對象上更新對應的 image 等數(shù)據(jù)。

如上圖所示，在原地升級的時候 CloneSet 只會更新 Pod spec 中對應容器的 image，而后 kubelet 看到 Pod 中這個容器的定義發(fā)生了變化，則會把對應的容器停掉、拉取新的鏡像、并使用新鏡像創(chuàng)建啟動容器。另外可以看到在過程中，這個 Pod 的 sandbox 容器以及其他本次未升級的容器還一直處于正常運行狀態(tài)，只有需要升級的容器會受到影響。

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

• 首先就是發(fā)布效率大大提升了，根據(jù)非完全統(tǒng)計數(shù)據(jù)，在阿里環(huán)境下原地升級至少比完全重建升級提升了 80% 以上的發(fā)布速度：不僅省去了調(diào)度、分配網(wǎng)絡、分配遠程盤的耗時，連拉取新鏡像的時候都得益于 node 上已有舊鏡像、只需要拉取較少的增量 layer）；

• IP 不變、升級過程 Pod 網(wǎng)絡不斷，除本次升級外的其他容器保持正常運行；

• Volume 不變，完全復用原容器的掛載設備；

• 保障了集群確定性，使排布拓撲能通過大促驗證。

后續(xù)我們將會有專文講解阿里在 Kubernetes 之上做的原地升級，意義非常重大。如果沒有了原地升級，阿里巴巴內(nèi)部超大規(guī)模的應用場景幾乎是無法在原生 Kubernetes 環(huán)境上完美落地的，我們也鼓勵每一位 Kubernetes 用戶都應該“體驗”一下原地升級，它給我們帶來了不同于 Kubernetes 傳統(tǒng)發(fā)布模式的變革。

流式+分批發(fā)布

前一章我們提到了，目前 Deployment 支持 maxUnavailable/maxSurge 的流式升級，而 StatefulSet 支持 partition 的分批升級。但問題在于，Deployment 無法灰度分批，而 StatefulSet 則只能一個一個 Pod 串行發(fā)布，沒辦法并行的流式升級。

首先要說的是，我們將 maxUnavailable 引入了 Advanced StatefulSet。原生 StatefulSet 的 one by one 發(fā)布，大家其實可以理解為一個強制 maxUnavailable=1 的過程，而 Advanced StatefulSet 中如果我們配置了更大的 maxUnavailable，那么就支持并行發(fā)布更多的 Pod 了。

然后我們再來看一下 CloneSet，它支持原生 Deployment 和 StatefulSet 的全部發(fā)布策略，包括 maxUnavailable、maxSurge、partition。那么 CloneSet 是如何把它們結(jié)合在一起的呢？我們來看一個例子：

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

針對這個副本數(shù)為 5 的 CloneSet，如果我們修改了 template 中的 image，同時配置：maxSurge=20%  maxUnavailable=0  partition=3。當開始發(fā)布后：

1. 先擴出來 1 個新版本的 Pod，5 個存量 Pod 保持不動；

2. 新 Pod ready 后，逐步把舊版本 Pod 做原地升級；

3. 直到剩余 3 個舊版本 Pod 時，因為滿足了 partition 終態(tài)，會把新版本 Pod 再刪除 1 個；

4. 此時 Pod 總數(shù)仍然為 5，其中 3 個舊版本、1 個新版本。

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

發(fā)布順序可配置

對于原生的 Deployment 和 StatefulSet，用戶是無法配置發(fā)布順序的。Deployment 下的 Pod 發(fā)布順序完全依賴于它修改 ReplicaSet 后的擴縮順序，而 StatefulSet 則嚴格按照 order 的反序來做一一升級。

但在 CloneSet 和 Advanced StatefulSet 中，我們增加了發(fā)布順序的可配置能力，使用戶可以定制自己的發(fā)布順序。目前可以通過以下兩種發(fā)布優(yōu)先級和一種發(fā)布打散策略來定義順序：

• 優(yōu)先級(1)：按給定 label key，在發(fā)布時根據(jù) Pod labels 中這個 key 對應的 value 值作為權(quán)重：

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

• 優(yōu)先級(2)：按 selector 匹配計算權(quán)重，發(fā)布時根據(jù) Pod 對多個 weight selector 的匹配情況計算權(quán)重總和：

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 打散到不同批次中發(fā)布：

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

可能有同學會問為什么要配置發(fā)布順序呢？比如 zookeeper 這類應用在發(fā)布時，需要先把所有非主節(jié)點升級，最后再升級主節(jié)點，這樣才能保證在整個發(fā)布過程中只會發(fā)生一次切主。這時用戶就可以通過流程打標、或者寫一個 operator 自動為 zookeeper 的 Pod 打上節(jié)點職責的標簽，而后配置非主節(jié)點的發(fā)布權(quán)重較大，使得發(fā)布時能夠盡量減少切主的次數(shù)。

sidecar 容器管理

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

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

1. 當應用和 workload 數(shù)量眾多時，我們很難統(tǒng)一的 sidecar 增減管理；

2. 應用開發(fā)者不知道（甚至也不關(guān)心）自己的應用需要配置哪些 sidecar 容器；

3. 當 sidecar 鏡像需要升級時，要把所有應用的 workload 全部升級一遍，很不現(xiàn)實。

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

開放能力應用

到了這里，大家是不是對阿里巴巴的應用部署模式有了一個基本的了解呢？其實上述的能力都已經(jīng)開源到了社區(qū)，我們的項目就叫做 OpenKruise，目前它已經(jīng)提供了 5 種擴展 workload：

• CloneSet：提供了更加高效、確定可控的應用管理和部署能力，支持優(yōu)雅原地升級、指定刪除、發(fā)布順序可配置、并行/灰度發(fā)布等豐富的策略，可以滿足更多樣化的應用場景；

• Advanced StatefulSet：基于原生 StatefulSet 之上的增強版本，默認行為與原生完全一致，在此之外提供了原地升級、并行發(fā)布（最大不可用）、發(fā)布暫停等功能；

• SidecarSet：對 sidecar 容器做統(tǒng)一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器；

• UnitedDeployment：通過多個 subset workload 將應用部署到多個可用區(qū)；

• BroadcastJob：配置一個 job，在集群中所有滿足條件的 Node 上都跑一個 Pod 任務。

此外，我們還有更多的擴展能力還在開源的路上！近期，我們會將內(nèi)部的 Advanced DaemonSet 開放到 OpenKruise 中，它在原生 DaemonSet 的 maxUnavailable 之上，額外提供了如分批、selector 等發(fā)布策略，分批的功能使 DaemonSet 在發(fā)布的時候能夠只升級其中部分 Pod，而 selector 更是允許發(fā)布的時候指定先在符合某些標簽的 node 上升級，這為我們在大規(guī)模集群中升級 DaemonSet 帶來了灰度能力和穩(wěn)定性的保障。

而后續(xù)，我們還計劃將阿里巴巴內(nèi)部擴展的 HPA、調(diào)度插件等通用化能力開放出來，讓每一位 Kubernetes 開發(fā)者和阿里云上的用戶都能很便捷地使用上阿里內(nèi)部開發(fā)應用的云原生增強能力。

最后，我們也歡迎每一位云原生愛好者來共同參與 OpenKruise 的建設。與其他一些開源項目不同，OpenKruise 并不是阿里內(nèi)部代碼的復刻；恰恰相反，OpenKruise Github 倉庫是阿里內(nèi)部代碼庫的 upstream。因此，每一行你貢獻的代碼，都將運行在阿里內(nèi)部的所有 Kubernetes 集群中、都將共同支撐了阿里巴巴全球頂尖規(guī)模的應用場景！