解讀2015之容器篇：擴張與進化

編者按

2015年，整個IT技術領域發生了許多深刻而又復雜的變化，InfoQ策劃了“解讀2015”年終技術盤點系列文章，希望能夠給讀者清晰地梳理出技術領域在這一年的發展變化，回顧過去，繼續前行。

回顧2015年容器技術的發展歷程，我們可以用兩個關鍵詞來概括：擴張與進化。

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

國外容器技術項目

在2015年，一直以“善意獨裁”面孔示人的Docker公司終于邁出了合作的第一步。OCI組織的成立宣告了工業界對Docker提出的容器技術的高度認同，也暗含了后進場玩家試圖從這個由startup開創的新領域中分得一杯羹的決心。然而runC項目運作到現在，依然沒能夠進入Docker Daemon的實現主干，也沒有任何巨頭發布以runC為基礎的新容器實現。Docker而不是runC被用戶當作容器技術的事實標準的現狀在短期內（1-2年）恐怕還很難發生本質改變。容器技術領域多樣化的任務目前還是落在直接競爭對手CoreOS，以及另辟蹊徑的虛擬化容器技術比如Hyper和Intel Clear Linux身上。但是無論如何，誕生于startup的Docker容器注定要經歷更多的考驗才能在巨頭林立的云計算領域真正地扎根生長，無論其是否愿意，將容器技術標準化是這條道路上必須面對的選擇和進化方向。

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

2015年，Google和RedHat聯盟以Kubernetes 1.0為陣地宣告了大規模容器編排與管理領域的領主地位。號稱以Borg等Google多年容器技術實踐經驗為理論指導、以Google和RedHat PaaS團隊為主要工程力量的Kubernetes項目一經宣布生產級別可用，便立刻吸引了的工業界乃至學術界的大量關注和投入。盡管不是第一家，但是我們不得不承認Google的號召力和Kubernetes不凡的背景直接推動了CNCF這一容器編排管理標準組織的誕生。在技術方向上，Kubernetes團隊則試圖以Kubernetes為依托來對外輸出Google的容器技術的思想和經驗，或多或少有點要彌補LMCTFY項目中途夭折的意思。無論如何，Kubernetes所體現出的前瞻性的容器技術實踐思路，確實值得我們每一個容器技術實踐者重點關注和學習。無論是Pod及伙伴容器、單Pod單IP網絡模型、volume插件機制、容器生命周期鉤子這種對容器技術本身的改造，還是虛擬IP與負載均衡、垂直健康檢查、密碼數據卷管理、元數據API等平臺級別能力的實現，都展現出了Kubernetes與其他編排管理項目與眾不同的技術視野和團隊實力。在未來發展方向上，Kubernetes已經開始向1000+節點的集群規模進發，畢竟在性能和規模化領域，Kubernetes沒有理由落后競爭者太久。另一方面，除了常規的long time running任務，其他類型任務比如短任務和daemon任務的支持都已經引入了項目主干，類似big data業務的支持將是未來的一個重要方向。

在與Docker”分手“之后，CoreOS一直在積極地尋求展示自己技術想法的機會，包括加入OCI組織以及在Kubernetes上同Google開展深度的合作。鑒于OCI最開始只關注于container runtime的實現標準，CoreOS的AppC一直在積極推進鏡像標準的概念。目前這個標準已經在Kubernetes上初見雛形。最值得關注的是，CoreOS還在0.8.0版本發布時高調宣布了同Intel Clear Linux團隊合作在rkt上實現了基于虛擬化技術隔離的容器（這與國內的Hyper團隊的做法不謀而合，只不過后者是在Docker上做出的類似實現）。這種hypervisor-based container是目前在公有云上提供容器服務最佳選擇，CoreOS在容器安全和隔離性問題上進行本質革新的做法的確很有說服力。而在容器編排管理領域，CoreOS公司將Kubernetes組件內置到CoreOS項目中作為主要的底層依賴之一。Etcd的作者目前也正在Kubernetes社區積極推進項目整體性能提升和調度效率優化的工作，畢竟作為整個項目的核心依賴，Etcd的作者們有足夠的理由和能力承擔起Kubernetes性能提升的重任。這一點上其他容器管理項目可能要稍微眼紅一下了。

而在另一邊，Mesosphere公司借助在資源調度管理領域與生俱來的優勢，在2015年成功開拓出了一片以DCOS為核心、兼顧大數據和應用托管的服務平臺市場。Apache Mesos項目原生的兩級調度和多框架支持使得用戶在自己的組織內部設施云計算平臺終于變得唾手可得。尤其是在傳統技術型企業轉型互聯網架構的過程中，Mesos生態圈能夠非常方便的在企業內部迅速實現一套原本在一線互聯網公司中都算得上“黑科技”的資源調度管理平臺，然后快速搭建起PaaS和BigData服務。盡管Mesos原生并非針對容器設計，Mesosphere所提供的諸如Marathon等上層解決方案也明顯在成熟度和技術實現上有著這樣那樣的不足，但是不得不說Mesos生態體系目前是企業自建私有云最快速、最有利于展示POC的一套技術方案。鑒于Mesos本身較難只針對Docker進行根本性的改造，Mesosphere生態圈目前依賴于Marathon等上層項目來響應Docker容器技術的快速發展，在這種形勢下，一組包含了用戶生命周期管理、多維度監控、整合大數據業務管理等功能的完善的PaaS很可能是這些上層框架的最終形態。

