說實(shí)話，我是一個(gè)Kubernetes愛好者。Kubernetes可以說是軟件開發(fā)領(lǐng)域邁出的一大步。當(dāng)我知道Kubernetes的時(shí)候，我就想這才是在生產(chǎn)環(huán)境使用容器的正確之道。我沒有任何遲疑就接受了Kubernetes。像我這樣的，還有數(shù)以千計(jì)的架構(gòu)師已經(jīng)成功擁抱了這一技術(shù)。

首先讓我們了解一下Kubernetes是如何解決在大多數(shù)在云端部署應(yīng)用時(shí)碰到的問題，它是如何支持我們的基礎(chǔ)設(shè)施向云端遷移。

[[315634]]

牢記你的目標(biāo)

在萬物云化的時(shí)代，對(duì)于所有公司都有一些共同的目標(biāo)。

以下一些目標(biāo)一般都會(huì)具有高優(yōu)先級(jí)：

• 盡快遷移到云上(云端遷移)
• 減少系統(tǒng)管理的成本，基礎(chǔ)設(shè)施的成本，人力成本(成本縮減)
• 減少完成項(xiàng)目所需的時(shí)間(盡快面向市場)
• 系統(tǒng)高性能、高可用(質(zhì)量提升)
• 牢記這些目標(biāo)，我們就能邁上云端，然后思索下一步的動(dòng)作。

我們?yōu)槭裁葱枰萜?

在我們思考為什么需要Kubernetes之前，我們需要先問自己，為什么我們需要容器?容器在軟件開發(fā)的歷史上是一次巨大的變革，因?yàn)樗鼘⑸a(chǎn)環(huán)境帶入到每個(gè)開發(fā)者的本地環(huán)境中，我們不再需要擔(dān)心Linux和Windows的兼容問題。通過使用容器，我們可以在任何工作站上輕易地重現(xiàn)出任何問題。并且，我們也能輕易地將容器遷移到任何一個(gè)平臺(tái)上，不需要做任何其他多余的操作。在容器出現(xiàn)之前，開發(fā)者就懂得把應(yīng)用程序打包進(jìn)行發(fā)布，因?yàn)樗麄冎缿?yīng)用程序如何能夠正常運(yùn)行，比如你可以將依賴組件和應(yīng)用一起打包。站在DevOps的角度，容器非常優(yōu)雅，因?yàn)槊總€(gè)發(fā)布系統(tǒng)只需要處理一件事物，那就是容器。不僅如此，所有的容器構(gòu)建過程可以由開發(fā)者通過Dockerfile來描述，這意味著無論在本地開發(fā)環(huán)境還是持續(xù)集成環(huán)境，你都使用同樣的方法來構(gòu)建應(yīng)用。

容器意味著維護(hù)的事項(xiàng)更少，屏蔽環(huán)境的細(xì)節(jié)做到無差異化，那么也就更少的錯(cuò)誤。

我們能夠把容器的鏡像推送到Registry。通過Registry，我們在任何地方都能下載、部署，無論是筆記本電腦還是虛擬機(jī)(本地或者云端)甚至是Serverless的場景，比如Heroku。相較于虛擬機(jī)，容器真正的優(yōu)勢在于它虛擬了操作系統(tǒng)你那個(gè)而不是外部資源。這樣更高級(jí)別的抽象使得我們擁有一種更輕量級(jí)、更簡單也更經(jīng)濟(jì)的方式來部署應(yīng)用。

為什么需要Kubernetes?

在之前的一節(jié)中我們解釋了為什么大家都會(huì)使用容器，但并沒有提及我們?yōu)槭裁葱枰狵ubernetes。不管怎么說，我們已經(jīng)接受了容器這個(gè)事物。這帶來了一個(gè)新的需求，我們?nèi)绾喂芾砣萜?我們?nèi)绾慰煽康鼐幣湃萜?我們的答案是Kubernetes!

擁有了Kubernetes，你所需要做的事就是將鏡像推送到Registry，然后等待Kubernetes來完成剩余的工作。所有部署環(huán)節(jié)的任務(wù)都由Kubernetes來管理，我們根本無需去擔(dān)心基礎(chǔ)設(shè)施。

Kubernetes是業(yè)界領(lǐng)先的容器編排解決方案。它是在Google對(duì)容器的實(shí)踐中逐漸開發(fā)完善的，同時(shí)也是開源的。它的架構(gòu)允許容器編排，也允許與舊的系統(tǒng)集成。這意味著你能在本地安裝Kubernetes，也可以在云端安裝、使用，甚至允許你是用混合云的架構(gòu)。

