導言
2014 年，Google 公佈開源專案 Kubernetes，它由 Joe Beda、Brendan Burns 以及 Craig McLuckie 帶頭建立，並於 2015 年 7 月 21 日正式釋出 Kubernetes v1.0 版本。
微軟 Azure 在 2014 年便引入 Kubernetes 以及 libswarm，開發者可以在 Azure 上使用 Kubernetes 管理 Docker 容器。然而，將 Windows 的應用執行在 Linux 上，或者將 Linux 應用執行在 Windows 上在當時無法實現。

2016 年 12 月， Kubernetes 1.5

Kubernetes 眼下已成為眾多容器管理系統核心——比如 CoreOS 公司的商務平臺 Tectonic。最近，微軟也宣佈已將 Kubernetes 整合到其公有云上。

“現在，我們支援 Kubernetes，它會比原來更加好用，並且宣佈 Azure 容器服務的預釋出版本，”Azure 的計算總監，Corey Sanders 在微軟 Azure 釋出的時候說道，“對 Kubernetes 本地有更高等級的支援，會為容器編排引擎提供了另外一個開源選擇。”

微軟也支援 Docker Swarm 和 Mesosphere 的 DC／OS，但是似乎 Kubernetes 更加有掌控容器編排界的趨勢。隨著事物的發展速度變快，Kubernetes 可能並非容器界的唯一一匹快馬，但是它確實是很多廠商的選擇。它的地位至此，值得深思。

開源軟體公司 Red Hat 的高階產品經理，同時也是決定將 Red Hat 開源 OpenShift PaaS 進行標準化的小組成員之一的 Joe Fernandes 對容器管理系統非常瞭解。
2013 年，該公司想要建立一個本土的容器管理系統，那時，公司看到了 Mesos，並且跟 Google 討論 Kubernetes 的開源計劃，Joe Fernandes 說，“就功能上來說，Kubernetes 遠遠超過

Mesos 和 Marathon。”
Gartner 研究副總裁 Richard Watson 說，“這表明微軟也希望成為 Kubernetes 生態系統內的重要貢獻者。使用者期望 Kubernetes 在 Windows 上正常工作，未來能夠有 Windows 的叢集功能，這對混合環境的IT部門很重要。”

Kubernetes 如何從眾多容器編排工具中脫穎而出

但是對於 Fernandes 來說同樣重要的就是 Google 在容器上的繼承，他說，“就像他們之前說的那樣，他們執行的所有東西都已容器化。Kubernetes 不是 Borg（Google 的資源編排軟體），但是編寫 Kubernetes 花費了他們過去使用 Borg 十幾年的經驗。

另外一個很重要的東西就是（或許對於像 Red Hat 這樣的開源公司來說並不意外），Kubernetes 專案現在隸屬於 CNCF 旗下，Google 則是開源專案的贊助商之一（在 Fernandes 看來，這絕對是一個加分項）。“我們在 Kubernetes 開源之前就跟 Google 聊過，但是現在 Kubernetes 專案發展很快，有很多廠商支援它，它增加新功能的速度非常快，能夠執行很多不同型別的工作負載。”Fernandes 說道。

相比之下，他指出，雖然 Mesos 有 Apache 的支援，但是沒有像 Kubernetes 那麼多廠商支援。“只有 Mesosphere——雖然有幾個廠商確實在雲的選擇（比如微軟）上提供了幾個選項。”
Fernandes 認為原因是 Mesos 的程式碼庫不容易拓展，也不容易在它上面建立服務。他說，“我覺得他們的開源社群做得不太好。”

在他認為，Kubernetes 最大的競爭對手是 do-it-yourself 實現方法。但是現實就是，容器領域擴張速度非常快，這也使得實現方法不切實際。

Fernandes 說，“Kubernetes 每年更新 4 次，Docker 每年更新 3-4 次，如果自己動手建立這些解決方法會非常耗時間，所以大多數企業都選擇更有效率地建立應用以及讓第三方公司來建立編排平臺。”

現在有一些容器編排平臺供你選擇。按照道理來講，Me sos 和 Docker Swarm 短時間內是不會被淘汰掉的。但是 Kubernetes 也有理由繼續擴張式發展。

目前，類似於像 Tectonic 這樣的平臺，以及完全開源解決方案（比如 OpenShift）都是建立在 Kubernetes 的技術之上的，未來，會有更多的產品（不僅限於上述兩種產品型別）選擇 Kubernetes 作為底層技術。

Kubernetes 的優勢

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 被普及，但是這個問題 Kubernetes 眼下還無法解決。鑑於崩潰的傾向，很多工程師猶豫要不要在容器中執行“關鍵任務”負載，畢竟儲存資料並不是容器的設計初衷。慣例是，大家會使用那些在崩潰時不會在容器內引起宕機的應用程式。

Kubernetes 的未來

即使有這樣那樣的缺點，也不阻擋不了像 Goldman Sachs、Box、SAP 和紐約時報等公司使用 Kubernetes 的步伐，他們將 Kubernetes 平臺列入了他們下一個資料中心的計劃。

應用程式是很多商務的血液。很多公司正在努力滿足日益加快的部署時間和高質量應用程式的需求。這些需求就是開發人員為什麼要湧向容器的原因。隨著容器技術的爆發，Kubernetes 在市場中也找好了自己的定位。平臺領域還有很多潛在效能可以挖掘，但是如果規模變大的還，它是很難管理的。在產品中，初始設定和大規模執行 Kubernetes 之間存在著巨大的鴻溝。在接下來這一年中，第三方管理平臺之間的競爭將會很激烈。對於 Kubernetes 來說，不偏離它過去所做的成就顯得尤為重要。如果社群能夠合理地對平臺進行擴容，那麼 Kubernetes 的未來將無可限量。

Kubernetes 2017 發展趨勢

2016 是 Kubernetes 作為開源容器編排工具在技術圈瘋狂圈地的一年。世界範圍內成千上萬的程式碼貢獻者都在爭相為 Kubernetes 貢獻功能。越來越多的公司選擇 Kubernetes 作為最佳工具，實現在生產環境中容器化微服務的高可用。瞭解Kubernetes2016年大事記錄

版本釋出記錄：2016 年 3 月 16 日釋出 1.2 版，7 月 1 日釋出 1.3 版，9 月 27 日釋出 1.4 版，12 月 14 日釋出 1.5 版：

據上圖資料來看，2016 年 Kubernetes 穩定版釋出 34 次，釋出次數相比 2015 年增加了 112.5%，平均釋出間隔為 11 天。2016 年度，K8S 連同 alpha 版和 beta 版共計釋出 111 次。

（Kubernetes 2017 版本釋出時間線）

2017 年，Kubernetes 預計釋出 4 個版本：1.6、1.7、1.8 和 1.9。Github 上顯示，1.6 版本將在三月釋出，釋出頻率基本上保持 3 個月一更的狀態。

據悉，很多應用使用 GPU 可以提升效率，所以 Kubernetes 上游計劃在其 1.6 發行版本中加入 GPU 功能，提升應用程式執行效率。