Docker公司被誰(shuí)收了?

Docker公司被誰(shuí)收了?Mirantis。

Mirantis干啥的?

這個(gè)公司在國(guó)內(nèi)可能知名不太高，在之前的OpenStack社區(qū)挺有名的，也是風(fēng)云人物。

我們看一下迄今為止，在OpenStack基金會(huì)，各個(gè)廠商的整體正式代碼提交量：

所以說(shuō)，在OpenStack社區(qū)，Mirantis每次都沒(méi)干的過(guò)紅帽。

Kubernetes社區(qū)呢?紅帽代碼貢獻(xiàn)占到16.5%，前幾名沒(méi)看到Docker公司和MItantis：

在Docker社區(qū)呢?紅帽還是排在第三，Docker排在第二。紅帽在Docker社區(qū)的排名沒(méi)變，份額確實(shí)有所下降。

那么，既然很多開(kāi)源的PaaS方案都是基于Docker做的，那么，Docker公司被此前做OpenStack的MItantis收購(gòu)，開(kāi)源社區(qū)尷尬不?

一點(diǎn)也不。

紅帽也一點(diǎn)都不尷尬!

為什么呢?請(qǐng)看下文。

容器運(yùn)行時(shí)的愛(ài)恨情仇

對(duì)著下圖先說(shuō)故事脈絡(luò)：

1. 業(yè)內(nèi)最早的容器格運(yùn)行時(shí)是LXC
2. Docker最早讓容器火起來(lái)，Docker最開(kāi)始用LXC，覺(jué)得隔離性差，開(kāi)發(fā)libcontainer，最終形成runC。所以說(shuō)，runC是Docker的獨(dú)生子。
3. Kubernetes發(fā)布時(shí)時(shí)，發(fā)現(xiàn)市面上Docker挺火，因此就用Docker做容器管理工具。
4. Docker越做越重，CoreOS做了rkt容器格式(CoreOS被紅帽收購(gòu)了)。rkt與Kubernetes協(xié)同工作比較好。
5. 容器運(yùn)行時(shí)格式有點(diǎn)多了，Linux基金會(huì)主導(dǎo)的開(kāi)源項(xiàng)目說(shuō)：我們要做一個(gè)container runtime標(biāo)準(zhǔn)。叫OCI。以后容器運(yùn)行時(shí)要符合這個(gè)標(biāo)準(zhǔn)。Docker的獨(dú)生子runC在第一時(shí)間符合了OCI標(biāo)準(zhǔn)。
6. Kubernetes為了與容器運(yùn)行時(shí)解耦(主要是Docker)，提出了CRI(Container Runtime Interface)標(biāo)準(zhǔn)。它是一組與Kubernetes與container runtime進(jìn)行交互的接口。所以說(shuō)，CRI和OCI并不沖突：Kubernetes定義的是它調(diào)用容器運(yùn)行時(shí)的標(biāo)準(zhǔn)接口，OCI定義的是容器運(yùn)行時(shí)本身的標(biāo)準(zhǔn)。
7. OCI關(guān)于容器運(yùn)行時(shí)的標(biāo)準(zhǔn)提出來(lái)以后，紅帽想可以專(zhuān)門(mén)為Kubernetes做一個(gè)輕量級(jí)的容器運(yùn)行時(shí)。紅帽自然會(huì)考慮到它自己全力投入的Kubernetes發(fā)布的CRI標(biāo)準(zhǔn)(Kubernetes紅帽代碼貢獻(xiàn)第二)，因此決定重用了runC等基本組件來(lái)啟動(dòng)容器， 并實(shí)現(xiàn)了一個(gè)最小的CRI接口。它叫CRI-O。所以說(shuō)，CRI-O是CRI的一種標(biāo)準(zhǔn)實(shí)現(xiàn)。
8. 當(dāng)Red Hat正在開(kāi)發(fā)其CRI-O，Docker也在研究CRI標(biāo)準(zhǔn)，這導(dǎo)致創(chuàng)建了另一個(gè)名為containerd的運(yùn)行時(shí)(實(shí)際上是從Docker Engine剝離出來(lái)的)。所以新版本的Docker會(huì)多一層containerd。Kubernetes將containerd接入到CRI的標(biāo)準(zhǔn)中。即cri-containerd。

由于容器的和Kubernetes的發(fā)展史，最終暫時(shí)形成如下局面：

從概念上，從PaaS頂層到底層的調(diào)用關(guān)系是：

Orchestration API ->ContainerEngine API ->Kernel API

現(xiàn)有OpenShift3的調(diào)用架構(gòu)：

• KubernetesMaster->Kubelet->DockerEngine-> containerd -> runc -> Linux Kernel

紅帽O(jiān)penShift4的調(diào)度架構(gòu)：

• KubernetesMaster->Kubelet-> CRI-O -> runc ->Linux kernel

有一些開(kāi)發(fā)者想用如下的模式：

• KubernetesMaster->Kubelet->CRI-containerd->containerd -> runc ->Linux kernel

總結(jié)

1. LXC容器運(yùn)行時(shí)基本下課了。runC容器運(yùn)行時(shí)受到大佬們的青睞。
2. Docker Engine將下課基本也是事實(shí)，這事兒谷歌和紅帽聯(lián)手干的。但Docker急中生智，最終containerd也被Kubernetes社區(qū)采納了。
3. rkt與Kubernetes協(xié)同工作不錯(cuò)，但與OCI的認(rèn)證還沒(méi)測(cè)試完。
4. 紅帽O(jiān)penShift目前在全球企業(yè)容器市場(chǎng)的占有率超過(guò)1/3。Containerd能否火起來(lái)，后面也得看Kubernetes社區(qū)的態(tài)度，但紅帽作為企業(yè)容器的總瓢把子，肯定是不玩Containerd了。

