轉(zhuǎn)載:基于 Kubernetes 實踐彈性的 CI/CD 系統(tǒng)

大家好,我是來自阿里云容器服務(wù)團隊的華相。首先簡單解釋一下何為 Kubernetes 來幫助大家理解坪仇。Kuberentes 是一個生產(chǎn)可用的容器編排系統(tǒng)杂腰。Kuberentes 一方面在集群中把所有 Node 資源做一個資源池，然后它調(diào)度的單元是 Pod烟很，當(dāng)然 Pod 里面可以有多個容器颈墅。 就像一個人左手抓著 ECS 資源或計算資源蜡镶，右手抓容器雾袱，然后把它們兩個匹配起來，這樣它就可以作為一個容器的編排系統(tǒng)官还。

而?Cloudnative 這個概念現(xiàn)在會經(jīng)常被大家提起芹橡，很多人迷惑 Cloudnative 又與 Kuberentes 有什么關(guān)聯(lián)？我們又該如何判斷一個應(yīng)用是 Cloudnative 呢望伦？我認(rèn)為有以下三個判斷標(biāo)準(zhǔn)：

第一林说，它能夠給資源做池化；

第二屯伞，應(yīng)用可以快速接入池的網(wǎng)絡(luò)腿箩。在 Kuberentes 里面有一層自己的獨立網(wǎng)絡(luò)，然后只需要知道我要去訪問哪個服務(wù)名就可以劣摇，就是各種服務(wù)發(fā)現(xiàn)的一些功能珠移，它可以通過 service mesh 去做一個快速地訪問；

第三是有故障轉(zhuǎn)移功能，如果一個池子里面有一臺主機钧惧，或者某一個節(jié)點 down 掉了暇韧，然后整個應(yīng)用就不可用了，這肯定不算是 Cloudnative 的應(yīng)用浓瞪。

比較這三點就可以發(fā)現(xiàn) Kuberentes 做的非常好懈玻。首先我們看一個資源池的概念，Kuberentes 一個大的集群就是一個資源池乾颁，我們再也不用去關(guān)心說我這個應(yīng)用要跑在哪臺主機上了涂乌，我只要把我們部署的 yaml 文件往 Kuberentes 上發(fā)布就可以了，它會自動做這些調(diào)度英岭，并且它可以快速地接入我們整個應(yīng)用的網(wǎng)絡(luò)骂倘，然后故障轉(zhuǎn)移也是自動。接下來我就來分享如何基于 Kuberentes 實現(xiàn)一個彈性的 CI/CD 系統(tǒng)巴席。

CI/CD 的現(xiàn)狀

首先了解一下 CI/CD 的現(xiàn)狀历涝。CI/CD 這個概念實際上已經(jīng)提出很多年了，但是隨著技術(shù)地演進和新工具地不斷推出漾唉，它在整個流程和實現(xiàn)方式上逐漸豐富荧库。而我們通常最早接觸 CI/CD 就是代碼提交，隨之觸發(fā)一個事件赵刑，然后在某個 CI/CD 系統(tǒng)上做自動構(gòu)建分衫。

下圖可以反映目前 CI/CD 的現(xiàn)狀：

它中間包含了很多流程，從代碼提交開始觸發(fā)一個事件般此，然后它可以中間做一層 Build 蚪战，首先通 maven 做一個 build，然后做一個單元測試铐懊，然后做代碼規(guī)范掃描邀桑，然后部署。 接下來科乎，做一個端到端的 UI 方面的一層測試壁畸，這是一個 UI 的自動測試工具。

然后做了一個壓測（性能上的壓測）茅茂，這只是在開發(fā)測試環(huán)境做了一層處理捏萍。然后它可以在 QA 環(huán)境，最終延伸到 UAT 環(huán)境空闲，整個 pipeline 是一個非常長的過程令杈。CI/CD 的使用范圍很廣，它可以把整個 IT 從代碼編寫提交到代碼倉庫為起點碴倾，從這兒開始往后做逗噩，各個步驟都可以納入 CI/CD 的范圍悔常。但是隨著它的管控范圍越來越多，整個流程越來越復(fù)雜给赞，它對資源的占用也是越來越高机打。

