摘要：因此，也是運(yùn)行谷歌的一種方式，所以本質(zhì)上來說，你注冊就是為了能夠訪問一組指定的設(shè)計(jì)原則，這組原則會(huì)讓你的應(yīng)用程序有效運(yùn)作，像谷歌那樣輕松建立和管理您的應(yīng)用程序。

今天我們來聊聊，但不從技術(shù)細(xì)節(jié)角度，聊為什么容器、Kubernetes是值得使用和整合到你的項(xiàng)目堆棧中的。我們的目標(biāo)是給你們提供一個(gè)關(guān)于應(yīng)該如何思考你的底層構(gòu)架以及將它可視化問題，從這個(gè)角度來談我們的話題：Kubernetes為什么重要？

Kubernetes旨在作為你容器的管理層。然而，它的重點(diǎn)是無縫提供給你的應(yīng)用程序真實(shí)實(shí)在的需要，滿足你的應(yīng)用程序所依賴的需要。舉個(gè)例子，這些應(yīng)用所需就是由Kubernetes提供的：訪問與供應(yīng)商無關(guān)的數(shù)據(jù)卷、負(fù)載均衡、冗余控制、彈性擴(kuò)容、滾動(dòng)更新以及配置密鑰管理。
有了例如上述的性能和特點(diǎn)，再加上由Docker和容器本身運(yùn)行時(shí)提供的打包件，管理應(yīng)用程序的實(shí)踐（不是servers）才開始通過使用Kubernetes展開。

Kubernetes的開始起源于谷歌，它在谷歌系統(tǒng)中有自己的起源：Borg和Omega。許多基于這些系統(tǒng)的設(shè)計(jì)和安裝的相同概念，已經(jīng)作為一個(gè)新的表現(xiàn)形式滲入Kubernetes，這個(gè)表現(xiàn)形式包括現(xiàn)今的標(biāo)準(zhǔn)，合并了很多谷歌在過去十年里吸取到的實(shí)踐經(jīng)驗(yàn)教訓(xùn)。

Kubernetes不是像很多人開場白講得那樣，是Borg或者Omega的“開源”版本；而是一個(gè)谷歌花了很多力氣來為你的工作和服務(wù)創(chuàng)建的新管理工具。Kubernetes在谷歌是利用許多年的架構(gòu)和實(shí)踐經(jīng)驗(yàn)開始的，但是因?yàn)樗情_源項(xiàng)目，而且已經(jīng)證明它可以真正簡化開發(fā)、操作和管理職責(zé)，所以自從它的初始公開版本在2014年6月提交后，就積累了越來越多的代碼提交貢獻(xiàn)。

這是Kubernetes自從2015年以來收到的代碼提交數(shù)量的一個(gè)截圖：

這些圖簡短地描述了一個(gè)真實(shí)的、合作的Kubernetes技術(shù)社區(qū)。

就像我們之前提到過的，有很多人以個(gè)人名義或者是公司名義加入到Kubernentes。然而，真正的問題是，你有沒有像最初開始的那樣，按照谷歌的方式來運(yùn)行你的應(yīng)用程序和服務(wù)呢？

我們現(xiàn)在了解到的是，Kubernetes不僅僅只是一個(gè)容器管理系統(tǒng)，它也從內(nèi)部查看了谷歌為實(shí)踐每一個(gè)服務(wù)和產(chǎn)品：從Gmail、搜索、地圖到GCE（服務(wù)產(chǎn)品清單還在持續(xù)增長），是如何運(yùn)行他們的基礎(chǔ)設(shè)施的。

因此，Kubernetes也是運(yùn)行谷歌的一種方式，所以本質(zhì)上來說，你注冊就是為了能夠訪問一組指定的設(shè)計(jì)原則，這組原則會(huì)讓你的應(yīng)用程序有效運(yùn)作，像谷歌那樣輕松建立和管理您的應(yīng)用程序。這并不是說，底層系統(tǒng)例如OpenStack或者AWS處理IaaS資源，就不能用了，而是說這些系統(tǒng)都盡可能做到最好，而Kubernetes就是為帶來你的應(yīng)用程序所需要的一切而生。最終，融合Kubernetes會(huì)創(chuàng)建一個(gè)良好組件的結(jié)合。

