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 体验。
Related Articles
5月 01st, 2023
My First Day at SUSE
5月 11th, 2023
SUSE Awarded 16 Badges in G2 Spring 2023 Report
6月 05th, 2023
No comments yet