Moby(Docker)社區(qū)

Docker在17年4月的時候推出了名為Moby項目,Moby著眼于“一個將組件裝配成定制化基于容器的系統(tǒng)的框架和一個所有容器發(fā)燒友試驗與交流想法的場所”,它內(nèi)部除了Docker 容器引擎外，還孵化了多個項目：Moby,buildkit，Datakit膘掰，HyperKit，VpnKit挽封。Docker對Moby的玩法，就是從Moby中抽取Docker版本，然后將其他孵化項目中比較成熟的部分納入到Docker里清焕。其中BuildKit就是一個成功孵化并進(jìn)入Docker的例子竟终。

發(fā)布Moby之后Docker-ce（docker的開源版本）發(fā)布采用兩種方式蝠猬，Stable版本和edge版本。Stable版本顧名思義為穩(wěn)定版本统捶，而兩次Stable版本之間一月發(fā)一次Edge版本榆芦，一般的商用選擇都是Stable版本。
截止到18年上半年之前喘鸟，Docker版本的發(fā)布采用3個月左右為周期進(jìn)行發(fā)布匆绣。這樣導(dǎo)致了上游社區(qū)特別是K8s社區(qū)對接上的麻煩，為了減少Docker用戶頻繁的更新版本什黑，Docker在18年Q4調(diào)整了版本發(fā)布計劃崎淳，從Docker 18.09開始，Docker版本保證6個月左右的版本維護(hù)期愕把，中間不再發(fā)布Edge版本拣凹，下一個版本是Docker-CE 19.03

Moby社區(qū)在過去的18年發(fā)布了如下Docker-ce stable版本：

Docker（Moby）近期最大的變化實際發(fā)生在17年11月的Docker-ce 17.11爬迟，對應(yīng)的Stable版本為18年2月出現(xiàn)的Docker-ce 17.12 在這兩個版本中Docker使用的Containerd從Containerd0.2.x一躍升級為Containerd 1.x。Containerd 0.2.x和Containerd1.x之間API級不兼容菊匿，且架構(gòu)發(fā)生重大變更
雕旨。由此引發(fā)了Docker-ce架構(gòu)的巨大變更。這是Docker社區(qū)在17年底到18年發(fā)生的重大的變更項捧请。

2014 年開始凡涩，Docker 和 Microsoft 便積極展開合作，在 2016 年疹蛉，先讓 Windows Server 整合了 Docker 引擎活箕。到 2017 年，整合了 Windows 容器可款，讓 Docker 能一次通吃 Linux育韩、Windows 容器集群。在18年1月份闺鲸，發(fā)布了Docker Desktop 的Deta版本筋讨，在其上在可以部署kubernete集群了，在Docker con舊金山大會上摸恍，Docker公司正式對外展示了Docker Desktop-Windows部署kubernete集群悉罕。

我們可以看到在18年度，Moby社區(qū)有大量Microsoft貢獻(xiàn)者在活躍立镶，在18年的所有Docker發(fā)布版本中可以看到大量Windows容器的特性和Bug修正壁袄。
其中最大的突破出現(xiàn)在18年，Docker Desktop和Docker-ce原本就是兩個獨立的產(chǎn)品媚媒。但是在Docker-ce18.09之前Docker Desktop采用Docker-CE的版本號嗜逻，例如18年8月推出了18.06.1-ce-win73 。但是在Docker-ce 18.09時刻缭召，Docker Desktop正式采用了自己獨立的版本為2.0.0.0;其中引擎部分還是采用的Docker-ce 18.09

Containerd社區(qū)

Containerd是Docker從15年12月推出的一個子項目栈顷，它將Docker引擎中的containerd捐獻(xiàn)到社區(qū)中，由此出現(xiàn)了一個Containerd社區(qū)嵌巷。Containerd的目標(biāo)是開發(fā)遵循OCI規(guī)范的商用環(huán)境容器運行時萄凤。
containerd并不是直接面向最終用戶的，而是設(shè)計為被用于集成到更上層的系統(tǒng)里晴竞，如Swarm蛙卤， Kubernetes， Mesos等容器編排系統(tǒng)。它利用已有的runtime颤难，對容器生命期管理神年、容器鏡像和容器存儲上做出更多工作；而容器網(wǎng)絡(luò)和編排交給了Docker引擎行嗤、Kubernetes等編排系統(tǒng)已日。

Containerd社區(qū)在18年發(fā)生的大事件有：

