摘要：后面幾個(gè)狀態(tài)的字段都是，其中是節(jié)點(diǎn)上一個(gè)重要的模塊，負(fù)責(zé)維護(hù)和管理運(yùn)行于該節(jié)點(diǎn)上的所有容器，確保的運(yùn)行狀態(tài)與使用者期望一致。

上一篇文章?在Kubernetes上運(yùn)行SAP UI5應(yīng)用(上)，我介紹了如何在Docker里運(yùn)行一個(gè)簡(jiǎn)單的SAP UI5應(yīng)用，并且已經(jīng)成功地將一個(gè)包含了這個(gè)UI5應(yīng)用的docker鏡像上傳到Docker hub上。

這篇文章作為這個(gè)主題的下半部分，將會(huì)介紹如何在Kubernetes里運(yùn)行這個(gè)docker鏡像。

文章目錄

Kubernetes里的兩個(gè)重要概念：pod和deployment

Kubernetes保證應(yīng)用程序高可用性和伸縮性的一些體驗(yàn)

Kubernetes滾動(dòng)升級(jí)(Rolling Update)特性體驗(yàn)

在Kubernetes上運(yùn)行我們的應(yīng)用，有什么收益？根據(jù)Jerry這十多天有限的時(shí)間里對(duì)Kubernetes的學(xué)習(xí)，我的理解是，Kubernetes可以幫助應(yīng)用開(kāi)發(fā)人員確保其開(kāi)發(fā)出的應(yīng)用程序以一種高可用的、可伸縮和容錯(cuò)的方式進(jìn)行部署和運(yùn)行，應(yīng)用開(kāi)發(fā)人員無(wú)需花費(fèi)大量時(shí)間和精力去學(xué)習(xí)Kubernetes底層細(xì)節(jié)。

換句話說(shuō)，Kubernetes環(huán)境的搭建，系統(tǒng)的配置，可以全部交給Kubernetes的管理員，而應(yīng)用開(kāi)發(fā)人員作為Kubernetes的消費(fèi)者，只需要記住幾個(gè)簡(jiǎn)單的kubectl命令，就能夠輕松完成應(yīng)用程序到Kubernetes上的部署，幾乎不需付出額外的代價(jià)就能享受到Kubernetes作為一個(gè)平臺(tái)給應(yīng)用程序帶來(lái)的上述非功能性的提升。

我們繼續(xù)用前一篇文章使用到的UI5應(yīng)用進(jìn)行講解。

Jerry很窮，沒(méi)有錢(qián)購(gòu)買(mǎi)額外的服務(wù)器自己搭建Kubernetes集群環(huán)境。幸運(yùn)的是，Kubernetes并沒(méi)有拋棄我們這些貧窮的程序員，我們還可以選擇Kubernetes Clusters as a Service這種解決方案。

在我另一篇文章?站在巨人肩膀上的牛頓：Kubernetes和SAP Kyma?里我提到過(guò)Gardener, 一個(gè)開(kāi)源的創(chuàng)建Kubernetes集群的解決方案：

https://github.com/gardener

我在SAP內(nèi)部的Gardener上創(chuàng)建一個(gè)基于Google Cloud Platform的Kubernetes集群，取名jerry1204：

可以看到這個(gè)創(chuàng)建好的集群上的Kubernetes版本還是比較新的, 1.12.3僅僅低于12月3日剛剛發(fā)布的1.13版。

點(diǎn)擊上圖Access標(biāo)簽頁(yè)里的Dashboard(控制臺(tái))超鏈接，即可對(duì)這個(gè)Kubernetes集群進(jìn)行操作。當(dāng)然像SAP上海研究院Kubernetes培訓(xùn)課程上講課的那些老司機(jī)們更喜歡用命令行。

因?yàn)槭敲赓M(fèi)的集群，只分配了一個(gè)工作節(jié)點(diǎn)：

