如果說2017年的容器技術圈子只能用一個關鍵詞來概括的話，那一定非“Kubernetes”莫屬。

從2017年2月，“Kubernetes”開始頻繁登上各大技術媒體頭條，來自不同維度不同渠道的商業分析和技術文章也紛至沓來。有趣的是，無論是官方報道還是個人評述，無論是直接還是委婉，無一不在透露著一個同樣的資訊：“Kubernetes要贏！”

可是，描述這樣一個連商業實體都沒有的開源專案“要贏”，總是聽起來有些奇怪。

“要贏誰？”

“為什麼要贏？”

“贏了之後呢？”

我們不妨就從這個論斷說起吧。

Kubernetes贏在何處

如果說錯失了Big Data時代的Google實在令人扼腕，那麼Container時代的Google終於靠開源社群打了個翻身仗。雖然在最初的lmctfy專案（Google自研容器）上依然栽了跟頭，雖然同Docker公司共舉容器編排大業的計劃依然吃了閉門羹。但Google還是笑到了最後。

不過，Kubernetes專案的發展絕非一帆風順。它的前期只有一篇不溫不火的B類會議文章Borg來站臺，遠沒有“三大paper”一舉奠定大資料基石那麼耀眼。而在它釋出的之後，炙手可熱Docker公司卻始終拒絕同Google開展任何形式的合作。而與此同時，Mesos等一票老牌排程系統的陰影則從一開始就讓Kubernetes團隊心有芥蒂。種種不利因素，再加上當時Google在Kubernetes上投入資源時的捉肘見襟，無論再怎麼樂觀，這個“要贏”的論斷恐怕都不容易成為現實，

當然，如果不是Google找到了一個靠譜的盟友的話。

這位盟友有多靠譜？它是這個世界上唯一一家年盈利超10億美元的開源技術公司。

Kubernetes剛發起的時候，其核心的理念來自幾位“Elder（元老）”的構想，他們大多是Borg和Omega專案的開發者或者架構師，一直專注於如何在沒有cloud的場景下構建足夠規模的通用Infrastructure Layer的實踐，並且在這個領域摸索的過程中，這批技術人員也逐漸形成了一套創新性的設計理念，這些觀點在Borg論文中曾經透露出了一些端倪，但真正全面揭曉還是依託於Kubernetes開源專案。所以如果大家回頭去翻Kubernetes最早的一些Issue和Design，其實都是一篇篇“小論文”，思路嚴謹，論證充分（廢話連篇），這跟大多數開源專案早期的頭腦風暴，或者圍繞一個核心設計逐漸展開的做法，是有很大不同的。

另一方面，彼時的RedHat正苦於自家OpenShift被競爭對手碾壓的境況。經典PaaS不能破局的困難，反倒讓RedHat對Docker這個有望顛覆PaaS的專案格外上心。這樣一個在作業系統領域積累深厚、資源充足、並且蠢蠢欲動以求變革的開源巨頭，碰上了滿腦子Idea卻對全面推進Kubernetes心有餘而力不足的Google團隊，可謂一拍即合。2014年12月，在Google正式釋出Kubernetes專案不久，RedHat即官方宣佈與Google開展戰略合作，全面投入Kubernetes。在當時的一份官宣中，RedHat以非常自信的姿態表達了對容器的“顛覆性”創新的認可，並大膽預言Kubernetes會在2015年後取得應用編排與管理領域的統治地位：

……（RedHat的競爭對手們） 必須要認識到自研任何容器的侷限性，儘早接納Docker專案 ……

…… （RedHat的競爭對手們）必須要認識到沒有人能夠同Google在成規模的容器編排和管理領域裡相抗衡 ……

誰曾想到，當年這套透露著幾分“終於傍上大腿”的僥倖、甚至“託大”的說辭，現在看起來卻幾乎句句“實錘”。

這也是為何，Kubernetes雖一直大幅受益於Google的聲譽和名望，還長期擁有Borg/Omega團隊的技術加持，但如果從技術實現上來審視，這個專案卻稱得上是半個RedHat專案。也正是憑藉最初階段“Google賦予靈魂，RedHat賦予實體”的策略，Kubernetes才能夠秉持著天馬行空的設計思想的同時，穩紮穩打，然後一步步崛起於社群。

如今的Kubernetes，既贏得了GitHub等眾多明星使用者的青睞，也受到了全世界所有公有云巨頭的熱捧，還硬生生把Docker公司逼到改旗換帥、徹底摒棄了以往“暴力不合作”的路線，如果用一個“贏”字來描述它現在的情形，倒也並不為過。不過，這個“贏”字背後的原因，又在哪裡呢？

