編者按：2015年 的容器技術(shù)圈，是各家施展手腳封疆劃土的擴(kuò)張一年，也是 Docker 以及容器技術(shù)生態(tài)參與者不斷完善自己的進(jìn)化一年。本文作者張磊，浙江大學(xué) VLIS/SEL 實(shí)驗(yàn)室云計(jì)算團(tuán)隊(duì)負(fù)責(zé)人，Kubernetes 項(xiàng)目 Collaborator。本文由 36 氪轉(zhuǎn)載自微信公眾號(hào)infoQ（微信號(hào)：infoqchina）。

回顧 2015年 容器技術(shù)的發(fā)展歷程，我們可以用兩個(gè)關(guān)鍵詞來概括：擴(kuò)張與進(jìn)化。

如果說 2014年 僅僅是 Docker 為主的容器技術(shù)在云計(jì)算以及 DevOps 圈初露鋒芒的話，那么 2015年 則是以 Docker 為核心的容器生態(tài)圈迅猛擴(kuò)張的一年。這種擴(kuò)張的態(tài)勢，一直從 2015 上半年火爆的 DockerCon 蔓延到了 2015年 的最后一天。伴隨著容器技術(shù)快速發(fā)展的過程，國內(nèi)外的技術(shù)人員有幸親歷了 OCI、CNCF 兩大標(biāo)準(zhǔn)組織的確立，第一時(shí)間體驗(yàn)了 Docker 1.8 和 1.9 兩大關(guān)鍵版本的發(fā)布，見識(shí)到了 CoreOS 一系列關(guān)鍵技術(shù)革新與戰(zhàn)略布局，也感受到了國內(nèi) Docker 創(chuàng)業(yè)圈的如火如荼。

國外容器技術(shù)項(xiàng)目

在 2015年，一直以 “善意獨(dú)裁” 面孔示人的 Docker 公司終于邁出了合作的第一步。OCI 組織的成立宣告了工業(yè)界對(duì) Docker 提出的容器技術(shù)的高度認(rèn)同，也暗含了后進(jìn)場玩家試圖從這個(gè)由 startup 開創(chuàng)的新領(lǐng)域中分得一杯羹的決心。然而 runC 項(xiàng)目運(yùn)作到現(xiàn)在，依然沒能夠進(jìn)入 Docker Daemon 的實(shí)現(xiàn)主干，也沒有任何巨頭發(fā)布以 runC 為基礎(chǔ)的新容器實(shí)現(xiàn)。Docker 而不是 runC 被用戶當(dāng)作容器技術(shù)的事實(shí)標(biāo)準(zhǔn)的現(xiàn)狀在短期內(nèi)（1-2年）恐怕還很難發(fā)生本質(zhì)改變。

容器技術(shù)領(lǐng)域多樣化的任務(wù)目前還是落在直接競爭對(duì)手 CoreOS，以及另辟蹊徑的虛擬化容器技術(shù)比如 Hyper 和 Intel Clear Linux 身上。但是無論如何，誕生于 startup 的 Docker 容器注定要經(jīng)歷更多的考驗(yàn)才能在巨頭林立的云計(jì)算領(lǐng)域真正地扎根生長，無論其是否愿意，將容器技術(shù)標(biāo)準(zhǔn)化是這條道路上必須面對(duì)的選擇和進(jìn)化方向。

另一方面，Docker 公司這種獨(dú)一無二的親和力和號(hào)召力正是 2015年Docker 為主的容器生態(tài)圈版圖迅速擴(kuò)張的主要基石。當(dāng)然，既然是擴(kuò)張，這張容器生態(tài)圈版圖的背后也必然少不了大小領(lǐng)主 “封地” 的確立和斗爭。

2015年，Google 和 RedHat 聯(lián)盟以 Kubernetes 1.0 為陣地宣告了大規(guī)模容器編排與管理領(lǐng)域的領(lǐng)主地位。號(hào)稱以 Borg 等 Google 多年容器技術(shù)實(shí)踐經(jīng)驗(yàn)為理論指導(dǎo)、以 Google 和 RedHat PaaS 團(tuán)隊(duì)為主要工程力量的 Kubernetes 項(xiàng)目一經(jīng)宣布生產(chǎn)級(jí)別可用，便立刻吸引了的工業(yè)界乃至學(xué)術(shù)界的大量關(guān)注和投入。盡管不是第一家，但是我們不得不承認(rèn) Google 的號(hào)召力和 Kubernetes 不凡的背景直接推動(dòng)了 CNCF 這一容器編排管理標(biāo)準(zhǔn)組織的誕生。

