SUSE CaaS Platform 3 上的 CRI-O 容器运行时

对 Kubernetes 和容器运行时（Container Runtime）感兴趣？

很好，这就是我们一直在为开源社区所做的工作！

随着 SUSE CaaS Platform 3 版本的发布，我们很自豪地宣布 CRI-O 是一个可选的容器运行时，作为技术预览提供给我们的用户。CRI-O 是与 Kubernetes CRI（Container Runtime Interface，容器运行时接口）和 OCI（Open Container Initiative，开放容器计划）完全兼容的容器运行时，是传统容器运行时的轻量级替代品。对 Kubernetes 最终用户来说，完全无法察觉 CRI-O 的使用，但是它却带来了很多非功能性的好处。今天，我们将重点介绍其在安全性、稳定性和可维护性方面的改进。

CRI-O 由来自不同公司的维护人员和贡献者开发，SUSE 非常骄傲能够成为这个社区的一员并为其做出贡献，SUSE 的终极目标是为用户提供一流的企业级 Kubernetes 体验。

接下来我们将对 CRI-O 容器运行时进行介绍，其中包括如何使用 CRI-O 容器运行时以及 CRI-O 容器运行时与传统容器运行时的区别。此外，还将进一步解释如何通过配置让 SUSE CaaS Platform 集群使用 CRI-O，并展示如何在 CRI-O 节点上执行常见的维护和容器管理任务。

为什么是 CRI-O？

CRI-O 的主要目标始终是 Kubernetes 的稳定性。在过去，Kubernetes 的稳定性一直受到不断发展的、较传统的容器运行时的影响，因此人们一直渴望拥有一个真正的 Kubernetes 专用容器运行时，CRI-O 也就应运而生。社区通过将 CRI-O 的范围和用例限制为只服务于 Kubernetes CRI 而不提供其他服务来实现这一目标。这大大减少了源代码的数量，从而减少了 CRI-O 的攻击面，提高了安全性，同时使其更易于维护和测试。因此，对 CRI-O 的每个代码更改必须在提交到代码存储库之前通过整个 Kubernetes 端到端测试套件。

CRI-O 社区从 Docker 开源项目的技术成果中学到了很多，甚至重用了部分源代码，比如说，支持不同的存储驱动程序，如 Btrfs、Overlayfs、devicemapper 和 AUFS。两者之间的最大差别在于体系结构。Docker 开源引擎需要在主机系统上运行大量的守护进程，CRI-O 则是设法将正在运行的进程数量降至最低。这种差异源于不同的设计方法，也源于 Docker 服务于过多的用例，而 CRI-O 仅服务于 Kubernetes。

下图描述了 CRI-O 的体系结构，其中 kubelet 通过 gRPC 远程过程调用与 CRI-O 进行通信。CRI-O 实现了 Kubernetes 容器运行时接口的基本构建块，包括推送和提取与 OCI 兼容的容器镜像、设置 CNI 网络环境和配置 pod 和容器等服务。容器可以由任何与 OCI 兼容的容器运行时执行，例如 runc 和 Kata 容器，它们都是 CRI-O 测试向量的一部分。每个容器都由一个单独的 conmon 进程监视，该进程处理容器的日志记录并记录容器进程的退出代码。

与功能丰富但臃肿的 Docker 守护进程相比，上述体系结构使得 CRI-O 更加纤薄。使用 Docker 时，kubelet 与 docker- shim 通信，将 CRI 请求转换为适用于 Docker 守护进程的 Docker-API 请求，Docker 守护进程又与 containerd 通信，最终启动容器的 runc，然后是 pid1。

在 SUSE CaaS Platform 3 上使用 CRI-O

在 SUSE CaaS Platform 3 发布的同时，我们提供了 CRI-O 作为可选的容器运行时，该运行时可通过初始配置菜单进行选择，此处可以选择 Docker 开源引擎，也可以选择 CRI-O。

如上面截图所示，CRI-O 是作为技术功能预览的一部分提供的，Docker 仍然是默认选项并获得全面支持。SUSE 希望给您机会让您在企业环境中测试 CRI-O 并收集反馈。目前的计划则是努力使 CRI-O 在 SUSE CaaS Platform 4 中获得全面支持。

使用 CRI-O