控制臺(tái)里看到的Kubernetes集群工作節(jié)點(diǎn)信息和命令行kubectl get node -o wide看到的一致：

Kubernetes里的兩個(gè)重要概念：pod和deployment

下面我們使用命令行來(lái)消費(fèi)我們前一篇文章上傳到Docker Hub上的鏡像i042416/ui5-nginx:

kubectl run jerry-ui5 --image=i042416/ui5-nginx

這個(gè)命令行背后發(fā)生了很多事情。

首先，運(yùn)行在Kubernetes上的應(yīng)用程序，其高可用性，可伸縮性和容錯(cuò)性到底是通過(guò)Kubernetes什么機(jī)制保證的？

答案是pod。請(qǐng)單擊上面Kubernetes的架構(gòu)圖，然后放大，能看到node(節(jié)點(diǎn))里包含了多個(gè)pod，每個(gè)pod里又包含了多個(gè)容器。像它的中文含義(豆莢，飛機(jī)，航天器或船只上可與主體分離的分離倉(cāng))暗示的一樣，pod就是應(yīng)用程序運(yùn)行的載體，是Kubernetes的基本操作單元。整套Kubernetes系統(tǒng)的設(shè)計(jì)都是圍繞著pod展開(kāi)，例如pod的部署和運(yùn)行，如何保證處于運(yùn)行狀態(tài)的pod總數(shù)量等于一個(gè)恒定值，如何將pod里應(yīng)用提供的服務(wù)暴露給外部訪問(wèn)等等。

回到我們之前的命令行，我們?cè)囍鴪?zhí)行另一個(gè)命令kubectl get pod，果然發(fā)現(xiàn)了一個(gè)pod被創(chuàng)建出來(lái)，誕生已經(jīng)40秒了(Age = 40s)。

用describe命令查看這個(gè)pod的明細(xì)：

kubectl describe pod jerry-ui5-6ffd46bb95-6bgpg

下圖Container ID后面的docker://說(shuō)明這是一個(gè)docker容器，當(dāng)然并不意味著Kubernetes只支持Docker這一種容器技術(shù)，比如Kubernetes還支持CoreOS的Rocket。

describe命名輸出的Events區(qū)域揭示了一個(gè)pod從誕生到開(kāi)始服役的生命周期狀態(tài)跳轉(zhuǎn)：

Scheduled->Pulling->Pulled->Created->Started

從每個(gè)狀態(tài)的from字段也能看出很多信息。

Scheduled狀態(tài)的from:?default-scheduler。Scheduler是Kubernetes的組件之一，負(fù)責(zé)調(diào)度pod到合適的節(jié)點(diǎn)上。具體什么樣的節(jié)點(diǎn)算合適，取決于Kubernetes Scheduler調(diào)度算法的實(shí)現(xiàn)，Jerry沒(méi)有研究過(guò)。如果把Scheduler看成一個(gè)黑匣子，那么它的輸入是pod和由多個(gè)節(jié)點(diǎn)組成的列表，輸出是Pod和一個(gè)匹配節(jié)點(diǎn)的綁定。這個(gè)狀態(tài)message顯示的內(nèi)容"Successfully assigned XXX to?shoot--jerrytest-jerry1204-worker-yamer-z1-XXX"后面這個(gè)shoot--jerrytest開(kāi)頭的字符串就是pod被分配到的節(jié)點(diǎn)的名稱。

后面幾個(gè)狀態(tài)的from字段都是kubelet,shoot--jerrytest-jerry1204-worker-yamer-z1-XXX，其中kubelet是Kubernetes節(jié)點(diǎn)上一個(gè)重要的模塊，負(fù)責(zé)維護(hù)和管理運(yùn)行于該節(jié)點(diǎn)上的所有容器，確保pod的運(yùn)行狀態(tài)與使用者期望一致。

在Kubernetes web控制臺(tái)里也一樣能看到這個(gè)處于運(yùn)行狀態(tài)的pod：