在技術(shù)方向上，Kubernetes 團(tuán)隊(duì)則試圖以 Kubernetes 為依托來對(duì)外輸出 Google 的容器技術(shù)的思想和經(jīng)驗(yàn)，或多或少有點(diǎn)要彌補(bǔ) LMCTFY 項(xiàng)目中途夭折的意思。無論如何，Kubernetes 所體現(xiàn)出的前瞻性的容器技術(shù)實(shí)踐思路，確實(shí)值得我們每一個(gè)容器技術(shù)實(shí)踐者重點(diǎn)關(guān)注和學(xué)習(xí)。無論是 Pod 及伙伴容器、單 Pod 單 IP 網(wǎng)絡(luò)模型、volume 插件機(jī)制、容器生命周期鉤子這種對(duì)容器技術(shù)本身的改造，還是虛擬 IP 與負(fù)載均衡、垂直健康檢查、密碼數(shù)據(jù)卷管理、元數(shù)據(jù) API 等平臺(tái)級(jí)別能力的實(shí)現(xiàn)，都展現(xiàn)出了 Kubernetes 與其他編排管理項(xiàng)目與眾不同的技術(shù)視野和團(tuán)隊(duì)實(shí)力。在未來發(fā)展方向上，Kubernetes 已經(jīng)開始向 1000+ 節(jié)點(diǎn)的集群規(guī)模進(jìn)發(fā)，畢竟在性能和規(guī)?；I(lǐng)域，Kubernetes 沒有理由落后競爭者太久。

另一方面，除了常規(guī)的 long time running 任務(wù)，其他類型任務(wù)比如短任務(wù)和 daemon 任務(wù)的支持都已經(jīng)引入了項(xiàng)目主干，類似 big data 業(yè)務(wù)的支持將是未來的一個(gè)重要方向。

在與 Docker” 分手 “之后，CoreOS 一直在積極地尋求展示自己技術(shù)想法的機(jī)會(huì)，包括加入 OCI 組織以及在 Kubernetes 上同 Google 開展深度的合作。鑒于 OCI 最開始只關(guān)注于 container runtime 的實(shí)現(xiàn)標(biāo)準(zhǔn)，CoreOS 的 AppC 一直在積極推進(jìn)鏡像標(biāo)準(zhǔn)的概念。目前這個(gè)標(biāo)準(zhǔn)已經(jīng)在 Kubernetes 上初見雛形。最值得關(guān)注的是，CoreOS 還在 0.8.0 版本發(fā)布時(shí)高調(diào)宣布了同 Intel Clear Linux 團(tuán)隊(duì)合作在 rkt 上實(shí)現(xiàn)了基于虛擬化技術(shù)隔離的容器（這與國內(nèi)的 Hyper 團(tuán)隊(duì)的做法不謀而合，只不過后者是在 Docker 上做出的類似實(shí)現(xiàn)）。

這種 hypervisor-based container 是目前在公有云上提供容器服務(wù)最佳選擇，CoreOS 在容器安全和隔離性問題上進(jìn)行本質(zhì)革新的做法的確很有說服力。而在容器編排管理領(lǐng)域，CoreOS 公司將 Kubernetes 組件內(nèi)置到 CoreOS 項(xiàng)目中作為主要的底層依賴之一。Etcd 的作者目前也正在 Kubernetes 社區(qū)積極推進(jìn)項(xiàng)目整體性能提升和調(diào)度效率優(yōu)化的工作，畢竟作為整個(gè)項(xiàng)目的核心依賴，Etcd 的作者們有足夠的理由和能力承擔(dān)起 Kubernetes 性能提升的重任。這一點(diǎn)上其他容器管理項(xiàng)目可能要稍微眼紅一下了。

而在另一邊，Mesosphere 公司借助在資源調(diào)度管理領(lǐng)域與生俱來的優(yōu)勢，在 2015年 成功開拓出了一片以 DCOS 為核心、兼顧大數(shù)據(jù)和應(yīng)用托管的服務(wù)平臺(tái)市場。