从 Kubernetes 用户的角度来看，完全无法察觉 CRI-O 的使用，与使用 Docker 开源引擎相比没有任何功能差异。无论是 Kubernetes 清单还是容器镜像都不需要更改。但有时我们可能需要调试给定的 pod 或容器，比如说，当试图重现在容器中运行的失败的 MySQL 数据库时。这样的维护任务最好直接在 Kubernetes 主机上执行。

在使用 Docker 开源引擎运行的 Kubernetes 主机上，我们可以使用 Docker 命令行客户端，例如，使用 docker ps 命令列出当前正在运行的容器，或者使用 docker exec 命令在容器中执行命令。但是在使用 CRI-O 时，由于各种技术原因，我们无法使用 Docker 命令行客户端。这正是 CRICTL 的切入点。CRICTL 是一个命令行客户端，与实现 Kubernetes CRI 的运行时端点进行通信，这使得它成为调试和使用 Kubernetes 的通用工具，与正在使用哪个 CRI 容器运行时无关。让我们看看如何在 Kubernetes 主机上使用 CRICTL 执行一些常见操作。

首先，让我们登录到运行 SUSE CaaS Platform 的计算机。在登录时，我们会收到一些关于节点的基本信息，包括我们之前在设置集群时在 Velum 仪表板中配置的容器运行时（即 CRI-O）：

Welcome to SUSE CaaS Platform! Machine ID: 331c55b79e7c44c88f1f7615db62a09bHostname: worker-1Container Runtime: CRI-O The roles of this node are:- kube-minion- etcd

现在让我们看看节点上有哪些容器正在运行，我们可以通过 crictl ps 命令来完成：

$ crictl psCONTAINER ID  IMAGE                 CREATED    STATE             NAME         ATTEMPT67cc18ec3e675 6f06a3d36408bc50[…] 4 days ago CONTAINER_RUNNING kubedns      05480ff45a71fc b4968854a7d16084[…] 4 days ago CONTAINER_RUNNING kube-flannel 091a1906ce76f2 2cb98d8e45f36556[…] 4 days ago CONTAINER_RUNNING haproxy      0

crictl ps 命令的输出看起来与使用 docker ps 命令时的输出类似，但由于不显示已执行的命令和映射端口等信息，所以更为简洁。如果您正在寻找此类信息，可以对特定容器 ID 使用 crictl inspect 命令，列出关于容器的各类详细信息，包括容器的状态、使用的容器镜像、开放端口、挂载点等。如果您想查看特定镜像或 POD 的详细信息，可以分别使用 crictl inspecti 和 crictl inspectp 命令。

除了收集正在运行的容器的信息等基本操作外，CRICTL 还提供了更强大的操作来操纵容器的状态和镜像存储：

• 通过 crictl pull opensuse/opensuse:tumbleweed 命令提取镜像
• 通过 crictl exec $CONTAINER $COMMAND 命令在容器中执行命令
• 通过 crictl exec -it $CONTAINER sh 命令获得容器的外壳

CRICTL 是一项功能强大的工具，用于在 Kubernetes 节点上执行各种维护和容器管理任务，拥有与传统容器客户端类似的命令行界面。然而，CRICTL 与 Kubernetes CRI 密切相关，这可能会给新容器的运行带来一点麻烦。这就是为什么 SUSE CaaS Platform 将 Podman 作为纯调试和维护工具的原因。

Podman 是一个命令行客户端，用于执行与 Docker 客户端类似的操作。它可以被看作是除 Kubernetes 之外的 Docker 的简易替代品，用于运行、构建和管理容器和容器镜像。Podman 的命令行界面几乎与 Docker 的命令行界面完全相同，因此用户可以从一个界面无缝过渡到另一个界面。Podman 的设计模式与 CRI-O 类似，但完全没有守护进程。Podman 和 CRI-O 共享相同的镜像存储，但是在编写本文时，它们没有共享容器，因此社区目前正在努力实现这两种工具之间的无缝集成。我们之前加载的 alpine 镜像可以使用 Podman 的 podman run -it alpine 命令运行，这样我们就拥有了一个容器外壳，可以使用它来调试或执行某些维护任务。

欢迎试用并提出反馈意见

对于能够将 CRI-O 作为技术预览提供给 SUSE CaaS Platform 3 用户，SUSE 感到非常自豪。在设置集群时，可以将容器运行时配置为 CRI-O。我们希望鼓励用户试用 CRI-O 并提供反馈建议。SUSE 将继续并扩展其在社区中的工作，以提供完全由社区推动的开源容器运行时，满足 SUSE 对企业级软件的需求，进而提供一流的 Kubernetes 体验。