• 18年7月發(fā)布Containerd1.1.2正式將CRI-containerd以插件形式cri-plugion集成到了Containerd中。理論上來說栅屏，從此刻開始Containerd就可以獨立支持Kubelete CRI了飘千。

• 18年9月Containerd1.2.rc0出現(xiàn)，它實現(xiàn)為支持VM類型的容器栈雳，提供了shimv2抽象护奈。而Containerd 1.2在19年1月15日才正式發(fā)布。Containerd 1.2的出現(xiàn)標(biāo)志著Containerd對VM容器（Kata容器哥纫，runV容器）的支持上了一個新臺階霉旗。

Containerd的發(fā)布時就定位成容器編排工具的底層運行時，也就意味著Containerd可以被多種編排工具調(diào)用蛀骇，一同提供容器服務(wù)⊙崦耄現(xiàn)階段有Docker，阿里的Pouch這兩個容器引擎使用Containerd作為自己的運行時擅憔。Kubernete從1.7開始使用cri-containerd的方式支持kubelete使用containerd鸵闪；而Kubelete 1.10以上的版本就支持了直調(diào)containerd（通過containerd的cri-plugin）。在Kubelete直接使用containerd商用嘗試上暑诸，谷歌和IBM走在了前列偏灿。在18年11月轨帜，它在自家公有云下kubenete服務(wù)GKE 1.1上宣布提供beta方式的支持kubelete直調(diào)containerd髓抑。IBM在18年IBM cloud Private（ICP）上推出的三個release（5月的2.1.0.3评疗，9月的3.1.0和11月的3.1.1）已經(jīng)將kubenete直調(diào)containerd做為tech preview方式橄抹。

rkt社區(qū)

rkt（Rocket）是由前coreOS公司在14年底推出的容器引擎温赔，rkt推出的初衷是因為當(dāng)時Docker引入了Docker swarm編排工具况木，向著Docker平臺化的方向大步前行咐蚯。coreOS認(rèn)為Docker的設(shè)計理念偏離乃坤。所喲coreOS推出了自己的容器引擎Rocket（在15年更名為rkt）苛让。rkt的設(shè)計目標(biāo)就是純粹的容器引擎，它不提供容器平臺湿诊，不提供容器的編排狱杰。rkt從14年底推出0.0.0到18年4月11日推出最后一個版本1.30一共推出了46個版本。在rkt的github社區(qū)上列出了幾個商用客戶厅须，由于不知所以本文就不再列出仿畸。

rtk和kubenete的集成出現(xiàn)在kubenete1.3版本，也就是因為rkt這一類容器的出現(xiàn)才促使kubenete社區(qū)在16年底kubenete1.5時刻推出的自己容器運行時標(biāo)準(zhǔn)接口CRI。在17年kubenete社區(qū)孵化了rkt的cri接口層rktlet错沽，至今為止它只在17年11月推出了一個版本0.1.0簿晓。這個版本只通過了部分kubenete 1.9 e2e測試用例。

rkt和rktlet社區(qū)都以coreOS公司為主導(dǎo)千埃。18年發(fā)生了一個大事件憔儿，導(dǎo)致了rkt實際死亡，那就是18年1月紅帽收購了coreOS放可。由于紅帽早已大力主推自己的容器運行時項目CRI-O谒臼，所以rkt項目的實際運作在18年4月份中止了，rkt和rktlet的最后更新都停止在了18年4月耀里◎阽停可以認(rèn)為紅帽將coreOS rkt資源投入到了CRI-O中。

gvisor社區(qū)

在18年5月冯挎，谷歌推出了一種全新的沙盒式容器運行時gvisor劫樟。gvisor它是一個支持OCI規(guī)范的容器運行時。它能夠為容器提供更安全的隔離织堂，同時比VM更輕量叠艳。gvisor的設(shè)計者認(rèn)為現(xiàn)在的容器使用了用戶態(tài)隔離而內(nèi)核卻是共用的，雖然使用seccomp易阳，selinux和Appamor在控制了潛在的安全風(fēng)險附较。但是傳統(tǒng)容器中惡意應(yīng)用依然存在逃逸的可能性。針對這樣的安全風(fēng)險潦俺，VM容器可以實現(xiàn)基于虛擬化層的強(qiáng)隔離拒课；但是VM容器也引入了不小的虛擬化層開銷——更多的cpu、內(nèi)存消耗事示。而gvisor使用了類似于用戶態(tài)Linux的方式早像，在內(nèi)核和容器之間引入的新的linux系統(tǒng)調(diào)用隔離層將所有的容器內(nèi)部發(fā)起的系統(tǒng)調(diào)用進(jìn)行截?fù)舨⒅匦聦崿F(xiàn)。

