Share with friends and colleagues on social media

对 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 体验。

Share with friends and colleagues on social media
Tags:
Category: Containers, Containers as a Service, Kubernetes, SUSE CaaS Platform
This entry was posted 星期一, 17 九月, 2018 at 6:38 上午
You can follow any responses to this entry via RSS.

发表评论

电子邮件地址不会被公开。 必填项已用*标注

No comments yet