作者 | 酒祝 阿里云技術(shù)專家、墨封 阿里云開發(fā)工程師
企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的,是企業(yè)文化與產(chǎn)品對外擴展宣傳的重要窗口,一個合格的網(wǎng)站不僅僅能為公司帶來巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺,創(chuàng)新互聯(lián)公司面向各種領(lǐng)域:成都門簾等成都網(wǎng)站設(shè)計公司、營銷型網(wǎng)站解決方案、網(wǎng)站設(shè)計等建站排名服務(wù)。直播完整視頻回顧: https://www.bilibili.com/video/BV1mK4y1t7WS/
關(guān)注“阿里巴巴云原生”公眾號,后臺回復(fù) “528” 即可下載 PPT
5 月 28 日,我們發(fā)起了第 3 期 SIG Cloud-Provider-Alibaba 網(wǎng)研會直播。本次直播主要介紹了阿里經(jīng)濟體大規(guī)模應(yīng)用上云過程中遇到的核心部署問題、采取的對應(yīng)解決方案,以及這些方案沉淀為通用化能力輸出開源后,如何幫助阿里云上的用戶提升應(yīng)用部署發(fā)布的效率與穩(wěn)定性。
本文匯集了此次直播完整視頻回顧及資料下載,并整理了直播過程中收集的問題和解答,希望能夠?qū)Υ蠹矣兴鶐椭鷡
隨著近年來 Kubernetes 逐漸成為事實標準和大量應(yīng)用的云原生化,我們往往發(fā)現(xiàn) Kubernetes 的原生 workload 對大規(guī)?;瘧?yīng)用的支持并不十分“友好”。如何在 Kubernetes 上為應(yīng)用提供更加完善、高效、靈活的部署發(fā)布能力,成為了我們探索的目標。
本文將會介紹在阿里經(jīng)濟體全面接入云原生的過程中,我們在應(yīng)用部署方面所做的改進優(yōu)化、實現(xiàn)功能更加完備的增強版 workload、并將其開源到社區(qū),使得現(xiàn)在每一位 Kubernetes 開發(fā)者和阿里云上的用戶都能很便捷地使用上阿里巴巴內(nèi)部云原生應(yīng)用所統(tǒng)一使用的部署發(fā)布能力。
阿里巴巴容器化道路的起步在國內(nèi)外都是比較領(lǐng)先的。容器這個技術(shù)概念雖然出現(xiàn)得很早,但一直到 2013 年 Docker 產(chǎn)品出現(xiàn)后才逐漸為人所熟知。而阿里巴巴早在 2011 年就開始發(fā)展了基于 LXC 的容器技術(shù),經(jīng)過了幾代的系統(tǒng)演進,如今阿里巴巴有著超過百萬的容器體量,這個規(guī)模在世界范圍內(nèi)都是頂尖的。
隨著云技術(shù)發(fā)展和云原生應(yīng)用的興起,我們近兩年間逐步將過去的容器遷到了基于 Kubernetes 的云原生環(huán)境中。而在這其中,我們遇到了不少應(yīng)用部署方面的問題。首先對于應(yīng)用開發(fā)者來說,他們對遷移到云原生環(huán)境的期望是:
阿里的應(yīng)用場景非常復(fù)雜,基于 Kubernetes 之上生長著很多不同的 PaaS 二層,比如服務(wù)于電商業(yè)務(wù)的運維中臺、規(guī)?;\維、中間件、Serverless、函數(shù)計算等,而每個平臺都對部署、發(fā)布要求各有不同。
我們再來看一下 Kubernete 原生所提供的兩種常用 workload 的能力:
簡單來說,Deployment 和 StatefulSet 在一些小規(guī)模的場景下是可以 work 的;但到了阿里巴巴這種應(yīng)用和容器的規(guī)模下,如果全量使用原生 workload 則是完全不現(xiàn)實的。目前阿里內(nèi)部容器集群上的應(yīng)用數(shù)量超過十萬、容器數(shù)量達到百萬,有部分重點核心應(yīng)用甚至單個應(yīng)用下就有上萬的容器。再結(jié)合上圖的問題,我們會發(fā)現(xiàn)不僅針對單個應(yīng)用的發(fā)布功能不足,而且當(dāng)發(fā)布高峰期大量應(yīng)用同時在升級時,超大規(guī)模的 Pod 重建也成為一種“災(zāi)難”。
針對原生 workload 遠遠無法滿足應(yīng)用場景的問題,我們從各種復(fù)雜的業(yè)務(wù)場景中抽象出共通的應(yīng)用部署需求,據(jù)此開發(fā)了多種擴展 workload。在這些 workload 中我們做了大幅的增強和改進,但同時也會嚴格保證功能的通用化、不允許將業(yè)務(wù)邏輯耦合進來。
這里我們重點介紹一下 CloneSet 與 Advanced StatefulSet。在阿里內(nèi)部云原生環(huán)境下,幾乎全量的電商相關(guān)應(yīng)用都統(tǒng)一采用 CloneSet 做部署發(fā)布,而中間件等有狀態(tài)應(yīng)用則使用了 Advanced StatefulSet 管理。
Advanced StatefulSet 顧名思義,是原生 StatefulSet 的增強版,默認行為與原生完全一致,在此之外提供了原地升級、并行發(fā)布(大不可用)、發(fā)布暫停等功能。而 CloneSet 則對標原生 Deployment,主要服務(wù)于無狀態(tài)應(yīng)用,提供了最為全面豐富的部署發(fā)布策略。
CloneSet、Advanced StatefulSet 均支持指定 Pod 升級方式:
所謂原地升級,就是在升級 template 模板的時候,workload 不會把原 Pod 刪除、新建,而是直接在原 Pod 對象上更新對應(yīng)的 image 等數(shù)據(jù)。
如上圖所示,在原地升級的時候 CloneSet 只會更新 Pod spec 中對應(yīng)容器的 image,而后 kubelet 看到 Pod 中這個容器的定義發(fā)生了變化,則會把對應(yīng)的容器停掉、拉取新的鏡像、并使用新鏡像創(chuàng)建啟動容器。另外可以看到在過程中,這個 Pod 的 sandbox 容器以及其他本次未升級的容器還一直處于正常運行狀態(tài),只有需要升級的容器會受到影響。
原地升級給我們帶來的好處實在太多了:
后續(xù)我們將會有專文講解阿里在 Kubernetes 之上做的原地升級,意義非常重大。如果沒有了原地升級,阿里巴巴內(nèi)部超大規(guī)模的應(yīng)用場景幾乎是無法在原生 Kubernetes 環(huán)境上完美落地的,我們也鼓勵每一位 Kubernetes 用戶都應(yīng)該“體驗”一下原地升級,它給我們帶來了不同于 Kubernetes 傳統(tǒng)發(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。當(dāng)開始發(fā)布后:
如果我們接下來把 partition 調(diào)整為 0,則 CloneSet 還是會先擴出 1 個額外的新版 Pod,隨后逐漸將所有 Pod 升級到新版,最終再次刪除一個 Pod,達到 5 個副本全量升級的終態(tài)。
對于原生的 Deployment 和 StatefulSet,用戶是無法配置發(fā)布順序的。Deployment 下的 Pod 發(fā)布順序完全依賴于它修改 ReplicaSet 后的擴縮順序,而 StatefulSet 則嚴格按照 order 的反序來做一一升級。
但在 CloneSet 和 Advanced StatefulSet 中,我們增加了發(fā)布順序的可配置能力,使用戶可以定制自己的發(fā)布順序。目前可以通過以下兩種發(fā)布優(yōu)先級和一種發(fā)布打散策略來定義順序:
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
# ...
updateStrategy:
priorityStrategy:
orderPriority:
- orderedKey: some-label-key
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
apiVersion: apps.kruise.io/v1alpha1
kind: CloneSet
spec:
# ...
updateStrategy:
scatterStrategy:
- key: some-label-key
value: foo
可能有同學(xué)會問為什么要配置發(fā)布順序呢?比如 zookeeper 這類應(yīng)用在發(fā)布時,需要先把所有非主節(jié)點升級,最后再升級主節(jié)點,這樣才能保證在整個發(fā)布過程中只會發(fā)生一次切主。這時用戶就可以通過流程打標、或者寫一個 operator 自動為 zookeeper 的 Pod 打上節(jié)點職責(zé)的標簽,而后配置非主節(jié)點的發(fā)布權(quán)重較大,使得發(fā)布時能夠盡量減少切主的次數(shù)。
輕量化容器也是阿里巴巴在云原生階段的一次重大改革,過去阿里的容器絕大多數(shù)都是以“富容器”的方式運行的,所謂“富容器”即在一個容器中既運行業(yè)務(wù)、也跑著各種各樣的插件和守護進程。而在云原生時代,我們在逐漸把原先“富容器”中的旁路插件拆分到獨立的 sidecar 容器中,使主容器逐漸回歸業(yè)務(wù)自身。
這里對于拆分的好處就不贅述了,我們來看下另一個問題,就是拆分之后這些 sidecar 容器如何做管理呢?最直觀的方式是在每個應(yīng)用的 workload 中顯示去定義 Pod 中需要的 sidecar,但這樣帶來的問題很多:
因此,我們設(shè)計了 SidecarSet,將 sidecar 容器的定義與應(yīng)用 workload 解耦。應(yīng)用開發(fā)者們不再需要再關(guān)心自己的 workload 中需要寫哪些 sidecar 容器,而通過原地升級, sidecar 維護者們也可以自主地管理和升級 sidecar 容器。
到了這里,大家是不是對阿里巴巴的應(yīng)用部署模式有了一個基本的了解呢?其實上述的能力都已經(jīng)開源到了社區(qū),我們的項目就叫做 OpenKruise,目前它已經(jīng)提供了 5 種擴展 workload:
此外,我們還有更多的擴展能力還在開源的路上!近期,我們會將內(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ā)應(yīng)用的云原生增強能力。
最后,我們也歡迎每一位云原生愛好者來共同參與 OpenKruise 的建設(shè)。與其他一些開源項目不同,OpenKruise 并不是阿里內(nèi)部代碼的復(fù)刻;恰恰相反,OpenKruise Github 倉庫是阿里內(nèi)部代碼庫的 upstream。因此,每一行你貢獻的代碼,都將運行在阿里內(nèi)部的所有 Kubernetes 集群中、都將共同支撐了阿里巴巴全球頂尖規(guī)模的應(yīng)用場景!
Q1:目前阿里大規(guī)模的業(yè)務(wù) pod 數(shù)量有多少,發(fā)布一次需要多少時間?
A1:這個只能透露數(shù)量目前大規(guī)模的單個應(yīng)用下數(shù)量是以萬為單位的,一次發(fā)布時間要看具體分批灰度的時長了。如果分批較多、觀察時間較長的話,可能是會持續(xù)一兩周的。
Q2:pod 的資源 request 和 limit 是怎么配置的?request 和 limit 是什么比例來配置?過多的 request 造成浪費,過少可能會導(dǎo)致熱點 node 負載超高。
A2:這個主要還是根據(jù)應(yīng)用的需求來定的,目前大部分在線應(yīng)用都是 1:1 的關(guān)系,部分離線和job 類型的會配置 request>limit。
Q3:kruise 升級問題,升級 kurise apiversion 版本的情況下,原有的版本的部署如何升級?
A3:目前 kruise 中資源的 apiVersion 還都是統(tǒng)一的。我們計劃在今年下半年將部分較為成熟的 workload 進行版本升級,用戶在自己的 K8s 集群內(nèi)升級后,存量的舊版本資源會自動通過 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:阿里集團內(nèi)部使用 Kube-On-Kube 的架構(gòu)進行大規(guī)模的 Kubernetes 集群管理,用一個元 K8s 集群管理成百上千個業(yè)務(wù) K8s 集群。其中元集群版本較為穩(wěn)定,業(yè)務(wù)集群會進行頻繁升級,業(yè)務(wù)集群的升級流程事實上就是對元集群中的 workloads(原生 workloads 以及 kruise workloads) 進行版本或配置升級,與正常情況我們對業(yè)務(wù) workloads 的升級流程相似。
Q6:這個灰度之后,流量是怎么切的?
A6:在原地升級前,kruise 會先通過 readinessGate 將 Pod 置為 not-ready,此時 endpoint 等控制器會感知到并把 Pod 從端點摘掉。然后 kruise 更新 pod image 觸發(fā)容器重建,完成后再把 Pod 改為 ready。
Q7:daemonset 的分批是通過類似 deployment 的暫停功能實現(xiàn)的么?統(tǒng)計已經(jīng)發(fā)布數(shù)量然后暫停,然后繼續(xù),然后再暫停。
A7:總體過程上類似,升級過程中對新舊版本進行統(tǒng)計并判斷是否已達到指定終態(tài)。但相比 deployment,daemonset 需要處理比較復(fù)雜的邊界情況(例如初次發(fā)布時集群中并沒有指定的 Pod),具體細節(jié)可以持續(xù)關(guān)注我們即將開源的代碼。
Q8:多集群的發(fā)布頁面上怎么開始發(fā)布的?
A8:直播中演示的是一個 demo 的發(fā)布系統(tǒng)結(jié)合 Kruise Workloads 的例子,從交互上是通過用戶選擇對應(yīng)的集群,點擊開始執(zhí)行進行發(fā)布;從實現(xiàn)上實際是對新版本的 YAML 與集群中的 YAML 計算 diff 后 Patch 進集群,再操作 DaemonSet 的控制字段(partition / paused 等),控制灰度進程。
“ 阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐,做最懂云原生開發(fā)者的公眾號。”