gvisor架構(gòu)圖

gvisor現(xiàn)在由兩種系統(tǒng)調(diào)用截?fù)舴桨福?/p>

• ptrace方案
• kvm方案

ptrace方案可以應(yīng)用于任何宿主機(jī)包括云主機(jī)環(huán)境上肖爵，它采用ptrace方式卢鹦，在容器內(nèi)部應(yīng)用發(fā)起系統(tǒng)調(diào)用的時刻將應(yīng)用跳轉(zhuǎn)到自己實現(xiàn)的系統(tǒng)調(diào)用代碼中。ptrace模式的工作模式類似于使用gdb調(diào)試用戶態(tài)進(jìn)程的方式劝堪。此外gvisor還支持kvm方式冀自，在 KVM 模式下，gVisor 能夠截獲應(yīng)用程序的每個系統(tǒng)調(diào)用秒啦，并將其轉(zhuǎn)交給 gvisor自己實現(xiàn)的系統(tǒng)調(diào)用層進(jìn)行處理熬粗。相比較 VM，我們看不到 Qemu 的身影余境，也看不到 Guest Kernel驻呐，gvisor自己實現(xiàn)的系統(tǒng)調(diào)用層包攬了所有必要的操作灌诅。這種對虛擬化的實現(xiàn)方法，我們稱之為“進(jìn)程級虛擬化”含末。gvisor只實現(xiàn)了部分的系統(tǒng)調(diào)用：實現(xiàn)了 200 個左右的系統(tǒng)調(diào)用延塑，而 Linux Kernel 則為 X86_64 提供了 318 個系統(tǒng)調(diào)用。所以現(xiàn)在部分軟件還不支持gvisor答渔，例如postgel关带。而且現(xiàn)階段gvisor實現(xiàn)的部分系統(tǒng)調(diào)用依然依賴于宿主機(jī)上的內(nèi)核系統(tǒng)調(diào)用。

對于容器網(wǎng)絡(luò)沼撕，gvisor實現(xiàn)了用戶態(tài)網(wǎng)絡(luò)協(xié)議棧宋雏。其整個數(shù)據(jù)流跟原生容器一樣，唯一區(qū)別在于 gVisor 需要捕獲到安全容器內(nèi)應(yīng)用程序關(guān)于網(wǎng)絡(luò)的系統(tǒng)調(diào)用务豺。例如, listen/accept/sendmsg 等等磨总。之后再將其轉(zhuǎn)換成 host 的系統(tǒng)調(diào)用來進(jìn)行網(wǎng)絡(luò)通信。

對于文件訪問笼沥，gvisor實現(xiàn)了自己的vfs層蚪燕。其上實現(xiàn)了實現(xiàn)具體的文件系統(tǒng)。有 9p奔浅，tmpfs馆纳，procfs，sysfs 汹桦。真正的文件訪問使用9pfs文件系統(tǒng)訪問到宿主機(jī)上的文件鲁驶。

gvisor作為容器運行時，它實際上和Docker世界的RunC是同層次的舞骆。gvisor目前支持替換runC作為Docker容器的運行時钥弯。Kubenete使用gvisor有兩種方式，第一種方式是在Minikube里使用gvisor容器督禽；另外一種方式是使用kubelete對接Containerd脆霎，配置Containerd使用gvisor-containerd-shim，那么所有帶特定標(biāo)記的容器都會以gvisor方式創(chuàng)建狈惫。
截止到18年9月社區(qū)上kubenete +docker+gvisor這條路依然沒有走通睛蛛。
目前來看gvisor成熟尚需時日，未見任何商用用例虱岂。

CRI-O社區(qū)