大家如果了解 C++的話，就會知道 C++ 以前是一門著名的片迅、構(gòu)建時間特別長的語言残邀。Go 語言的作者之一，也是 C 語言的作者, 談及當(dāng)時寫 Go 完全是因為不想寫一次代碼柑蛇，編譯那么久芥挣。所以，Go 語言剛出現(xiàn)時的一大優(yōu)勢就是編譯時間非常短耻台。Go 的編譯時間確實非常短空免。

我曾用一個 I5 的筆記本編譯 Kubernetes 源碼做一次完整地構(gòu)建，大概編譯了 45 分鐘左右盆耽，這是一個非常漫長的過程蹋砚。所以，即便已經(jīng)對編譯過程做了很大優(yōu)化和改進摄杂，只要項目大了之后坝咐，只是構(gòu)建階段就已經(jīng)很長了，更不要說包括后面的一些自動化測試了析恢。包括所有東西之后墨坚，CI/CD 流程對資源地消耗和占用的時間是非常大的。

CI/CD 工具的選擇

接下來映挂，我們看一下 CI/CD 這些工具的選擇和他們的發(fā)展泽篮。首先最老牌的肯定是 Jenkins。實際上在容器技術(shù)興起之前柑船，CI/CD 簡直約等于 Jenkins帽撑。但是在出現(xiàn)容器技術(shù)之后，很多新生 CI/CD 的工具也應(yīng)運而生椎组，比如 Drone 工具油狂，它是一個完全基于容器來實現(xiàn)的 CI/CD 工具。它與容器地結(jié)合地非常好寸癌，并且它的構(gòu)建過程是完全在容器中實現(xiàn)的。

另外還有 Gitlab CI弱贼，它主要特點是與 Gitlab 代碼管理工具結(jié)合地比較好蒸苇。Jenkins 2.0 開始引入 pipeline as code 特性，pipeline as code 可以幫我們自動生成一個 jenkins file吮旅。

在 Jenkins 1.0 時溪烤，如果我們想要配置一條流水線味咳，需要先登錄 Jenkins 建一個項目，然后在里面寫一些 shell檬嘀。這樣雖然能達到同樣的效果槽驶，但是它有一個最大的弊端，就是可復(fù)制性和遷移性不好鸳兽。而且它與 Devops 有天然地割裂掂铐，比如一般是由運維人員來管理 Jenkins 系統(tǒng)，開發(fā)人員編寫代碼揍异，但是這個代碼怎么去構(gòu)建全陨，發(fā)布到哪里，開發(fā)人員完全不知道衷掷。這就造成了開發(fā)和運維地割裂辱姨。但 pipeline as code 方式出現(xiàn)了之后，jenkins file 與代碼源碼可以放在同樣的倉庫里面戚嗅。

首先它有一個非常大的好處是發(fā)布的流程也可以納入版本管理雨涛，這樣對一個錯誤就可追溯。這是一個非常大地改動，但是實際上我們在與客戶溝通中發(fā)現(xiàn)竞阐，雖然很多人在 Jenkins 上都已經(jīng)升到 2.0 系列了喘沿，但是它們的用法還是完全在 1.0 系列，很多用戶都沒有把 jenkins file 這種方式用起來侣肄。另外一個就是對容器地支持，大概 2016 年左右醇份，那時對容器的支持是非常弱的稼锅，在容器里面運行 Jenkins，同時構(gòu)建的產(chǎn)物也是 Docker 會非常麻煩僚纷。

