容器，你還只用Docker嗎？（下）
作者：周暉，Pivotal大中華區雲端計算首席架構師，有著豐富的PaaS雲實際建設經驗，負責過國內某知名銀行已經生產上線一年的PaaS雲的架構設計和部分功能的實現，參與過某超算PaaS、某超市電商PaaS、某電力PaaS等專案的建設。
上文說到CaaS生態圈的公司如何應對Docker用捆綁方式從容器入侵CaaS領域，CaaS廠商通過容器抽象、標準化容器執行時RunC以及容器功能外化外掛來重新定義容器。下面我們繼續來看CaaS廠商的具體方案。
CaaS業界通過分解重組Docker技術來替代Docker的方案
1、Kubernetes通過CRI-O取代Docker容器管理引擎架構
和Cloud Foundry的架構模式類似，Kubernetes也發展了CRI-O來取代Docker，架構圖如下：
CRI-O是Google的Kelsey和Docker CTO所羅門論戰之後的結果，論戰之後，Google就提出一個設想，要讓Kubernetes排程的容器去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的Kubernetes提供映象管理功能（Container/Images），完全可以取代Docker的映象倉庫。Kubernetes一方面支援容器外掛技術，另一方面自己也制定實現一些容器外掛，最典型的就是容器網路外掛，自己定義並實現了CNM的容器網路外掛。
因為Kubernetes之前一直支援Docker，為了保持一定的相容性，Kubernetes繼續支援Docker容器，但是不再支援Docker超出標準容器之外的特定功能，也就是把Docker的定位和RunC等同化，Docker做的再多功能也不用。
2、Mesos通過UnifiedContainer取代Docker容器管理引擎
和Kubernetes類似，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也支援容器外掛，容器外掛是獨立程序，在網路外掛方面優先支援Kubernetes的CMN外掛標準。CF Diego有自己的映象倉庫管理，也可以從Docker倉庫中獲取Docker映象部署。
不得不對Garden的設計多說幾句，Garden包括之前的Warden，從一開始的設計就是容器抽象，使得可以支援不同的容器執行時，而且Garden做了三層抽象，所以Garden從一開始就支援.Net應用，不是通過Windows 2016的容器機制來實現，而是在.Net執行時模擬了一個容器的實現，所以Garden支援Windows的幾乎所有版本的.Net應用。
Kubernetes 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廠商的推動下會在生產環境得到廣泛的應用。
Kubernetes目前基本只支援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廠商和技術，如Kubernetes/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人。
除了Kubernetes/Mesos/CloudFoundry支援RunC容器執行時，Docker的容器從1.11開始也內建RunC作為容器執行時，說明RunC受到最為廣泛的支援。
而Kubernetes/Mesos/CloudFoundry明確表示在容器抽象層不再支援Docker超越RunC之外的功能。
RunC屬於OCI，不再受Docker註冊商標的影響，對RunC的程式碼貢獻不再受限於Docker。
用RunC相當於給你一個乾淨簡單的容器執行時，用Docker相當於不管你要不要，強塞給你一堆可能你不想用的東西。
對於RunC和Docker的技術區別，詳細請參考上篇的4.5。
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專案來說，Kubernetes/Mesos/CloudFoundry往往就是基於RunC容器執行時。
RunC的社群也很活躍，除了RunC本身的更新很快，各大CaaS/PaaS生態圈如Google/Pivotal/Redhat/華為/CoreOS等都有專人在貢獻程式碼。
RunC相應的生態空間也在活躍，也有不同的專案在進行中。
RunC是CaaS/PaaS/OCI等生態圈共同的孩子，不是沒人看的孩子。
5、容器不需要標準更好
業界也有一些人持這個觀點。其實，標準的價值是常識，當然總會有反常識的言論出來。沒有標準就沒有合力，沒有合力哪來的發展。如果Docker公司把閉源，那可以沒有標準。既然是開源，又想要生態圈的其他公司和力量做貢獻，就要讓大家有合力，就要讓大家在標準的基礎做貢獻，而不是把生態圈的其他公司當作免費打工的。
總結和展望
Docker和CaaS生態圈在容器上的分裂已經是現在進行時了，雖然大家都沒有明說。這也將是容器和CaaS生態圈重要轉折事件。讓我們來看看目前正在發生的和在未來一年中很有可能發生的事情：
- Cloud Foundry率先採用RunC作為容器執行時，而且剛剛做了一個25萬個容器叢集的測試，https://www.cloudfoundry.org/cloud-foundry-approaching-250000-containers/ 驗證了PaaS+RunC的大規模叢集的支援。
Kubernetes的CRI-O也會盡快釋出，等CRI-O成熟以後，內建的容器執行時就應當是RunC，而不再是Docker了。
- Mesos的Unified Containerizer 也應當會在1年之內成熟，隨後內建的容器應當也是RunC，而不再是Docker。
- 在Docker被科普以後，客戶更關注的是CaaS而不是容器，再給客戶去科普Docker體現不出容器創業公司的價值。
- 一些不適合容器的Docker應用場景的案例會被證偽，在Docker和容器鮮為人知的時候，各種各樣的Docker案例層出不窮，包括一些明顯和常識有違的案例，比如交易系統採用Docker, 交易極嚴格的延時的要求不適合Docker。有的是故意混淆概念，交易本身不在Docker容器中，交易系統相關的一些模組在Docker中，為了突出宣傳效果，說交易系統採用Docker。
- Docker創業公司分化，越來越多的容器創業公司給別人介紹自己的時候會說我們是Kubernetes初創公司(或我們是Mesos創業公司)，不是Docker創業公司，強調自己是CaaS廠商，突出自己不是Docker廠商。當然，也有純Docker的創業公司，但優勢會變成劣勢，畢竟在CaaS領域,Docker沒有優勢。
- Docker在容器失去了Kubernetes/Mesos/CloudFoundry的支援之後，會更專注於Swarm，和CaaS的其他廠商的競爭將更直接，但是Docker公司一貫的對企業生產環境特性的不在乎，Swarm很難對其他CaaS形成競爭優勢。
- RunC的生態圈將越來越豐富，第一個就是把Docker映象轉換為RunC標準映象(這個已經有了)，其次就是各種各樣的外掛和RunC可以互動，中間還可以衍生出各種外掛的功能，如即插即用(動態性)、自動發現之內的。
一年以後，我們再來複盤。
參考內容
本文部分內容原創，但是大量引用了下面的參考連結，給這些參考文章作者致敬。
- http://www.dockerinfo.net/1959.html
- http://dockone.io/article/1672
- http://dwz.cn/4HTw6S
- http://www.infoq.com/cn/articles/docker-standard-container-execution-engine-runc
- https://segmentfault.com/a/1190000007157374
- http://www.echojb.com/dotnet-other/2016/09/25/213618.html
- http://www.wtoutiao.com/p/4fdLO2y.html
- http://dockone.io/article/1770
- http://dockone.io/article/776
- http://www.kubernetes.org.cn/300.html
- http://dockone.io/article/1327
- http://mp.weixin.qq.com/s/NlyJtev6sVTCGSaGSmVtzg
文章出處：DBAplus社群