所以，如果你正在為你的項(xiàng)目考慮Kubernetes，那么你必須信任項(xiàng)目所呈現(xiàn)的基礎(chǔ)和范式，從Pod開始，然后剩下的concepts自然會(huì)跟過來。這將給用戶非凡的組合功能和靈活性，Kubernetes本身的視野在重新定義你的應(yīng)用程序是如何構(gòu)建的上體現(xiàn)了輔助作用。

就像最近的關(guān)于Borg、Omega和Kubernetes的那篇論文里提到的細(xì)節(jié)（論文戳這里：點(diǎn)我）Kubernetes幫助建立成套工具來輔助管理和縮放你的應(yīng)用程序。

以下是Kubernetes如何讓改進(jìn)應(yīng)用程序開發(fā)的方法：

容器將應(yīng)用環(huán)境封裝，從應(yīng)用程序開發(fā)者和基礎(chǔ)設(shè)施層面抽象掉很多機(jī)器和操作系統(tǒng)的細(xì)節(jié)。

管理API從面向機(jī)器轉(zhuǎn)到面向應(yīng)用程序，程序部署和檢查極大提高，數(shù)據(jù)中心也由面向機(jī)器轉(zhuǎn)向面向應(yīng)用程序。

應(yīng)用程序API的轉(zhuǎn)換可以讓團(tuán)隊(duì)無需擔(dān)心機(jī)器和操作系統(tǒng)的細(xì)節(jié)特性。

專注于機(jī)器上的應(yīng)用程序，這也允許團(tuán)隊(duì)以更靈活、更模塊化的方式來操作。

原因是Kubrnetes是pod的常見使用模式實(shí)例，或者說是一個(gè)組件，是一個(gè)復(fù)雜應(yīng)用程序中可以編寫，運(yùn)行以及被一個(gè)小團(tuán)隊(duì)全權(quán)負(fù)責(zé)管理功能的組件。

甚至其它的Kubernetes旨在提高你的應(yīng)用程序的組件，是建立在例如像ReplicationsSets，部署，服務(wù)之類的概念之上，因此，合并鞏固所有的應(yīng)用程序需求，業(yè)務(wù)政策以及團(tuán)隊(duì)，就變得簡單，可以無縫銜接。你可以探測不同的Kubernetes的概念，不僅僅跟Pod互相作用，而且允許你為你的應(yīng)用在《用戶指南詞匯表》里創(chuàng)建新功能。

Kubernetes也會(huì)通過吸引大量不同的任務(wù)角色來給你的公司構(gòu)架提供幫助。

開發(fā)者（developers）：不僅可以創(chuàng)建通用的應(yīng)用，他們還可以使用集群本質(zhì)的屬性來完成任何應(yīng)用的特定需求。
在使用案例之中，devs想要把一個(gè)特定的Node作為目標(biāo)，或者將一組Nodes作為目標(biāo)，表示不同的硬件細(xì)節(jié)的特定標(biāo)簽可以用于個(gè)人Pod調(diào)度。也就是，如果你想要在AMD CPU（而不是Intel）架構(gòu)上運(yùn)行你的應(yīng)用程序，或者你希望利用GPU，甚至是有大數(shù)量的RAM的Node。

消耗各種不同的機(jī)器在不僅在Kubernetes上是可能的，而且它事實(shí)上將所有的機(jī)器都拉平衡，并且將他們呈現(xiàn)為一個(gè)通用的計(jì)算資源。
這不僅由你的應(yīng)用程序體現(xiàn)了Pets vs. Cattle的意識(shí)形態(tài)，你的機(jī)器也是。

運(yùn)維（Devops）：Kubernetes概念，比如像Deployments，replicaSets，Services等等，所有這些都會(huì)幫助減輕運(yùn)維，確保每個(gè)應(yīng)用都有一個(gè)描述性的系列業(yè)務(wù)政策，而且這些規(guī)格都是隨時(shí)實(shí)施和維護(hù)的。