但是矩距， Drone 對容器的支持力度就非常好怖竭。首先它完全用 Docker 方式來運行，就是說你的構(gòu)建環(huán)境也在一個容器里痊臭，你需要構(gòu)建一個 Docker build 鏡像，然后在推送出去的時候允趟，它也在容器里面運行，然后它需要一個 privilege 權(quán)限潮剪。它這種方式有幾個特別好的地方涣楷，首先它不會對宿主機產(chǎn)生任何殘留狮斗，比如說你這個容器一銷毀，構(gòu)建中產(chǎn)生的一些中間文件完全都跟著銷毀了碳褒，但是你如果用 Jenkins 的話，隨著用的時間越來越久會沉淀出很多臨時文件骤视，它占的空間會越來越大。你需要定期做一些清理专酗，而且清理過程中你又不能直接一鍵清空，所以這是很麻煩的過程祷肯。

然后插件的管理 Jenkins 還有一個特別讓人頭疼的地方，就是它的插件升級疗隶。首先你在 Jenkins 登錄進去佑笋，然后就做插件升級。如果說我想臨時在一個新的環(huán)境里面斑鼻，起一個 Jenkins 先測試一下或做一些調(diào)試可能每新建一個環(huán)境蒋纬，都需要把這些插件升級一次。而且剛才我們說的在 Jenkins 里面做的所有配置坚弱，也都需要重新配置一遍蜀备，這是一個非常繁瑣的一個過程。

但是 Drone 這個工具它有一個特別好的地方荒叶，就是所有的插件都是 Docker 容器碾阁，比如說你在 pipeline 里用這個插件，你只要聲明用這個插件就可以了些楣，你不用去自己管理把插件下載到哪里脂凶，然后怎么安裝，它這個一切都是全自動愁茁，只要說你網(wǎng)絡(luò)能把插件容器鏡像訪問到就可以了蚕钦，這非常便利。

然后關(guān)于生態(tài)的構(gòu)建埋市，Jenkins 的最大的優(yōu)勢就是它的插件非常多冠桃，就是你想用的各種東西都有，而且它基礎(chǔ)的底座非常好道宅，你的插件可以實現(xiàn)的能力非常的強食听。比如說 pipeline 就是這種方式，它從 1.0 到 2.0 雖然有了污茵，但是它完全是通過插件來實現(xiàn)的樱报。但是現(xiàn)在 Jenkins 的發(fā)展又開始有點第二春的感覺。他開始對 Kuberentes 的支持力度明顯的加大了很多泞当，首先從 JenkinsX 開始迹蛤，它融合了一些 Kuberentes 生態(tài)相關(guān)的一些工具，比如 Harbor襟士、Helm 它可以非常便利地在 Kuberentes 集群上來做一些構(gòu)建盗飒，并且把一些做服務(wù)的固化的一些編排文件放到 Helm 里面。

另外陋桂，現(xiàn)在它有一個新的子項目叫 config as code逆趣，也就是說他把所有 Jenkin 里面做了一些配置宣渗，都可以輸出成一個 code 的形式痕囱，就是對整個 Jenkins 的遷移暴匠，或者說復(fù)制都是一個很便利的改進每窖。

講了那么多岛请，實際上最后我們選擇的東西還是 Jenkins，因為最重要的是生態(tài)的構(gòu)建盅称，他們已經(jīng)很好了缩膝。今天我們要講的在做一個彈性在 CI/CD 這個 Jenkins 上已經(jīng)有這個插件了疾层，但是在 Drone 的社區(qū)里面痛黎，有人提這個事，但是現(xiàn)在還沒有看到掖蛤。

CI/CD 的系統(tǒng)業(yè)務(wù)場景

然后我們看一下 CI/CD 它的系統(tǒng)的業(yè)務(wù)場景蚓庭，它有一個比較典型的場景與特點仅仆，首先它面向開發(fā)人員墓拜，這是比較少見的撮弧，因為開發(fā)人員一般都比較挑剔一點。所以你要是這個系統(tǒng)做的不夠穩(wěn)健了授舟，或者說響應(yīng)時間比較長一點的話释树，會被經(jīng)常吐槽奢啥。