Rancher的創始人樑勝博士最近有過一句評論，可謂道破天機：

時至今日，在容器技術領域依然有許多創新，只不過這些創新大多發生在Kubernetes以及CNCF生態系統中了

沒錯，容器技術圈的創新能力，在2015年後就已經逐漸轉移到了Kubernetes生態，這是一個不爭的事實，卻也是一個曾經被忽視的變化。實際上，伴隨著DockerCon越來越“boring”，Kubernetes的專屬生態CNCF基金會卻開始風生水起的原因也正在於此。

而從技術的角度上看，Kubernetes生態能取得這樣的成功，依託的乃是一項其他競爭對手所不具備的核心能力：“使能使用者二次創新“。

何謂“使能使用者二次創新”？這其實是Kubernetes專案從開始設計之初就高度重視的一項關鍵訴求：

第一：從上層API到底層容器執行時，Kubernetes工作流中的每個環節，都希望具備完善的可擴充套件性。

第二：Kubernetes任何功能特性的設計和實現，都儘可能針對更通用的使用者場景而非特定需求。

原生“使能二次創新”的技術基礎，加上Google與生俱來的技術號召力，在加上CNCF基金會的整合和商業運作，以Kubernetes為核心所建立起來的這套容器編排生態，絕不比Docker公司最初建立起來的以容器為核心社群有任何遜色。再加上容器編排與管理的概念天生就更接近使用者，Kubernetes的理念很快被社群接納乃至追捧，也是情理之中。

一個直觀的例子就是CoreOS的Operator專案。我們知道，在Kubernetes裡部署任務，經常使用的是Deployment（Replication）來管理多個副本組成叢集。但如果我們這次要部署的任務比較特殊，它的叢集需要在增/刪副本之後/之前做手動的運維操作呢？各種資料庫叢集就是最典型的例子。而Operator實際上是個使用者自己編寫的管理器，通過程式設計的方式把“運維”邏輯寫進了管理器的程式碼當中。但關鍵在於，這個管理器的編寫過程是完全“無腦”的，無非就是複製貼上官方模板、然後填充自己的運維邏輯而已。這是因為Operator是構建於Kubernetes的CRD（自定義API資源）特性之上的，這個特性的目的就是允許並幫助使用者自己編寫一個可以與系統etcd互動的、Kubernetes風格的API資源管理器，並無縫地銜接到Kubernetes的核心API當中。

這個設計看起來很很直白，但是卻解決了一個長期以來困擾系統級開源專案的難題：使用者對專案的API不滿意怎麼辦？

在過去的實踐中，原封不動使用開源專案的場景是非常少見的，更常見的情況是使用者把開源專案的API修改的面目全非。但在Kubernetes的場景下，使用者的自定義API和原生API可以友好共處，統一對外服務，而且不會隨著upstream變更而分家。這是保證Kubernetes社群完整性和被接納程度的一個核心手段。

更為重要的是，有了這些標準化的擴充套件性API，使用者就可以發揮自己的能動性，在Kubernetes之上構建出更多的擴充套件，甚至把這些擴充套件再交還給社群中的其他使用者推廣和使用。正如CoreOS的Operator，現在已經成為了社群運維有狀態應用的一大法寶。

當然，“二次創新”的例子遠不止於此。

2017年5月24日，Lyft，IBM聯合Google共同宣佈了Istio專案，一舉撼動了微服務這個以往“光說不練”的“花架子”領域。Istio的核心思想，乃是藉助一個proxy來接管容器裡業務的進出流量，從而通過在proxy上的控制操作來完成應用流量的切分、訪問授權、策略配置等一些列微服務治理功能。可以看到，這裡有一個核心問題是：如何保證每一個需要治理的容器都繫結這樣一個proxy呢？

解決這個問題的手段就是Pod。作為Kubernetes裡的核心概念和原子排程單位，Pod是一組親密耦合的容器集合，容器之間共享同一Network Namespace，顯然，Istio框架中的proxy和業務容器正屬於這樣的耦合關係。但這還不是關鍵所在，這裡最棘手的問題在於，Istio要做的是一個非侵入型的微服務框架，不可能要求使用者在自己的部署檔案中每次都額外定義一個proxy容器。怎麼辦？

答案還是藉助Kubernetes。Kubernetes中有一個叫Initializer的擴充套件機制，允許使用者在不修改業務Pod部署描述前提下，請求Kubernetes為業務Pod“自動注入”並啟動一個預先定義號的容器。在Istio裡，這個自動注入的容器正是前面不斷提到的proxy：Envoy（Lyft自研的高效能服務代理）。

