從風口浪尖到十字路口，寫在 Kubernetes 兩周年之際

作者｜張鑫

編輯｜小智

作為一個開源項目，Kubernetes 的發展速度之快著實令人咋舌。發布至今，2 年時間，Kubernetes 在 GitHub 上的活躍度就已經超過了 99.99% 的項目。這短短的兩年間，到底發生了什麼？可預見的未來里，Kubernetes 又會扮演怎樣的角色？

寫在前面

2015 年 7 月 21 日，Google 宣布成立 CNCF 基金會，並正式發布 Kubernetes 1.0 版本。經過 2 年多時間的迅猛發展，Kubernetes 已經從昔日的小樹苗長成了蒼天大樹，甚至有人說 Kubernetes 已經贏得了容器之戰。而就在前段時間，GitHub 宣布他們已經全部切換到 Kubernetes 集群，京東也表示他們有超過 60% 的線上業務跑在 Kubernetes 上，這些典型案例無疑給 Kubernetes 社區注入了一針強心劑。

回顧這兩年，容器生態圈到底發生了哪些有意思的事情？Kubernetes 經歷了哪些成長和變化？Docker、Mesos、OpenStack 等相關開源項目了？在 Kubernetes 2 周歲之際，InfoQ 邀請才雲科技 CEO 張鑫來為大家剖析解讀這個來自 Google 的開源項目發展背後的風風雨雨。

1

生於地震、起於亂世：Kubernetes 發展回顧

皚皚白雪下的避暑山莊

2014 年美國的秋季，寒意來得格外早；而在 Google 內部，一場火熱的「地震」卻轟轟烈烈地展開，公司內部稱之為 「Ursquake」（地震 earthquake 的諧音）。原來，這皆起源於 Google Technical Infrastructure 的老大，瑞士籍 Senior Vice President，Urs H?lzle。Google 公司組織架構的頂層由眾多 PA（Product Area）構成，Urs 所領導的 Technical Infrastructure PA 負責管理 Google 上百個數據中心、逾百萬台機器的基礎架構，為公司內部所有其他業務 PA（例如廣告 PA、移動和媒體 PA 等）提供「算力」支持；而這套基礎架構，則以 Cluster Management 生態體系為核心，通過全容器化管理、分散式存儲、軟體定義網路這「三駕馬車」，為上層的生產業務（如 Google Search）和批處理任務（如大數據和深度學習）提供外界難以匹敵的功能、性能、和穩定性的保障。

「酒香也怕巷子深」，這套 10 年間飽含上百位 Google 精英工程師的工程傑作，無奈也只能作為業務支持和公司的成本中心；而基礎架構的工程們，每每在提交升職申請時，也只能以「支持了什麼業務」、為公司「省了多少錢」為度量，頗有為人做嫁衣的感慨，少了諸如廣告 PA 的同事們「為公司掙了多少億」的意氣風發。

Urs』 earthquake，即 Ursquake，正是看到了 2014 年雲計算的大潮和 AWS 的成功，旨在將幕後英雄推到台前，將 Google 內部一流的基礎設施變成公開的盈利產品，將 Technical Infrastructure 這一成本中心變成公司的利潤中心。雖然當時在已經上雲的企業里，AWS 在 14 年的市場佔有率已經超過了 80%，但整體上雲的公司比例甚微，Urs 和 Google 志在啃下還未開採過的蛋糕。

「理想很豐滿、現實很骨感」，志向在落地時卻遇到了兩大難題：

AWS 的先發優勢和產品成熟度優勢如何趕超?

PaaS 和 IaaS 產品之間的矛盾如何解決：Google 的 公有雲 PaaS 產品 AppEngine 雖有很強的託管性（自動部署、運維），但靈活性較差（只支持固定語言和中間件）；而 IaaS 產品 Compute Engine 雖然靈活性高（近似裸機的可配置性），但管理性很低（用戶自行進行應用安裝、維護、配置）。

