|
本文为你介绍：Docker vs Containerd vs CRI-O（我们将谈一下Docker、CRI-O和containerd之间的差异）。
Docker 在1.11版之前，Docker的实现是一个整体的守护程序。整体程序将所有功能作为一个程序包完成，例如下载容器映像，启动容器进程，公开远程API并充当日志收集守护程序，所有这些都在以root身份运行的集中式进程中进行。 这样的集中式体系结构在部署方面有一些好处，但会发现其他基本问题。一个例子是，它没有遵循Unix进程和特权分离的最佳实践。而且，整体的实现使Docker难以与Linux初始化系统（如upstart和systemd）正确集成。 导致将Docker拆分为不同的部分，如以下在Docker 1.11启动时开头的段落所述。 “我们很高兴推出Docker Engine 1.11，这是我们第一个基于runC和containerd构建的版本。在此版本中，Docker率先发布了基于OCI技术的运行时，证明了自2015年6月在Linux基金会捐赠了我们行业标准的容器格式和运行时以来，团队所取得的进步。” 根据Docker的说法，将其拆分为专注的独立工具意味着维护人员更加专注，最终将获得更高质量的软件。 下图说明了在runC和containerd上构建的Docker 1.11的新体系结构：
从那时起，containerd现在处理容器的执行，而该操作以前是由docker daemon本身完成的，这是确切的流程： 用户从Docker-CLI运行命令> Docker-CLI与Docker守护程序（dockerd）对话> Docker守护程序（dockerd）侦听请求并通过与之联系的容器管理容器的生命周期>容器获取请求并启动容器通过runC并在主机内执行所有容器生命周期。 注意：简而言之，runc是用于根据OCI规范生成和运行容器的CLI工具。 参考：在Linux系统下使用Docker Compose管理Docker容器。
Containerd 现在，让我们转移我们的注意力，来了解容器的全部含义。从较高的角度来看，containerd是控制runC的守护程序。在containerd网站上：“containerd管理着其主机系统的整个容器生命周期，从图像传输和存储到容器执行和监督，再到低级存储再到网络附件等等。” containerd帮助抽象化系统调用或特定于操作系统的功能，以在Linux、Windows或任何其他操作系统上运行容器。它提供了一个客户端层，任何其他平台（例如Docker或Kubernetes）都可以在该客户端层之上构建，而无需关心内核级别的细节。应该注意的是，在Kubernetes中，容器可以用作CRI运行时，我们将立即解决CRI。这些是通过利用容器获得的： 您可以获得push和pull功能。 图像管理API，用于创建，执行和管理容器及其任务。 快照管理。 您将获得所有这些，而不必再为底层的操作系统细节而烦恼。
CRI-O 现在进入CRI-O，在深入谈论CRI-O之前，让我们先简要介绍一下CRI池，即Container Runtime Interface。CRI是一个插件接口，使kubelet能够使用不同的OCI兼容容器运行时（例如容器化，docker或cri-o），而无需重新编译Kubernetes。如您所知，Kubelet是用于创建Pod和启动容器的群集节点代理。 要了解对CRI的需求，明智的是了解Kubernetes在此之前所经历的痛点。Kubernetes以前绑定到特定的容器运行时，这为上游Kubernetes社区带来了大量维护开销。此外，在Kubernetes上构建解决方案的供应商也经历了相同的开销。这就需要开发CRI，以使Kubernetes容器与各种运行时解耦，从而使其与运行时无关。 由于已经构建了插件，因此CRI-O项目开始提供专门用于Kubernetes的轻量级运行时。CRI-O使Kubernetes无需大量工具和代码即可直接运行容器。 以下是CRI-O的组件： OCI兼容运行时（OCI compatible runtime）–默认为runC，还支持其他OCI兼容，例如Kata容器。 容器/存储（containers/storage）–用于管理层和为容器中的容器创建根文件系统的库。 容器/图像（containers/image）–库用于从注册表中提取图像。 networking (CNI)－用于为Pod设置网络，Flannel、Weave和OpenShift-SDN CNI插件已经过测试。 container monitoring (conmon)– CRI-O中的实用程序，用于监视容器。 Linux的几个核心功能提供了安全性。 下面的屏幕截图说明了整个Kubernetes和CRI-O过程：
结论 Docker、Containerd和CRI-O都有各自的空间，并且都可以使Kubernetes在启动和维护Pod时受益。可以观察到的是，这三个在最低级别上依赖runC来处理容器的运行。
相关主题 |
