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

圖木舒克網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、自適應(yīng)網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)于2013年開始到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

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

關(guān)注“阿里巴巴云原生”公眾號(hào)，后臺(tái)回復(fù) “528” 即可下載 PPT

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

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

前言

隨著近年來 Kubernetes 逐漸成為事實(shí)標(biāo)準(zhǔn)和大量應(yīng)用的云原生化，我們往往發(fā)現(xiàn) Kubernetes 的原生 workload 對(duì)大規(guī)?；瘧?yīng)用的支持并不十分“友好”。如何在 Kubernetes 上為應(yīng)用提供更加完善、高效、靈活的部署發(fā)布能力，成為了我們探索的目標(biāo)。

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

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

阿里應(yīng)用場景與原生 workloads

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

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

• 面向豐富業(yè)務(wù)場景的策略功能
• 極致的部署發(fā)布效率
• 運(yùn)行時(shí)的穩(wěn)定性和容錯(cuò)能力

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

我們?cè)賮砜匆幌?Kubernete 原生所提供的兩種常用 workload 的能力：

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

阿里自研的擴(kuò)展 workloads

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

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

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

原地升級(jí)

CloneSet、Advanced StatefulSet 均支持指定 Pod 升級(jí)方式：

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

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

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

原地升級(jí)給我們帶來的好處實(shí)在太多了：

• 首先就是發(fā)布效率大大提升了，根據(jù)非完全統(tǒng)計(jì)數(shù)據(jù)，在阿里環(huán)境下原地升級(jí)至少比完全重建升級(jí)提升了 80% 以上的發(fā)布速度：不僅省去了調(diào)度、分配網(wǎng)絡(luò)、分配遠(yuǎn)程盤的耗時(shí)，連拉取新鏡像的時(shí)候都得益于 node 上已有舊鏡像、只需要拉取較少的增量 layer）；
• IP 不變、升級(jí)過程 Pod 網(wǎng)絡(luò)不斷，除本次升級(jí)外的其他容器保持正常運(yùn)行；
• Volume 不變，完全復(fù)用原容器的掛載設(shè)備；
• 保障了集群確定性，使排布拓?fù)淠芡ㄟ^大促驗(yàn)證。

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

流式+分批發(fā)布

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

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

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

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

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

1. 先擴(kuò)出來 1 個(gè)新版本的 Pod，5 個(gè)存量 Pod 保持不動(dòng)；
2. 新 Pod ready 后，逐步把舊版本 Pod 做原地升級(jí)；
3. 直到剩余 3 個(gè)舊版本 Pod 時(shí)，因?yàn)闈M足了 partition 終態(tài)，會(huì)把新版本 Pod 再刪除 1 個(gè)；
4. 此時(shí) Pod 總數(shù)仍然為 5，其中 3 個(gè)舊版本、1 個(gè)新版本。

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

發(fā)布順序可配置

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

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

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

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