為了解決這一難題，2015 年的 3 月，在皚皚白雪覆蓋下的避暑山莊 Woodloch 里，舉行了閉門 Google Cloud Summit，經一致討論決定，解決上述問題的核心，就是通過推出開源的容器編排管理系統 「Project 7」，利用開源社區迅速圈粉、打造生態、「shape people』s mind」，進行市場顛覆。同時，這一開源系統既提供了底層的容器、網路、存儲等配置項，又提供了豐富的管理功能，從而打破了上述 PaaS 與 IaaS 產品在靈活性與託管性之間的矛盾。而在問世之後，「Project 7」也很快更名為「Kubernetes」。

標誌性的 1.0 與 CNCF

Kubernetes 站在了 Google 內部久經考驗的容器管理系統 Borg 的肩膀上；同時也吸取了旨在替代 Borg 但是沒有成功的 Omega 項目的失敗經驗。Omega 項目出現的動機，就是為了解決 Borg 里控制節點（Borgmaster）單體化嚴重、與集群管理生態中其他組件互動不夠、使用和配置極其複雜等問題；而 Omega 項目的失敗，則要歸咎於工程上無法解決 Omega 調度精度與吞吐量的矛盾、從 Borg 到 Omega 的平滑過度等挑戰上。Kubernetes 則很好地規避了上述問題。

2014 年 6 月 6 號，在這一個吉利的日子裡，Kubernetes founder 之一 Joe Beta 在 GitHub 上合併了第一個 GitHub commit；在另外兩位早期創始人 Brendan Burns 和 Craig McLuckie 的帶領下，Kubernetes 團隊迅速擴大，其中包括了在 Google 內部曾經帶領 Omega 項目的 Brian Grant 和 Borg 技術帶頭人 Tim Hockin。一年之後，2015 年 7 月 21 日，Kubernetes 宣布發布正式 1.0 版本，達到生產可用。隨後，Kubernetes 在以每季度一個新版本的速度快步向前發展，在兩歲生日時已經問世了 1.7 版本。

伴隨著 Kubernetes 1.0 的發布，Cloud Native Computing Foundation（CNCF）也同時宣布問世，從此為 Kubernetes 撐起了一朵強大的法律、運營、項目維護的保護傘，讓 Kubernetes 項目自身可以專註在技術創新上。與 Apache 基金會截然不同，CNCF 並不會把自身的組織架構和管理模式強加在其成員項目上，而是讓其成員項目如 Kubernetes 更加自治化地自我管理，並提供如下維度的幫助：

生態綁定：將緊密圍繞 Kubernetes 的插件項目（如 linkerd、fluentd、promethues）放在同一個 CNCF 生態下，形成有機的綁定。

法律保護：保障 Kubernetes 的商標、Logo、License、專利、版權等被合理使用和消費。

市場推廣：通過 meetups、K8sPort、Kubecon、Blog、Twitter、新聞媒體等線下、線上活動對 Kubernetes 等技術進行推廣。

培訓認證：制定規範、流程、課程來對 Kubernetes 等技術進行普及和相應的盈利。

最後，協調不同廠商之間的關係和競爭。

在「競合」亂世中突圍

Docker 公司帶火了容器技術，也讓幾乎所有的雲計算廠商意識到了新的機會。早在 2009 年問世的 Apache Mesos 項目也在 Docker 問世後通過與 Docker 的整合煥發了第二春，並定位為基於容器的數據中心操作系統（Data Center Operating System, 即 DCOS），在一定程度上與容器集群管理平台 Kubernetes 發生了定位上的重疊。而 Docker 公司也隨後意識到容器自身只是一個輕薄的、底層的運行載體，很難大規模盈利並推動企業在複雜生產環境下使用；因此也開始研發自帶的集群管理工具 Docker Swarm, 並在 Docker 1.2 版本後將 Swarm 集成在了 Docker 引擎中，引發了社區的一片爭議。而後 Docker 公司推出的 Swarmkit，更是將其進軍集群管理領域的雄心壯志昭示於天下。