當然，最后一定要說的就是Docker公司了。在進入2015年之后，雄心勃勃的Docker公司在Docker源碼層面開始了大規模的重構，將原先倉促發布的很多模塊進行了統一的抽象和整合，使得在1.9版本徹底解耦Volume和Network成為了可能。另一方面，Docker公司加緊了自己在組建生態圈閉環上的戰略布局，這一點以年末收購Tutum為2015年畫上了圓滿的句號。之所以強調這一點，是因為Docker之前的收購對象都是在某一領域具有獨創性的公司或團隊，比如容器編排上的Fig，容器網絡上的SocketPlane，而Tutum雖然在Control Panel以及產品化上做的很早很出色，但是類似的競爭者卻不在少數且產品能力也很強，更何況Docker公司自己在這一領域已經有所動作。所以Tutum最終勝出的確是自身技術和產品實力的最有力證明。

在技術路線上，Docker把同runC的集成列到了高優先級任務上，并且已經為之做了大量重構工作，但是奈何daemon同libcontainer的交互過于繁雜，此項工作進展一直緩慢。好消息是Docker在年末發布了Containerd項目來專門負責同runC進行交互，此項目最終會進入Docker Engine主干從而間接實現Docker同libcontainer的解耦。一旦這個目的達成，Docker daemon的復雜度會大大降低，性能也很可能得到大幅提升，更重要的是屆時容器開發者將有能力定制自己的daemon，在容器端加入定制化的功能和特性，這才是runC項目的真正意義和玩法，非常值得期待。Docker公司在2015年的另一個大動作便是1.9版本的發布終于完成了存儲和網絡功能的解耦，使得用戶可以以插件的方式提供第三方存儲和網絡功能來支持遠程數據卷和跨主機網絡。

但是需要提醒讀者的是，無論是網絡還是存儲，這些插件方式的工作原理與非插件方式并沒有本質區別，Docker并沒有能力也沒有理由提供任何優化。所以在這一點上，普通用戶在前期階段需要寄希望于社區里的插件開發者的能力和技術水平不要太低。因為筆者前面的經驗表明即使是Docker官方比如SocketPlane提供的網絡方案，在穩定性、可用性上也沒有特別值得表揚的地方，建議用戶保守上線該功能，必要時自己按需開發插件。“Docker之心，路人皆知”。這家已經在云計算領域掀起革命的startup背后的野心之大，的確配得上目前它在輕量級應用容器界的號召力和絕對地位。在未來的發展方向上，有如下幾個方向上的進化是一定會發生的：

1. Docker Engine的進一步模塊化和解耦，最終用戶一定可以選擇使用其中的一部分來達成自己的目的
2. runC全面取代execdriver來執行容器
3. 更豐富的插件能力和以此為基礎的數據卷管理能力（類似Flocker）