可以看到，通過組合Initializer等一系列Kubernetes標準API，使用者可以優雅地實現很多以往繁瑣或者困難的分散式系統的構建工作：就比如Istio裡這套Spring AOP（面向切面程式設計）風格的組合方式。也正是因為有了這種標準化的實現手段，使用者基於Kubernetes的“二次創新”才有可能再次交還給Kubernetes社群，從而碰撞出更多的創新火花和更新穎的使用者案例。最終，不斷激發出的創新開始吸引了更多人力和資本的進入，而資本與生俱來的促進作用就會推動這個社群的更強勢的擴張。這種“開源-社群-商業”互相促進而構建出來的正向激勵迴圈，正是Kubernetes生態在過去一年裡“勢不可擋”的重要原因。

回想在Kubernetes剛釋出的時候，甚至在2017年初，Kubernetes的Pod以及Pod所體現出來的“解耦容器關係”的設計模式，依然時常被質疑為“用處不大”或者“過度設計”，然後現在回頭來看Istio專案的炙手可熱，我們確實要感慨“技術視野”的培育絕非一朝一夕。

從利用CNI、CRI等一系列良好設計的通用介面來實現不同型別、不同功能的網路和容器執行時，到使用API Aggregation擴充套件Kubernetes API Server從而支援自定義資源監控格式並以此來做Auto-Scaling，Kubernetes生態之中類似的“二次創新”的例子已然不勝列舉。依託於這種原生地鼓勵使用者發揮自己聰明才智的先進理念，在2018年，我們有足夠的理由相信“二次創新”將繼續成為Kubernetes生態中的一大關鍵詞，各種基於Kubernetes可擴充套件能力的創新工作將成為社群的常態，甚至成為更多團隊“一戰成名”的不二法寶。

在未來，已經爭取到領先地位的Kubernetes專案的進化重點，將逐步轉移到安全性、穩定性、多租戶能力、規模和效能優化、可擴充套件性設計等更多橫向功能的升級上面。另外，將更多的非核心功能從主幹程式碼中移除也將是未來一段時間Kubernetes社群的主要工作之一。2017年裡，隨client-go、apimachinery等API庫的獨立，已經為CRD等可擴充套件性功能的實現帶來了極大的便利，而將來諸如部署工具kubeadm，內建的各種Cloud Provider，內建的rkt整合，各種各樣的volume plugin等程式碼，也都將逐步遷移到它們單獨的庫中維護，這將有希望大大降低Kubernetes主庫的複雜度和維護難度。

另一方面，Kubernetes可擴充套件性上的另一個重要設計CSI（Container Storage Interface）也已經發布。這意味著不久的將來，就如同容器執行時一樣，容器持久化儲存方案也將不必再跟Kubernetes的核心程式碼耦合，Kubernetes將使用統一的gRPC介面在完全獨立的控制邏輯中維護容器儲存卷（volume）生命週期。這個設計也很有可能會刺激容器儲存領域更多的創新工作和更多的儲存選擇出現在Kubernetes社群當中。而包括KataContainers在內的虛擬化容器執行時，也將受益於儲存解耦帶來的、完全不同於現有容器儲存設計的高效能的持久化儲存方案。

在接下來的叢集管理能力上，目前最大5000個節點的支援能力已經能夠滿足大多數使用者的生產需求，而IPVS Service的引入也有很大希望能解決以往純iptables Service引發的大規模叢集中效能額外損耗問題。而在排程層面，預設排程器的可配置規則已經大幅增加，排程優先順序和搶佔技術也已經進入了預設排程器的alpha功能當中。而通過靈活配置親密/反親密關係、Taint/Toleration規則，Kubernetes的使用者已經能夠解決絕大多數生產環境中的運維和排程需求。

在多租戶與安全能力上，Kubernetes專案終於彌補上了這部分的短板。RBAC（基於角色的訪問控制）功能目前已經成熟應用於很多基於CRD的Kubernetes外部擴充套件上面，Secret儲存的加密也已經實現，叢集部署中的節點通訊加密配置也成為了預設功能。而在社群中，更完善的“強多租戶”設計也第一次被提出，以便真正滿足多租戶環境下的叢集管理需求。不過需要指出的是，Kubernetes的角色定位依然是Layer 0（Infrastructure Layer），更傾向於對上提供必要的多租戶支援API和規範而不是實現完整的多租戶模型。後者還是需要依靠Layer 1（Service Layer）來自己完成。

