筆者在前邊的兩篇文章中皱蹦，詳細(xì)介紹了在Kubernetes平臺調(diào)度的基本單位是POD，并且我們也介紹了Deployment這個對象，通過Deployment對象來部署應(yīng)用述暂，并且我們還可以通過scale這樣的命令來非常方便的擴(kuò)容，可以說Kubernetes為我們運(yùn)維需要提供高并發(fā)流量的互聯(lián)網(wǎng)應(yīng)用建炫，提供了完善的平臺畦韭。

但是，不知道你有沒有想過肛跌，既然有了容器艺配，鏡像察郁，Kubernetes為什么還需要再抽象一個POD這樣的對象出來呢？或者換個角度來看转唉，POD給部署在Kubernetes平臺上的應(yīng)用帶來了具體哪些好處皮钠？我們是否可以在Kubernetes上不使用POD來部署應(yīng)用，筆者希望通過今天這篇文章赠法，來把這幾個問題給講清楚鳞芙。

我們在《云計算時代操作系統(tǒng)Kubernetes之Pod（上）》這篇文章中將容器進(jìn)程和虛擬機(jī)中的進(jìn)程進(jìn)行了對比，如果對這部分內(nèi)容不是很清楚的的讀者期虾，請回去再仔細(xì)看看原朝。容器本質(zhì)上就是操作系統(tǒng)上一個特殊的進(jìn)程，這個特殊性主要體現(xiàn)在：容器進(jìn)程通過設(shè)置不同命名空間（Linux操作系統(tǒng)有7種）镶苞，以及利用內(nèi)核的Cgroup和鏡像提供的文件系統(tǒng)喳坠，讓容器進(jìn)程認(rèn)為自己是運(yùn)行在宿主機(jī)上的唯一的進(jìn)程。

因此容器本質(zhì)上就是進(jìn)程茂蚓，而容器運(yùn)行的應(yīng)用程序就來自于我們提供的鏡像壕鹉，而Kubernetes扮演的角色就類似于操作系統(tǒng)，我們通過kubectl create等命令提交給Kubernetes集群的應(yīng)用程序任務(wù)聋涨，就雷雨我們在Windows操作系統(tǒng)上雙擊可執(zhí)行文件exe晾浴，操作系統(tǒng)會給啟動的exe文件創(chuàng)建對應(yīng)的進(jìn)程，以及分配系統(tǒng)資源牍白，并啟動應(yīng)用開始執(zhí)行脊凰。從這個角度來看，Kubernetes其實(shí)就是未來企業(yè)數(shù)字化應(yīng)用部署和運(yùn)維的企業(yè)級虛擬化應(yīng)用程序部署和管理的操作系統(tǒng)茂腥。

而隨著多核技術(shù)的發(fā)展狸涌，以及超線程機(jī)制，我們的應(yīng)用程序運(yùn)行起來后最岗，為了提高運(yùn)行的效率以及資源的使用率帕胆，通常會創(chuàng)建多個線程，這是高并發(fā)服務(wù)端應(yīng)用程序的架構(gòu)設(shè)計的核心般渡，因此我們可以看到進(jìn)程或者線程從來都不是單兵作戰(zhàn)（線程可以看成是一個輕量級的進(jìn)程懒豹，另外在Golang等語言中還有協(xié)程的概念，）驯用，多個線程相互協(xié)作脸秽，工作完成應(yīng)用的請求處理。而對于用戶來說晨汹，如果我們要在Kubernetes平臺上部署應(yīng)用程序豹储，需要有對應(yīng)的抽象，這樣才能順利將我們的應(yīng)用程序遷移到Kubernetes平臺上淘这。

注意：我們知道操作系統(tǒng)在線程等待IO的時候剥扣，會阻塞當(dāng)前線程巩剖，切換到其它線程，這樣在當(dāng)前線程等待IO的過程中钠怯，其它線程可以繼續(xù)執(zhí)行佳魔。當(dāng)系統(tǒng)線程較少的時候沒有什么問題，但是當(dāng)線程數(shù)量非常多的時候晦炊，卻產(chǎn)生了問題鞠鲜。一是系統(tǒng)線程會占用非常多的內(nèi)存空間，二是過多的線程切換會占用大量的系統(tǒng)時間断国。而協(xié)程的出現(xiàn)就是為了解決上述2個問題贤姆。協(xié)程運(yùn)行在線程之上，當(dāng)一個協(xié)程執(zhí)行完成后稳衬，可以選擇主動讓出霞捡，讓另一個協(xié)程運(yùn)行在當(dāng)前線程之上。協(xié)程并沒有增加線程數(shù)量薄疚，只是在線程的基礎(chǔ)之上通過分時復(fù)用的方式運(yùn)行多個協(xié)程碧信，而且協(xié)程的切換在用戶態(tài)完成，切換的代價比線程從用戶態(tài)到內(nèi)核態(tài)的代價小很多街夭。