Apache Mesos 項(xiàng)目原生的兩級(jí)調(diào)度和多框架支持使得用戶在自己的組織內(nèi)部設(shè)施云計(jì)算平臺(tái)終于變得唾手可得。尤其是在傳統(tǒng)技術(shù)型企業(yè)轉(zhuǎn)型互聯(lián)網(wǎng)架構(gòu)的過程中，Mesos 生態(tài)圈能夠非常方便的在企業(yè)內(nèi)部迅速實(shí)現(xiàn)一套原本在一線互聯(lián)網(wǎng)公司中都算得上 “黑科技” 的資源調(diào)度管理平臺(tái)，然后快速搭建起 PaaS 和 BigData 服務(wù)。盡管 Mesos 原生并非針對(duì)容器設(shè)計(jì)，Mesosphere 所提供的諸如 Marathon 等上層解決方案也明顯在成熟度和技術(shù)實(shí)現(xiàn)上有著這樣那樣的不足，但是不得不說 Mesos 生態(tài)體系目前是企業(yè)自建私有云最快速、最有利于展示 POC 的一套技術(shù)方案。

鑒于 Mesos 本身較難只針對(duì) Docker 進(jìn)行根本性的改造，Mesosphere 生態(tài)圈目前依賴于 Marathon 等上層項(xiàng)目來響應(yīng) Docker 容器技術(shù)的快速發(fā)展，在這種形勢下，一組包含了用戶生命周期管理、多維度監(jiān)控、整合大數(shù)據(jù)業(yè)務(wù)管理等功能的完善的 PaaS 很可能是這些上層框架的最終形態(tài)。

當(dāng)然，最后一定要說的就是 Docker 公司了。在進(jìn)入 2015年 之后，雄心勃勃的 Docker 公司在 Docker 源碼層面開始了大規(guī)模的重構(gòu)，將原先倉促發(fā)布的很多模塊進(jìn)行了統(tǒng)一的抽象和整合，使得在 1.9 版本徹底解耦 Volume 和 Network 成為了可能。

另一方面，Docker 公司加緊了自己在組建生態(tài)圈閉環(huán)上的戰(zhàn)略布局，這一點(diǎn)以年末收購 Tutum 為 2015年 畫上了圓滿的句號(hào)。之所以強(qiáng)調(diào)這一點(diǎn)，是因?yàn)?Docker 之前的收購對(duì)象都是在某一領(lǐng)域具有獨(dú)創(chuàng)性的公司或團(tuán)隊(duì)，比如容器編排上的 Fig，容器網(wǎng)絡(luò)上的 SocketPlane，而 Tutum 雖然在 Control Panel 以及產(chǎn)品化上做的很早很出色，但是類似的競爭者卻不在少數(shù)且產(chǎn)品能力也很強(qiáng)，更何況 Docker 公司自己在這一領(lǐng)域已經(jīng)有所動(dòng)作。所以 Tutum 最終勝出的確是自身技術(shù)和產(chǎn)品實(shí)力的最有力證明。

在技術(shù)路線上，Docker 把同 runC 的集成列到了高優(yōu)先級(jí)任務(wù)上，并且已經(jīng)為之做了大量重構(gòu)工作，但是奈何 daemon 同 libcontainer 的交互過于繁雜，此項(xiàng)工作進(jìn)展一直緩慢。好消息是 Docker 在年末發(fā)布了 Containerd 項(xiàng)目來專門負(fù)責(zé)同 runC 進(jìn)行交互，此項(xiàng)目最終會(huì)進(jìn)入 Docker Engine 主干從而間接實(shí)現(xiàn) Docker 同 libcontainer 的解耦。

一旦這個(gè)目的達(dá)成，Docker daemon 的復(fù)雜度會(huì)大大降低，性能也很可能得到大幅提升，更重要的是屆時(shí)容器開發(fā)者將有能力定制自己的 daemon，在容器端加入定制化的功能和特性，這才是 runC 項(xiàng)目的真正意義和玩法，非常值得期待。Docker 公司在 2015年 的另一個(gè)大動(dòng)作便是 1.9 版本的發(fā)布終于完成了存儲(chǔ)和網(wǎng)絡(luò)功能的解耦，使得用戶可以以插件的方式提供第三方存儲(chǔ)和網(wǎng)絡(luò)功能來支持遠(yuǎn)程數(shù)據(jù)卷和跨主機(jī)網(wǎng)絡(luò)。

