K8s容器运行时,移除Dockershim后存在哪些疑惑?

秋意零 2024-9-22 156 9/22

K8s容器运行时,移除Dockershim后存在哪些疑惑?

大家好,我是秋意零。

K8s版本截止目前(24/09)已经发布到了1.31.x版本。早在K8s版本从1.24.x起(22/05),默认的容器运行时就不再是Docker了或者说Dockershim。

发行版本 | Kubernetes

Patch Releases | Kubernetes

K8s容器运行时,移除Dockershim后存在哪些疑惑?

最直接的原因,就是影响了性能。因为K8s调用Docker中Containerd容器运行时需要一个中间层Dockershim,造成了多余的性能和系统稳定性问题。具体是怎么个事呢,这里就来捋上一捋!同时介绍runc、ctr、crictl、nerdctl都是怎么个事!

内心OS:1.24第一版本早在22/05就发布了,距今已经过去2年多了。现在才来捋属实感觉有点晚了,不知有没有朋友和我一样一直没有捋明白呢😬!

如果是 那就接着往下看,有用点个赞、评论明白了😘!

Containerd 简介

官方解释:containerd 是一种行业标准的容器运行时,强调简单性、健壮性和可移植性。它可作为 Linux 和 Windows 的守护进程使用,可以管理其主机系统的完整容器生命周期:镜像传输和存储、容器执行和监督、底层存储和网络附件等。

一句话总结:Containerd 是一种基于 CRI 的容器运行时,用于管理容器的生命周期。

PS:

  • 容器运行时:是负责运行容器的软件

  • CRI:这个接口是 Kubernetes 与容器运行时交互的标准接口

K8s架构理解:【探索 Kubernetes|容器基础进阶篇 系列 4】理解现代云原生时代的引擎

捋上一捋

1)为什么不继续使用Docker作为运行时

Docker并不是一个“物件”,他是一个完整技术栈。它技术栈中有一个叫做 “containerd” 的部件本身,才是一个容器运行时。

执行yum install docker-ce,验证Docker是否包含Containerd,最简单的方式。

K8s容器运行时,移除Dockershim后存在哪些疑惑?

Docker 它提供了很多用户体验增强功能,而这简化了我们用户开发工作时的操作。然而 Kubernetes 用不到这些增强的用户体验,毕竟它并非人类。

因为这个用户友好的抽象层,Kubernetes 集群不得不引入一个叫做 Dockershim 的工具来访问它真正需要的 containerd。 这不是一件好事,因为这引入了额外的运维工作量,同时影响性能与稳定性,而且还可能出错。

2)为什么K8s不直接访问Docker中的Containerd组件,为什么需要Dockershim呢?

Docker Engine 没有实现(CRI)接口,因此 Kubernetes 项目创建了特殊代码来帮助过渡, 并使 Dockershim 代码成为 Kubernetes 的一部分。Dockershim 代码一直是一个临时解决方案(因此得名:shim 垫片)。

如果 Docker 兼容 CRI,就不需要这个 Dockershim 了。

3)Docker构建/拉取的镜像,K8s还能使用嘛?

Docker 构建的镜像并不是 Docker 特有的镜像,它是一个基于 OCI 的镜像。任一以 OCI 为标准构建的镜像,K8s都是可以使用的。

PS:

  • OCI:定义了容器运行时的规范和镜像格式规范

K8s架构理解:【探索 Kubernetes|容器基础进阶篇 系列 4】理解现代云原生时代的引擎

Containerd 与 runc 关系

官方解释:runc是一个 CLI 工具,用于根据 OCI 规范在 Linux 上生成和运行容器。

GitHub - opencontainers/runc

1)Containerd 与 runc 关系

Containerd 的运行时要求非常低。与 Linux 和 Windows 容器功能集的大多数交互都是通过 runc 和特定于操作系统的库处理的。所有Containerd 依赖于 runc 来实现具体功能。

  • runc 是一个低级别的工具,用于创建、运行和管理容器的进程。它是容器运行时(container runtime)的一部分,主要用于执行容器内的应用程序。runc 实现了 OCI(Open Container Initiative)规范,允许开发者以标准化的方式创建和运行容器。
  • Containerd 是一个更高层次的容器管理系统,它负责管理容器的整个生命周期,包括容器的创建、启动、停止以及镜像的管理等。Containerd 提供了一个稳定、可插拔的架构,允许开发者以高度可定制的方式管理和编排容器。