2017年也是人工智慧技術席捲全球的一年，Kubernetes在其中也扮演了推波助瀾的作用。在與之相對應的硬體加速器（Hardware Accelerator）功能的設計上，Kubernetes社群在Google，NVIDIA和Intel的牽頭下發布了Device Plugin來允許使用者自己編寫自定義的、自發現的高效能硬體資源描述，並且以此為基礎，將支援NUMA，InfinitiBand，FPGA等硬體框架的設計納入了路線圖。隨著Kubeflow等專案的釋出，不難預料到，Kubernetes在新的一年裡會繼續加大同人工智慧社群合作，向成為機器學習領域支撐大規模分散式訓練和AI服務的預設框架這一目標上不斷挺進，而在此過程中，各家vendor在Kubernetes社群中進行技術上的角逐，亦將成為這個領域的主旋律之一。

隨著Kubernetes專案的逐漸穩定，其開發迭代週期也將有所放緩，將目前每3個月一次release週期延長已經被提上討論日程。與此同時，隨著社群自動化管理能力（bot）的提高和SIG（Special Interest Group）組織的進一步完善，現有社群成員的寫許可權回收也是將來可能發生的大概率事件。這些都是Kubernetes社群逐步走向成熟的標誌性里程碑。

容器執行時的二次繁榮

2017年，Kubernetes引領了容器編排與管理領域的蓬勃發展，而與此同時，另一個很有意思的現象則是容器執行時（Container Runtime）迎來了一次難得的二次繁榮。

一般來說，伴隨著容器編排領域的迅速發展和成熟，容器執行時技術一定會因為被上層編排框架所遮蔽而逐漸淡出使用者視野。事實上，這也正是Docker公司自成立以來的心病：光有一個容器執行時Docker，並不足以吸引使用者真正投入到有價值的商業產品（比如PaaS）上來，更何況容器技術本身又是一個門檻相對不高的組合性創新成果，不能形成長期有效的技術壁壘。這個事實，也正是Docker公司一定要強推Swarm和SwarmKit等專案，以及Mesosphere曾短暫取得矚目的一個主要原因。

當然，在Kubernetes依託社群和強大的創新能力崛起之後，容器執行時和它背後的主體的淡出便成了不可避免的宿命。這也是為什麼我們會看到Docker公司會宣佈將它的開源專案改名為Moby，這其實是它自己宣佈將要放棄在開源社群中繼續同Kubernetes和CNCF社群對抗的重要訊號。這也是為什麼我們會看到containerd和rkt被接連捐獻給CNCF基金會：各類容器執行時的歷史使命已經走向尾聲了。

但是歷史總有意外。Kubernetes的擴充套件性設計中一項核心功能的確立，卻為容器執行時的創新者帶來了新的機遇，這就是CRI（Container Runtime Interface）。

CRI的誕生還得追溯到容器執行時第一次繁榮、也就是容器理念第一次席捲技術圈的時候。彼時，Docker公司手持Docker專案大殺四方、是當之無愧的容器技術領導者。而CoreOS公司在選擇擁抱Google和Kubernetes的同時，則釋出了rkt以制衡Docker，以希望維護自己在容器技術上的話語權。這兩位，再加上RedHat，他們在容器執行時領域的合作與競爭，直接推動了OCI這一容器技術標準的誕生。但實際上我們不難看到，Docker公司在容器執行時領域所佔據的絕對主導地位，以及OCI本身對Docker公司商業利益的不友好意味，使得OCI長期以來並沒能發揮出“標準”所應起到的推動和整合作用。

也正是在這個階段，以Intel ClearContainer和Hyper為代表虛擬化容器技術，則開始從安全和多租戶角度進入到開發者的視野。一時間，容器執行時領域可謂熙熙攘攘，不勝熱鬧。

而在Kubernetes釋出之後，很多機敏的技術人員其實已經嗅到了其中的機遇。在Kubernetes未來有大概率會成功的前提下，誰能在Kubernetes內建的容器執行時中搶佔到一個位置，誰才有可能在將來的容器技術圈子中爭取到一席之地。所以很快，CoreOS公司通過政治和技術雙管齊下的努力下，rkt成功躋身為Docker之後第二個被Kubernetes支援的容器執行時。但也正在這時，一些連鎖反應式的問題也被激發出來。

一方面，彼時的Kubernetes羽翼未豐，並沒有強勢到能直接幫扶起rkt這個相對弱勢的容器執行時的地步，更何況當時的Docker專案正突飛猛進，沒有給同質的rkt留下任何喘息和反擊的機會。所以雖然很早就進入了Kubernetes體系，rkt卻一直處於少有使用者問津的尷尬地位。

