ドッカー会社が買収された、オープンソースコミュニティが恥ずかしいされていませんか？
HTTPS：// news.51cto.com/art/201911/606189.htm
受信ドッカー会社？
受信？Mirantisをドッカー会社。
やってのMirantis？
国ではよく知られている会社は、OpenStackのコミュニティは非常に有名な、だけでなく、時間の人の前に、高すぎないかもしれません。
私たちは、OpenStackの財団で、これまでに見て、全体的な量のすべてのメーカーが正式にコードを提出します：
だから、OpenStackのコミュニティで、MirantisそれぞれがあまりにもRed Hatのをしませんでした。
？それは、Red Hatの16.5％を占めKubernetesコミュニティコードの貢献を、上位のいくつかの企業がドッカーとMItantisを見ていません。
コミュニティのドッカーはありますか？またはRed Hatは、第三に来て、ドッカーは、第二に来ました。ランキングドッカーのRed Hatのコミュニティが変更されていない、本当にシェアが減少しました。
まあ、オープンソースのPaaSがたくさんあるためのソリューションがそのように、同社は以前にドッカーがOpenStackののMItantisの取得を行うたんドッカーに基づいており、オープンソースコミュニティが恥ずかしいされていませんか？
すべてではありませんで。
また、Red Hatは少しは困っていません！
なぜ？下記を参照してください。
良い面と悪いコンテナ・ランタイムの両方
最初に対する次の図は、物語の文脈を伝えるために：
- 業界初のコンテナフォーマットランタイムLXC
- ドッキングウィンドウが最初にドッカーLXCで始まる、コンテナ火をアップさせ、孤立感や貧困、先進libcontainerは、最終的にrunCを形成します。だから、runCドッカーは一人息子です。
- Kubernetesは、市場がドッカーTinghuoを見つけたので、ドッカーコンテナ管理ツールで行い、随時発行されます。
- ドッカーがCoreOSは（Red Hatが買収CoreOS）RKTコンテナフォーマットを行い、重いを取得しています。RKT、より良いKubernetes作品。
- コンテナフォーマットランタイムはもう少し、Linux Foundationの、主要なオープンソースプロジェクトは、言った：私たちは、標準コンテナのランタイムをしなければなりません。OCIに呼び出されます。コンテナは、この規格を満たすために実行された後。ドッカーの唯一の息子runC OCIの規格に沿って、初めて。
- Kubernetes为了与容器运行时解耦(主要是Docker)，提出了CRI(Container Runtime Interface)标准。它是一组与Kubernetes与container runtime进行交互的接口。所以说，CRI和OCI并不冲突：Kubernetes定义的是它调用容器运行时的标准接口，OCI定义的是容器运行时本身的标准。
- OCI关于容器运行时的标准提出来以后，红帽想可以专门为Kubernetes做一个轻量级的容器运行时。红帽自然会考虑到它自己全力投入的Kubernetes发布的CRI标准(Kubernetes红帽代码贡献第二)，因此决定重用了runC等基本组件来启动容器， 并实现了一个最小的CRI接口。它叫CRI-O。所以说，CRI-O是CRI的一种标准实现。
- 当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
总结
- LXC容器运行时基本下课了。runC容器运行时受到大佬们的青睐。
- Docker Engine将下课基本也是事实，这事儿谷歌和红帽联手干的。但Docker急中生智，最终containerd也被Kubernetes社区采纳了。
- rkt与Kubernetes协同工作不错，但与OCI的认证还没测试完。
- 红帽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年以上前のように、地域社会とRed HatはすでにドッカーとKubernetesを話すことを始めていたデカップリング。CRI-Oの使用を放棄するドッカーの決定におけるRed Hat OpenShift4。
だから、ドッカーが取得された、オープンソースコミュニティとRed Hatは困っていません！