然后就是有時效性要求桩盲，因為我們代碼寫完之后赌结，往上提交柬姚，我們都不希望在這個代碼的構(gòu)建中一直排隊庄涡，我們希望馬上就開始進行構(gòu)建，并且資源足夠豐富拿穴。另外一個就是它的資源占用的波峰波谷是非常明顯的贞言。就因為開發(fā)人員不可能時時刻刻都在提交代碼阀蒂，有的人可能一天提交幾次蚤霞，有的人會提交很多次昧绣。

因為我之前看過有一個分享夜畴，有一個人畫了一條反映自家公司構(gòu)建任務(wù)的曲線贪绘。他們公司大概是每天下午三央碟、四點的時候代碼提交量最高亿虽，其他時間都比較平緩洛勉。這說明他們公司三、四點的時候攻走，程序員提交代碼開始劃水了陋气。然后隨著 CI/CD 資源地需求越來越高巩趁，構(gòu)建集群是一個必須要做的一件事情议慰。就是提高負(fù)載能力，縮短任務(wù)的排隊時間草讶。當(dāng)然真正的集群有一個讓人覺得很不太好的地方堕战，就是它的 Master 實際上只有一個嘱丢，當(dāng)然這個也可以通過插件來做改進越驻。

但這不是今天我們要講的重點缀旁，因為很多時候 Master 短暫的不可用勺鸦，然后能快速恢復(fù)也是可以接受的祝旷。然后另外它需要來滿足各種構(gòu)建場景怀跛。一個公司里面可能用到很多的開發(fā)環(huán)境，就像雖然我們都用 Java忠蝗，但可能會有 1.5阁最、1.6速种、1.7 的差別配阵。 如果不用 Java，很可能用很多其他語言如 Python救拉、Go亿絮、NodeJS 等需要很多的構(gòu)建環(huán)境派昧。而且如果我們不引入容器的話斗锭，這些構(gòu)建環(huán)境不能重用失球，可能一臺主機只能給 PHP 在用实苞。

容器可以給我們 CI/CD 系統(tǒng)來注入新的能力黔牵，就是環(huán)境隔離的能力猾浦。我們可以通過 Kubernetes 來為 CI/CD 系統(tǒng)注入更多的能力金赦，然后矛盾點就出現(xiàn)了夹抗。開發(fā)人員總是希望 CI/CD 系統(tǒng)能夠快速地響應(yīng)代碼提交的一個事件漠烧，但是每個公司資源都不可能是無限的靡砌。因為就像上面提到的通殃，如果每天下午三、四點的時候是一個代碼提交的高峰媳瞪，這個時候可能需要 30 或 40 臺機器才能滿足構(gòu)建的任務(wù)蛇受。但是我不可能每天就開著 30 或 40 臺機器在這里厕鹃，就為了每天下午三剂碴、四點忆矛，可能會構(gòu)建一、兩個小時洽议。

Kubernetes 可以為 jenkins 注入新的能力亚兄，讓 CI/CD 系統(tǒng)實現(xiàn)彈性的能力审胚。我們期望的目標(biāo)是什么呢膳叨？有構(gòu)建任務(wù)的時候各淀，可以自動為我們資源增加新的機器也好碎浇，或增加新的運計算能力也好奴璃，反正就是當(dāng)我需要的時候苟穆，可以幫我自動地做一個資源擴張唱星，但是同時也在我不需要的時候间聊，可以自動把這些資源釋放掉哎榴。

