Kubernetes：過去、現在與未來

本文講的是<b>Kubernetes：過去、現在與未來</b>【編者的話】本文讨論了Kubernetes的過去、現在和将來，包括了Kubernetes的優點和缺點等等。

有些人将自動化、雲計算和人工智能稱為第四次工業革命。IT行業中自動化的日漸興起也就不足為奇，尤其是在應用程式部署與管理方面（我保證這絕不是吹噓）。幾年前，Google宣布啟動一個名為Kubernetes的項目，即大家所熟知的K8s。Kubernetes是一個開源的容器叢集管理器，其目标是成為容器應用程式自主部署與擴充平台。

Kubernetes出自希臘語“helmsman”，由Google于2014年公布。它由Joe Beda、Brendan Burns及Craig McLuckie建立。Kubernetes v1.0于2015年7月21日正式釋出，并立即作為雲原生計算基金會（Cloud Native Computing Foundation）的一部分捐贈給了Linux基金會。

在說明Kubernetes的興起之前，很重要的一點是要了解如果沒有容器，Kubernetes将不複存在。從高層次看，容器與虛拟機類似，不過一個主要差異在于：容器與其他容器共享主控端的核心。之是以說它是主要差異因素，是因為容器共享實體主機的作業系統，這使得它們易于遷移。同時，一台主控端能容納的容器比虛拟機多得多，因為它們共享了核心、庫檔案及二進制檔案。舉個例子，一個虛拟機可能會占用20GB，而一個運作相同應用程式的容器可能隻占用200MB。

容器（不論是Docker或是CoreOS的rkt）讓開發人員可以無縫地專注于運作時的應用程式。靈活應用程式開發過程中碰到淩亂的基礎設施問題的日子一去不複返。使用容器，開發人員隻需要考慮如何正确地擴充、部署及管理新寫的應用程式即可。不過，現有的容器方案自身還不能進行跨多節點環境的容器管理、排程和部署。

Kubernetes在容器環境中是作為該環境的管理與部署引擎而存在的。使用最基本的Kubernetes就可以在實體硬體或虛拟機上排程和運作應用程式。Kubernetes的更進階用法讓開發人員得以從以主控端為中心的世界中脫身，進入一個以容器為中心的環境。

Kubernetes的入門很簡單。有一個REST API用于操作Kubernetes内部的主要元件。雖然Kubernetes被稱為一個平台，但它具有多個元件服務于自身特有的角色。Master是Kubernetes叢集的控制服務（它也被稱之為控制平面）。Master非常重要，因為對那些與它互動的元件來說它起着API調用的作用。它位于主伺服器内，這是叢集單元規則生效及排程服務存在的所在。

<a href="http://dockerone.com/uploads/article/20170113/612b978af6a7d12992749157d73a8854.png" target="_blank"></a>

在主伺服器之下是Kubernetes工作單元，它們定義了相關實體程式設計所要實作的指定工作。雖然最終目标是傳遞一個應用程式，這些單元還是擁有更具體的功能。

Pod：最基本的單元是一個pod，在配置設定容器時，它實際上并不會被配置設定到實體硬體上，而是被配置設定到一個pod上。Pod通常包含了基礎容器或提供單一應用程式的容器。這意味着一個pod裡的所有容器可以共享資料卷和IP空間，進而作為一個單一應用程式進行擴充。

服務：一旦開始建構一個更加強健的容器化政策，“服務”的概念就變得很重要。服務作為資源均衡器，可在容器之間做切換。後端容器可通過一個單一的、穩定的入口與前端應用程式通信。這項功能為使用者提供了易用性和可擴充性。

複制控制器（Replication Controller，簡稱RC）：這些單元的任務是確定在任何時間點都有指定數量的容器啟動及運作。假如出現核心錯誤，一個容器（或一組容器）崩潰，RC會負責啟動一個複制的pod，直到原pod重新啟動上線。一旦原pod再次啟動并運作，RC将殺掉複制的pod。

标簽：盡管标簽不是一個真正的工作單元，但對組織而言卻至關重要。标簽用作組的名稱，讓使用者可以設定一個單元組作為目标或進行操作。讓你可以組織你的容器環境。

在最基本的層面上，這些就是組成Kubernetes平台的實體。