我們在介紹容器的時候砰碴，特別強(qiáng)調(diào)了容器的單進(jìn)程模型，而單進(jìn)程本質(zhì)上不是說容器中只能運(yùn)行一個進(jìn)程板丽，而是說容器中PID=1的進(jìn)程呈枉，也就是我們在容器中啟動的應(yīng)用程序，不具備管理進(jìn)程的能力檐什。這句話看著還是暈啊碴卧，你可以想一下，Linux操作系統(tǒng)在誕生支持乃正，大概是V0.11版本的時候，才實(shí)現(xiàn)了進(jìn)程并發(fā)婶博，進(jìn)程并發(fā)有個核心的功能是進(jìn)程管理瓮具，我們需要管理進(jìn)程運(yùn)行過程中fork的子進(jìn)程，以及協(xié)調(diào)主進(jìn)程和子進(jìn)程的資源使用凡人，狀態(tài)同步等名党，操作系統(tǒng)實(shí)現(xiàn)了一套復(fù)雜的進(jìn)程或者線程管理機(jī)制，因此我們才能在Linux操作系統(tǒng)上啟動多任務(wù)挠轴，但是很明顯咱自己寫的SpringCloud應(yīng)用并沒有這樣的邏輯传睹。

說到這里你可能會問，PID=1這個進(jìn)程沒有進(jìn)程管理能力有啥影響鞍痘蕖欧啤？我們來舉個例子睛藻，比如我們部署了訂單中心，訂單中心在啟動的時候邢隧，通過docker exec啟動了一個Nginx進(jìn)程店印，來提供訂單服務(wù)需要的某些靜態(tài)資源的訪問，這樣我們就在一個容器中倒慧，啟動了兩個進(jìn)程按摘，但是這個Nginx進(jìn)程從啟動一刻開始，就處于散養(yǎng)狀態(tài)纫谅，Nginx進(jìn)程退出炫贤，沒有人知道，因此那就沒有辦法納入到Kubernetes的管理中付秕，因此在容器化部署方案中照激，筆者強(qiáng)烈建議大家一個容器中只啟動一個進(jìn)程，在這個進(jìn)程中把工作做好盹牧。

但是問題來了俩垃，你剛說過應(yīng)用程序一般都不是單兵作戰(zhàn)的，會啟動多個進(jìn)程或者線程汰寓，如果一個容器只運(yùn)行一個進(jìn)程口柳，我們的應(yīng)用還能部署到Kubernetes平臺嗎？

首先回答這個問題有滑，Kubernetes本身是谷歌多年容器化經(jīng)驗(yàn)的集大成者跃闹，因此我們遇到的問題，其實(shí)谷歌很多年前應(yīng)該都遇到過毛好，并且解決這些問題的思路和方案都已經(jīng)設(shè)計進(jìn)Kubernetes平臺了望艺，因此從這個角度來看，Kubernetes要解決的一個核心的部署問題就是:如何將多個有關(guān)系的應(yīng)用部署到一起?

我們來舉個例子來說明一下肌访，假設(shè)我們的訂單中心由三個子模塊構(gòu)成找默，模塊1負(fù)責(zé)處理購物車的邏輯，模塊2主要用來處理下單吼驶，而模塊三是一個定時任務(wù)惩激，基于業(yè)務(wù)規(guī)則來定期將支付超時的訂單關(guān)閉，針對這個應(yīng)用程序來說蟹演，如果我們按Kubernetes之前的容器部署方案风钻，比如說Docker Swarm，那么我們就需要將三個分別啟動容器實(shí)例酒请。

這三個模塊有比較親密的關(guān)系骡技，并且在當(dāng)前的數(shù)據(jù)中心中是通過localhost來進(jìn)行通信的，因此我們必須將這三個容器實(shí)例運(yùn)行在一臺機(jī)器上羞反，假設(shè)我們?nèi)齻€容器實(shí)例都需要1G的內(nèi)存布朦，那么當(dāng)我們有兩臺工作節(jié)點(diǎn)Node1和Node2囤萤，其中Node1有2.5G可用的內(nèi)存空間，而Node2有3G的可用內(nèi)存空間.

