Docker公司被誰收了?

Docker公司被誰收了?Mirantis。

Mirantis干啥的?

這個公司在國內可能知名不太高，在之前的OpenStack社區挺有名的，也是風云人物。

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

所以說，在OpenStack社區，Mirantis每次都沒干的過紅帽。

Kubernetes社區呢?紅帽代碼貢獻占到16.5%，前幾名沒看到Docker公司和MItantis：

在Docker社區呢?紅帽還是排在第三，Docker排在第二。紅帽在Docker社區的排名沒變，份額確實有所下降。

那么，既然很多開源的PaaS方案都是基于Docker做的，那么，Docker公司被此前做OpenStack的MItantis收購，開源社區尷尬不?

一點也不。

紅帽也一點都不尷尬!

為什么呢?請看下文。

容器運行時的愛恨情仇

對著下圖先說故事脈絡：

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

由于容器的和Kubernetes的發展史，最終暫時形成如下局面：

從概念上，從PaaS頂層到底層的調用關系是：

Orchestration API ->ContainerEngine API ->Kernel API

現有OpenShift3的調用架構：

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

紅帽OpenShift4的調度架構：

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

有一些開發者想用如下的模式：

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

總結

1. LXC容器運行時基本下課了。runC容器運行時受到大佬們的青睞。
2. Docker Engine將下課基本也是事實，這事兒谷歌和紅帽聯手干的。但Docker急中生智，最終containerd也被Kubernetes社區采納了。
3. rkt與Kubernetes協同工作不錯，但與OCI的認證還沒測試完。
4. 紅帽OpenShift目前在全球企業容器市場的占有率超過1/3。Containerd能否火起來，后面也得看Kubernetes社區的態度，但紅帽作為企業容器的總瓢把子，肯定是不玩Containerd了。

完整故事

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

CRI-O

看到這些新標準，紅帽認為應該創建一個更簡單的運行時，只能做Kubernetes所需要的。那個“skunkworks”項目最終被稱為CRI-O并實現了一個最小的CRI接口。

Red Hat負責其OpenShift平臺的2016年底啟動，該項目也得益于英特爾和SUSE的支持，紅帽主持CRI-O開發人員Mrunal Patel主持了此次演講。CRI-O與CRI(運行時)規范以及OCI和Docker鏡像格式兼容。

CRI-O重用了runC等基本組件來啟動容器，以及為skopeo項目創建的容器/圖像和容器/存儲等軟件庫，以提取容器圖像和創建容器文件系統。一個名為oci-runtime-tool的獨立庫準備容器配置。

containerd：Docker的運行時獲取API

當Red Hat正在開發其OCI的實現時，Docker也在研究該標準，這導致創建了另一個名為containerd的運行時。新守護進程是對內部Docker組件的重構，以組合OCI特定的位，如執行，存儲和網絡接口管理。它已經在1.12 Docker版本中有所體現。雖然我們將containerd稱為“運行時”，但它并不直接實現CRI接口，該接口由另一個名為cri-containerd的守護進程覆蓋。所以容器需要比Kubernetes的CRI-O更多的守護進程(5個，而CRI-O為三個)。Kubernetes將containerd接入到CRI的標準中。

與CRI-O不同，containerd通過Go API支持Kubernetes生態系統之外的工作負載。盡管containerd定義了一個明確的發布過程，用于更改API和命令行工具，但API尚未被認為是穩定的。與CRI-O一樣，containerd功能完備并通過所有Kubernetes測試，但它不與systemd的cgroup互操作。

為了進一步與oci進行兼容，kubernetes還孵化了cri-o，成為了架設在cri和oci之間的一座橋梁。通過這種方式，可以方便更多符合oci標準的容器運行時，接入kubernetes進行集成使用。可以預見到，通過cri-o，kubernetes在使用的兼容性和廣泛性上將會得到進一步加強。

結論

早在2年多以前，社區和紅帽就已經開始講Kubernetes與Docker解耦了。紅帽在OpenShift4中果斷放棄的了Docker而使用CRI-O。

所以，Docker公司被收購，開源社區和紅帽都不感到尷尬!