管理員（Admins）：作為Kubernetes的一部分，admins可以通過使用例如像Heapster或者cAdvisor一樣的工具來獲得訪問權(quán)和流程容器資源，同樣的，檢查集群的事件，API請求，監(jiān)測數(shù)據(jù)，和利用Kubedash做分析。
這些不同的軟件度量不僅提供檢測Kubernetes集群服務(wù)，而且還提供一個(gè)對這些應(yīng)用程序自身的細(xì)粒度理解，因?yàn)樗麄兌际嵌鄮Э刂频摹Ｈ绻话岩恍?fù)雜沉重的安裝留給用戶的話，很多在其他系統(tǒng)里的應(yīng)用程序?qū)用娴姆治鍪遣豢赡芡瓿傻摹＿@些在Kubernetes上的本地功能說明了項(xiàng)目的努力不僅是針對你的應(yīng)用程序的增長，而且這個(gè)水準(zhǔn)的信息是一個(gè)為你的應(yīng)用程序確定的需求，你不該自己創(chuàng)建這個(gè)功能，而是該功能應(yīng)該被通過系統(tǒng)提交給你。

其他：最近，許多不同的任務(wù)角色可以跟Kubernetes互相作用，在基礎(chǔ)水準(zhǔn)上，通過利用dashboard將你的集群可視化，同時(shí)運(yùn)行措施：比如創(chuàng)建一個(gè)新的資源，比如為對資源利用標(biāo)簽進(jìn)行查詢，比如檢查或生成報(bào)告。

為了幫助大家理解Kubernetes大框架是如何運(yùn)作，我們來展示的一些圖，可以幫助大家更好的理解這個(gè)項(xiàng)目。

就像James Burker說的：

只有你知道自己去過哪里，你才會(huì)知道你想去往哪里。

基于這個(gè)話，我們要考慮Kubernetes的鼻祖就是Borg以及它和Borg的極大淵源。從這句話出發(fā)，我們可以考慮該如何有組織的思考集群。
讓我們先來看一些從Borg的論文里讀到的情況，這不僅可以讓我們一窺Borg是如何配置的，還可以讓我們知道同樣的模型是如何應(yīng)用到Kubernetes上面的。
這里我們可以看到我們的首要云架構(gòu)從上面看是怎么樣的。

如果我們進(jìn)一步放大，我們可以檢測到每個(gè)在數(shù)據(jù)中心的建設(shè)包括了至少一個(gè)Borg集群，它被分成了約10000個(gè)機(jī)器：

再進(jìn)一步觀察這個(gè)“細(xì)胞”，我們可以一睹控制臺(tái)的組件和工人／Nodes的不同，以及Kubernetes Pods和Borg里十分相像，對于任何應(yīng)用程序后者在整個(gè)過程中的服務(wù)，是唯一的原子單元。

可能就像你現(xiàn)在注意到的那樣，這里有很多平行的Borg組件，還有現(xiàn)在存在于Kubernetes之中的，特別是1:1相對應(yīng)的集群和Pods——這些相似點(diǎn)會(huì)讓你在思考聯(lián)合Kubernetes配置的時(shí)候更快想明白。

雖然Kubernetes目前還不能像Borg那樣每個(gè)集群規(guī)模達(dá)到10000個(gè)節(jié)點(diǎn)，但是它最近已經(jīng)優(yōu)化到可以允許集群支持最多1000個(gè)Nodes和30000個(gè)pods，而且99%的API可以在1秒內(nèi)呼叫回應(yīng)，還有99%的Pods（已經(jīng)有先拉下來的鏡像）在5秒內(nèi)開啟——巨額收益代表規(guī)模增長10倍，據(jù)報(bào)道稱根據(jù)谷歌的內(nèi)部人士稱，實(shí)際是增長將近14倍。

Kubernetes當(dāng)然是為“黃金時(shí)間段”準(zhǔn)備的，不僅是因?yàn)樵S多公司都在生產(chǎn)過程中使用，而且還單純因?yàn)樗男阅芎鸵?guī)模。

我們希望你能夠有更好的理解在現(xiàn)今的軟件發(fā)展時(shí)代“Kubernents為什么重要”的原因，也希望你能夠更好理解如何組織以及構(gòu)架你的集群來使之整合。

去接受Kubernetes的規(guī)范，可能一開始看起來像是消防水龍帶但本質(zhì)上是深思熟慮之后的設(shè)計(jì)原則，這原則不僅為軟件開發(fā)展示適當(dāng)?shù)姆椒紤]，還為每一個(gè)從ops到管理系統(tǒng)的不論重要還是輔助的應(yīng)用程序組件都考慮到了。