我們在Node1上成功啟動了模塊1和2喝滞，但是當(dāng)我們啟動模塊3的時候阁将，由于Node1只剩下0.5G的內(nèi)存，因此模塊3無法運(yùn)行在Node1右遭，但是模塊3又必須和模塊1做盅，2運(yùn)行在同一臺機(jī)器上，這樣就比較尷尬了窘哈。

而這個問題的解決吹榴，就需要有更加優(yōu)秀的調(diào)度算法，能夠識別到這總具有親密關(guān)系的應(yīng)用滚婉，從而給他們統(tǒng)一申請計算資源图筹，回到上邊的例子中，如果Docker Swarm具備這種調(diào)度計算的能力让腹，那么它就壓根不會去考慮Node1远剩，直接選擇Node2就滿足三個模塊對部署的需求了。

回到Kubernetes平臺上骇窍，你是否已經(jīng)意識到Kubernetes處理這個問題的方案瓜晤？沒錯，就是POD腹纳，POD是Kubernetes中資源調(diào)度的基本單位痢掠，而調(diào)度器的工作原理，其實(shí)就是基于POD的資源來進(jìn)行申請和調(diào)度的嘲恍。

而筆者剛才提到的訂單中心的例子足画，我們可以通過在POD中啟動三個容器，每個容器是一個進(jìn)程佃牛，資源是按POD進(jìn)行申請和調(diào)度淹辞，這個POD會被毫無爭議的調(diào)度到Node2上，調(diào)度器壓根就不會考慮Node1吁脱，而這種通過localhost進(jìn)行通信的多個容器實(shí)例桑涎，我們稱他們具備超親密關(guān)系。

雖然說我們可以在一個POD里運(yùn)行多個容器兼贡，按時筆者要再三強(qiáng)調(diào)，這只限于具備這種”超親密“關(guān)系的容器娃胆，如果你問我是否應(yīng)該把MYSQL和SpringCloud應(yīng)用在一個POD中啟動起來遍希，我的回答是：千萬不要。

先不說這種部署方式是否符合公司的部署規(guī)范里烦，就從數(shù)據(jù)庫和應(yīng)用這兩個應(yīng)用需要使用的資源特征來看凿蒜，我們更應(yīng)該把他們放到不同的POD中禁谦，而不是同一個POD中的不同容器。很明顯我們擴(kuò)容POD的方式和擴(kuò)容數(shù)據(jù)庫是不一致的废封，而數(shù)據(jù)庫是應(yīng)用具備云原生無狀態(tài)特征的關(guān)鍵州泊，理論上容器化部署MYSQL要比應(yīng)用程序復(fù)雜很多，因此處理數(shù)據(jù)庫的狀態(tài)不是那么簡單漂洋。

在整個Kubernetes對象模型中遥皂，POD只是一個”邏輯“的概念，筆者在前邊的幾篇文章中詳細(xì)介紹過支持容器的Linux提供的內(nèi)核機(jī)制：7種命名空間刽漂，文件系統(tǒng)演训，和CGroup來做資源限制。

而Kubernetes最終落到每臺宿主機(jī)上贝咙，處理的還是命名空間样悟，CGroup和文件系統(tǒng)，這是決定容器邊界的機(jī)制庭猩，并且容器在操作系統(tǒng)上就是一個被施加了特殊命名空間和資源限制的進(jìn)程窟她，操作系統(tǒng)上其實(shí)并不存在POD這個進(jìn)程，這是邏輯一詞的由來蔼水。

那么POD是什么震糖，其實(shí)筆者在介紹容器的時候就埋下了伏筆，當(dāng)時我們并沒有說透和虛擬機(jī)對應(yīng)的對象是什么徙缴。具體來說试伙，POD就是一組共享了資源的容器，POD里的所有容器于样，共享相同的網(wǎng)絡(luò)命名空間和接口疏叨，并且可以通過聲明掛載相同Volume來交換數(shù)據(jù)。關(guān)于存儲卷筆者后續(xù)會通過專門的文章來介紹穿剖。那么POD是不是就是虛擬機(jī)的概念呢蚤蔓？其實(shí)筆者想告訴大家的是，無論是從原理糊余，資源使用秀又，功能等角度，容器和虛擬機(jī)沒有太多的相似之處贬芥。筆者讀過很多文章吐辙，都在講容器是比虛擬機(jī)更加高效的虛擬化技術(shù)，并且還把他們畫在對比圖的相同層蘸劈，其實(shí)這樣的理解昏苏，不是太準(zhǔn)確。因此也不存在把虛擬機(jī)遷移到Kubernetes平臺。

