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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了幫助大家理解Kubernetes大框架是如何運作，我們來展示的一些圖，可以幫助大家更好的理解這個項目。

就像James Burker說的：

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

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

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

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

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

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

Kubernetes當(dāng)然是為“黃金時間段”準(zhǔn)備的，不僅是因為許多公司都在生產(chǎn)過程中使用，而且還單純因為它的性能和規(guī)模。

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

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