Kubernetes 的領導者們從一開始就意識到了生態「競合」關係的重要性，在一路上打出了「中立」的旗號，博得社區的認同和好感；同時一直努力支持底層不同的容器運行時和引擎，逐漸解除對 Docker 的依賴。在 Kubernetes 嬰兒時期，領導者們選擇了更加討好社區的「老好人」做法，通過藉助更多資源幫助自己高速成長。早在 2015 年 5 月，當 Kubernetes 宣布支持除了 Docker 以外的新的容器運行時 AppC 和 rkt 時，Kubernetes 的產品經理 Craig McLuckie 就專門發博客表明此舉並非是要替代 Docker，並大肆讚揚了 Docker 為生態所做的貢獻。而在更早的 2015 年 4 月 22 日，Kubernetes 官方博客專門報道了 Mesosphere 將 Kubernetes 集成進 DCOS 的消息。

隨著 Kubernetes 的壯大，在 2016 年 Kubernetes 愈發明顯地贏得了容器管理之戰時，Kubernetes 對於其他「兄弟項目」的態度也愈發的強勢，例如 2016 年 Kubernetes 佈道師 Kelsey Hightowers 和 Docker 高層在 twitter 上的爆發的口水戰、在 2016 年西雅圖 KubeCon 的多個主題演講中直白地宣示著 Kubernetes 的領導者地位、到 Kubernetes 社區放大對 container runtime、network plugin 等抽象介面的投入。

連橫合縱、落地結果

一個開源項目的壯大，除了領頭人和技術社區，還需要眾多廠商的支持和有說服力的用戶群體。在 2015 年 7 月發布 1.0 之際，Kubernetes 的合作夥伴、廠商、用戶還只是聚集在早期貢獻者如 Red Hat、Mirantis、Rackspace、CoreOS 和區區幾個名不見經傳的創業公司。伴隨著 Kubernetes 的一個個裡程碑式的版本發布，Kubernetes 的功能性、穩定性、實用性得到了不斷升華，也吸引了眾多 500 強大廠紛紛參與進來，變成了合作夥伴、廠商和終端用戶：

2016 年 Q2-Q3: 以 Mirantis 為首的 OpenStack 廠商積極推動與 Kubernetes 的整合，避免站在 Kubernetes 的對立面，成為被 Kubernetes 推翻的「老一代技術」。

2016 年 11 月，CNCF 與 Linux Foundation 聯手，正式推出 Kubernetes 認證服務，進一步推動 Kubernetes 的商業化落地和普及。

2016 年 11 月，在西雅圖召開的 KubeCon 會議上，包括 Pearson、Box 等數十家 Kubernetes 終端用戶向世人展示了 Kubernetes 在其生產環境中的成功應用。

2016 年 12 月，伴隨著 Kubernetes 1.5 的發布，Windows Server 和 Windows 容器可以正式支持 Kubernetes，微軟生態完美融入。

2017 年 2 月，Kubernetes 官方微博報道了中國京東用 Kubernetes 替代了 OpenStack 中的大量服務和組件，實現全容器化私有雲和公有雲的建設，中國的 Kubernetes 用戶案例首次登上國際舞台。

2017 年 6 月，在北京召開的 LinuxCon 上，中國公司報道了 Kubernetes 在中國金融、電力、互聯網行業的成功案例，標誌著 Kubernetes 的終端用戶群體走向國際化。

2 歲生日之際，Kubernetes 的用戶涵蓋了諸如金融（摩根斯坦利、高盛）、互聯網（eBay、Box、GitHub）、傳媒（Pearson、New York Times） 、通信（三星、華為）等行業的龍頭企業。

2

State of the Kube：Kubernetes 項目現狀

99.99%！

簡單地回顧完歷史，我們概覽下 Kubernetes 今天的模樣。如果用一個詞來形容 Kubernetes 項目的當今狀況，那就是 —— 活躍；如果非要給這個詞加一個期限，筆者希望是 —— 十年。通過一組客觀的官方數據，我們可以感性地體會到 Kubernetes 項目的活躍程度。

從 2015 年 7 月到 2017 年 7 月兩年時間，Kubernetes 的主要代碼倉庫（github.com/kubernetes/kubernetes）從 1.0 版本時的 10000+ commits 變成了如今的近 50000+ commits，增長近五倍。

