作者 | 酒祝 阿里云技術(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ā)布能力。
阿里巴巴容器化道路的起步在國內(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ī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)難”。
針對(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ā)布策略。
CloneSet、Advanced StatefulSet 均支持指定 Pod 升級(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í)在太多了:
后續(xù)我們將會(huì)有專文講解阿里在 Kubernetes 之上做的原地升級(jí),意義非常重大。如果沒有了原地升級(jí),阿里巴巴內(nèi)部超大規(guī)模的應(yīng)用場景幾乎是無法在原生 Kubernetes 環(huán)境上完美落地的,我們也鼓勵(lì)每一位 Kubernetes 用戶都應(yīng)該“體驗(yàn)”一下原地升級(jí),它給我們帶來了不同于 Kubernetes 傳統(tǒng)發(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ā)布后:
如果我們接下來把 partition 調(diào)整為 0,則 CloneSet 還是會(huì)先擴(kuò)出 1 個(gè)額外的新版 Pod,隨后逐漸將所有 Pod 升級(jí)到新版,最終再次刪除一個(gè) Pod,達(dá)到 5 個(gè)副本全量升級(jí)的終態(tài)。
對(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ā)布打散策略來定義順序:
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é)會(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ù)。
輕量化容器也是阿里巴巴在云原生階段的一次重大改革,過去阿里的容器絕大多數(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,但這樣帶來的問題很多:
因此,我們?cè)O(shè)計(jì)了 SidecarSet,將 sidecar 容器的定義與應(yīng)用 workload 解耦。應(yīng)用開發(fā)者們不再需要再關(guān)心自己的 workload 中需要寫哪些 sidecar 容器,而通過原地升級(jí), sidecar 維護(hù)者們也可以自主地管理和升級(jí) sidecar 容器。
到了這里,大家是不是對(duì)阿里巴巴的應(yīng)用部署模式有了一個(gè)基本的了解呢?其實(shí)上述的能力都已經(jīng)開源到了社區(qū),我們的項(xiàng)目就叫做 OpenKruise,目前它已經(jīng)提供了 5 種擴(kuò)展 workload:
此外,我們還有更多的擴(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)用場景!
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>
新聞標(biāo)題:如何為云原生應(yīng)用帶來穩(wěn)定高效的部署能力?
標(biāo)題網(wǎng)址:http://jinyejixie.com/article2/podjic.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供響應(yīng)式網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站改版、用戶體驗(yàn)、網(wǎng)站維護(hù)、域名注冊(cè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)