自從上次跟女朋友嘮了嘮“容器技術”之后，似懂非懂、欲拒還迎的女朋友仿佛并沒有get到云原生、容器與Kubernetes之間的“瓜葛”，每天糾纏著、催促著下一輪的“科普”。于是，我又雙叒叕妥協了。

那么，這一期，我們主要嘮一嘮Kubernetes。在這里提醒一下大家，想知道更多關于容器技術的內容，可以看一看《趣說“容器技術”，女朋友讓我白話它的精彩故事》。同時，我們也會沿著上一期的脈絡往下說。

好了，我們言歸正傳。

話說，開源之后的Docker容器技術被炒得熱火朝天，儼然紅得像帶貨界的領軍人物。但是隨著用它的企業越來越多，大家發現將Dcoker用于具體業務是存在困難的，尤其是編排、管理、調度等，都非常不容易。這時，人們迫切需要一個Docker管理系統，對容器進行靈活的管理。 

細心的企業逐漸發現這也是商機，時間來到2013年，那是一個炎熱的夏天，谷歌內部有一群非常有想法的產品經理，腦洞了一個想法，我們何不開發一個開源的容器管理系統?于是開始的谷歌內部進行游說，希望可以得到一定的支持。

按照他們的說法，在預算緊張的早年間，谷歌為了榨取服務器的沒一點性能，漸漸開啟嘗試容器，并且構建了一個名為Borg的集群管理系統。在這套系統下，谷歌的服務器可以運行成千上萬個任務，提高了計算效率。

事實上，他們的基于容器的集群管理平臺，也是從Borg蛻變來的。

苦心人，天不負，三千越甲可吞吳。終于，他們的游說得到了反饋。于是，谷歌開始做基于容器的集群管理平臺——Kubernetes。

2014年6月，Google正式公布并開源Kubernetes。

Emmmm，Kubernetes這個單詞來自于希臘語，意思是舵手或領航員。K8S是它的縮寫，用“8”字替代了“ubernete”這8個字符。

在宣布開源之后，微軟、Red Hat、IBM、Docker、CoreOS、Mesosphere、Saltstack等公司聞風而來，紛紛投入K8s溫暖的懷抱。

此后，VMware、HP、Intel等公司，也陸續加入。

2015年7月，Google正式加入OpenStack基金會。與此同時，Kuberentes v1.0正式發布。

目前，kubernetes的版本已經發展到V1.13。

截止目前，K8s的煉金之旅正式完成。

如今，K8s在容器領域、云原生領域初露鋒芒，未來亦將潛力無限。

這就是K8s，簡而言之，它就是基于容器的集群管理平臺。

緊接著，我們來看一下K8s的架構，其實一個K8s系統，通常被成為一個K8s集群(Cluster)。該集群主要包括兩個部分：一個Master節點(主節點)、一群Node節點(計算節點)。其中，Master節點負責管理和控制;Node節點是工作負載節點，包含具體的容器。

Master節點 

Master節點包括API Server、Scheduler、Controller manager、etcd。

API Server是整個系統的對外接口，供客戶端和其它組件調用，相當于“營業廳”。

Scheduler負責對集群內部的資源進行調度，相當于“調度室”。

Controller manager負責管理控制器，相當于“大總管”。

Node節點 

Node節點包括Docker、kubelet、kube-proxy、Fluentd、kube-dns(可選)，還有就是Pod。

Pod是Kubernetes最基本的操作單元。一個Pod代表著集群中運行的一個進程，它內部封裝了一個或多個緊密相關的容器。

Docker，創建容器。

Kubelet，負責監視指派到它所在Node上的Pod，包括創建、修改、監控、刪除等。

Kube-proxy，主要負責為Pod對象提供代理。

Fluentd，主要負責日志收集、存儲與查詢。 

那么，K8s有什么樣的優缺點?

我們知道，Kubernetes并不是市場唯一的容器管理平臺，但仍然受到極大地歡迎。我們來看一下原因。

• 使用簡單。利用Kubernetes，容器化的應用程序可以只編寫一次，就能夠在所有類型云供應商以及私有云上運行。
• 快速簡捷。開發人員可以快速部署應用程序。
• 降低硬件使用量，可以減少40-50%。
• 開源社區大。Google將其發布為開源項目，吸引了1000+的社區貢獻者，34000次commit。

與此同時，K8s有著不可規避的缺點。

• 首次部署比較艱難，困難度很高。
• 作為容器的第三方管理系統，容器本身的缺陷影響K8s提供的服務。
• Kubernetes欠缺的領域是調度器。

隨著云原生的深入發展，容器技術再次彰顯其價值，其中Kubernetes作為容器的編排、管理平臺或系統，將會發揮至關重要的作用，前途不可限量。

......

好了，云原生、容器技術、K8s終于和盤托出，我也可以跟女朋友交差了。