所以，我們之所以會(huì)使用Kubernetes，是因?yàn)樗姆€(wěn)定性、可靠性和易用性。簡單來說，Kubernetes是部署容器的最佳方式。

Kubernetes是Serverless嗎?

Kubernetes是不是Serverless?我認(rèn)為Kubernetes和Serverless是兩個(gè)不同領(lǐng)域的詞。Serverless更多是一種哲學(xué)，而Kubernetes則是一個(gè)具體的工具。讓我們暫且先回顧一下我們最初的目標(biāo)，我們說我們需要減少對(duì)操作系統(tǒng)的依賴以及減少維護(hù)他的成本，而這就是Serverless。

那么問題就變成了，Kubernetes是否讓我們實(shí)現(xiàn)了這個(gè)目標(biāo)呢?簡單來說，是的。

Serverless的嚴(yán)格定義是，我們不需要關(guān)心到底是什么應(yīng)用容器、什么系統(tǒng)、什么硬件在運(yùn)行我的代碼，甚至我都不知道它位于世界的哪個(gè)角落。雖然Kubernetes確實(shí)向開發(fā)者隱藏了諸多的復(fù)雜性，但我們確實(shí)還是需要了解服務(wù)器的相關(guān)部分，比如，你仍然依賴于某個(gè)特定的容器提供的操作系統(tǒng)。同時(shí)，你也依賴于某個(gè)特定版本的Kubernetes。這意味著，理論上來說Kubernetes并不算Serverless。

接著，讓我們來看幾個(gè)Serverless的解決方案。

Heroku Runtime[1]的底層是依賴于容器，當(dāng)然你也可以在Heroku上直接部署自己的容器[2]。大部分的Lambda函數(shù)都是運(yùn)行在容器中。

這就是為什么我們認(rèn)為部署在云端的Kubernetes不是Serverless，因?yàn)樗腔谌萜鞯模⑶疫€依賴于操作系統(tǒng)。然而，同樣依賴于容器的Heroku Runtime或是Lambda計(jì)算服務(wù)卻被認(rèn)為是Serverless。

所以我仍然認(rèn)為Kubernetes是一種Serverless的解決方案，即使它不滿足嚴(yán)格的定義。這個(gè)世界并不是非黑即白的，云端版本的Kubernetes提供的抽象程度(如屏蔽了操作系統(tǒng)以及底層資源)對(duì)我來說已經(jīng)足夠了。

我不希望在這里咬文嚼字。除開我們是否要給Kubernetes貼上Serverless這個(gè)標(biāo)簽的問題，Kubernetes確實(shí)能夠讓我們迅速上云，是減少系統(tǒng)管理成本、基礎(chǔ)設(shè)施維護(hù)成本，提高業(yè)務(wù)質(zhì)量的一大利器。所以我們實(shí)際上無須去關(guān)心那些標(biāo)簽，黑貓白貓抓到老鼠就是好貓。

Kubernetes的優(yōu)勢

Kubernetes是一個(gè)非常優(yōu)秀的平臺(tái)，使我們能夠脫下傳統(tǒng)虛擬機(jī)的戎裝去擁抱云。它帶來活力，減少系統(tǒng)管理成本，并且將服務(wù)的質(zhì)量推上一個(gè)新的高度，在Kubernetes誕生之前我們很難做到這一步。許多傳統(tǒng)的問題比如網(wǎng)絡(luò)，數(shù)據(jù)保護(hù)等在Kubernetes中都能夠通過高級(jí)配置來實(shí)現(xiàn)。

以下是Kubernetes帶來的一些優(yōu)勢：

• 可擴(kuò)展性：你只需要部署一個(gè)容器，就能夠毫無障礙地設(shè)置擴(kuò)容策略。然后，你只需要保證你的賬戶里有足夠的余額就行了。
• 透明化：每個(gè)容器只完成一項(xiàng)工作。容器之間的關(guān)系被映射成配置文件，不需要擔(dān)心遺漏什么，當(dāng)然細(xì)節(jié)也無法被隱藏。
• 節(jié)約時(shí)間：流程非常簡單，所有的步驟都能夠被重復(fù)。
• 版本控制：從設(shè)計(jì)上來看，每一次部署都被版本化。當(dāng)然，稍微花點(diǎn)時(shí)間，你也可以將配置文件用Git管理起來。