而另一方面，在當時快速迭代、完全沒有穩定的Kubernetes尤其是kubelet元件中，額外引入的rkt執行時其實帶來了大量的維護工作，並且這些工作很多時候還要依賴於CoreOS的介入才能解決，這無疑給Kubernetes團隊帶來了很大的壓力。

與此同時，Kubernetes團隊本身並不希望鎖定在Docker容器之上。Docker公司不斷推進Swarm專案的決心，很難讓人對繼續使用這樣一個唯一的、不穩定的、將來甚至可能會變成一個PaaS的“容器”感到放心。

在這樣的背景下，適逢Kubernetes團隊也開始嘗試逐步在專案中引入虛擬化容器技術，能不能提供一個通用的、與下層容器執行時無關的接入層來無縫對接上述所有容器執行時，就成為了當時Kubernetes能否更進一步關鍵所在。更重要的是，這也是Docker的軟肋之一。由於顯而易見的原因，Swarm體系並沒有動力去支援任何非Docker之外的容器執行時，而另一方面，彼時的OCI話語權不濟，並不能發揮對接其他容器執行時的作用，這就意味著Kubernetes專案會成為對接非Docker容器執行時的唯一出路。

就這樣，一套由Google，Hyper和CoreOS共同主導的、以Kubernetes專案為核心的容器執行時介面的設計，應運而生。

CRI的及時釋出，使得Kubernetes團隊在後續SwarmKit等事件中可以處變不驚。而它的誕生，也直接推動了容器執行時這原本應該逐步淡化的領域煥發了第二次繁榮。

cri-o與cri-containerd

這次繁榮的第一個標誌性的事件，是runC容器執行時cri-o的釋出。

cri-o的初衷非常直白，既然現在Kubernetes可以藉助CRI對接任何容器執行時甚至虛擬機器，那麼我們自然會想到，為什麼不直接把runC封裝成一個CRI的實現呢？這樣不就可以繞過現有Docker容器的大部分機制而直接操作Linux容器了麼？

所以，不同於Docker，除了用來響應CRI的gRPC server，cri-o並不需要額外的daemon元件來維護Linux容器。CRI的API呼叫在這裡被直接翻譯成對runC的操作命令，然後在宿主機上建立並啟動runC容器。不難看出，這個工作流其實跟containerd的功能是基本一致的，但有意思的是，cri-o的發起者RedHat並沒有使用containerd而是重新造了輪子。這其中，containerd的實際維護者是Docker公司恐怕是主要的考量因素之一。

實際上，在Docker公司決定打造自己的封閉生態之後，RedHat就跟Docker公司走向了對立的一面。畢竟相比Google專注於公有云業務而不太在意企業及市場，Docker公司隨後釋出的每一項產品（專案），卻都在不同領域實實在在爭搶著RedHat的蛋糕。作為曾經一起同推進容器技術的“兄弟”，如今“分手”後的RedHat對Docker公司的負面態度是可想而知的。所以，cri-o在某些實現細節上透露出來的一些偏執，也是這種思想指導下的必然產物。從最初放出言論要“fork Docker”，到現在cri-o的實際落地，RedHat在容器執行時領域的志向目前都壓在這個專案之上。這也是為何RedHat的宣傳機器在2017年 可謂開足了馬力，連Kubernetes首席佈道師Kelsey Hightower也曾短期被“攻陷”過。

然而，開源社群裡最有意思的事情也莫過於此。就在cri-o幾乎要以下一代Kubernetes預設容器執行時的身份粉墨登場之時，Google和IBM以及containerd的維護者們卻默默的上線了cri-containerd專案。這個專案的思路更加顯而易見：鑑於containerd已經捐給了CNCF，現在只要在其基礎上略微封裝，就可以為Kubernetes打造一個Docker native的、身份中立的CRI實現。相比cri-o每個release都要推廣一番的風風火火，cri-containerd的進展可謂低調，僅在最近的DockerCon上小幅亮相了一次，並且期間一直與cri-o保持的良好的合作關係（比如共同維護lib）。但低調並不意味著不作為，2017年底，cri-containerd專案悄無聲息地開始了與containerd專案的合併計劃，這意味著很快containerd本身將會原生支援Kubernetes CRI。

CRI的成功我們有目共睹，但Kubernetes下一代預設容器執行時目前卻尚無定論。Kelsey Hightower一向不太“待見”Docker，他的成名作“Kubernetes the Hard Way”在短暫試用cri-o後目前還是切換到了cri-containerd上。不過這也並不足以說明所有問題，至少在未來一段時間內，“No Default”還是可以繼續作為這一領域的官方說辭。