在容器編排與管理領域，Docker已經構建出了Compose+Swarm+Machine的技術閉環，這套技術棧的最大亮點是全面兼容Docker API。當然，這個優勢的前提是目前Docker而不是runC仍然是業界公認的容器標準。在這個領域，Docker目前選擇了重點照顧用戶友好度而適當放棄性能和規模能力的路線，畢竟在兼容Docker API的前提下引入更復雜的編排、調度和管理能力是比較困難的。這也是為什么Swarm現在正在推進同Mesos集成以提高調度方面的性能和可擴展能力，雖然筆者認為這個路線可能并不太友好(想象一下宿主機上同時運行著Docker dameon，Swarm agent和Mesos Slave的場景）。

總之，Docker目前在容器界的領導地位已經毋庸置疑。一系列產品和技術布局的完成也確立了Docker公司在這一由它自己開拓的疆土上的霸主地位。接下來，如何在不甘心的巨頭們設置的規則叢林里生存、壯大并且健康發展下去，甚至達成Linux項目的創舉，則是考驗這家已經創造了一個不小的奇跡的初創團隊真正實力和水平的難題。

國內容器技術圈

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

1. 重點關注應用生命周期管理
2. 強調應用訪問和域名綁定
3. 納入Docker的部分概念比如數據卷和鏡像
4. 對用戶屏蔽網絡、存儲和調度細節
5. 將數據庫等應用依賴抽象成”服務”

而另外一部分則選擇了稍微偏向通用化的產品形態，這類項目一般會強調自己為CaaS（Container as a Service），例如:

1. 更多地對外暴露Docker容器各類概念
2. 強調容器的IP而不是域名
3. 不區分應用和它所依賴的“服務”
4. 強調直接運維容器而不是應用

這種類型的創業組織提供出來的更類似基于容器的IaaS，意在給用戶更大的自由度和發揮空間。當然，無論哪種形態，大家一般都會把CI/CD流程的支持納入到自己的主要產品體系，畢竟這是Docker最受大家認同的一個場景；而且各家產品也都在功能上互相滲透，其實并沒有一個非常明確的邊界。從這個角度出發，當前的大多數創業組織的產品在大方向上會逐漸趨同，畢竟Docker本來的發展路線也是淡化云計算的分層理念，變輕，變薄。然后在小方向上營造差異化，比如有的組織會選擇構建各類開發者工具形成產品鏈，有的會選擇在Infra層面提供更優質、廉價、可靠的計算和存儲資源（比如SSD，高效的調度策略，最大程度壓榨IaaS層利用率，甚至提供基于虛擬化技術的容器以徹底解決安全和隔離性問題）。總之，目前國內容器創業圈子產品能力優秀，相比之下即使是剛剛被Docker收購的Tutum恐怕在這一領域也沒有太多優勢；但是創新能力稍顯不足，各個技術和產品點都是跟隨者，尚沒有展現出自己獨有的優勢。

2015年國內容器技術圈的另一大事件便是巨頭的跟進。各類互聯網甚至傳統技術企業在自己內部進行容器的規模化應用的案例早已不是新聞，而阿里云，阿里百川TAE，新浪SAE，網易等諸多廠商也都在2015年開始對外提供或基于容器提供云計算服務，我們相信還有更多的團隊還在醞釀中。一般來說國內的AE類型的廠商（TAE SAE BAE）會優先選擇提供PaaS類型的產品，原先的IaaS廠商則更愿意提供容器云服務。不管是哪種形態，國內容器服務的熱度值的確做到了另前來布道的Docker、Google的老外們都驚嘆不已的程度。但是稍微另筆者擔憂的是，這種熱度的發展，可能會過早的將國內容器技術提供商拖到價格戰的泥潭，屆時大家過早停滯技術和產品的打磨而開始拼價格、拼渠道、拼運營，長遠來看可能并不利于國內容器圈子的發展。

關于傳統PaaS和IaaS

國內容器技術熱火朝天的背后，或多或少反襯出了傳統PaaS和IaaS提供商的些許落寞。而事實上，傳統PaaS和IaaS廠商在2015年依舊取得了不菲的成績，僅以Pivotal Cloud Foundry為例，其商業產品已打入了大量國際一線制造業和金融業巨頭，僅其中某一個大客戶的日均運行容器數量恐怕目前尚沒有哪家互聯網公司能望其項背。就這一點而言，目前的Docker容器服務商恐怕在很長一段時間之后都很難出現這種規模和高質量的客戶案例。但是商業歸商業，開發者歸開發者，Docker為主的容器技術掀起的風潮起始于一線技術人員，也風靡于一線技術人員，這與商業產品的成功路線本質上就是不同的。這也正是為什么很多PaaS和IaaS廠商2015年甚至更早開始宣布支持Docker的最主要原因，OpenShift甚至完全轉型基于Kubernetes進行徹底重構。但是無論如何，在關系更密切的開發者服務場景下，目前startup做的更好。

另一方面，OpenStack社區也在積極的尋求同Docker等容器技術的結合點來試圖擴展一線技術人員這一不能忽視客戶群，但是稍顯遺憾的是哪怕是2015年被反復提及的Magnum項目都沒有針對容器而對OpenStack本身做本質的改進和集成，項目依然是停留在調用OpenStack API然后把容器運行在VM里的程度。筆者認為，考慮到當前情況下虛擬機的不可替代性，OpenStack如果能夠提供虛擬機和物理機上容器的統一調度，或者引入類似Hyper或者Clear Linux這樣的虛擬化技術容器，進而提供任務優先級、搶占、混部等一系列數據中心級別的高級特性，也不失為一種進取的手段。僅就OpenStack社區目前的應對方案來看，仍然不足以解決開發者的目光被Docker吸引并且采用容器作為OpenStack替代方案的情況。當然，OpenStack無論是社區質量、規模還是產品、生態圈都不是現在的Docker所能挑戰的，只是在社區層面對Docker以及容器技術的支持上做的還不夠好。

總結

綜上所述，2015年的容器技術圈，是各家施展手腳封疆劃土的擴張一年，也是Docker以及容器技術生態參與者不斷完善自己的進化一年。總的來說，盡管有不少亮點涌現，這一年的容器技術仍然處于厚積階段，標準尚未達成，社區缺乏平衡，跟進者多創新者少。但是，我們也不得不考慮到很可能這才是容器技術發展的一種常態，而不是重復其他開源項目的發展模式。或許在未來，容器技術生態圈的參與者始終會保持著這種不斷進化的姿態以應對瞬息萬變的應用場景和捉摸不定的開發者意圖，很難達成一種平衡或者穩定的狀態。畢竟在容器技術這種無限貼近于每一個一線技術人員的特殊領域里，“唯有適者，才能生存”。

作者簡介

張磊，浙江大學VLIS/SEL實驗室云計算團隊負責人，Kubernetes項目Collaborator。