但是需要提醒讀者的是，無論是網(wǎng)絡(luò)還是存儲(chǔ)，這些插件方式的工作原理與非插件方式并沒有本質(zhì)區(qū)別，Docker 并沒有能力也沒有理由提供任何優(yōu)化。所以在這一點(diǎn)上，普通用戶在前期階段需要寄希望于社區(qū)里的插件開發(fā)者的能力和技術(shù)水平不要太低。

因?yàn)槲仪懊娴慕?jīng)驗(yàn)表明即使是 Docker 官方比如 SocketPlane 提供的網(wǎng)絡(luò)方案，在穩(wěn)定性、可用性上也沒有特別值得表揚(yáng)的地方，建議用戶保守上線該功能，必要時(shí)自己按需開發(fā)插件。“Docker 之心，路人皆知”。這家已經(jīng)在云計(jì)算領(lǐng)域掀起革命的 startup 背后的野心之大，的確配得上目前它在輕量級(jí)應(yīng)用容器界的號(hào)召力和絕對(duì)地位。在未來的發(fā)展方向上，有如下幾個(gè)方向上的進(jìn)化是一定會(huì)發(fā)生的：

Docker Engine 的進(jìn)一步模塊化和解耦，最終用戶一定可以選擇使用其中的一部分來達(dá)成自己的目的

runC 全面取代 execdriver 來執(zhí)行容器

更豐富的插件能力和以此為基礎(chǔ)的數(shù)據(jù)卷管理能力（類似 Flocker）

在容器編排與管理領(lǐng)域，Docker 已經(jīng)構(gòu)建出了 Compose+Swarm+Machine 的技術(shù)閉環(huán)，這套技術(shù)棧的最大亮點(diǎn)是全面兼容 Docker API。當(dāng)然，這個(gè)優(yōu)勢的前提是目前 Docker 而不是 runC 仍然是業(yè)界公認(rèn)的容器標(biāo)準(zhǔn)。在這個(gè)領(lǐng)域，Docker 目前選擇了重點(diǎn)照顧用戶友好度而適當(dāng)放棄性能和規(guī)模能力的路線，畢竟在兼容 Docker API 的前提下引入更復(fù)雜的編排、調(diào)度和管理能力是比較困難的。這也是為什么 Swarm 現(xiàn)在正在推進(jìn)同 Mesos 集成以提高調(diào)度方面的性能和可擴(kuò)展能力，雖然我認(rèn)為這個(gè)路線可能并不太友好 (想象一下宿主機(jī)上同時(shí)運(yùn)行著 Dcker dameon，Swarm agent 和 Mesos Slave 的場景）。

總之，Docker 目前在容器界的領(lǐng)導(dǎo)地位已經(jīng)毋庸置疑。一系列產(chǎn)品和技術(shù)布局的完成也確立了 Docker 公司在這一由它自己開拓的疆土上的霸主地位。接下來，如何在不甘心的巨頭們?cè)O(shè)置的規(guī)則叢林里生存、壯大并且健康發(fā)展下去，甚至達(dá)成 Linux 項(xiàng)目的創(chuàng)舉，則是考驗(yàn)這家已經(jīng)創(chuàng)造了一個(gè)不小的奇跡的初創(chuàng)團(tuán)隊(duì)真正實(shí)力和水平的難題。

國內(nèi)容器技術(shù)圈

與國外相比，以 Docker 為主的容器技術(shù)在國內(nèi)的發(fā)展勢頭甚至要更猛烈一些，其中部分原因是因?yàn)?2014年 以前的 PaaS 風(fēng)潮沒能夠在國內(nèi)掀起本質(zhì)上的變革，使得國內(nèi)云計(jì)算圈子在除了 IaaS 之外的領(lǐng)域頗有點(diǎn)一籌莫展的感覺。在這層意義上，Docker 容器技術(shù)的誕生和普及絕對(duì)起到了久旱逢甘霖的效果。容器創(chuàng)業(yè)組織雨后春筍般萌發(fā)，不少團(tuán)隊(duì)的背景也跟經(jīng)典 PaaS 領(lǐng)域息息相關(guān)；另一方面原先經(jīng)典 PaaS 從業(yè)者的轉(zhuǎn)型到容器創(chuàng)業(yè)領(lǐng)域的也不在少數(shù)。所以目前國內(nèi) Docker 創(chuàng)業(yè)項(xiàng)目的產(chǎn)品形態(tài)，有一部分延續(xù)了原先 PaaS 項(xiàng)目的產(chǎn)品路線（尤其是 Cloud Foundry），比如：