我們期望的目標(biāo)就是這樣尚蝌，Kuberentes 就可以為 Jenkins 來做這樣的能力飘言。Kuberentes 作為一個容器編排的系統(tǒng)姿鸿，它所能提供的能力泪电，它可以快速地彈出一些新的實例相速，并且把它們自動調(diào)度到空閑的機器上突诬，做一個資源池旺隙，在資源池里面做一個調(diào)度蔬捷，并且他執(zhí)行完任務(wù)之后周拐，它可以做一個回收妥粟。而且如果把這 Jenkins Master 也部署在 Kuberentes 之上吏够，它可以對 Master 做一個故障轉(zhuǎn)移，就是說如果我們系統(tǒng)可以容忍的話脓钾，Master 就算掛了桩警，我可以快速把它調(diào)到另外一臺機器上生真，這個響應(yīng)時間不會很長柱蟀。

Kubernetes-piugin

這里面也是用一個插件來實現(xiàn)长已，這個插件名字比較直接叫 Kuberentes-plugin术瓮，它這個插件所能提供的能力就是說，他直接管理一個 Kuberentes 集群恬汁，它在 Jenkins 里面安裝之后辜伟，它可以監(jiān)聽 Jenkins 的構(gòu)建任務(wù)导狡。有構(gòu)建任務(wù)，在等待資源的時候独郎，它就可以向 Kuberenetes 去申請一個新的資源氓癌，申請一個新的 Pod 去做自動地構(gòu)建完之后标锄，它就會自動的清理料皇。

先簡單介紹一下它的能力，因為這個插件安裝完之后鬼譬，它對 pipeline 的語法也有一個改造,一會我們來看一下實例优质。但是就算到了這一步，還是不行的演怎。首先爷耀，Kuberentes 的集群規(guī)劃還是一個問題拍皮。比說我有個集群有 30 個節(jié)點铆帽，真正的 master 部署在這上面爹橱，然后裝了那些插件，做了一個管理之后屑迂，我們可以發(fā)現(xiàn)來了一個新的任務(wù)，它就起一個新的 Pod，把這個構(gòu)建任務(wù)給執(zhí)行制定完惫确。

執(zhí)行完之后改化，這 Pod 自動銷毀不占集群的資源枉昏。 平時我們可以在這集群上做一些別的任務(wù)兄裂，但這個終究還是有一點不好，就是我們這個集群到底規(guī)劃多大谈撒，并且這個集群我們平時不做構(gòu)建任務(wù)的時候啃匿，可以在上面做一些別的任務(wù)。但是如果正在做任務(wù)夹厌，突然來了一些構(gòu)建任務(wù)矛纹，它可能會出現(xiàn)資源的沖突問題崖技。

Kubernetes Autoscaler

總的來說迎献，還是有一些不完美的地方腻贰，那么我們可以利用 Kuberentes 一些比較沒那么常見的特性，來解決我們剛才說的這個問題冀瓦。這兩個東西一個是叫 Autoscaler翼闽，一個叫 Virtual node感局。我們先看一下 Autoscaler询微，Autoscaler 是一個 Kubernetes 官方的一個組件狂巢。在 Kuberentes 的 group 下面支持三種能力:

Cluster Autoscaler唧领，可以對集群節(jié)點做自動伸縮；

Vertical Pod Autoscaler西雀，對集群的 Pod 豎直方向的資源伸縮歉摧。因為 Kuberentes 本身里面就帶著 HPA 可以做水平方向的 Pod 伸縮再悼、節(jié)點數(shù)量的伸縮膝但；這個特性還不是生產(chǎn)可用的特性跟束；

Addone Resizer冀宴，是 Kuberentes 上那些 addone 比如說 Ingress Controler甚疟、 DNS 可以根據(jù) Node 的數(shù)量來對資源的分配做調(diào)整逃延。

Cluster autoscaler

我要講的是 Cluster autoscaler揽祥，是對集群 node 節(jié)點數(shù)量做一個擴縮容拄丰。 首先我們看一下愈案，這個是在阿里云我們?nèi)萜鞣?wù)上所實現(xiàn)的 Autoscaler 的一個方式站绪。我們看一下這個圖恢准，這個是 HPA 和 Autoscler 做結(jié)合使用的一個場景馁筐。