完整故事

Docker是第一個(gè)推廣容器的廠商。最初，Docker使用LXC，但其隔離層不完整，因此Docker編寫(xiě)了libcontainer，最終成為runC。隨后，Docker成為部署容器的事實(shí)標(biāo)準(zhǔn)。在它2014年問(wèn)世時(shí)，Kubernetes自然地使用了Docker，因?yàn)镈ocker是當(dāng)時(shí)唯一可用的運(yùn)行時(shí)。但Docker是一家雄心勃勃的公司，一直致力于開(kāi)發(fā)新功能。例如，Docker Compose與Kubernetes同時(shí)達(dá)到1.0，兩個(gè)項(xiàng)目之間存在一些重疊。雖然有很多方法可以使用諸如Kompose之類(lèi)的工具來(lái)使兩個(gè)工具互操作，但Docker通常被視為一個(gè)做太多事情的大項(xiàng)目。這種情況導(dǎo)致CoreOS以rkt的形式發(fā)布了一個(gè)更簡(jiǎn)單的獨(dú)立運(yùn)行時(shí)，這是通過(guò)這種方式解釋的：rkt的一個(gè)創(chuàng)新是通過(guò)appc規(guī)范標(biāo)準(zhǔn)化鏡像格式。rkt的Kubernetes兼容層(rktlet)，沒(méi)有通過(guò)所有Kubernetes集成測(cè)試，仍在開(kāi)發(fā)中。

CRI-O

看到這些新標(biāo)準(zhǔn)，紅帽認(rèn)為應(yīng)該創(chuàng)建一個(gè)更簡(jiǎn)單的運(yùn)行時(shí)，只能做Kubernetes所需要的。那個(gè)“skunkworks”項(xiàng)目最終被稱(chēng)為CRI-O并實(shí)現(xiàn)了一個(gè)最小的CRI接口。

Red Hat負(fù)責(zé)其OpenShift平臺(tái)的2016年底啟動(dòng)，該項(xiàng)目也得益于英特爾和SUSE的支持，紅帽主持CRI-O開(kāi)發(fā)人員Mrunal Patel主持了此次演講。CRI-O與CRI(運(yùn)行時(shí))規(guī)范以及OCI和Docker鏡像格式兼容。

CRI-O重用了runC等基本組件來(lái)啟動(dòng)容器，以及為skopeo項(xiàng)目創(chuàng)建的容器/圖像和容器/存儲(chǔ)等軟件庫(kù)，以提取容器圖像和創(chuàng)建容器文件系統(tǒng)。一個(gè)名為oci-runtime-tool的獨(dú)立庫(kù)準(zhǔn)備容器配置。

containerd：Docker的運(yùn)行時(shí)獲取API

當(dāng)Red Hat正在開(kāi)發(fā)其OCI的實(shí)現(xiàn)時(shí)，Docker也在研究該標(biāo)準(zhǔn)，這導(dǎo)致創(chuàng)建了另一個(gè)名為containerd的運(yùn)行時(shí)。新守護(hù)進(jìn)程是對(duì)內(nèi)部Docker組件的重構(gòu)，以組合OCI特定的位，如執(zhí)行，存儲(chǔ)和網(wǎng)絡(luò)接口管理。它已經(jīng)在1.12 Docker版本中有所體現(xiàn)。雖然我們將containerd稱(chēng)為“運(yùn)行時(shí)”，但它并不直接實(shí)現(xiàn)CRI接口，該接口由另一個(gè)名為cri-containerd的守護(hù)進(jìn)程覆蓋。所以容器需要比Kubernetes的CRI-O更多的守護(hù)進(jìn)程(5個(gè)，而CRI-O為三個(gè))。Kubernetes將containerd接入到CRI的標(biāo)準(zhǔn)中。

與CRI-O不同，containerd通過(guò)Go API支持Kubernetes生態(tài)系統(tǒng)之外的工作負(fù)載。盡管containerd定義了一個(gè)明確的發(fā)布過(guò)程，用于更改API和命令行工具，但API尚未被認(rèn)為是穩(wěn)定的。與CRI-O一樣，containerd功能完備并通過(guò)所有Kubernetes測(cè)試，但它不與systemd的cgroup互操作。

為了進(jìn)一步與oci進(jìn)行兼容，kubernetes還孵化了cri-o，成為了架設(shè)在cri和oci之間的一座橋梁。通過(guò)這種方式，可以方便更多符合oci標(biāo)準(zhǔn)的容器運(yùn)行時(shí)，接入kubernetes進(jìn)行集成使用?？梢灶A(yù)見(jiàn)到，通過(guò)cri-o，kubernetes在使用的兼容性和廣泛性上將會(huì)得到進(jìn)一步加強(qiáng)。

結(jié)論

早在2年多以前，社區(qū)和紅帽就已經(jīng)開(kāi)始講Kubernetes與Docker解耦了。紅帽在OpenShift4中果斷放棄的了Docker而使用CRI-O。

所以，Docker公司被收購(gòu)，開(kāi)源社區(qū)和紅帽都不感到尷尬!