不過，cri-o本身的崛起，側面說明了“得編排者得天下”是目前容器執行時領域進一步發展的正確思路。CRI的及時釋出，使得Kubernetes團隊在後續SwarmKit等事件中可以處變不驚。而它的誕生，也直接推動了容器執行時這原本應該逐步淡化的領域煥發了第二次繁榮

Kata！Kata!

這個事件，正是Hyper runV同Intel ClearContainer的合併。合併之後的專案以KataContainers命名並託管於中立基金會，為虛擬化容器技術路線之爭畫上了句號。

實際上，在Hyper推出了runV技術之後，部分敏銳的技術人員就迅速開始了往Kubernetes推進基於runV的虛擬化容器技術的的整合工作。相比於Swarm體系的封閉和Mesos社群的後知後覺，Kubernetes專案從一開始就展現出來的技術遠見，使得這個選擇倒並不意外。而這次技術行為的直接結果，則是推動了CRI這一關鍵特性的誕生和落地：又是一個典型的社群“二次創新”然後再反哺社群的故事。在這個過程中，kubernetes/frakti專案作為虛擬化容器執行時的官方CRI實現，正是推動這項技術進入Kubernetes生態核心的關鍵一步。

不過，相比於Linux容器領域的Docker專案的一枝獨秀，虛擬化容器技術則有一個困擾社群許久的問題，那就是幾乎同期釋出的Intel ClearContainer專案一直以來跟runV處於重合位置。儘管在專案的後期，Intel和Hyper團隊已經開始共同維護很多公有的子專案，但開源社群的掣肘關係依然牽制了虛擬化容器技術進入容器生態核心的步伐。

不過，明智的是，runV並沒有固執地在容器API層面同Intel開展類似Docker和rkt之間的競爭，而是把原生接入Kubernetes當成了第一要務，希望藉助上層編排框架來為容器執行時發聲。這個策略無疑改變了社群對虛擬化容器技術在整個生態中所處位置的看法。事實上，相比於我們所熟知的硬體級別隔離和容器安全這樣的常識，虛擬化容器技術的獨立核心特性為Kubernetes支援遺留應用和傳統業務帶來的巨大的想象空間，才是這種技術最大優勢所在。尤其是伴隨著2017年後期“強多租戶”概念被引入到Kubernetes社群，能夠從容器執行時層就開始進行租戶隔離的設計已經成了一種剛性需求。沒有虛擬化級別的隔離能力和獨立核心來保證業務的多樣性，“強多租戶”基本無從談起。試想一下，在一個真正的多租戶雲資料中心裡，有的租戶的應用是Windows的，有的是Linux的，除非做低效的靜態劃分，常規Linux容器又該如何應對這樣的需求呢？

KataContainers專案的出現，把剛剛嶄露頭角的虛擬化容器技術推向了一個新的階段。作為OpenStack基金會力圖革新後發起的第一個專案，託管於該基金會下面的KataContainers卻不必遵守OpenStack社群任何現有的規範，其自由度和改革力度，可見一斑。而這次合併的最終促成雖然被OpenStack基金會搶了先機，但CNCF基金會則開始從OCI入手，試圖將KataContainers的執行時再納入到OCI的範疇之中。我們有理由相信，在兩大基金會的通力合作之下，KataContainers的前景非常光明。

不過，更為重要的是，以KataContainers為代表的虛擬化容器技術在雲端計算領域的探索，正有意無意地打開了公有云的一個新篇章。

ACI，Fargate與“Serverless容器雲”

在runV容器釋出之後，為了驗證虛擬化容器對公有云帶來的變化，一個名為hyper.sh服務同步上線並隨後迅速霸榜了HackerNews頭條。這個服務的創新之初在於，雖然它的整個技術棧都基於Kubernetes，但是它卻不對外暴露任何Kubernetes API，也沒有提供任何操作console，而是讓使用者用本地的“hyper run <IMAGE>”指令來在雲端建立和啟動容器。由於使用了虛擬化容器技術，這個工作流裡完全不需要虛擬機器的介入，所有租戶的容器直接執行在裸物理機叢集當中。

雖然看起來簡單，但這個設計的本質，卻提供了一種容器雲的Serverless的設計思路。在這個“無伺服器”雲的設計中，雲的使用者完全不必學習任何Kubernetes或者雲平臺API或者文件，僅靠開發者所熟悉的本地容器操作就可以完成作業的雲端部署，然後按秒計費。