重點(diǎn)關(guān)注應(yīng)用生命周期管理

強(qiáng)調(diào)應(yīng)用訪問和域名綁定

納入 Docker 的部分概念比如數(shù)據(jù)卷和鏡像

對(duì)用戶屏蔽網(wǎng)絡(luò)、存儲(chǔ)和調(diào)度細(xì)節(jié)

將數(shù)據(jù)庫等應(yīng)用依賴抽象成” 服務(wù)”

而另外一部分則選擇了稍微偏向通用化的產(chǎn)品形態(tài)，這類項(xiàng)目一般會(huì)強(qiáng)調(diào)自己為 CaaS（Container as a Service），例如:

更多地對(duì)外暴露 Docker 容器各類概念

強(qiáng)調(diào)容器的 IP 而不是域名

不區(qū)分應(yīng)用和它所依賴的 “服務(wù)”

強(qiáng)調(diào)直接運(yùn)維容器而不是應(yīng)用

這種類型的創(chuàng)業(yè)組織提供出來的更類似基于容器的 IaaS，意在給用戶更大的自由度和發(fā)揮空間。當(dāng)然，無論哪種形態(tài)，大家一般都會(huì)把 CI/CD 流程的支持納入到自己的主要產(chǎn)品體系，畢竟這是 Docker 最受大家認(rèn)同的一個(gè)場景；而且各家產(chǎn)品也都在功能上互相滲透，其實(shí)并沒有一個(gè)非常明確的邊界。

從這個(gè)角度出發(fā)，當(dāng)前的大多數(shù)創(chuàng)業(yè)組織的產(chǎn)品在大方向上會(huì)逐漸趨同，畢竟 Docker 本來的發(fā)展路線也是淡化云計(jì)算的分層理念，變輕，變薄。然后在小方向上營造差異化，比如有的組織會(huì)選擇構(gòu)建各類開發(fā)者工具形成產(chǎn)品鏈，有的會(huì)選擇在 Infra 層面提供更優(yōu)質(zhì)、廉價(jià)、可靠的計(jì)算和存儲(chǔ)資源（比如 SSD，高效的調(diào)度策略，最大程度壓榨 IaaS 層利用率，甚至提供基于虛擬化技術(shù)的容器以徹底解決安全和隔離性問題）。

總之，目前國內(nèi)容器創(chuàng)業(yè)圈子產(chǎn)品能力優(yōu)秀，相比之下即使是剛剛被 Docker 收購的 Tutum 恐怕在這一領(lǐng)域也沒有太多優(yōu)勢；但是創(chuàng)新能力稍顯不足，各個(gè)技術(shù)和產(chǎn)品點(diǎn)都是跟隨者，尚沒有展現(xiàn)出自己獨(dú)有的優(yōu)勢。

2015年 國內(nèi)容器技術(shù)圈的另一大事件便是巨頭的跟進(jìn)。各類互聯(lián)網(wǎng)甚至傳統(tǒng)技術(shù)企業(yè)在自己內(nèi)部進(jìn)行容器的規(guī)?；瘧?yīng)用的案例早已不是新聞，而阿里云，阿里百川 TAE，新浪 SAE，網(wǎng)易等諸多廠商也都在 2015年 開始對(duì)外提供或基于容器提供云計(jì)算服務(wù)，我們相信還有更多的團(tuán)隊(duì)還在醞釀中。一般來說國內(nèi)的 AE 類型的廠商（TAE SAE BAE）會(huì)優(yōu)先選擇提供 PaaS 類型的產(chǎn)品，原先的 IaaS 廠商則更愿意提供容器云服務(wù)。

不管是哪種形態(tài)，國內(nèi)容器服務(wù)的熱度值的確做到了另前來布道的 Docker、Google 的老外們都驚嘆不已的程度。但是稍微令我擔(dān)憂的是，這種熱度的發(fā)展，可能會(huì)過早的將國內(nèi)容器技術(shù)提供商拖到價(jià)格戰(zhàn)的泥潭，屆時(shí)大家過早停滯技術(shù)和產(chǎn)品的打磨而開始拼價(jià)格、拼渠道、拼運(yùn)營，長遠(yuǎn)來看可能并不利于國內(nèi)容器圈子的發(fā)展。

關(guān)于傳統(tǒng) PaaS 和 laaS