發展至今，Kubernetes 已經從一個單體的龐大代碼庫（github.com/kubernetes/kubernetes）向一個生態型多個代碼庫演進；除了主體代碼庫之外，還有約 40 個其他的插件代碼庫和超過 20 的孵化項目。

截止今日，Kubernetes 生態社區總共有 2505 個開發者，來自於 789 個參與公司

有意思的是，「大象現象」同樣存在於社區貢獻者中，前 10 的貢獻者貢獻了超過 26% 的代碼。

Kubernetes 的主要代碼倉庫已經獲得了近 25000 個 GitHub Stars，遙遙領先於早期的競爭者（Swarm 和 Mesos 均不到 5000 顆星）。

CNCF 在全球召開了超過 200 場線下 meetups，僅在中國就有過十場。

而最具代表性、最直觀的一個數據，莫過於：Kubernetes 的 GitHub 活躍度已經超過了 99.99% 的項目！

快而不散

社區的發展之快如今甚至超過了 Kubernetes 創始人的預期。根據 2016 年 11 月西雅圖 KubeCon 上發布的數據，Kubernetes 的締造者和帶頭人 Google 所貢獻的代碼量約為 40%+，超過半數的貢獻來自 Google 以外的公司和社區開發者。2000 多位的貢獻者在高速推動項目發展的同時，也為保證開源項目的一致性、穩定性和中立性提出了極高的挑戰。在 2017 年 6 月 2 號位於美國聖何塞三星公司召開的 Kubernetes Leadership Summit 上，當 Kubernetes 創始人之一 Brendan Burns 被問到是否需要更多的社區貢獻者的時候，Mr Burns 的回答卻是： 「Maybe not」。當然，Kubernetes 的領導者和 CNCF 絕非等閑之輩，也提出了從管理和技術層面兩個維度的解決方案。

首先在管理維度上，CNCF 與 Kubernetes 社區一起正式提出了管理架構（如圖 1 所示），來幫助更好地分散式地運營這一開源項目，其中包括：

Steering Committee：作為最高決策董事會，肩負了把握項目方向、定義文化、規則、管理團隊等使命。同時 Steering Committee 要時刻提醒自己最大程度放權，將具體任務委託給下面相應的管理團隊。目前 Steering Committee 設有 13 個席位，由提名、競選產生。

Special Interest Groups（SIG）：擁有和負責具體的子代碼庫和功能模塊。

Working Group（WG）：根據實現短期任務的需求臨時組建，或負責討論早期的功能點。

Committee: 負責討論敏感話題（如安全、行為規範），由閉門組織討論並推行（不面向社區）。

這樣的管理組織架構，保證了整個 Kubernetes 的社區能夠在有機的層次領導下快而不散，既自治又集權。除了管理，Kubernetes 的項目架構也在進行調整和演化，通過更加模塊化、解耦合、分層次的架構，讓數千位貢獻者能夠高效地分散式協作而無需做自己的 fork 版本。

圖 1. Kubernetes 項目管理組織架構【1】

苦練內功

如果說早期 Kubernetes 能夠迅速走到聚光燈下是因為頂著 Google 的光環，那發展至今天它被各行業用戶廣泛採納和應用則是得益於它的真功夫：功能性、穩定性、可擴展性、安全性。直到今天，Kubernetes 社區最大的努力還是花在苦練內功上，致力讓每個季度的新版本都有十足的飛躍。以推出新功能為例，我們可以從下面的數據【2】上看到社區的努力和加速的腳步：

在 2017 年 3 月份推出的 Kubernetes 1.6 版本中，總共包含 29 個新的功能點，其中 8 個 Alpha 版本，12 個 Beta 版本，9 個 Stable 版本。1.6 版本關注的領域如下：

存儲 (10 個新功能點)

調度 (5 個新功能點)

集群生命周期管理 (4 個新功能點)

認證授權 (RBAC)

在 2017 年 6 月推出的 Kubernetes 1.7 版本中，則一口氣發布了 43 個新的功能點，其中 Alpha 版本占 31 個，Beta 占 6 個，Stable 占 3 個。而關注的領域也有了較大的變化：