总结:Containerd 和 runc 之间的关系可以类比为主管与执行者的关系。Containerd 作为主管,负责高层次的管理工作,如容器和镜像的生命周期管理,而 runc 作为执行者,负责具体容器进程的创建和运行。

ctr、crictl、nerdctl 分不清?

1)ctr 是 containerd 的原生自带命令行客户端工具,主要用于与 containerd 进行低级别的交互。它提供了对 containerd 的全面管理能力,包括镜像管理、容器管理、沙箱管理等。

2)crictl 是 Kubernetes Container Runtime Interface (CRI) 的客户端工具,用于与实现了 CRI 接口的容器运行时(如 containerd 或 Docker)进行交互。它提供了类似于 docker 命令的高级功能,使得用户可以方便地管理容器和镜像。

3)nerdctl 是 containerd 的另一个命令行工具,它的设计目标是提供一个与 docker 命令相似的体验,使得用户可以无缝地从 Docker 迁移到 containerd。nerdctl 提供了许多与 docker 命令相同的子命令,使得迁移更加简便。但只支持 containerd 容器运行时。

常用操作指令

Containerd容器运行时,存在NameSpace的概念。创建好K8s集群后Containerd中存在两个名称空间default与k8s.io

NameSpace就好比,Windows系统中的文件夹,每个NameSpace内容相互隔离。

注意:与K8s的名称空间类似,不过不要搞混了。K8s名称空间是隔离资源,Containerd名称空间是隔离镜像。

ctr、crictl、nerdctl

  1. ctr 默认采用 default 名称空间

    切换名称空间:-n参数选择不同的名称空间ctr -n k8s.io images ls

  2. crictl 默认采用 k8s.io 名称空间

  3. nerdctl 默认采用 default 名称空间

    切换名称空间:在 /etc/nerdctl/nerdctl.toml 中添加或修改配置 namespace = "k8s.io"

1)Ctr(不常用,可忽略,了解即可)

镜像管理

1. 查看镜像
ctr images ls # images可以简写为i。如:ctr i ls 
查看指定名称空间镜像
ctr -nk8s.io images ls
2. 下载镜像
ctr image pull <镜像名称>
3. 删除镜像
ctr image rm <镜像名称>
4. 镜像导出
ctr i export <导出名称> <需要导出的源镜像名称>
5. 镜像导入
ctr i import <镜像被导出时的镜像名称>
6. 修改tag
ctr images tag <源镜像名称> <>
7. 查看名称空间
ctr ns ls

容器管理

1. 查看运行的容器
ctr container ls  # container可以简写为c。如:ctr c ls 
2. 创建容器
ctr container create <镜像名称> <容器名称>
3. 查看容器中跑的进程
ctr task ls
4. 停止容器
ctr tasks kill <容器名称>
5. 删除容器
ctr tasks delete <容器名称>

crictl、nerdctl常用指令,就不列出来,网上可以找到很多。

2)crictl

crictl 常见的命令大全 (aliyun.com)

3)nerdctl

简单的nerdctl命令使用,操作手册-CSDN博客

参考

容器运行时 | Kubernetes

GitHub - containerd/containerd:开放可靠的容器运行时

更新:移除 Dockershim 的常见问题 | Kubernetes

别慌: Kubernetes 和 Docker | Kubernetes

End

这篇文章有用吗?

点击星号为它评分!

平均评分 0 / 5. 投票数: 0

到目前为止还没有投票!成为第一位评论此文章。

很抱歉,这篇文章对您没有用!

让我们改善这篇文章!

告诉我们我们如何改善这篇文章?

- THE END -

秋意零

9月22日20:42

最后修改:2024年9月22日
0

非特殊说明,本博所有文章均为博主原创。

共有 0 条评论