CRI-O 现在是我们的默认容器运行时接口

我们非常激动地宣布，从今天起，我们正式支持 CRI-O 容器运行时接口，作为在您的 Kubic 系统上与容器交互的默认方式！

嗯，这很好，但什么是容器运行时接口？

与您可能听到的相反，运行容器的方式不仅仅是 docker 工具。事实上，越来越多的选项，例如 runc、rkt、frakti、cri-containerd 等。其中大多数遵循 OCI 标准，定义了运行时启动和运行容器的方式，但它们缺乏与编排器交互的标准方式。这给像 Kubernetes 这样的工具带来了复杂性，这些工具在容器运行时之上运行，为您提供编排、高可用性和管理功能。

因此，Kubernetes 引入了一个标准 API，以便能够与容器运行时进行通信和管理。这个 API 被称为 容器运行时接口 (CRI)。

像 Docker 这样的现有容器运行时使用“shim”在 Kubernetes 和运行时之间进行接口，但还有另一种方法，使用一个旨在原生与 CRI 协同工作的接口。而 CRI-O 正是在这里发挥作用。

CRI-O 简介

CRI-O 始于一年前多一点，最初是 Kubernetes 孵化项目，为符合 OCI 标准的运行时实现 CRI 接口。使用轻量级的 runc 运行时来实际运行容器，将 CRI-O 描述为 Docker 引擎的轻量级替代品的最简单方法，尤其专为与 Kubernetes 配合使用而设计。

截至 2018年9月6日，CRI-O 不再是孵化项目，而是 Kubernetes 工具家族的官方组成部分。

为什么选择 CRI-O？

Kubic 项目有很多喜欢 CRI-O 的理由，但为了给出一个 Top 4，其中一些最大的理由包括

• 真正开放的项目： 如前所述，CRI-O 作为更广泛的 Kubernetes 社区的一部分进行运营。有一个 广泛的贡献者集合，来自 Red Hat、SUSE、Intel、Google、阿里巴巴、IBM 等公司。该项目以一种所有这些不同利益相关者可以积极提出变更并期望其合并或至少促使朝着该方向迈进的方式进行运行。其他类似项目很难这样说。
• 轻量级： CRI-O 由许多小型组件组成，每个组件都有特定的角色，与其他组件协同工作，为您提供功能齐全的容器体验。相比之下，Docker 引擎是一个重量级的守护进程，通过 docker CLI 工具以客户端/服务器的方式进行通信。您需要在守护进程运行后才能使用 CLI，如果守护进程停止，您就无法对容器执行任何操作。
• 更安全： 使用 Docker CLI 运行的每个容器都是该大型 Docker 守护进程的“子级”。这会使使用 cgroups 和安全约束等工具来为您的容器提供额外的保护层变得复杂或直接阻止。由于 CRI-O 容器是生成它的进程的子级（而不是守护进程），因此它们完全兼容这些工具，而不会出现复杂情况。这不仅对 Kubernetes 很有用，也适用于与 Podman 配合使用，但稍后会详细介绍……
• 与 Kubernetes 对齐： 作为 Kubernetes 的官方项目，CRI-O 的发布与 Kubernetes 保持同步，版本号相似。例如，CRI-O 1.11.x 与 Kubernetes 1.11.x 配合使用。这对于像 Kubic 这样的项目来说非常有益，我们正在滚动并希望保持所有内容在最新版本上协同工作。另一方面，Kubernetes 目前仅正式支持 Docker 版本 17.03.x，这已经超过一年，远远落后于我们当前在 Kubic 中使用的 18.06.x 版本。

CRI-O 和 Kubernetes

鉴于 Kubic 的主要作用之一是运行 Kubernetes，从今天起，Kubic 的 kubeadm 系统角色 现在设计为默认使用 CRI-O。

我们的文档已更新以反映新的 CRI-O 操作方式。

最简单的描述方式是我们现在比 以前 减少了步骤。
您现在可以在安装后立即使用单个命令初始化您的主节点。
但是，您需要记住将 --cri-socket=/var/run/crio/crio.sock 添加到您的 kubeadm init 和 join 命令。（我们正在寻找简化此操作的方法）。

CRI-O 和 MicroOS

Kubic 不仅仅是 Kubernetes，我们的 MicroOS 系统角色 是在独立机器上运行容器的理想平台。这也包括 CRI-O 作为其默认运行时接口。

为了在没有 Kubernetes 的情况下使用 CRI-O，您需要一个命令行工具，该工具被称为 podman。它现在默认安装在 Kubic MicroOS 上。

Podman

Podman 在 Tumbleweed 和 Kubic 中已经可用一段时间了。简单来说，它与 Docker CLI 工具之于 Docker 引擎守护进程，就像 CRI-O 之于容器运行时一样。它甚至具有非常相似的语法。

• 使用 podman run 运行容器，就像您期望从 docker run 一样
• podman pull 从注册表中拉取容器，就像 docker pull 一样，默认情况下，我们的 podman 配置为使用许多用户期望的相同的 Docker Hub。
• 一些 podman 命令与它们的 docker 等效项相比具有其他功能，例如 podman rm --all 和 podman rmi --all，它们将分别删除所有容器及其镜像。
• Podman 命令及其 Docker 等效项的完整抄本可用

Podman 还受益于 CRI-O 更轻量级的架构。由于每个 Podman 容器都是创建它的 podman 命令的直接子级，因此将 podman 作为 systemd 服务的一部分使用是微不足道的。这可以与 systemd 功能（如套接字激活）结合使用，从而实现真正酷的事情，例如仅在用户尝试访问它时才启动您的容器！

Docker 呢？

尽管我们对 CRI-O 和 Podman 感到兴奋，但我们并没有忽视许多用户根本不在乎并且会更喜欢运行众所周知的 docker 工具的现实。

对于运行容器的基本用例，docker 和 podman 都可以安全地在系统上共存。因此，它仍然可用并且默认安装在 Kubic MicroOS 上。
如果您想将其删除，只需运行 transactional-update pkg rm -u docker-kubic 并重新启动。

Docker 引擎与 Kubernetes 场景中的 CRI-O 并不太好地共存，因此我们不会在 kubeadm 系统角色 上默认安装两者。
我们仍然希望支持希望使用 Docker 引擎与 Kubernetes 的用户。因此，要从 CRI-O 切换到 Docker 引擎，只需运行 transactional-update pkg in patterns-caasp-alt-container-runtime -cri-o-kubeadm-criconfig 并重新启动。

或者，如果您从安装介质安装 Kubic，您可以取消选择“容器运行时”并选择安装过程中的“软件”选项中的“替代容器运行时”模式。

无论您选择使用哪个运行时，感谢您使用 Kubic，请参与其中，向我们发送您的反馈、代码和其他贡献，并记住，玩得开心！。