請注意，容器技術圈已邁入后Kubernetes時代！

2017 年的容器技術圈，Kubernetes 要贏？Docker Inc 的未來何在？國內容器技術玩家終發聲？來看浙江大學博士研究員張磊筆力雄渾的容器技術圈年度解讀。1寫在前面

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

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

可是，描述這樣一個連商業實體都沒有的開源項目「要贏」，總是聽起來有些奇怪。

「要贏誰？」「為什麼要贏？」「贏了之後呢？」

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

2Kubernetes 贏在何處

如果說錯失了 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 社區逐步走向成熟的標誌性里程碑。

3容器運行時的二次繁榮

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 等事件中可以處變不驚。而它的誕生，也直接推動了容器運行時這原本應

4cri-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 本身的崛起，側面說明了「得編排者得天下」是目前容器運行時領域進一步發展的正確思路。而也正是這個思路的推動下，我們得以見證了這次技術繁榮的第二個標誌性事件。

5Kata！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 為代表的虛擬化容器技術在雲計算領域的探索，正有意無意地打開了公有雲的一個新篇章。

6ACI，Fargate 與「Serverless 容器雲」

在 runV 容器發布之後，為了驗證虛擬化容器對公有雲帶來的變化，一個名為 hyper.sh 服務同步上線並隨後迅速霸榜了 HackerNews 頭條。這個服務的創新之初在於，雖然它的整個技術棧都基於 Kubernetes，但是它卻不對外暴露任何 Kubernetes API，也沒有提供任何操作 console，而是讓用戶用本地的「hyper run

」指令來在雲端創建和啟動容器。由於使用了虛擬化容器技術，這個工作流里完全不需要虛擬機的介入，所有租戶的容器直接運行在裸物理機集群當中。

雖然看起來簡單，但這個設計的本質，卻提供了一種容器雲的 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」，將會沉寂許多。

7Docker 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 公司在容器領域不俗的創新能力和產品積累其實是有增無減，其產品線也更完整，在開發者群體中的基礎也更雄厚，這樣一個人氣與技術兼備的創業公司的未來，絕不見得會像某些文章中描述的那樣一片哀鴻。這一點，我們不妨拭目以待。

8國內

相比於過去默默無聞，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 社區通過從技術和生態雙重層面上使能用戶二次創新的做法，必將推動這個生態走向一個更加繁榮而有意義的新階段。

9總結

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

—— Solomon Hykes

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

免責聲明：轉載自網路 不用於商業宣傳 版權歸原作者所有 侵權刪