國內(nèi)容器技術(shù)熱火朝天的背后，或多或少反襯出了傳統(tǒng) PaaS 和 IaaS 提供商的些許落寞。而事實(shí)上，傳統(tǒng) PaaS 和 IaaS 廠商在 2015年 依舊取得了不菲的成績，僅以 Pivotal Cloud Foundry 為例，其商業(yè)產(chǎn)品已打入了大量國際一線制造業(yè)和金融業(yè)巨頭，僅其中某一個(gè)大客戶的日均運(yùn)行容器數(shù)量恐怕目前尚沒有哪家互聯(lián)網(wǎng)公司能望其項(xiàng)背。

就這一點(diǎn)而言，目前的 Docker 容器服務(wù)商恐怕在很長一段時(shí)間之后都很難出現(xiàn)這種規(guī)模和高質(zhì)量的客戶案例。但是商業(yè)歸商業(yè)，開發(fā)者歸開發(fā)者，Docker 為主的容器技術(shù)掀起的風(fēng)潮起始于一線技術(shù)人員，也風(fēng)靡于一線技術(shù)人員，這與商業(yè)產(chǎn)品的成功路線本質(zhì)上就是不同的。這也正是為什么很多 PaaS 和 IaaS 廠商 2015年 甚至更早開始宣布支持 Docker 的最主要原因，OpenShift 甚至完全轉(zhuǎn)型基于 Kubernetes 進(jìn)行徹底重構(gòu)。但是無論如何，在關(guān)系更密切的開發(fā)者服務(wù)場景下，目前 startup 做的更好。

另一方面，OpenStack 社區(qū)也在積極的尋求同 Docker 等容器技術(shù)的結(jié)合點(diǎn)來試圖擴(kuò)展一線技術(shù)人員這一不能忽視客戶群，但是稍顯遺憾的是哪怕是 2015年 被反復(fù)提及的 Magnum 項(xiàng)目都沒有針對(duì)容器而對(duì) OpenStack 本身做本質(zhì)的改進(jìn)和集成，項(xiàng)目依然是停留在調(diào)用 OpenStack API 然后把容器運(yùn)行在 VM 里的程度。

我認(rèn)為，考慮到當(dāng)前情況下虛擬機(jī)的不可替代性，OpenStack 如果能夠提供虛擬機(jī)和物理機(jī)上容器的統(tǒng)一調(diào)度，或者引入類似 Hyper 或者 Clear Linux 這樣的虛擬化技術(shù)容器，進(jìn)而提供任務(wù)優(yōu)先級(jí)、搶占、混部等一系列數(shù)據(jù)中心級(jí)別的高級(jí)特性，也不失為一種進(jìn)取的手段。僅就 OpenStack 社區(qū)目前的應(yīng)對(duì)方案來看，仍然不足以解決開發(fā)者的目光被 Docker 吸引并且采用容器作為 OpenStack 替代方案的情況。當(dāng)然，OpenStack 無論是社區(qū)質(zhì)量、規(guī)模還是產(chǎn)品、生態(tài)圈都不是現(xiàn)在的 Docker 所能挑戰(zhàn)的，只是在社區(qū)層面對(duì) Docker 以及容器技術(shù)的支持上做的還不夠好。

總結(jié)

綜上所述，2015年 的容器技術(shù)圈，是各家施展手腳封疆劃土的擴(kuò)張一年，也是 Docker 以及容器技術(shù)生態(tài)參與者不斷完善自己的進(jìn)化一年?？偟膩碚f，盡管有不少亮點(diǎn)涌現(xiàn)，這一年的容器技術(shù)仍然處于厚積階段，標(biāo)準(zhǔn)尚未達(dá)成，社區(qū)缺乏平衡，跟進(jìn)者多創(chuàng)新者少。

但是，我們也不得不考慮到很可能這才是容器技術(shù)發(fā)展的一種常態(tài)，而不是重復(fù)其他開源項(xiàng)目的發(fā)展模式?；蛟S在未來，容器技術(shù)生態(tài)圈的參與者始終會(huì)保持著這種不斷進(jìn)化的姿態(tài)以應(yīng)對(duì)瞬息萬變的應(yīng)用場景和捉摸不定的開發(fā)者意圖，很難達(dá)成一種平衡或者穩(wěn)定的狀態(tài)。畢竟在容器技術(shù)這種無限貼近于每一個(gè)一線技術(shù)人員的特殊領(lǐng)域里，“唯有適者，才能生存”。