從chroot颂跨，control groups敢伸，lxc，warden恒削，一路走到如今的docker池颈、rocket、windows container钓丰、hyper躯砰，容器技術(shù)才算是真正的走向了大規(guī)模應(yīng)用。詳細的容器技術(shù)發(fā)展歷史可以參考下面這篇文章
本文主要從宏觀的角度携丁，梳理Docker與hyper這兩種container runtime及其相關(guān)生態(tài)的一個關(guān)系琢歇，幫助感興趣的人建立一個整體的印象。
Docker
Docker一路走來梦鉴，從獨立發(fā)展到參與開放容器規(guī)范的建設(shè)李茫，自身架構(gòu)也在不斷調(diào)整與完善，逐漸走向了更加規(guī)范和生態(tài)化的道路尚揣。宏觀上看涌矢，Docker Engine是一種client/server架構(gòu)，server端快骗，也即是daemon,由一個后臺常駐進程dockerd構(gòu)成娜庇。對外提供REST API塔次，整體架構(gòu)如下圖所示。
自1.11版本起名秀，Docker全面調(diào)整模塊架構(gòu)励负，成為了第一個符合OCI規(guī)范的容器運行時。具體來說匕得，Docker Engine目前是基于containerd和runc構(gòu)建的继榆。下面詳細介紹相關(guān)OCI規(guī)范、runC汁掠、containerd略吨。
什么是OCI規(guī)范
OCI(Open Container Initiative)致力于建立一個容器運行時和鏡像格式的規(guī)范，其核心目的在于避免容器生態(tài)的分化考阱，確保在不同容器引擎上構(gòu)建的容器可以相互兼容翠忠。這是容器可移植性的根本保證。雖然Docker目前是容器的事實規(guī)范乞榨，但隨著時間的推移秽之，會不斷涌現(xiàn)一些其他的容器引擎，這個時候就很有必要來定義一下“什么是一個容器”吃既，保證不同的實現(xiàn)遵循一些共同的東西考榨。這既是OCI期望做的事情。
- runtime spec
OCI Runtime Specification鹦倚，主要定義如何container配置河质、執(zhí)行環(huán)境以及container生命周期。
- image spec
OCI Image Format Specification震叙，主要定義一個OCI image由一個manifest, 一個image index (optional), 一組filesystem layers, 以及一個configuration組成愤诱。該規(guī)范的目的在于確保能構(gòu)建一套不同容器引擎間可互操作的工具，用于鏡像的構(gòu)建捐友、傳輸淫半，以及鏡像運行準備工作。
有關(guān)OCI詳細資料匣砖，可參考其官方網(wǎng)站
什么是runC
在早期的Docker Engine中科吭，主要用LXC工具來運行和管理容器；后來采用自研的libcontainer來做這類事情猴鲫，libcontainer直接使用Linux內(nèi)核提供的相關(guān)隔離技術(shù)对人，比如cgroups、namespace等等拂共。
runC是一個輕量級的工具牺弄，做且只做一件事情，那就是運行一個容器宜狐。由libcontainer演變而來势告，并且由Docker捐獻給Linux基金會蛇捌，作為OCI的參考實現(xiàn)。
有關(guān)runC詳細資料咱台，可參考其github repo
什么是containerd
2016年12月14日络拌，Docker公司宣布將containerd從Docker Engine中分離，并捐贈到一個新的開源社區(qū)獨立發(fā)展和運營回溺，"一個工業(yè)標準的容器運行時春贸，注重簡單、 健壯性遗遵、可移植性"萍恕。containerd可以作為daemon程序運行在Linux和Windows上，管理機器上所有容器的生命周期车要。
Docker 1.11的Docker Engine里就包含了containerd雄坪，而現(xiàn)在則是把containerd從Docker Engine里徹底剝離出來，作為一個獨立的開源項目獨立發(fā)展屯蹦，目標是提供一個更加開放、穩(wěn)定的容器運行基礎(chǔ)設(shè)施绳姨。和原先包含在Docker Engine里containerd相比登澜，獨立的containerd將具有更多的功能，可以涵蓋整個容器運行時管理的所有需求飘庄。
containerd并不是直接面向最終用戶的脑蠕，而是主要用于集成到更上層的系統(tǒng)里，比如Swarm, Kubernetes, Mesos等容器編排系統(tǒng)跪削。containerd以Daemon的形式運行在系統(tǒng)上谴仙，通過unix domain docket暴露很低層的gRPC API，上層系統(tǒng)可以通過這些API管理機器上的容器碾盐。每個containerd只負責一臺機器晃跺，Pull鏡像，對容器的操作（啟動毫玖、停止等）掀虎，網(wǎng)絡(luò)，存儲都是由containerd完成付枫。具體運行容器由runC負責烹玉，實際上只要是符合OCI規(guī)范的容器都可以支持。
- 整體架構(gòu)
- 模塊分層
有關(guān)詳細信息可參考官網(wǎng)和github項目主頁
Docker如何組合上述組件
先看上面這張圖阐滩，docker目前被分成了4個獨立部分二打，engine管理鏡像，通過containerd掂榔，containerd調(diào)用containerd-shim继效，containerd-shim調(diào)用runc啟動容器症杏。containerd只與容器打交道。圖中列出的每個組件莲趣，都有一個獨立的二進制可執(zhí)行文件與之對應(yīng)鸳慈，如下所示
Kubernetes on Docker
基本的容器runtime還遠遠不能滿足大規(guī)模應(yīng)用的需求，典型的訴求就是容器的編排管理系統(tǒng)喧伞，Docker公司自身的swarm走芋，google的kubernetes，以及mesos marathon就是這類編排系統(tǒng)潘鲫。經(jīng)過這幾年的發(fā)展翁逞，kubernetes大有一統(tǒng)江湖的趨勢，kubernetes本身與docker的結(jié)合方式也在不斷的變化溉仑，自身的定位也逐漸在往通用性容器編排調(diào)度系統(tǒng)發(fā)展挖函，所以k8s一直在探索如何兼容更多的container runtime，CRI就是在這種背景下誕生的浊竟。
CRI
從1.5版本開始怨喘，kubernetes引入了CRI(Container Runtime Interface)，可參考Introducing Container Runtime Interface (CRI) in Kubernetes振定，其核心目的在于通過一種標準的方式來集成各種不同容器runtime必怜。并且是一種可插拔的架構(gòu)，可以在不改變kubernetes的前提下后频，使用不同的container runtime梳庆。在CRI之前，不同的container runtime（docker/rkt等）集成到kubelet是通過在kubelet中實現(xiàn)一個高層接口來完成的卑惜，之前叫做OCID膏执，CRI-O則是完全聚焦與OCI兼容的container runtime和container images。
CRI-containerd
CRI-containerd則是基于containerd的CRI實現(xiàn)露久，目前是kubernetes的一個孵化項目更米，kubernetes 1.8中已進入beta版本。主要用于替代前期基于dockerd的CRI實現(xiàn)毫痕。
-
kubelet從dockershim向cri-containerd遷移
CRI-containerd架構(gòu)
[圖片上傳失敗...(image-c3ebe5-1517490845623)]
所以在這種新型架構(gòu)下壳快，kubelet直接通過基于containerd的CRI實現(xiàn)(CRI-containerd)與docker-containerd交互，以實現(xiàn)container的管理镇草。
hyper container
鑒于docker是共享宿主機的內(nèi)核眶痰，所以在安全性方面有天然的弱勢。傳統(tǒng)的虛擬機則屬于內(nèi)核相互隔離的梯啤。那么能否結(jié)合二者的優(yōu)點呢竖伯，答案就是hyper container。
hyper container主要有4部分構(gòu)成，hyperctl客戶端七婴，hyperd祟偷，hyperkernel，hyperStart打厘。整體架構(gòu)如下圖所示
hyper container直接使用OCI鏡像規(guī)范修肠，hyper的runtime是基于hypervisor的runV，兼容OCI runtime規(guī)范户盯，但是由于hypervisor和container的天然區(qū)別嵌施，OCI中有部分規(guī)范在hyper里是沒有的，詳情可參見github項目主頁莽鸭。
類似hyper的還有intel開源的clearcontainers
小結(jié)
容器生態(tài)正在走向規(guī)范化吗伤，結(jié)和虛擬機和container二者優(yōu)勢的hyper正在快速發(fā)展，編排系統(tǒng)kubernetes正在穩(wěn)步成熟硫眨，周邊生態(tài)也在不斷完善足淆，CNCF家庭成員也在不斷壯大，微服務(wù)理念也逐步深入人心礁阁，service mesh技術(shù)正在高速發(fā)展...一切值得期待