想想如今大家熟知的一項技術，讓我們從虛拟化的視角來說明Kubernetes。Kubernetes裡的Master類似于VMware裡的vCenter。Master知曉叢集的節點以及節點的容量。此外，Master排程和放置Pod與vCenter将虛拟機部署到vSphere主控端相類似。Pod的作用與vApp非常相近，它們都是将多個容器放置在一個扁平化的網絡裡。容器與VM類似，除非被賦予了網絡中定義的路徑，它們互相之間是獨立的。最後，複制控制器與HA類似，RC會持續對環境輪詢以確定正确數量的pod處于運作狀态，如果數量短缺，它将排程一個新的執行個體。

Kubernetes并不是市面上唯一的容器管理平台（其他如Docker Swarm或Mesos），但它是行業首選。為何會這樣？從一個高層次角度看，Kubernetes吸引人的一點是它提供了一個平台，實作容器化應用程式的一次編寫并在各類型雲基礎設施上運作。它将公有雲與私有雲之間存在的複雜的基礎設施差異抽象化掉了。并且，Kubernetes下一步将允許開發人員運作任何他們覺得适合在Kubernetes運作的應用程式。Box的合夥人Sam Ghods相信隻要一個二進制檔案可以運作，那它就能在Kubernetes裡運作。

使用Kubernetes，開發人員可以快速地部署應用程式而無須面對傳統平台所具有的風險（想象一下跨多作業系統環境的橫向擴充）、動态地擴充應用程式以及更佳的資源配置設定。

硬體使用率的下降也是企業推動Kubernetes的另外一個原因。有些公司報告說，由于容器的輕量特性以及（相比傳統架構）更快速殺掉未使用的實體，對硬體的需求降低了40-50%。EBay是Kubernetes著名的支援者及使用者，它聲稱在轉換到該平台後伺服器的開銷支出急劇減少。

最後，Kubernetes的一個最大的優勢是它面向的是社群而不是一個技術規範，這讓它的功能更加強大。Google将其作為一個開源項目釋出，獲得超過1千個社群貢獻者及3萬4千個送出的支援。其社群比Mesos（第二大的競争社群）要大5倍，比所有競争社群加起來還大。

Kubernetes赢得了行業的廣泛贊譽，不過也存在一些顯著的缺點。當涉及初始部署時（擴充時），據說要進行正确地設定會很複雜和困難。它需要一個具有特定技能組的工程師，而這在如今的工程行業很難找到。

另外，Kubernetes是容器的第三方管理系統。容器技術自身存在的缺點和痛苦的成長經曆對Kubernetes能提供的服務也存在影響。

Kubernetes缺少的一個領域是排程器。Kubernetes預設的規化器依賴于應用程式屬主提供的資源配置設定需求，而無視實時的消耗。這一做法将在每個節點上産生資源碎片。

最後，容器内允許運作的負載範圍将限制Kubernetes的普及，不過這是一個Kubernetes無法直接解決的問題。舉個例子，很多工程師對在容器中運作“關鍵性任務”負載會比較猶豫，一是因為其崩潰的傾向，二是因為容器設計之初就不打算用于存儲資料。一個通常做法是隻在容器中運作那些崩潰時不會造成停機時間的應用程式。

即便存在這些缺點，也不妨礙像高盛、Box、SAP及紐約時報這類公司将該平台列為下一代資料中心計劃的一部分。

應用程式已經成為當今多數企業不可或缺的部分。所有公司對更快的部署及高品質的應用程式提出了更高的要求。這些要求也是開發人員湧向容器的原因。随着容器的爆發，若要說Kubernetes對其市場定位不佳的話那是不明智的。這個平台具有很大的潛力，但上了規模就變得難以管理。Kubernetes初始設定與其在生産環境中大規模運作之間存在着巨大的鴻溝。未來幾年，在管理這些部署和負載方面，它将面臨第三方強有力的競争。對Kubernetes而言，不要迷失在過去成就它的因素之中将顯得格外重要。如果其社群能正确地擴充該平台，Kubernetes的未來一片文明。

<b>原文釋出時間為：</b>2017-01-13

<b>本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。</b>

<b></b>

<b>原文标題：</b><b>Kubernetes：過去、現在與未來</b>