HPA 監(jiān)聽監(jiān)控的事件時發(fā)現(xiàn)資源使用率上升到一定程度了之后，HPA 會自動通知 workload果正，來彈出一個新的 Pod秋泳，彈出一個新的 Pod迫皱，可能這時候集群資源就已經(jīng)不夠了，所以這個 Pod 可能就會 pending 在這里凹炸。它就會觸發(fā) Autoscaler 的事件饲握，Autoscaler 就會根據(jù)我們之前配置好的 ESS 這個模板來去彈出來一臺新的 Node救欧，然后自動地把 Node 加入到我們集群里面笆怠。 它是利用了 ESS 定制的模板功能，并且它可以支持多種的 Node 實例的類型誊爹，可以支持普通實例蹬刷，支持 gpu，還有搶占式實例频丘。

Virtual node

然后第二種是 Virtual node办成，Virtual node 實現(xiàn)方式是基于微軟開源的 Virtual Kubelet 這個項目。它做了一個虛擬的 Kubelet搂漠，然后向 Kubernetes 集群里面去注冊上面迂卢。但如果不太好理解的話，可以想象一下 MySQL proxy ，然后他把自己偽裝成一個MySQL server而克，然后后端可能管理著非常多的 MySQL server靶壮，并且它可以幫你自動的做一些 SQL 查詢的路由或者拼接。

Virtual kubelet 做的也是類似的工作，就是說它本身向著 Kubernetes 注冊說我是一個節(jié)點映穗，但實際上它后端管理的可能是整個公有云上的非常多的資源赘淮，他可能對接公有云的一些 ECI 或者說對接的這些 VPC，這是一個它的大體的示意圖。

在阿里云上他們對接的是阿里云的 ECI 做一個彈性的容器實例，它響應(yīng)時間就非常快诀浪，因為它不需要把 Node 去加入到集群里面春宣，它是大概能夠到一分鐘一百個 Pod 左右這種性能幽污。而且我們可以在 Pod 上聲明這種資源的使用情況，這是一個非常快的響應(yīng)速度時間。

然后剛才說我們利用這兩種方式，就可以對我們 CI/CD 彈性的系統(tǒng)做出新的改造，我們不用非常早規(guī)劃好我們集群的規(guī)模家坎，我們可以讓集群規(guī)模在需要的時候自動的做一些伸縮的動作憔涉。但是你做了這些動作之后，我們做了這些把真正的放在容器里面的這些動作之后，引入了一些新的門檻：docker-outside-of-docker 和 docker in docker。

我們在 Docker 中運行 Jenkins 時，通常有兩種方式，一個是把宿主機的 docker.sock 掛載到容器里面，讓 Jenkins 通過這個文件來和本機的 docker daemon 做一個通信，然后它在這里面做 docker build 構(gòu)建鏡像，或者把這些鏡像 push 到遠程的倉庫里面，所以它中間產(chǎn)生的所有鏡像都會堆積在本機上魔熏，這是一個問題。

在一些 serverless 的那些場景上使用相赁，它就會有一些限制绵脯，因為 serverless 本身就不允許把 socket 文件給掛在進去。另外一個就是 docker in docker 這種方式，它的優(yōu)點就在于在容器里面它啟動一個新的 Docker daemon毡咏，它所有的中間產(chǎn)物、構(gòu)建產(chǎn)物隨著容器都一起銷毀片仿，但是它有問題，它就是需要 privilege 的權(quán)限咖熟。

很多時候我們是盡量不要用它堪置。另外一個就是說你做 docker build 的時候能在宿主機上做的時候雷激，它如果有已經(jīng)有鏡像了，它會直接就使用這個鏡像矿卑，但是你用 docker in docker 這種方式來使用的，它每次都會重新拉進項勤讽，拉鏡像也是需要一定時間君纫，這個取決于我們各個使用場景來判斷肢执。