與其他方式相比，Kubernetes簡化了所有開發(fā)運(yùn)維的事項(xiàng)，將開發(fā)者帶入到一個(gè)幾乎不需要運(yùn)維的理想狀態(tài)。開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)之間的摩擦也減少了，因?yàn)樵緝烧呗氊?zé)的模糊地帶現(xiàn)在也劃清了界線，系統(tǒng)本身也保持了相當(dāng)?shù)耐该鞫取?/p>

其他的一些優(yōu)點(diǎn)列舉如下：

• 水平擴(kuò)展：Kubernetes本身能夠自動(dòng)擴(kuò)展，支持在集群中增加節(jié)點(diǎn)或者調(diào)整可用的物理資源。同時(shí)，他也能擴(kuò)展邏輯資源，如調(diào)整一個(gè)服務(wù)的Pod數(shù)目。
• 智能升級(jí)：每次你升級(jí)容器鏡像的時(shí)候，升級(jí)的過程是平滑的。舊的Pod會(huì)一直保持可用的狀態(tài)直到新的Pod啟動(dòng)完成才會(huì)被銷毀。這就是我們常說的零宕機(jī)部署。
• 支持本地搭建或是云端服務(wù)：使用使用云以外還有別的選擇嗎?當(dāng)然!我總是偏好完全云端的解決方案，當(dāng)然在一些場景下，可能也需要在本地環(huán)境或者機(jī)房部署，當(dāng)然Kubernetes也能夠完美支持。
• 遠(yuǎn)離廠商捆綁：Kubernetes在每個(gè)通過認(rèn)證的公有云平臺(tái)具有一致性[3]。如果你對(duì)你的服務(wù)商不滿，你只需要花費(fèi)少量的時(shí)間就可以更換廠商。
• 對(duì)開發(fā)者沒有額外的成本：任何已經(jīng)被容器化的軟件都能一鍵部署。開發(fā)團(tuán)隊(duì)不需要學(xué)習(xí)額外的知識(shí)。

我們到底如何選擇?

Kubernetes的靈活性很強(qiáng)，利用云端的方案，你可以輕松地管理Kubernetes集群。當(dāng)我了解到Kubernetes的時(shí)候，我就認(rèn)為它是一個(gè)可行的、安全的方案，能夠有效減少開發(fā)者的負(fù)擔(dān)。它具備所有傳統(tǒng)基礎(chǔ)設(shè)施的優(yōu)勢，同時(shí)讓我們在不重構(gòu)應(yīng)用的同時(shí)，享受不需要運(yùn)行維護(hù)的便利。和很多其他看上去閃閃發(fā)亮的解決方案(如Serverless)相比，Kubernetes更加實(shí)在。Serverless確實(shí)很不錯(cuò)，但是很多復(fù)雜的場景，它并不能很自如地應(yīng)付。并且從邏輯上來看，全盤接受像Lambda這樣前沿的技術(shù)需要一個(gè)巨大的思維轉(zhuǎn)變。對(duì)于運(yùn)維團(tuán)隊(duì)來說，這樣的改變并不容易。

如今，減少系統(tǒng)管理的工作量，擁有能夠易于部署、能夠簡化運(yùn)維核心痛點(diǎn)的基礎(chǔ)設(shè)施對(duì)大部分團(tuán)隊(duì)來說都是核心需求。而Kubernetes滿足這所有的需求。

如果讓我現(xiàn)在去設(shè)計(jì)一套架構(gòu)，尤其是面向企業(yè)的解決方案，我會(huì)首選容器技術(shù)和Kubernetes。或許我會(huì)選擇云服務(wù)商提供的Kubernetes來減少運(yùn)維成本。我也有可能會(huì)用Git來管理DevOps流水線相關(guān)的配置。

這個(gè)方案對(duì)操作系統(tǒng)的依賴很少，對(duì)云廠商的依賴也很少，所有的基礎(chǔ)設(shè)施及其配置都依賴于代碼。

有人會(huì)說，這個(gè)方案并不完全擺脫了運(yùn)維，也不完全擺脫了服務(wù)器。但Kubernetes具有穩(wěn)定、模塊化、可伸縮的特性，能夠滿足最重要的架構(gòu)設(shè)計(jì)目標(biāo)。所以我們?yōu)槭裁床挥肒ubernetes呢?

那我們能不能做得更好?毫無疑問。我們能努力擺脫更多的負(fù)擔(dān)嗎?當(dāng)然可以。我們當(dāng)然能百尺竿頭更進(jìn)一步。然而，仰望星空也要腳踏實(shí)地，我們必須要承認(rèn)Kubernetes是一個(gè)極佳的折中方案：在大部分案例中，Kubernetes是成功的保障。