Apps 子模塊讓複雜應用的部署和管理更加的便捷。

Federation 子模塊讓 Kubernetes 可以無限擴展同時提供跨域多活和負載均衡。

Node 子模塊更加深化 Container Runtime Interface (CRI) 的整合，加速對容器的普適性並實現與 Docker 的解耦合。

Auth 子模塊通過更完善的證書管理、加密、審計來提升安全性。

除了上述功能性的飛速完善，Kubernetes 開發者更是在可擴展性、穩定性和可靠性上下足了功夫。以集群規模為例，兩年前的 Kubernetes 1.0 版本只能支持單集群 100 個節點，而在 2017 年 3 月份發布的 1.6 版本中，單集群已經可支持 5000 個節點，同時 API 相應延時更小。而集群聯邦功能更是可以跳出單集群的限制，讓集群規模幾十倍、上百倍的增加。

社區格局與主要玩家

隨著 Kubernetes 的壯大，其社區也時刻進行著動態的演化。尤其在國內，也出現了從早期受其他陣營廠商擠兌到現在眾人蜂擁而至的變化。從貢獻者上來看，Google 仍以 40%+ 的貢獻率領跑社區，而個人開發者的貢獻量總和也一躍超過了 25%。相比之下，紅帽、CoreOS 等早期參與的公司仍持續投入。從 2016 年開始，中國力量也開始登上國際舞台，以代碼貢獻度為例，如圖 2 所以，中興、華為、浙大、才云為貢獻最高的 4 個來自中國的公司或組織，並進入了全球 top 25 貢獻度排行榜。除此以外，來自華為、才雲的演講也被選拔連續多次登上 Kubernetes 的國際會議 KubeCon。

2 年來，Kubernetes 的廠商格局也不斷演化。在美國，Red Hat、CoreOS 作為 Kubernetes 項目參與者，紛紛推出了自己的商業發行版。早期的 Kubernetes 創業公司如 Kismatic、Deis 在過去一年中紛紛被併購（Kismatic 被 Apprenda 併購，而 Deis 則被微軟收購），顯示了大廠對 Kubernetes 方向的看好。此外，Kubernetes 早期的三個 founders 也均已不在 Google，其中的 Joe Beta 和 Craig McLuckie 也創辦了 Kubernetes 產品公司 Heptio，立志讓企業更方便的使用 Kubernetes。

在巨頭一端，除了 Google 理所當然的大張旗鼓支持 Kubernetes 並提供商業的 Google Container Engine（GKE），微軟也毫不手軟，挖走了 Kubernetes 創始人兼原 Google 工程師 Brendan Burns 並收購 Deis。反觀 AWS，其對於容器的重視程度毫無疑問，無奈在 Kubernetes 問世之前 AWS 自己研發了 ECS；如今 AWS 雖然支持 Kubernetes，但礙於 ECS 的存在，AWS 並沒有在 Kubernetes 上發力過猛，反而顯得束手束腳，影響了開發者體驗。這不禁讓人期待，若干年後再看 Google 當初用開源 Kubernetes 作為秘密武器來牽制 AWS 這一奇招兒是否會真的奏效。

在國內，Kubernetes 的熱度絲毫不減，才雲、時速雲、輕元科技等創業公司在成立之初便以 Kubernetes 作為其底層容器管理平台。隨著 Kubernetes 熱度的增加，騰訊、華為、京東等大商也紛紛投入了 Kubernetes 陣營。而受大勢所趨，一些之前在 Mesos、Swarm 陣營的創業公司也紛紛湧入 Kubernetes 大潮。還有一類公司例如 Rancher，則以兼容並包的定位，在支持自研調度框架、Swarm、Mesos 之外，同時兼容 Kubernetes。

圖 2. Kubernetes 社區的主要貢獻公司【3】

3

實踐得真知：Kubernetes 的落地與應用

數據之王