除了pod之外，Kubernetes第二個(gè)重要的概念就是deployment。

執(zhí)行另一個(gè)命令kubectl get deploy，發(fā)現(xiàn)kubectl run命令除了生成一個(gè)pod外，還生成了一個(gè)deployment。從這個(gè)命令輸出的Desired, Current和Up-to-Date, Available下面的數(shù)字，結(jié)合前面提到的Kubernetes里幾乎所有的設(shè)計(jì)都是圍繞著pod來(lái)展開(kāi)這一指導(dǎo)思想，我們不難猜測(cè)出，這個(gè)生成的deployment也是為pod服務(wù)的。

實(shí)際上，Kubernetes的初學(xué)者可以把deployment的主要職責(zé)理解成是保證pod的數(shù)量和健康。

在前面的文章里，我們已經(jīng)知道了怎樣使用docker run啟動(dòng)一個(gè)docker鏡像。然而在Kubernetes的世界里，我們不會(huì)直接和運(yùn)行在pod里的docker容器打交道，而是通過(guò)Kubernetes service將pod里的應(yīng)用提供的服務(wù)暴露給外界消費(fèi)。

到目前為止，Kubernetes集群上還沒(méi)有任何和應(yīng)用程序相關(guān)的service生成。命令kubectl get svc只返回了一個(gè)Kubernetes的標(biāo)準(zhǔn)服務(wù)。

因此我們使用命令kubectl expose基于剛剛使用kubectl run生成的deployment創(chuàng)建一個(gè)service：

kubectl expose deployment jerry-ui5 --type=LoadBalancer --port=80 --target-port=80

一旦expose命令執(zhí)行后，get svc命令這次就返回了一個(gè)和deployment同名的service，暴露給外界訪問(wèn)的IP地址為35.205.230.209:

于是，使用url?35.205.230.209/webapp就能訪問(wèn)運(yùn)行在Kubernetes pod里的SAP UI5了：

Kubernetes保證應(yīng)用程序高可用性和伸縮性的一些體驗(yàn)

到目前為止我們的SAP UI5應(yīng)用僅僅運(yùn)行在Kubernetes集群上的一個(gè)工作節(jié)點(diǎn)的單個(gè)pod里，還沒(méi)有感受到這個(gè)應(yīng)用運(yùn)行時(shí)的表現(xiàn)和之前運(yùn)行在Docker容器里有什么差異。

我們現(xiàn)在就來(lái)嘗試下Kubernetes deployment的水平擴(kuò)展功能。在Kubernetes操作臺(tái)里選中deployment，從菜單里執(zhí)行Scale命令，

設(shè)定新的pod的數(shù)量：下面截圖的3，意思是告訴這個(gè)deployment，在命令執(zhí)行完畢后，它必須要努力保證，在任何時(shí)候由它控制和監(jiān)控的pod個(gè)數(shù)必須等于3。

當(dāng)然這個(gè)控制臺(tái)上的圖形菜單在命令行里也存在對(duì)應(yīng)的命令，我們后面會(huì)用到。

上圖OK按鈕點(diǎn)擊后，再次執(zhí)行kubectl get pod, 能觀察到水平擴(kuò)展執(zhí)行之后，生成了兩個(gè)新的deployment，所以這次get pod命令總共返回了3個(gè)pod，其中后兩個(gè)pod從Age能看出是水平擴(kuò)展執(zhí)行之后剛剛創(chuàng)建的。

使用kubectl describe命令查看deployment的明細(xì)，在Replicas這個(gè)字段里看到這個(gè)deployment控制的pod的運(yùn)行時(shí)明細(xì)：

3 desired | 3 updated | 3 total | 3 available | 0 unavailable

我們現(xiàn)在故意用kubectl delete刪除一個(gè)pod，再次查看，發(fā)生一個(gè)新的pod瞬間就自動(dòng)生成了，處于運(yùn)行狀態(tài)的pod總數(shù)仍然為3。

