作者介紹
周晖，pivotal大中國區雲計算首席架構師，有豐富的paas雲實際建設經驗，負責過國内某知名銀行已經生産上線一年的paas雲的架構設計和部分功能的實作，參與過某超算paas、某超市電商paas、某電力paas等項目的建設。
上文說到caas生态圈的公司如何應對docker用捆綁方式從容器入侵caas領域，caas廠商通過容器抽象、标準化容器運作時runc以及容器功能外化插件來重新定義容器。下面我們繼續來看caas廠商的具體方案。
一、caas業界通過分解重組docker技術來替代docker的方案
1、k8s通過cri-o取代docker容器管理引擎架構
和cloud foundry的架構模式類似，k8s也發展了cri-o來取代docker，架構圖如下：
cri-o是google的kelsey和docker cto所羅門論戰之後的結果，論戰之後，google就提出一個設想，要讓k8s排程的容器去docker化，雖然他們一開始說的是要分支出一個docker的分支來做容器，但是後來考慮到這樣做屬于刺刀見紅，殺傷力太大，是以在2016年6月先弄了一個ocid(oci守護程序)，就是runc的守護程序，和docker daemon有異曲同工之妙，該項目的維護人員此地無銀三百兩的說“這不是docker的分支”。
由于ocid過于和docker daemon類似，随後google又把這個項目重新命名為—cri-o(container runtime interface，容器運作時接口，o表示oci，也就是runc的運作時接口)，這也反映了google的心态，一方面通過cri對容器進行抽象，什麼容器我都支援，另外加一個o，我重點支援oci的runc，顯得不是那麼白刀子進紅刀子出，大家表面上還是和平共處，而且顯得立意更高，通過容器抽象層進一步标準化容器，runc隻是标準化容器運作時，cri把對容器的調用管理等也标準化，潛台詞是docker daemon是非标準的、獨家的。
同時，google也在向mesos推銷其cri-o，希望mesos也采用其cri-o的架構。
cri-o對容器運作時提供基本管理功能，同時google的k8s提供鏡像管理功能(container/images)，完全可以取代docker的鏡像倉庫。k8s一方面支援容器插件技術，另一方面自己也制定實作一些容器插件，最典型的就是容器網絡插件，自己定義并實作了cnm的容器網絡插件。
因為k8s之前一直支援docker，為了保持一定的相容性，k8s繼續支援docker容器，但是不再支援docker超出标準容器之外的特定功能，也就是把docker的定位和runc等同化，docker做的再多功能也不用。
2、mesos通過unifiedcontainer取代docker容器管理引擎
和k8s類似，mesos也不再隻支援docker容器，而且對容器進行了抽象，項目名字直接就叫”unified containerizer”—統一容器。目前還是支援 docker 和 mesos containerizer 兩種容器機制，未來就統一到”unified containerizer”。架構圖如下：
unified containerizer也支援插件架構，但是和docker的插件不是完全一樣，設計的插件類型更豐富，包括三大類：
第一類是程序管理，支援容器之前的程序，這也是mesos一貫的排程管理政策
第二類是隔離器: 在容器生命周期的各個階段提供擴充接口，保護了docker的幾類插件，如網絡、磁盤、檔案系統、卷插件。
第三類是容器鏡像管理，除了容器鏡像，還将支援虛機鏡像等。
mesos的統一容器基本就包含了dockerdaemon、docker倉庫等功能。
當然，由于之前一直支援docker容器，目前階段mesos還繼續支援docker，但是也有自己的mesos containerizer容器機制。
3、cloud foundry通過garden取代docker容器管理引擎
從runc逐漸成熟，cloud foundry的容器引擎garden就采用了runc作為容器運作時，如下圖：
garden取代dockerdaemon(docker daemon有内有docker server，docker server内有docker引擎)，直接調用runc來生成容器運作環境，同時cfgarden也支援容器插件，容器插件是獨立程序，在網絡插件方面優先支援k8s的cmn插件标準。cf diego有自己的鏡像倉庫管理，也可以從docker倉庫中擷取docker鏡像部署。
不得不對garden的設計多說幾句，garden包括之前的warden，從一開始的設計就是容器抽象，使得可以支援不同的容器運作時，而且garden做了三層抽象，是以garden從一開始就支援.net應用，不是通過windows 2016的容器機制來實作，而是在.net運作時模拟了一個容器的實作，是以garden支援windows的幾乎所有版本的.net應用。
k8s cri-o和mesos的unifiedcontainerizer都借鑒了garden的容器抽象設計思路，是以garden也是第一個支援runc的caas/paas。
從這個架構可以看出，cloud foundry的garden基于runc和容器插件，就替代了docker的容器功能，共同的是runc和容器插件，而garden取代docker daemon的容器管理功能。
當然，garden也支援直接部署docker鏡像。
二、容器生态的演進
1、各方以runc為核心重新建構容器生态圈，docker容器被弱化
在對開源docker分支進行了反複斟酌、放風聲、試探和讨論之後，各方覺得殺傷力太大的方案。而重新回到了折中方案，以runc為核心重新建構生态圈，并且通過插件來弱化容器在caas生态圈的重要性。
我們來看看生态圈的演進示意：
如上圖，辨別了容器生态圈或是caas的演進變化。
最早隻有docker和garden兩大主流容器，mesos和google都專注于caas，容器就全部采用docker，cloudfoundry由于在docker之前就推出了warden(後更新到garden)容器，cf采用自己的容器打造了paas平台，形成了一個和諧的生态。
在docker撈過界了，并且确實有些不符合企業生産系統的因素，包括後向相容性、商标問題、穩定性問題，于是各caas/paas生态廠商組建oci聯盟，打造runc容器引擎，隻需要一個簡單的容器起停、管理等引擎，把docker的容器功能一分為二，runc作為一個簡單明了的運作環境，降低複雜度，提升穩定性，适合生産系統。而對于docker容器的其他功能，則在各自的容器抽象層，依據需要去實作，而且因為docker本身內建了太多功能，不利于生産環境穩定性要求，各個容器抽象層都采用插件模式，維持容器的簡潔性，需要什麼功能再插入容器，比如需要網絡就可以插入網絡插件，需要存儲和卷通路，就插入存儲和卷的插件。
目前的形勢，就形成了docker和各個caas/paas廠商在同一層面競争，在caas/paas平台，docker并沒有什麼優勢，但是docker想把其容器的廣泛使用的優勢在caas中延續，目前看來并不容易。容器的主要使用者還是個人使用者、開發者使用者、運維使用者，而caas是企業系統，二者目标客戶不同、技術要求不同。
随着這個生态的演進，docker容器會更多的用于開發、測試環境，而runc在各個caas廠商的推動下會在生産環境得到廣泛的應用。
k8s目前基本隻支援runc容器，對于docker超出其容器抽象層之外的功能，一概不支援。同樣，mesos也通過其unified containerizer隻支援runc容器，目前還支援docker，但是未來的規劃是隻支援unified containerizer。cf也通過garden隻支援runc，不支援docker超出runc之外的功能。
2、runc生态的快速發展
由于docker的消極抵制，runc的發展好像并不為人所知，但是runc的發展還是很快的，runc本身就簡單，通過版本的持續的疊代更新，目前已經達到生産可用，而且主流的paas/caas紛紛采用。docker也從1.11開始内置runc容器運作時。
除了runc本身的發展，runc的生态圈也在快速發展，這個生态圈就脫離了的docker。比如最近的riddler，就是一個把docker容器轉換為runc鏡像。
詳見https://github.com/jfrazelle/riddler。
三、你還隻用docker嗎？
docker作為目前最熱的容器開源項目，受到廣泛的追捧。但是也要清醒地看到docker和容器生态圈的種種争鬥，docker通過注冊商标和在docker中内嵌容器叢集管理，擠壓生态圈其他公司的生存空間，而受到生态圈聯盟以runc和相應的技術來制約docker。
如果你是開發測試用docker，那麼基本不受影響，可以繼續，這也是很多公司對docker的定位。如果你是生産系統采用docker(包括swarm)，你就要注意，如果是你自己定制開發基于docker/swarm的caas(container as a service)，那問題也不大，出現漏洞或是定制可以自己打更新檔，但是要意識到你的更新檔不一定能合并到docker的主幹版本。如果是你采用的是第三方給你定制的基于docker和swarm的caas，你就一定要當心了，他們針對docker做的定制要合并到docker的後續版本有相當的難度，因為對于docker的更新檔定制合并，除了docker公司其他公司幾乎是沒有什麼控制力度的，還包括後向相容性問題。
作為使用者或是容器生态圈的創業公司，不能一棵樹上吊死，如果在容器層面隻考慮docker，而不考慮runc，可能會和caas/paas生态圈的标準越來越遠，未來和caas/paas的标準容器差異越來越大，主流的caas/paas廠商和技術，如k8s/mesos/cloudfoundry均不再支援docker容器超越runc之外的功能，而隻支援插件對runc功能的擴充。
業界更普遍的定位是docker用于開發測試環境，而runc用于生産環境，是以對于要在生産環境采用容器技術的，一定要研究runc。
作為容器創業公司，很多是在docker的風口成立的，但是由于docker一家獨大和docker注冊商标的法務問題，可能還沒有在風口起飛。應當可以考慮在oci/runc的生态圈進行相關技術的發展，oci/runc的生态圈受到實力強大的幾家公司的強力支援，如google、cf基金會、pivotal、redhat、mesos、coreos等。而且runc的生态圈還剛剛起步，還有很大的發展空間。而且作為技術創新，對于技術的前瞻性判斷非常重要，方向判斷正确，一路辛苦是披荊斬棘，方向判斷錯誤，一路辛苦也是前程堪憂。
國内的公司對runc的貢獻度越來越高，特别是華為，可能是國内公司中對runc貢獻最大的。還有easystack、南大索芙特等的貢獻，反倒是一些著名的docker創業公司看不到對runc的貢獻。這一方面反應了華為、easystack技術眼光和對社群的貢獻，另外也反映了為什麼華為和easystack在商業上也更成功一些。
四、對一些問題的提前答複
1、runc也是docker的，用docker和用runc不是一樣的嗎？
docker對runc有重大的貢獻，runc的早期也是基于dockerlibcontainer，但是runc在oci下獨立發展，有貢獻的廠商遠遠不止docker。在runc項目後，在oci的推動下，各個廠商積極貢獻，docker的代碼貢獻并不占主導，更談不上主要是docker在維護，更準确的說docker是runc的重要維護力量之一。
如下圖，是git上runc的代碼貢獻者排名：
前10個貢獻者中，docker隻占2位，不得不提國内的公司華為代碼貢獻排名是相當的靠前。而且runc的代碼貢獻者超過100人。
除了k8s/mesos/cloudfoundry支援runc容器運作時，docker的容器從1.11開始也内置runc作為容器運作時，說明runc受到最為廣泛的支援。
而k8s/mesos/cloudfoundry明确表示在容器抽象層不再支援docker超越runc之外的功能。
runc屬于oci，不再受docker注冊商标的影響，對runc的代碼貢獻不再受限于docker。
用runc相當于給你一個幹淨簡單的容器運作時，用docker相當于不管你要不要，強塞給你一堆可能你不想用的東西。
2、在docker如日中天的時候這麼說是嘩衆取寵
docker現在是如日中天，但是3年前也是剛起步，也許可以說runc就是3年前的docker。docker由于docker公司自身的商業特征，對容器生态圈其他公司的生存空間的擠壓，已經造成了容器生态圈的裂變。
“風起于青萍之末”，如日中天的時候可能就是走向下坡路的開始。docker一家和其他caas生态圈分裂，這條路注定是不平坦的。
3、黑docker黑出翔來了
黑docker的資料很多，所有資料都有出處，有參考内容連結，詳見後面的引用。
docker已經被布道師們說成”無所不能”，稍微有幾個不能，我覺得大家還是能差別得出來。
4、runc是沒人管的孩子
runc的自身發展遠不如docker那麼有名氣，因為runc本身就是一個很小的容器運作時，不是針對開發者的，開發者往往是通過docker接觸到runc，是以runc的閱聽人遠比docker要少。
但是對于caas項目來說，k8s/mesos/cloudfoundry往往就是基于runc容器運作時。
runc的社群也很活躍，除了runc本身的更新很快，各大caas/paas生态圈如google/pivotal/redhat/華為/coreos等都有專人在貢獻代碼。
runc相應的生态空間也在活躍，也有不同的項目在進行中。
runc是caas/paas/oci等生态圈共同的孩子，不是沒人看的孩子。
業界也有一些人持這個觀點。其實，标準的價值是常識，當然總會有反常識的言論出來。沒有标準就沒有合力，沒有合力哪來的發展。如果docker公司把閉源，那可以沒有标準。既然是開源，又想要生态圈的其他公司和力量做貢獻，就要讓大家有合力，就要讓大家在标準的基礎做貢獻，而不是把生态圈的其他公司當作免費打工的。
五、總結和展望
docker和caas生态圈在容器上的分裂已經是現在進行時了，雖然大家都沒有明說。這也将是容器和caas生态圈重要轉折事件。讓我們來看看目前正在發生的和在未來一年中很有可能發生的事情：
cloud foundry率先采用runc作為容器運作時，而且剛剛做了一個25萬個容器叢集的測試，https://www.cloudfoundry.org/cloud-foundry-approaching-250000-containers/ 驗證了paas+runc的大規模叢集的支援。
k8s的cri-o也會盡快釋出，等cri-o成熟以後，内置的容器運作時就應當是runc，而不再是docker了。
mesos的unified containerizer 也應當會在1年之内成熟，随後内置的容器應當也是runc，而不再是docker。
在docker被科普以後，客戶更關注的是caas而不是容器，再給客戶去科普docker展現不出容器創業公司的價值。
一些不适合容器的docker應用場景的案例會被證僞，在docker和容器鮮為人知的時候，各種各樣的docker案例層出不窮，包括一些明顯和常識有違的案例，比如交易系統采用docker, 交易極嚴格的延時的要求不适合docker。有的是故意混淆概念，交易本身不在docker容器中，交易系統相關的一些子產品在docker中，為了突出宣傳效果，說交易系統采用docker。
docker創業公司分化，越來越多的容器創業公司給别人介紹自己的時候會說我們是k8s初創公司(或我們是mesos創業公司)，不是docker創業公司，強調自己是caas廠商，突出自己不是docker廠商。當然，也有純docker的創業公司，但優勢會變成劣勢，畢竟在caas領域,docker沒有優勢。
docker在容器失去了k8s/mesos/cloudfoundry的支援之後，會更專注于swarm，和caas的其他廠商的競争将更直接，但是docker公司一貫的對企業生産環境特性的不在乎，swarm很難對其他caas形成競争優勢。
runc的生态圈将越來越豐富，第一個就是把docker鏡像轉換為runc标準鏡像(這個已經有了)，其次就是各種各樣的插件和runc可以互動，中間還可以衍生出各種插件的功能，如即插即用(動态性)、自動發現之内的。
原文釋出時間為：2016-11-29
本文來自雲栖社群合作夥伴dbaplus