在全球範圍內，除了各大公有雲已經競相支持 Kubernetes，在企業私有雲場景下 Kubernetes 也在互聯網、金融、通信、能源、電商和傳統行業中獲得了極為廣泛的應用，並有適配底層裸機環境、OpenStack 環境、VMWare 環境等多種案例。僅在中國，Kubernetes 就已經擁有了諸如京東、國家電網、錦江集團、上汽集團、某大型銀行組織等 500 強企業用戶。

特別是在私有雲場景下，Kubernetes 獲得了巨大的成功：根據 2017 年 5 月美國權威調研機構 451 Research 與 CoreOS 發布的調研報告【4】表明，80% 的美國受訪企業認為 Kubernetes 足以取代 PaaS，其中 75% 的企業已經在使用 Kubernetes 來管理其容器雲平台，以絕對優勢領跑其他容器管理工具。在中國市場，2017 年 6 月 Kubernetes 中國社區 K8SMeetup 曾組織了國內首個針對中國容器開發者和企業用戶的調研；近 100 個受訪用戶和企業中給我們帶來了有趣的關於 Kubernetes 在中國落地狀況的觀察：

如圖 3 所示，在受訪企業中，Kubernetes 以高達近 70% 的使用率成為最受歡迎的容器管理系統。

如圖 4 所示，在受訪企業中，除了簡單的 Web 應用，越來越多的有狀態、數據類應用也運行在了 Kubernetes 平台上。

圖 3. 容器管理工具在中國受訪企業用戶中的使用分布

圖 4. 在中國受訪企業用戶中，Kubernetes 平台上運行的應用類型分布

The Good, the Bad, and the Ugly

在數據之外，我們試圖透過現象分析本質：為什麼 Kubernetes 這麼流行？在落地過程中，用戶最喜歡和最痛恨 Kubernetes 的哪些方面？Kubernetes 在落地的過程中存在哪些大坑？圖 5 和圖 6 總結了 K8SMeetup 容器調研中通過受訪企業中發現的一些端倪。

圖 5. 中國受訪企業用戶最喜歡 Kubernetes 的方面

圖 6. 中國受訪企業用戶最不喜歡 Kubernetes 的方面

特別針對 Kubernetes 在企業落地中的不足和陷阱，筆者結合自己的切身體會總結如下：

上游默認的 Kubernetes 配置都是基於公有雲環境或擁有完善的 IaaS 層 API，而對於私有雲裸機環境的支持相對欠缺，需要進行額外開發。

Kubernetes 的學習曲線較長，基於命令行和 JSON/YAML 的配置文件學習成本不低。

傳統行業技術債務較重、單體或有狀態應用較多，適配 Kubernetes 的現代微服務理念需要額外的二次開發工作或對 Kubernetes 高級配置項的深入理解。

Kubernetes 集群的部署較為繁瑣，尤其是在線升級缺乏成熟的上游開源方案。

上游的開源 Kubernetes 項目仍存在一些功能死角，例如多維度多指標的彈性伸縮、對於硬碟和網路資源的細粒度隔離、對於資源配合的合理配置等。

然而好消息是，隨著 Kubernetes 的快速迭代和開源社區的強有力支持，上述問題有望在 2017 年內獲得突破性進展。

基礎設施的解放、自由、與開放

Kubernetes 是雲原生（Cloud Native Computing）哲學的體現，通過容器技術和抽象的 IaaS 介面，屏蔽了底層基礎設施的細節和差異，可實現多環境部署並可以在多環境之間靈活遷移；這樣一方面可以實現跨域、多環境的高可用多活災備，另一方面幫助用戶不必被某個雲廠商、底層環境所綁定。

如圖 7 所示，在中國的容器調研受訪企業中，裸機環境、OpenStack、虛擬化、多種公有雲供應商形成了 Kubernetes 運行環境的「四分天下」格局。而 Kubernetes 恰恰給了用戶足夠的靈活度，可以讓其自身的業務系統快速部署、運行在不同的底層環境、數據中心、甚至公有雲之上，實現業務高可用和商務利益最大化。