如果PDO中的容器共享同一組資源贤惯，那么問題就來了洼专，誰應(yīng)該是第一hold主這些命名空間，而讓后來的容器實(shí)例能夠”加入“孵构？具體是誰比較容器屁商，但是如果按這個邏輯走，容器之間就有明確的依賴關(guān)系了颈墅，比如在訂單中心的例子中蜡镶，如果訂單服務(wù)必須先啟動，然后是訂單取消的異步任務(wù)容器精盅，那么我們就必須在啟動帽哑，擴(kuò)容和失敗重啟的時候，嚴(yán)格按照這個關(guān)系叹俏，很明顯這是有問題的妻枕，引入了依賴。

而Kubernetes解決這個問題的方法粘驰，就是每個POD在啟動的時候屡谐，依賴一個叫做infra的容器來占住資源，這樣其他的業(yè)務(wù)容器就可以加入進(jìn)來蝌数，這樣大家就會共享這些命名空間愕掏。

具體來說，假如我們的POD中有兩個容器A和B顶伞，那么POD在啟動的時候饵撑，首先會創(chuàng)建infras容器，然后容器A和B通過infra容器建立這種親密的關(guān)系唆貌，從這個角度來看滑潘，Infra容器要非常的輕量級和穩(wěn)定，占用的資源也不能太多锨咙，在Kubernetes平臺中语卤，Infras容器是通過一個叫pause的鏡像創(chuàng)建的。

資源具體的位置是：k8s.gcr.io/pause酪刀，這個容器是用匯編語言編寫粹舵，占用的空間在100-200k之間，并且永遠(yuǎn)處于暫停的狀態(tài)骂倘。通過Infra容器hold主命名空間眼滤，容器A和B就建立起來關(guān)系，因此如果我們查看這是哪個容器在宿主機(jī)上命名空間對應(yīng)的文件历涝，會發(fā)現(xiàn)他們指向相同的命名空間文件（也意味著屬于相同的命名空間）柠偶。

而運(yùn)行在同一個比說說網(wǎng)絡(luò)命名空間的容器A和B,可以享受如下的便利:

- 和Infra容器共享網(wǎng)絡(luò)設(shè)備

- 容器A和B可以通過localhost來直接進(jìn)行通信情妖，效率得到了極大的提升

- 由于IP地址是基于POD睬关，因此容器A和B共享IP地址

- POD的聲明周期只和Infra容器相關(guān)诱担，和容器A和B沒有直接的關(guān)系

因此，我們在自己的實(shí)際項(xiàng)目中电爹，上云或者上Kubernetes工作的核心,是深刻理解容器的本質(zhì)蔫仙，進(jìn)程這個概念。我們在物理機(jī)和虛擬機(jī)上部署應(yīng)用程序，進(jìn)程會受到systemd或者supervisord的管理，而在容器模型下株汉，一個容器中只有一個進(jìn)程爽撒，而POD只是扮演了資源分配的這個虛擬機(jī)的角色。

而POD這個邏輯的概念兢哭，更多是和編排相關(guān)，如果我們把POD理解成資源分配的”虛擬機(jī)“，那么鏡像就是這個虛擬機(jī)上啟動進(jìn)程的exe文件丑慎，我們可以定義initContainer來進(jìn)行初始化操作，并且定義多個不同的初始化容器瓤摧，并給他們安排具體啟動的順序竿裂，這就編排的具體體現(xiàn)。

好了照弥，今天的內(nèi)容就這么多了腻异，通過POD的三篇文章的學(xué)習(xí)，筆者希望大家能夠不光知道如何部署應(yīng)用到Kubernetes集群这揣，也能夠知道背后的原理悔常。

接下來，我們具備足夠的基礎(chǔ)知識后给赞，我們來看看如何通過聲明式的方式机打，也就是YAML文件的方式，來部署和版本更新我們的SpringCloud應(yīng)用程序塞俱，敬請期待!