新的構(gòu)建工具——Kaniko

這時又引入了一個谷歌開源的新工具——Kaniko假夺。它做的東西是 docker in docker 的方式讳癌。它有一個非常大的好處就是不依賴 Docker疤孕，而且所以它不需要 privilege 權(quán)限就可以在容器里面用用戶態(tài)的模式，來完全構(gòu)建 docker image颖系。用戶態(tài)執(zhí)行 Dockerfile 的命令不傅，它把這個鏡像完全構(gòu)建出來。

這算是一個比較期望的彈性的 CI/CD 系統(tǒng)疫向。然后這個時候就是說從真正的節(jié)點到底層的計算資源全部是彈性擴縮的囊嘉，而且滿足交付的需求博其，可以非常精細(xì)化地管理我們的資源携兵。

Demo 演示

然后我們可以看一下 Demo 演示：

https://github.com/hymian/webdemo?這里是我準(zhǔn)備好的一個例子，重點在這個 Jenkinsfile 文件钠署，里面定義了agent 的 pod template草戈，包含兩個容器揽思，一個用來做 golang 的 build肪凛，一個用來做 image 的 build。

然后我們現(xiàn)在構(gòu)建它拱烁。開始構(gòu)建了，剛開始的，因為是現(xiàn)在我們在這環(huán)境里面只有一個阅懦，只有一個 master，所以他就是沒有不會有構(gòu)建節(jié)點兆蕉。大家可以看到亡电，它現(xiàn)在新啟動了一個 Pod方咆，這個 Pod 是作為節(jié)點加進來的月腋，但是因為我在這個 Pod 模板里面定義了一個 label，所以它沒有這個節(jié)點，所以它 Pod 狀態(tài)是 pending 的榆骚。所以我們在構(gòu)建日志里面顯示的這個是 agent 節(jié)點是離線的片拍。

但是我們在這個集群里面定義了一個彈性伸縮的一個東西，當(dāng)沒有節(jié)點的時候妓肢，它會自動做一個新節(jié)點分配加入捌省，可以看到有一個節(jié)點正在加入，這個我就可以稍等一下碉钠。就是說這段時間可能會有個一分鐘兩分鐘的時間纲缓。

節(jié)點不夠的時候，它可以自動擴容然后加入集群喊废，這個要稍微等一下祝高。因為這個時間會稍微久一點，是因為首先它觸發(fā)到我這個擴容污筷，它有一個輪詢的時間差工闺。整個過程下來可能有三分鐘左右。我看一下我這個服務(wù)器颓屑，這個服務(wù)器剛才是三個斤寂，現(xiàn)在這個服務(wù)器是剛剛加入了，這是搶占揪惦，這是我剛剛加入的一個東西遍搞。

這個是異常，是因為這個節(jié)點正在向集群加入器腋，所以它顯示是異常溪猿，這是我們從命令行看一下，好纫塌，已經(jīng)是四個節(jié)點了诊县，加了一個節(jié)點，這時候我們看 Pod措左，這時候在 agent 正在創(chuàng)建依痊，這時候大家可能有一個小的細(xì)節(jié)，大家可以看一下怎披，就是 0/3 是顯示 Pod胸嘁，它有三個容器，但是我剛才在這個里面定義的凉逛，它實際上是 Pod 里面只有兩個容器性宏，這就是我們剛才 PPT 上寫的一個地方。

JNLP 那個容器状飞，是 plugin 自動注入的一個容器毫胜，它通過這個容器實時的向 master 匯報構(gòu)建的一個中間的狀態(tài)书斜，我把它的日志給發(fā)送出去。這個是 agent 的節(jié)點在初始化的一個過程一個事情這時候 slave節(jié)點已經(jīng)在運行了酵使。我這邊已經(jīng)輸出完了荐吉，構(gòu)建完成。我的分享內(nèi)容就這些凝化，謝謝大家稍坯。