筆者相信在相當長的一段時間內，由於存量投入，多基礎設施的混合部署會成為 Kubernetes 運行的主流，而將 Kubernetes 綁定到某一種特定的 IaaS 一定違背了雲原生的哲學和 Kubernetes 的設計初衷。此外，筆者相信隨著 Kubernetes 的成熟和用戶的成熟，在新的增量市場環境中，如同 Google 一樣用 Kubernetes 直接管理數據中心（運行在裸機之上，同時與對應的存儲、網路方案打通）則會成為最長期的趨勢和最合理的選擇。

圖 7. 中國受訪企業運行 Kubernetes 的底層環境分布

4

十字路口：Kubernetes 的彷徨、挑戰、應對、與未來

剩下的 90% 問題

Kubernetes 如今獲得了巨大的成功，然而在它的領導者的眼裡，會給這個成功打多少分？在 Kubernetes 技術帶頭人 Tim Hockin 2017 年 6 月發表的 Kubernetes 現狀總結中，他指出：「所有簡單的問題都已經得到了解決，還剩下什麼？那是 90% 的疑難雜症！」 而他口中的這些疑難雜症，包括：

代碼健康度：測試覆蓋率有待提升、測試穩定性有待提升、很多代碼模塊亟待重構。

開發者體驗：新的貢獻者上手困難、文檔需要完善、現存很多 hacky 腳本難以理解。

穩定性和可預測性需要同開發新功能一樣受到足夠重視。

社區和開源項目的管理要在開放的同時保持一致和可控。

而社區開發者也反饋了 Kubernetes 項目當前發展中遇到的一些問題，例如：

對於新功能如何被選取、映射到未來某個發布版本中的決策流程感到不夠明確。

新功能的討論、設計和開發門檻極高，溝通成本和設計文檔的審核延時阻礙了生產效率。

SIG 產品經理對於新功能產品規劃的幫助和理解不夠出彩。

此外，持續完善 Kubernetes 的功能，讓它能夠適用更多的場景也是技術社區投入最多精力的地方。雖然 Kubernetes 1.7 已經解決了「世界上 10% 的問題」，還有另外 90% 的問題亟待解決，而這些問題分布的領域從圖 8 中可見一斑：節點、API、Container runtime、網路、存儲、跨域集群聯邦、複雜應用管理是需求最多、挑戰最大的領域。

圖 8. 新功能需求個數按照 SIG 領域的分布圖【5】

除此以外，如何讓全球數千名開發者高效協作也是巨大的挑戰。雖然 Kubernetes 項目在組織架構和管理上分成了獨立的數十個 SIG，但是主代碼倉庫並沒有很好的實現解耦合，不同 SIG 所負責的代碼還是同處一個 GitHub 代碼倉庫中。我們需要一個更加模塊化的 Kubernetes 項目組織架構，讓不同的 SIG、領域、子模塊更加獨立，減少或者明確相互的依賴關係。為了改變這一現狀，新的 Kubernetes 架構也被提出，如圖 9 所示。

最後，儘管 Kubernetes 已然從 2016 年開始變成了技術領域 - 尤其是雲計算領域 - 最潮流的技術，它的真正統治性落地還需要時間和不懈的努力。如圖 10 所示，根據 Datadog 統計，還有超過 50% 的容器用戶並沒有採用容器管理工具（包括 Kubernetes），而又根據另外 RightScale 的報道，若整合公有雲和私有雲市場來看，目前使用最多的管理平台是 AWS 公有雲 ECS。因此，Kubernetes 要實現其容器管理霸主地位仍然任重道遠。

圖 9：新的模塊化的 Kubernetes 架構【6】

圖 10. 容器用戶同時使用容器管理工具的比例

5

Kubernetes 四歲時

回顧了歷史，審視了今日，我們再拋開繁瑣的技術和項目細節，大膽暢想下 Kubernetes 四歲時的模樣。想像空間很大，細化的功能很多，而筆者只想對比 Google 內部的集群管理系統，為 Kubernetes 暢想兩個大的方向：

從容器管理到集群管理