而在2017年，這種頗有遠見的容器雲Serverless開始得到了公有云巨頭的青睞。這一次的始作俑者正是近年來在雲服務領域出手“穩”、“準”、“狠”的Microsoft。2017年7月26日，Microsoft Azure團隊宣佈了ACI（Azure Container Instance）服務的釋出，其通過“az container create”建立容器的思路，與hyper.sh如出一轍，並且同樣遮蔽了所有下層的PaaS和IaaS概念然後按秒計費。一石激起千層浪，國外容器技術圈子對這種服務的討論迅速成為了當時的技術頭條。有人說它是AWS Lamda的有力競爭者，也有人說這才是Serverless服務的終極形態。

緊接著，在2017年11月，堪稱全球雲端計算技術風向標的AWS re:Invent 大會上，AWS高調宣佈了同類型服務Fargate的誕生，把Serverless Container Cloud的理念推向了新的高潮。作為迴應，Microsoft則聯合Hyper發起了virtual-kubelet專案，旨在定製一套標準，允許雲提供商把自己的Serverless Container Cloud，以kubelet API的方式接入到任意的Kubernetes叢集中作為一個特殊的節點而存在，從而輕鬆實現一個基於Kubernetes的混合雲。目前，AWS、甚至OpenStack都已經加入這個專案開始貢獻自己的實現，對應的基金會和開源生態正迅速形成。不出意外，很快Google、國內的阿里雲等巨頭，也會推出類似的Serverless Container Cloud服務，並且加入到virtual-kubelet專案當中。

Serverless Container Cloud服務備受歡迎的本質，乃在於公有云計算所服務的使用者，尤其是廣大的開發者群體，對於追求“簡單高效”的熱情其實是非常高漲的。對於他們來說，在各種設計拙劣的雲管理介面上進行凌亂的滑鼠操作，絕對不如在鍵盤上敲打本地命令來的舒服。這種微妙的體驗變化，正如同git對比SVN，Docker對比OpenStack。更為重要的是，這種服務形態也正符合了Kubernetes技術繼續發展的正確路線：Kubernetes所要扮演的角色，乃是取代傳統的Infrastructure Layer並鼓勵技術人員進行上層的“二次創新”，而並不是直接面對終端使用者（實際上Kubernetes本身的宣告式API也是對運維而非開發友好的）。真正為終端使用者提供雲服務的，很大概率應該是構建於Kubernetes之上的、更加簡潔高效的服務型API，而Serverless，尤其是Serverless Container Cloud的設計，正是這種需求下最為貼切的實現方式之一。

不難預料，在新的一年，基於Kubernetes之上構建出來的創新型Serverless服務（當然也包括OpenFaaS等優秀的Function），將會是大小云計算提供商進一步角逐的一個關鍵領域。相比之下，曾經在國內外普遍開花的、以直接售賣Kubernetes叢集為核心的各種“CaaS”，將會沉寂許多。

Docker Inc的未來

毫無疑問，2017年的Docker公司依然是容器圈子裡的主角。只不過這一次，波瀾之中的Docker公司的確並不好過。

從2017年4月Docker專案毫無徵兆地改名為Moby開始，Docker公司頂著巨大的爭議，逐步完成了開源技術創新公司到商業公司的轉變，也開始正視長期以來同Kubernetes社群競爭所帶來的極其不利的商業局面：伴隨著Kubernetes專案的成功，Swarm已成為明日黃花，曾一度承載著新希望的SwarmKit也漸漸淡出社群視野。2017年10月，在DockerCon EU上，Docker公司官方宣佈下一版本的Docker EE中將全力擁抱Kubernetes，標誌著持續了近三年之久的容器編排之爭徹底落下帷幕。緊接著，所有紛爭的始作俑者、曾經攜Docker對抗整個容器社群的Solomon Hykes也宣佈自己“角色轉變”，不再負責Docker產品的具體技術事宜。

曾經紛紛擾擾的容器圈子，竟然一夜之間塵埃落定，箇中滋味，不免讓人心生惆悵。Docker公司和Solomon的經歷可能不算是傳奇，但也絕對能夠在雲計算曆史中留下了濃墨重彩的一筆。我們甚至會不時想象，如果當初Solomon沒有去做Swarm，而是選擇同Google合作共舉Kubernetes，如今的CoreOS還會不會活著？如今的Docker公司又是什麼樣子？

歷史難做假設。

但是Docker公司的未來卻依然是光明的。