CRI-O（其O代表OCI）玖院，前身是OCID——OCI Daemon，它的誕生源于2016年夏天谷歌的K8s工程師和Docker CTO在社交媒體上的一起大論戰(zhàn)第岖。這場大論戰(zhàn)背后是Docker在16年7月推出的Docker 1.12將Swarm集成到了Docker引擎內(nèi)部，這無疑是動了K8s的蛋糕试溯，所以雙發(fā)終于在16年夏天擦槍走火蔑滓。這場大論戰(zhàn)的詳細(xì)過程本文不去回顧，感興趣者可以參考《容器，你還只用Docker嗎键袱？》燎窘。但是這場大論戰(zhàn)的直接后果就是在谷歌的推動下K8s社區(qū)推出的了OCID項目，也就是現(xiàn)在的CRI-O項目蹄咖。CRI-O在社區(qū)中有非常強(qiáng)有力的推動力量——谷歌和紅帽（紅帽因為Systemd和Docker之間也存在罅隙）褐健，而IBM，SUSE澜汤，Intel蚜迅，Hyper等公司也是CRI-O的contributor。

CRI-O認(rèn)為大多數(shù)的用戶只是使用k8s的容器俊抵，而并不關(guān)注其容器運行時到底是Docker谁不、rkt還是別的什么。CRI-O 設(shè)計目標(biāo)就是為OCI兼容的容器runtime實現(xiàn)了一個K8s CRI接口層徽诲。目前CRI-O支持兩種runtime：RunC和Kata刹帕。CRI-O是一個非常輕量的工具集，它使用runtime去管理容器的生命期谎替，使用CNI插件創(chuàng)建容器網(wǎng)絡(luò)偷溺，使用container/storage來管理容器的rootfs，使用container/image來管理容器鏡像钱贯，使用conmon來監(jiān)控容器的運行亡蓉。container/storage目前支持overlayfs、devicemapper喷舀、AUFS和btrfs砍濒，Overlayfs作為缺省的存儲驅(qū)動。目前計劃支持網(wǎng)絡(luò)文件系統(tǒng)nfs,ceph和Glusterfs硫麻。container/image支持從鏡像倉庫中pull鏡像爸邢，支持Dokcer V1和V2兩個版本的鏡像。
原本CRI-O的設(shè)計初衷是為了對接Kubenete拿愧，并不是直接對接終端客戶可以不提供類似于Docker cli一樣的命令行杠河。但是為了調(diào)試目的，CRI-O推薦使用：crictl調(diào)試CRI-O容器引擎浇辜，podman工具管理kubenete Pod券敌，buildah構(gòu)建、推送鏡像為鏡像簽名柳洋，skopeo拷貝待诅、刪除、查看和簽名鏡像熊镣。

CRI-O的架構(gòu)

CRI-O是目前容器社區(qū)中除了Docker外卑雁，商用進(jìn)程最快的募书、最廣泛應(yīng)用的容器引擎。紅帽為CRI-O投入了大量的資源测蹲，包含了收購CoreOS后獲得RKT的資源都投入到CRI-O中莹捡。CRI-O在17年推出了1.0版本，它對應(yīng)的Kubenete版本是1.7.x扣甲。CRI-O 1.10與Kubenete 1.10兼容篮赢，CRI 1.11與kubenete 1.11兼容，CRI-O 1.12與Kubenete1.12兼容琉挖，CRI-O
1.13與kubenete1.13兼容启泣。總之CRI-O與kubenete在版本號一致時粹排，保持兼容性种远。CRI-O在18年度商用進(jìn)程突然加速，紅帽的kubenete發(fā)行版本openshift3.9 中將CRI-O標(biāo)記為GA顽耳，在18年8月Redhat宣布在自己的云服務(wù)Openshift Online starter 里運行openshift 3.11使用CRI-O作為容器運行時坠敷。而在即將推出的openshift4.x中，在RedHat Enterprise Linux和RHCOS(Redhat CoreOS )平臺上射富，將正式將CRI-O作為默認(rèn)的容器運行時（雖然此版本依然可以使用Docker）膝迎。在已經(jīng)發(fā)布的Redhat Enterprise Linux 8 beta中，除了CRI-O外還包含了前文中介紹的Podman胰耗，Buildah和Skopeo限次，通過這些工具在紅帽8上，用戶可以獲得和Docker一樣的容器操作用戶體驗柴灯。這無疑是整個容器社區(qū)非Docker容器最大的商用進(jìn)展卖漫。

容器社區(qū)18年度大事記

18年度容器社區(qū)大事記1

18年度容器社區(qū)大事件2

總結(jié)

• rtk在18年度死亡
• containerd在k8s上替代docker在18年度從谷歌和IBM走向試商用
• cri-o 18在紅帽openshift上完成試商用，在redhat8上將正式商用化
• docker社區(qū)變化不大
• gvisor處于萌芽期