如今我們都在談論 Data Center Operating System (DCOS) 或集群管理，並往往容易將「集群管理」與 Kubernetes（或者 Mesos、Swarm）劃等號。然而以 Google 為例，其內部的集群管理是一個完整的生態，而 Borg（常說的 Kubernetes 的 Google 內部版）則是這個生態中的成員之一。具體來說，Borg 也好，Kubernetes 也好，更多的是容器管理／應用管理／服務管理；而一個完整的集群管理系統，或是 DCOS，則還涉及到節點管理、硬體管理、SLA 管理、網路管理、安全管理、運維管理等眾多功能組件。

作為兩歲的 Kubernetes，從問世之初專註於容器服務管理成績斐然，而我們真正要實現如 Google 一樣純粹的容器化數據中心（沒有且不需要 IaaS、PaaS 的分層），則需要圍繞 Kubernetes 建立一個完整的集群管理體系。筆者認為依據現在 CNCF 和 Kubernetes 的定位，並隨著企業對於 Kubernetes 使用深度的增加，在 Kubernetes 四歲之際，會布局成一個完善的容器化集群管理生態體系。

6

從自動化到智能化

Kubernetes 通過其 Declarative（聲明式）設計模式和 Control loop 控制閉環實現了眾多功能的自動化操作，例如 Pod 的生死控制、Replica 數量的伸縮控制等。然而，在人工智慧盛行的今日，「自動化」與「智能化」之間還存在著鴻溝，Kubernetes 當前的自動化程度也並沒有完全消除用戶學習和使用 Kubernetes 的門檻。例如 Kubernetes 最經典的 Declarative 設計模式雖然相比 Imperative（祈使式）的設計模式有了很大進步，但是用戶仍然需要按照規則和語法預先將應用的配置表示出來，而選擇什麼樣的配置仍需要大量的人工經驗和試錯。Kubernetes 還提供了很多配置選項，仍需要用戶去憑藉經驗或試錯進行合理的配置。

此外，Google 內部使用的 Borg 真正做到了「調度一切任務」，不論是無狀態微服務應用，還是大數據、深度學習業務，都通過 Borg 平台統一的管理；而大數據和深度學習業務也正是利用了 Borg 提供的敏捷分散式計算，極大地提升了其自身的性能。我們期待在 Kubernetes 四歲時，它能成長得更智能，並用自身的算力做更智能的事情。

7

附錄

https://docs.google.com/presentation/d/1pc-nayPpUZQlS10VPKqc-fb0Y3FXeSLeGAJ81g8NsCg/edit#slide=id.g22bd1761f4_0_57

https://docs.google.com/spreadsheets/d/1NVZmn5u_Xkezqe9ZA6ZZivj1KEJCL0DsMMahbcjIfws/edit#gid=38455014

http://stackalytics.com/?metric=commits&project_type=kubernetes-group&release=all

http://www.bitpipe.com/detail/RES/1497557025_989.html

https://docs.google.com/presentation/d/1XXHk-oy-8eeqGMGRHQwOolOV4hFHlLu-KDpoXuU-C74/edit#slide=id.g22c01c4c8e_0_0

https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.g21b1f16809_5_51

8

彩蛋

識別下圖「二維碼」，免費下載一本可能是最值得推薦的 Kubernetes 電子書！

作者介紹

張鑫，才雲科技創始人兼 CEO。曾為美國谷歌資深軟體工程師，並 6 次獲得谷歌副總裁和總監頒發的即時獎勵。 曾作為技術帶頭人從事谷歌容器化集群管理系統的研發，自動化管理 95% 以上的谷歌數據中心伺服器。2015 年參與了谷歌公有雲的產品設計與研發，開發的圖形化一鍵部署、應用商店、應用部署經理等產品上線後即獲得用戶廣泛使用。

張鑫在美國卡內基梅隆大學（CMU）獲得計算機博士學位，期間在分散式系統和網路安全領域的頂級國際會議發表學術論文數十篇，被引用上千次；研究成果曾被美國 Economist、英國 BBC、瑞士 RTS 電視台等國際媒體報道。張鑫曾獲杭州市「特聘專家」、「2017 萬物生長年度新銳人物」、「教育部優秀留學生」、「清華大學優秀畢業生」、「北京地區優秀畢業生」等稱號，併入選微軟加速器上海」黃埔一期」學員。

今日薦文

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！