在積極擁抱Kubernetes社群之後，Docker公司正走向正確的軌道。大家不要忘記，在迎合開發者社群和技術微創新這兩個關鍵手段上，Docker公司的實力絕不容忽視。2018年初，Docker Mac整合Kubernetes的版本正式釋出，並立刻在開發者群體中掀起了軒然大波。在Mac OS上如此流暢啟動和執行Kubernetes的體驗，在這麼短的時間內就被Docker公司帶到了開發者手裡，這其中體現出來的技術能力與產品理念，正是將來Docker公司繼續立足的核心所在。當然，Docker公司最終的成功，依然取決於其商業產品能否贏得重量級客戶的青睞，在這一點上，Kubernetes的堅定盟友CoreOS已然佔盡先機並且完成了轉型。但是Docker公司在容器領域不俗的創新能力和產品積累其實是有增無減，其產品線也更完整，在開發者群體中的基礎也更雄厚，這樣一個人氣與技術兼備的創業公司的未來，絕不見得會像某些文章中描述的那樣一片哀鴻。這一點，我們不妨拭目以待。

國內

相比於過去默默無聞，2017年的國內容器技術玩家終於得意發聲，而且“不鳴則已，一鳴驚人”。阿里集團在雙11過後，高調發布了源自其內部容器T4的開源專案Pouch，並迅速成為了當時的技術熱點。事實上，早在Docker和Kubernetes技術如火如荼的2015年，業界就發出過疑問：在此領域積累深厚（百度有Matrix，阿里有T4）的國內的網際網路巨頭為何遲遲不見動作？

好在廠商會遲到，但技術不會。Pouch的釋出，也正是前面提到的“2017年容器執行時技術二次繁榮”的又一例證。在Docker公司逐漸式微、rkt幾乎退役的檔口，Kubernetes的崛起和CRI的成熟正在為所有的容器執行時玩家帶來全新的機會。從程式碼上看，Pouch並非“Docker fork”，而是利用類似技術進行的全新實現。從功能上看，Pouch原生接入了runV來提供多樣化的隔離機制，內建“富容器”能力以滿足不同的業務場景，打包了Dragonfly來實現高效的映象分發，這意味著這套技術棧從底自上有著同Docker整體不一樣的業務考量。

但另一方面，如今的時間點不同與2015年，使用者的關注點已經從容器執行時轉移到了上層容器編排管理的服務能力。而作為近來Linux容器的第三個實現（cri-o只支援Kubernetes，不能算作完整的容器實現），儘管功能上有所差異，但Pouch仍然難免會陷入同質競爭的不利局面。不過需要指出的是，阿里集團接下來亦在醞釀其內部叢集管理系統Sigma專案的開源工作，並且會積極地將Sigma納入到Kubernetes的現有生態當中，這就為Pouch未來的前景增添了一層有趣的砝碼。畢竟，Pouch本身在Docker的優勢地位中突圍可以說困難重重，但正如前面所提到過的，如果能夠藉助上層容器編排能力重新表達這一容器執行時的關鍵作用，那這套技術方案的應用前景和接納難度很可能會發生變化。這也正回到了我們最開始談到“Kubernetes贏在何處”時所作出的闡述：Kubernetes社群通過從技術和生態雙重層面上使能使用者二次創新的做法，必將推動這個生態走向一個更加繁榮而有意義的新階段。

總結

“任何一個被濃厚的商業興趣所充斥的開源社群，最後都難免走向有毒的方向”

— Solomon Hykes

2017年，曾經的弄潮兒Docker公司在巨大的爭議中終於完成了向商業公司的重要轉變，也宣告了由Kubernetes社群所主導的、全新的容器生態正式拉開序幕。在回顧Kubernetes如何贏得這次競爭的同時，我們應該意識到容器執行時“二次繁榮”的短暫視窗正在為我們帶來新的機遇。與此同時，容器公有云的形態正在悄然發生變化，伴隨著這次變革而存在的，固然有風險，但也有很可能會催生出新的雲端計算贏家甚至獨角獸。最為重要的是，伴隨著Kubernetes社群的日益壯大，如何避免這個生態陷入Solomon所警告的“有毒”陷阱，恐怕很快就會成為擺在這個社群所有參與者面前的一道難題。是的，是所有參與者都對此負有責任，而絕不僅僅是CNCF或者Google就有能力獨自解決的一次危機。

作者

張磊，浙江大學博士研究員，Hyper專案成員，Kubernetes專案資深成員與社群維護者。長期專注並活躍於容器叢集管理與雲端計算資料中心領域，連續多次被微軟授予該領域“最有價值專家（MVP）”稱號。

來源：infoq

http://www.infoq.com/cn/articles/2017-container-Kubernetes