• 優(yōu)先級(jí)(2)：按 selector 匹配計(jì)算權(quán)重，發(fā)布時(shí)根據(jù) Pod 對(duì)多個(gè) weight selector 的匹配情況計(jì)算權(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

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

sidecar 容器管理

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

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

1. 當(dāng)應(yīng)用和 workload 數(shù)量眾多時(shí)，我們很難統(tǒng)一的 sidecar 增減管理；
2. 應(yīng)用開發(fā)者不知道（甚至也不關(guān)心）自己的應(yīng)用需要配置哪些 sidecar 容器；
3. 當(dāng) sidecar 鏡像需要升級(jí)時(shí)，要把所有應(yīng)用的 workload 全部升級(jí)一遍，很不現(xiàn)實(shí)。

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

開放能力應(yīng)用

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

• CloneSet：提供了更加高效、確定可控的應(yīng)用管理和部署能力，支持優(yōu)雅原地升級(jí)、指定刪除、發(fā)布順序可配置、并行/灰度發(fā)布等豐富的策略，可以滿足更多樣化的應(yīng)用場景；
• Advanced StatefulSet：基于原生 StatefulSet 之上的增強(qiáng)版本，默認(rèn)行為與原生完全一致，在此之外提供了原地升級(jí)、并行發(fā)布（最大不可用）、發(fā)布暫停等功能；
• SidecarSet：對(duì) sidecar 容器做統(tǒng)一管理，在滿足 selector 條件的 Pod 中注入指定的 sidecar 容器；
• UnitedDeployment：通過多個(gè) subset workload 將應(yīng)用部署到多個(gè)可用區(qū)；
• BroadcastJob：配置一個(gè) job，在集群中所有滿足條件的 Node 上都跑一個(gè) Pod 任務(wù)。

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

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

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

Q & A

Q1：目前阿里最大規(guī)模的業(yè)務(wù) pod 數(shù)量有多少，發(fā)布一次需要多少時(shí)間？
A1：這個(gè)只能透露數(shù)量目前最大規(guī)模的單個(gè)應(yīng)用下數(shù)量是以萬為單位的，一次發(fā)布時(shí)間要看具體分批灰度的時(shí)長了。如果分批較多、觀察時(shí)間較長的話，可能是會(huì)持續(xù)一兩周的。

Q2：pod 的資源 request 和 limit 是怎么配置的？request 和 limit 是什么比例來配置？過多的 request 造成浪費(fèi)，過少可能會(huì)導(dǎo)致熱點(diǎn) node 負(fù)載超高。
A2：這個(gè)主要還是根據(jù)應(yīng)用的需求來定的，目前大部分在線應(yīng)用都是 1:1 的關(guān)系，部分離線和job 類型的會(huì)配置 request>limit。

Q3：kruise 升級(jí)問題，升級(jí) kurise apiversion 版本的情況下，原有的版本的部署如何升級(jí)？
A3：目前 kruise 中資源的 apiVersion 還都是統(tǒng)一的。我們計(jì)劃在今年下半年將部分較為成熟的 workload 進(jìn)行版本升級(jí)，用戶在自己的 K8s 集群內(nèi)升級(jí)后，存量的舊版本資源會(huì)自動(dòng)通過 conversion 升級(jí)到新版本。

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

Q5：阿里 K8s 版本升級(jí)是如何做的？
A5：阿里集團(tuán)內(nèi)部使用 Kube-On-Kube 的架構(gòu)進(jìn)行大規(guī)模的 Kubernetes 集群管理，用一個(gè)元 K8s 集群管理成百上千個(gè)業(yè)務(wù) K8s 集群。其中元集群版本較為穩(wěn)定，業(yè)務(wù)集群會(huì)進(jìn)行頻繁升級(jí)，業(yè)務(wù)集群的升級(jí)流程事實(shí)上就是對(duì)元集群中的 workloads（原生 workloads 以及 kruise workloads） 進(jìn)行版本或配置升級(jí)，與正常情況我們對(duì)業(yè)務(wù) workloads 的升級(jí)流程相似。

Q6：這個(gè)灰度之后,流量是怎么切的？
A6：在原地升級(jí)前，kruise 會(huì)先通過 readinessGate 將 Pod 置為 not-ready，此時(shí) endpoint 等控制器會(huì)感知到并把 Pod 從端點(diǎn)摘掉。然后 kruise 更新 pod image 觸發(fā)容器重建，完成后再把 Pod 改為 ready。

Q7：daemonset 的分批是通過類似 deployment 的暫停功能實(shí)現(xiàn)的么？統(tǒng)計(jì)已經(jīng)發(fā)布數(shù)量然后暫停，然后繼續(xù)，然后再暫停。
A7：總體過程上類似，升級(jí)過程中對(duì)新舊版本進(jìn)行統(tǒng)計(jì)并判斷是否已達(dá)到指定終態(tài)。但相比 deployment，daemonset 需要處理比較復(fù)雜的邊界情況（例如初次發(fā)布時(shí)集群中并沒有指定的 Pod），具體細(xì)節(jié)可以持續(xù)關(guān)注我們即將開源的代碼。

Q8：多集群的發(fā)布頁面上怎么開始發(fā)布的？
A8：直播中演示的是一個(gè) demo 的發(fā)布系統(tǒng)結(jié)合 Kruise Workloads 的例子，從交互上是通過用戶選擇對(duì)應(yīng)的集群，點(diǎn)擊開始執(zhí)行進(jìn)行發(fā)布；從實(shí)現(xiàn)上實(shí)際是對(duì)新版本的 YAML 與集群中的 YAML 計(jì)算 diff 后 Patch 進(jìn)集群，再操作 DaemonSet 的控制字段（partition / paused 等），控制灰度進(jìn)程。

“ 阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號(hào)?！?/p>