Kubernetes滾動(dòng)升級(jí)(Rolling Update)特性體驗(yàn)

滾動(dòng)升級(jí)是Kubernetes一大特色，顧名思義，這是一種平滑過(guò)渡的升級(jí)方式，通過(guò)逐個(gè)容器替代升級(jí)的方式，來(lái)實(shí)現(xiàn)無(wú)中斷的服務(wù)升級(jí)。下圖deployment的describe命令的輸出，其中字段StrategyType字段表明kubectl run創(chuàng)建的deployment默認(rèn)的升級(jí)方式就是滾動(dòng)升級(jí)。

我設(shè)計(jì)了這樣一個(gè)簡(jiǎn)單的升級(jí)場(chǎng)景：我的SAP UI5應(yīng)用1.0版本同時(shí)運(yùn)行在一個(gè)Kubernetes節(jié)點(diǎn)的10個(gè)pod上。在整個(gè)應(yīng)用不中斷的前提下，通過(guò)滾動(dòng)升級(jí)的方式升級(jí)到2.0版本。

由于上一篇文章我上傳到Docker Hub上的鏡像的標(biāo)簽為默認(rèn)的latest，所以我需要在Docker Hub上分別制造兩個(gè)標(biāo)簽為v1.0和v2.0的鏡像。

下面的命令行推送一個(gè)標(biāo)簽為v1.0的鏡像到Docker Hub：

修改UI5應(yīng)用明細(xì)頁(yè)面的標(biāo)題，在文字后加上一個(gè)(v2.0), 用來(lái)表示這一版的應(yīng)用為2.0版本：

同樣將這個(gè)2.0版本的鏡像推送到Docker Hub上：

Docker Hub上兩個(gè)版本的鏡像都就緒了：

首先使用1.0版本的鏡像，啟動(dòng)單個(gè)pod去執(zhí)行SAP UI5應(yīng)用：

kubectl run jerry-ui5 --image=i042416/ui5-nginx:v1.0

使用scale命令將單個(gè)pod水平擴(kuò)展到10個(gè)pod：

kubectl scale --replicas=10 deployment/jerry-ui5

上圖看出kubectl get pod返回10個(gè)處于運(yùn)行狀態(tài)的pod。

使用下面的命令觸發(fā)滾動(dòng)升級(jí)，把名為jerry-ui5的deployent基于的鏡像從v1.0升級(jí)到v2.0:

kubectl set image deployment/jerry-ui5 i042416/ui5-nginx=i042416/ui5-nginx:v2.0

使用kubectl rollout status deployment/jerry-ui5查看滾動(dòng)升級(jí)的實(shí)時(shí)進(jìn)展情況。上圖顯示的日志表明，在某個(gè)時(shí)間點(diǎn)，有多少個(gè)舊版本的pod正等待被終止，有多少個(gè)新版本的pod已經(jīng)處于可用狀態(tài)。

X old replicas are pending termination

X of Y updated replicas are available

任意點(diǎn)開(kāi)一個(gè)pod查看明細(xì)，發(fā)現(xiàn)其使用的docker鏡像已經(jīng)是v2.0版本了：

最后在瀏覽器里看到訂單明細(xì)頁(yè)面的標(biāo)題，后面已經(jīng)出現(xiàn)(v2.0), 再次確認(rèn)了滾動(dòng)升級(jí)已經(jīng)成功結(jié)束了。

本文介紹的只是Kubernetes特性的冰山一角，更多細(xì)節(jié)，有待我們?nèi)W(xué)習(xí)，畢竟SAP云平臺(tái)即將支持Kubernetes環(huán)境了。感謝閱讀。

要獲取更多Jerry的原創(chuàng)文章，請(qǐng)關(guān)注公眾號(hào)"汪子熙":