K8S容器运行时弃用Docker转型Containerd

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
应用实时监控服务-应用监控,每月50GB免费额度
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: K8S容器运行时弃用Docker转型Containerd

Kubernetes社区在2020年7月份发布的版本中已经开始了dockershim的移除计划,在1.20版本中将内置的dockershim进行分离,这个版本依旧还可以使用dockershim,但是在1.24中被删除。从1.24开始,大家需要使用其他受到支持的运行时选项(例如containerd或CRI-O);如果选择Docker Engine作为运行时,则需要使用cri-dockerd  

容器进行时调用过程

当Docker要创建一个容器时,需要进行下面的步骤:

  • Kubelet 通过CRI接口(gRPC)调用dockershim,请求创建一个容器。(CRI即容器运行时接口)
  • dockershim 收到请求后,转换成Docker Daemon能听懂的请求,发到Docker Daemon上请求创建容器。
  • Docker Daemon 早在1.12版本中就已经针对容器的操作转移到另外一个进程containerd,因此Docker Daemon不会帮我们创建容器,而是要求containerd创建一个容器
  • Containerd收到请求后,并不会直接去操作容器,而是创建一个叫做containerd-shim的进程,让containerd-shim去操作容器。这是因为容器进程需要一个父进程来做收集状态,而加入这个父进程就是containerd,那每次containerd挂掉或者升级,整个宿主机上的容器都会退出。而引用containerd-shim就避免了这个问题 (containerd和shim并不是父子进程的关系)
  • OCI (Open Container Initiative,开放容器标准)。OCI执行namespacecgroups,挂载root filesystem等操作,OCI参考RunCcontainerd-shim在这一步调用RunC命令行来启动容器。实际上RunC就是一个二进制命令
  • runC启动完成后本身会直接退出containerd-shim则会为容器进程的父进程,负责收集容器进程的状态,上报给containerd,并在容器中pid为1的进程退出后接管容器中的子进程进行清理,确保不会出现僵尸进程。

OCI (Open Container Initiative,开放容器标准) runC实际上就是参考OCI实现,OCI实际上就是一个标准文档,主要规定了容器镜像的结构、以及容器需要接收那些操作指令,比如create、start、stop、delete等  

Containerd 发展史

Containerd 1.0中,对CRI的适配通过了一个单独的进程CRI-containerd来完成

containerd 1.1中,砍掉了CRI-containerd这个进程,直接把适配逻辑作为插件放进了containerd主进程中  

containerd 1.1中做的事情,实际上Kubernetes社区做了一个更漂亮的cri-o,兼容CRIOCI

Containerd与Docker区别?

实际上containerd只是一个精简版docker,为了更好的支持Kubernetes而已  

哪些容器运行时引擎支持CRI?

容器运行时

Kubernetes 平台中的支持

优点

缺点

Containerd

谷歌 Kubernetes 引擎、IBM Kubernetes 服务、阿里巴巴

经过大规模测试,用于所有 Docker 容器。比 Docker 使用更少的内存和 CPU。支持 Linux 和 Windows

没有 Docker API 套接字。缺少 Docker 方便的 CLI 工具。

CRI-O

红帽 OpenShift,SUSE 容器即服务

轻量级,Kubernetes 所需的所有功能,仅此而已。类似 UNIX 的关注点分离(客户端、注册表、构建)

主要在RedHat平台内使用不易安装在非RedHat操作系统上仅在Windows Server2019及更高版本中支持

Kata Containers

开放堆栈

提供基于 QEMUI 的完全虚拟化改进的安全性与 Docker、CRI-O、containerd 和 Firecracker 集成支持 ARM、x86_64、AMD64

更高的资源利用率不适合轻量级容器用例

AWS Firecracker

所有 AWS 服务

可通过直接 API 或使用 seccomp jailer 的 containerdTight 内核访问来访问

新项目,不如其他运行时成熟需要更多手动步骤,开发人员体验仍在不断变化

通过下图,我们可以看到这3个的区别,目前Kubernetes官网已经支持containerdCRI-O容器运行时支持 。

Containerd

早期Containerd是在Docker Engine中,目前将containerdDocker中拆分出来,作为一个独立的开源项目,目标是提供一个更加开放、稳定的容器运行基础设施。分离出来的containerd将具有更多的功能,覆盖整个容器运行时的所有需求,提供更强大的支持 。

Containerd是一个工业级标准的容器运行时,它强调简单性、可移植性

Containerd 架构

服务端通过 unix domain socket 暴露低层的 gRPC API 接口出去,客户端通过这些 API 管理节点上的容器,每个containerd只负责一台机器,Pull镜像,对容器的操作(启动、停止等),网络,存储都是由containerd完成。具体运行容器由runc负责,实际上只要是符合OCI规范的容器都可以支持 。

为了解耦,containerd 将系统划分成了不同的组件,每个组件都由一个或多个模块协作完成(Core 部分),每一种类型的模块都以插件的形式集成到 Containerd 中,而且插件之间是相互依赖的,例如,上图中的每一个长虚线的方框都表示一种类型的插件,包括 Service PluginMetadata PluginGC PluginRuntime Plugin 等,其中 Service Plugin 又会依赖 Metadata PluginGC PluginRuntime Plugin。每一个小方框都表示一个细分的插件,例如 Metadata Plugin 依赖 Containers PluginContent Plugin 等  

Content Plugin: 提供对镜像中可寻址内容的访问,所有不可变的内容都被存储在这里。
Snapshot Plugin: 用来管理容器镜像的文件系统快照,镜像中的每一层都会被解压成文件系统快照,类似于 Docker 中的  graphdriver  

对于K8s来说,实际需要Containerd即可,中间的垫片(shim)是完全可以省略,减少调用链  

Containerd已经将shim集成到kubelet中,减少了shim,但是如果我们使用containerd,那么将无法使用docker ps或者docker exec命令来获取容器。可以使用docker pull和docker build命令来构建镜像  

Containerd 安装

Kubernetes社区在2020年7月份发布的版本中已经开始了dockershim的移除计划,在1.20版本中将内置的dockershim进行分离,这个版本依旧还可以使用dockershim,但是在1.24中被删除。从1.24开始,大家需要使用其他受到支持的运行时选项(例如containerd或CRI-O);如果您选择Docker Engine作为运行时,则需要使用cri-dockerd  

本次环境信息  

[root@node2 ~]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
[root@node2 ~]# uname -sr
Linux 5.18.14-1.el7.elrepo.x86_64
[root@node2 ~]#

下载软件包

github地址:https://containerd.io/downloads/

containerd-1.6.1-linux-amd64.tar.gz 只包含containerd
cri-containerd-cni-1.6.6-linux-amd64.tar.gz 包含containerd以及cri runc等相关工具包,建议下载本包  

下载完解压

[root@node2 home]# tar -zxvf cri-containerd-cni-1.6.6-linux-amd64.tar.gz -C /

上面的文件都是二进制文件,直接移动到对应的目录并配置好环境变量就可以进行使用了。

升级libseccomplibseccomp需要高于2.4版本。

[root@node2 home]# rpm -qa | grep libseccomp
libseccomp-2.3.1-4.el7.x86_64
[root@node2 home]# rpm -e libseccomp-2.3.1-4.el7.x86_64 --nodeps
[root@node2 home]# wget http://rpmfind.net/linux/centos/8-stream/BaseOS/x86_64/os/Packages/libseccomp-2.5.1-1.el8.x86_64.rpm
[root@node2 home]# rpm -ivh libseccomp-2.5.1-1.el8.x86_64.rpm
警告:libseccomp-2.5.1-1.el8.x86_64.rpm: 头V3 RSA/SHA256 Signature, 密钥 ID 8483c65d: NOKEY
准备中...                          ################################# [100%]
正在升级/安装...
   1:libseccomp-2.5.1-1.el8           ################################# [100%]
[root@node2 home]# rpm -qa | grep libseccomp
libseccomp-2.5.1-1.el8.x86_64
[root@node2 home]#

接下来我们为Containerd设置一个配置文件  

[root@node2 home]# mkdir /etc/containerd
[root@node2 home]# containerd config default > /etc/containerd/config.toml
  • --config,-c可以在启动守护程序时更改此路径
  • 配置文件的默认路径位于/etc/containerd/config.toml

默认cri-containerd-cni包中会有containerd启动脚本,我们已经解压到对应的目录,可以直接调用启动  

[root@node2 home]# systemctl enable containerd --now
Created symlink from /etc/systemd/system/multi-user.target.wants/containerd.service to /etc/systemd/system/containerd.service.
[root@node2 home]systemctl status containerd

containerd配置

每个顶级配置块的命名都是plugin."io.containerd.xxx.vxx.xxx"这种形式,其实每个顶级配置块都代表一个插件,其中io.containerd.xxx.vxx表示插件类型,vxx后面的xxx表示 插件ID。并且可以通过命令ctr查看到  

[root@node2 home]# ctr plugin ls
TYPE                                  ID                       PLATFORMS      STATUS
io.containerd.content.v1              content                  -              ok
io.containerd.snapshotter.v1          aufs                     linux/amd64    skip
io.containerd.snapshotter.v1          btrfs                    linux/amd64    skip
io.containerd.snapshotter.v1          devmapper                linux/amd64    error

配置文件这三个地方需要修改:

  1. 修改SystemdCgroup的值为true
  2. 修改endpoint的值为https://registry.cn-hangzhou.aliyuncs.com
  3. 修改sandbox_image的值为registry.aliyuncs.com/google_containers/pause:3.7

Containerd属于cs架构需要安装ctr,通过crt进行管理控制;ctr实际上就是containerd的客户端工具  

ctr -->Containerd-->RunC

ctr在我们解压包中已经附带了,直接可以使用  

[root@node2 home]# ctr version
Client:
  Version:  v1.6.6
  Revision: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
  Go version: go1.17.11
Server:
  Version:  v1.6.6
  Revision: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
  UUID: 15c09e6d-3bdc-42e2-ba98-a9c0e4685c0e
[root@node2 home]# containerd --version
containerd github.com/containerd/containerd v1.6.6 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1

常用操作

拉取镜像  

在containerd中拉取docker的相关镜像也需要补全  

ctr i pull docker.io/library/nginx:alpine --all-platforms

拉取镜像添加了--all-platforms会将所有平台都下载下来  

并且containerd相比于docker , 多了namespace概念, 每个imagecontaine都会在各自的namespace下可见, 目前k8s会使用k8s.io作为命名空间,默认containerd会使用default.

[root@node2 home]# ctr ns ls
NAME LABELS
[root@node2 home]# ctr ns
NAME:
   ctr namespaces - manage namespaces
USAGE:
   ctr namespaces command [command options] [arguments...]
COMMANDS:
   create, c   create a new namespace
   list, ls    list namespaces
   remove, rm  remove one or more namespaces
   label       set and clear labels for a namespace
OPTIONS:
   --help, -h  show help

如果我们不指定namespace,默认就会使用default

创建 删除namespace

[root@node2 home]# ctr ns create didiplus
[root@node2 home]# ctr ns ls
NAME     LABELS
didiplus
[root@node2 home]# ctr ns remove didiplus
didiplus

接下来我们所有的containerd中的操作,都可以添加-n ns_namespace指定到专属的命名空间中 .

[root@node2 containerd]# ctr -n didiplus i  pull docker.io/library/nginx:alpine
docker.io/library/nginx:alpine:                                                   resolved       |++++++++++++++++++++++++++++++++++++++|
index-sha256:9c2030e1ff2c3fef7440a7fb69475553e548b9685683bdbf669ac0829b889d5f:    done           |++++++++++++++++++++++++++++++++++++++|
manifest-sha256:96a447b9474aff02d4e3b642f5fdb10ff7ff25d409e8132e536c71f494f59617: done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:a46fd6a16a7c6563c064f8ad9197db0bcf1191095cc3af29e75fb5e9b007f168:    done           |++++++++++++++++++++++++++++++++++++++|
config-sha256:e46bcc69753105cfd75905056666b92cee0d3e96ebf134b19f1b38de53cda93e:   done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:530afca65e2ea04227630ae746e0c85b2bd1a179379cbf2b6501b49c4cab2ccc:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:323a7915bc0486f17181676df748e5c3571103eb8ac38137aa60ea87e9d70b19:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:b5b558620e4027e2a918abda48eb0d3ecae77b6ced0f5244a55d78a02bcea87b:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:b37be0d2bf3c46c2d42cf536fcf0eb53cc8a5b7f8f0ee74abaf3e57610ae3f97:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:ba036c7f95ecc063c84fbe789765b97feefdbc331a31abf90153da5e16fe7264:    done           |++++++++++++++++++++++++++++++++++++++|
elapsed: 19.9s                                                                    total:  9.7 Mi (500.5 KiB/s)
unpacking linux/amd64 sha256:9c2030e1ff2c3fef7440a7fb69475553e548b9685683bdbf669ac0829b889d5f...
done: 1.08778507s
[root@node2 containerd]# ctr -n didiplus i ls -q
docker.io/library/nginx:alpine

查看镜像  

[root@node2 containerd]# ctr -n didiplus i ls
REF                            TYPE                                                      DIGEST                                                                  SIZE    PLATFORMS                                                                                LABELS
docker.io/library/nginx:alpine application/vnd.docker.distribution.manifest.list.v2+json sha256:9c2030e1ff2c3fef7440a7fb69475553e548b9685683bdbf669ac0829b889d5f 9.7 MiB linux/386,linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390x -
[root@node2 containerd]#

tag重新打标签  

[root@node2 containerd]# ctr -n didiplus i tag docker.io/library/nginx:alpine docker.io/library/nginx:v1
docker.io/library/nginx:v1
[root@node2 containerd]# ctr -n didiplus i ls -q
docker.io/library/nginx:alpine
docker.io/library/nginx:v1
[root@node2 containerd]#

删除镜像

[root@node2 containerd]# ctr -n didiplus i rm docker.io/library/nginx:v1
docker.io/library/nginx:v1
[root@node2 containerd]# ctr -n didiplus i ls -q
docker.io/library/nginx:alpine
[root@node2 containerd]#

mount  镜像  

mount镜像实际上就是可以将我们镜像中的文件,挂载到宿主机的目录中去  

[root@node2 home]# mkdir ctr_demo_nginx
[root@node2 home]# ctr -n didiplus i ls -q
docker.io/library/nginx:alpine
[root@node2 home]# ctr -n didiplus i mount docker.io/library/nginx:alpine /home/ctr_demo_nginx
sha256:0d78461785798d76ccb9432d71c47dda9b95eec6f6263062647c181774373842
/home/ctr_demo_nginx
[root@node2 home]# cd ctr_demo_nginx/
[root@node2 ctr_demo_nginx]# ls
bin  dev  docker-entrypoint.d  docker-entrypoint.sh  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[root@node2 ctr_demo_nginx]#

mount参数系统为只读状态,只可以读取,不可以写入数据
使用--rw Enable write support on the mount可以开启只读  

取消mount挂载  

[root@node2 home]# ctr -n didiplus i unmount  /home/ctr_demo_nginx
/home/ctr_demo_nginx
[root@node2 home]# cd ctr_demo_nginx/
[root@node2 ctr_demo_nginx]# ls
[root@node2 ctr_demo_nginx]#

导出导入镜像  

[root@node2 ctr_demo_nginx]# ctr -n didiplus i export  --all-platforms nginx.tar docker.io/library/nginx:alpine
ctr: content digest sha256:5a4ddaace7d557dc70582fc1de07cf8ab90bdc847082286322790bac3ecd18f2: not found
[root@node2 ctr_demo_nginx]# ls
nginx.tar

ctr不支持 build,commit 镜像  

创建容器  

这里我创建一个nginx容器  

[root@node2 ctr_demo_nginx]# ctr -n didiplus c create --net-host docker.io/library/nginx:alpine nginx
[root@node2 ctr_demo_nginx]# ctr -n didiplus c ls
CONTAINER    IMAGE                             RUNTIME
nginx        docker.io/library/nginx:alpine    io.containerd.runc.v2
[root@node2 ctr_demo_nginx]#
  • -n 指定命名空间
  • c create 创建容器
  • --net-host 使用宿主机网络
  • docker.io/xx/xxx:xxx 镜像地址
  • nginx 容器名称

可以通过info参数查看容器的相关信息  

[root@node2 ctr_demo_nginx]# ctr -n didiplus c info  nginx | less

Task任务

containerd中有一个task任务的概念,刚刚我们使用containerd create创建的容器,这时候并没有running;在Docker中可以直接run容器,但是在containerd是需要先create在通过task启动容器。create 容器并不会启动容器,可以理解只是声明了一个container,并不会启动和执行相关操作  。

在task我们也可以管理容器的网络,以及容器的监控等。实际上就是增强版的docker ps

#可以通过下面的命令进行查看正在运行的容器
[root@node2 ctr_demo_nginx]# ctr -n didiplus task ls
TASK    PID    STATUS

可以通过使用ctr -n didiplus task  help。task可以操作的相关命令  

使用task启动容器  

[root@node2 ctr_demo_nginx]# ctr -n didiplus task start -d nginx
[root@node2 ctr_demo_nginx]# ctr -n didiplus task ls
TASK     PID     STATUS
nginx    2021    RUNNING
[root@node2 ctr_demo_nginx]#

现在我们通过ps -ef就可以看到进程了  

[root@node2 ctr_demo_nginx]# ps -ef | grep nginx
root       2000      1  0 10:59 ?        00:00:00 /usr/local/bin/containerd-shim-runc-v2 -namespace didiplus -id nginx -address /run/containerd/containerd.sock
root       2021   2000  0 10:59 ?        00:00:00 nginx: master process nginx -g daemon off;
101        2058   2021  0 10:59 ?        00:00:00 nginx: worker process

进入容器  

[root@node2 ctr_demo_nginx]# ctr -n didiplus task ls
TASK     PID     STATUS
nginx    2021    RUNNING
[root@node2 ctr_demo_nginx]# ctr -n didiplus task exec --help
NAME:
   ctr tasks exec - execute additional processes in an existing container
USAGE:
   ctr tasks exec [command options] [flags] CONTAINER CMD [ARG...]
OPTIONS:
   --cwd value       working directory of the new process
   --tty, -t         allocate a TTY for the container
   --detach, -d      detach from the task after it has started execution
   --exec-id value   exec specific id for the process
   --fifo-dir value  directory used for storing IO FIFOs
   --log-uri value   log uri for custom shim logging
   --user value      user id or name
[root@node2 ctr_demo_nginx]# ctr -n didiplus task exec --exec-id 1 -t nginx sh
/ #

exec task进入容器操作

--exec-id 设置一个id,唯一即可

-t --tty为container分配一个tty

nginx 容器名称

sh && bash即可

暂停容器  

[root@node2 ctr_demo_nginx]# ctr -n didiplus task pause nginx
[root@node2 ctr_demo_nginx]# ctr -n didiplus task ls
TASK     PID     STATUS
nginx    2021    PAUSED

有暂停容器当然也有恢复容器  

需要注意暂停和恢复容器不等于重启容器  

[root@node2 ctr_demo_nginx]# ctr -n didiplus task ls
TASK     PID     STATUS
nginx    2021    RUNNING

如果我们需要停止容器,只能通过kill来进行停止,然后在重新start;在containerd中没有stop和restart参数  

[root@node2 ctr_demo_nginx]# ctr -n didiplus task kill nginx
[root@node2 ctr_demo_nginx]# ctr -n didiplus task ls
TASK     PID     STATUS
nginx    2021    STOPPED
[root@node2 ctr_demo_nginx]# ctr -n didiplus task rm nginx
[root@node2 ctr_demo_nginx]# ctr -n didiplus task ls
TASK    PID    STATUS
#删除task并不会删除container
[root@node2 ctr_demo_nginx]# ctr -n didiplus c ls
CONTAINER    IMAGE                             RUNTIME
nginx        docker.io/library/nginx:alpine    io.containerd.runc.v2
[root@node2 ctr_demo_nginx]#

删除容器  

[root@node2 ctr_demo_nginx]# ctr -n didiplus c rm nginx
[root@node2 ctr_demo_nginx]# ctr -n didiplus c ls
CONTAINER    IMAGE    RUNTIME

task还可以通过metrcis命令,获取到容器内部资源使用情况  

Containerd 对接私有镜像仓库 Harbor

首先我们需要将私有镜像仓库配置到 containerd 中去,修改 containerd的配置文件 /etc/containerd/config.toml

[plugins."io.containerd.grpc.v1.cri".registry]
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
      endpoint = ["https://bqr1dr1n.mirror.aliyuncs.com"]
  [plugins."io.containerd.grpc.v1.cri".registry.configs]
    [plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.k8s.local".tls]
      insecure_skip_verify = true
    [plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.k8s.local".auth]
      username = "admin"
      password = "Harbor12345"

plugins."io.containerd.grpc.v1.cri".registry.configs 下面添加对应 harbor.k8s.local 的配置信息,insecure_skip_verify = true 表示跳过安全校验,然后通过 plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.k8s.local".auth 配置 Harbor 镜像仓库的用户名和密码。  

Docker ctr nerdctl命令直接的区别

crictlkubernetes cri-tools的一部分,是专门为kubernetes使用containerd而专门制作的,提供了Pod、容器和镜像等资源的管理命令。

ctr功能简单,而且对已经习惯使用docker cli的人来说,ctr并不友好(比如无法像 docker cli 那样)。这个时候nerdctl就可以替代ctr了。nerdctl是一个与docker cli风格兼容的containerdcli工具,并且已经被作为子项目加入了 containerd 项目中。从nerdctl 0.8开始,nerdctl直接兼容了docker compose的语法(不包含 swarm), 这很大程度上提高了直接将 containerd 作为本地开发、测试和单机容器部署使用的体验。  

需要注意的是:安装 nerdctl 之后,要想可以使用 nerdctl 还需要安装 CNI 相关工具和插件。containerd不包含网络功能的实现,想要实现端口映射这样的容器网络能力,需要额外安装 CNI 相关工具和插件。  

另外 nerdctl 也可以使用 -n 指定使用的 namespace。  

docker

crictl

ctr

nerdctl

查看容器列表

docker ps

crictl ps

ctr c ls(查看非 kubernetes 中的容器)ctr -n k8s.io c ls(查看 kubernetes 集群中的容器)

nerdctl ps(查看非 kubernetes 中的容器)nerdctl -n k8s.io ps(查看 kubernetes 集群中的容器)

查看容器详情

docker inspect

crictl inspect

ctr c info

nerdctl inspect

查看容器日志

docker logs

crictl logs

nerdctl logs

容器内执行命令

docker exec

crictl exec

ctr t exec

nerdctl exec

挂载容器

docker attach

crictl attach

ctr t attach

显示容器资源使用情况

docker stats

crictl stats

ctr task metrics

创建容器

docker create

crictl create

ctr c create

启动容器

docker start

crictl start

ctr t start

nerdctl start

运行容器

docker run

crictl run

ctr run

nerdctl run

停止容器

docker stop

crictl stop

ctr t kill

nerdctl stop

删除容器

docker rm

crictl rm

ctr c rm

nerdctl rm

查看镜像列表

docker images

crictl images

ctr i ls

nerdctl images

查看镜像详情

docker inspect

crictl inspecti

nerdctl inspect

拉取镜像

docker pull

crictl pull

ctr i pull

nerdctl pull

推送镜像

docker push

ctr i push

nerdctl push

删除镜像

docker rmi

crictl rmi

ctr i rm

nerdctl rmi

查看Pod列表

crictl pods

查看Pod详情

crictl inspectp

启动Pod

crictl runp

停止Pod

crictl stopp

containerd构建镜像

containerd默认不支持build操作,需要安装插件配置使用

下载buildkit插件

wget https://github.com/moby/buildkit/releases/download/v0.10.3/buildkit-v0.10.3.linux-arm64.tar.gz

解压文件

tar -zxvf buildkit-v0.10.3.linux-amd64.tar.gz -C /usr/local/

创建配置systemd管理文件

#vim /etc/systemd/system/buildkit.service
[Unit]
Description=BuildKit
Documentation=https://github.com/moby/buildkit
[Service]
ExecStart=/usr/local/bin/buildkitd --oci-worker=false --containerd-worker=true
[Install]
WantedBy=multi-user.target

安装nerdctl

下载安装包

https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-0.22.2-linux-amd64.tar.gz

解压到指定目录下

tar xf nerdctl-0.22.2-linux-amd64.tar.gz -C /usr/local/bin/

配置环境变量

#vi /etc/profile
#在最后添加下面语句
alias docker='nerdctl --namespace k8s.io'
alias docker-compose='nerdctl compose'
source <(nerdctl completion bash)

启动

systemctl enable buildkit --now

参考资料

https://i4t.com/5435.html

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2天前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
116 77
|
3天前
|
数据建模 应用服务中间件 nginx
docker替换宿主与容器的映射端口和文件路径
通过正确配置 Docker 的端口和文件路径映射,可以有效地管理容器化应用程序,确保其高效运行和数据持久性。在生产环境中,动态替换映射配置有助于灵活应对各种需求变化。以上方法和步骤提供了一种可靠且易于操作的方案,帮助您轻松管理 Docker 容器的端口和路径映射。
26 3
|
15天前
|
Kubernetes Linux 开发者
深入探索容器化技术——Docker 的实战应用
深入探索容器化技术——Docker 的实战应用
46 5
|
19天前
|
运维 Cloud Native 云计算
云原生之旅:Docker容器化实战
本文将带你走进云原生的世界,深入理解Docker技术如何改变应用部署与运维。我们将通过实际案例,展示如何利用Docker简化开发流程,提升应用的可移植性和伸缩性。文章不仅介绍基础概念,还提供操作指南和最佳实践,帮助你快速上手Docker,开启云原生的第一步。
|
14天前
|
Kubernetes Cloud Native API
深入理解Kubernetes——容器编排的王者之道
深入理解Kubernetes——容器编排的王者之道
29 1
|
20天前
|
运维 持续交付 虚拟化
深入解析Docker容器化技术的核心原理
深入解析Docker容器化技术的核心原理
42 1
|
19天前
|
存储 运维 数据中心
使用Docker容器化应用程序的优势与挑战
使用Docker容器化应用程序的优势与挑战
19 0
|
23天前
|
运维 Cloud Native 虚拟化
一文吃透云原生 Docker 容器,建议收藏!
本文深入解析云原生Docker容器技术,涵盖容器与Docker的概念、优势、架构设计及应用场景等,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
一文吃透云原生 Docker 容器,建议收藏!
|
10天前
|
监控 Docker 容器
在Docker容器中运行打包好的应用程序
在Docker容器中运行打包好的应用程序
|
10天前
|
存储 缓存 监控
Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
38 6

相关产品

  • 容器服务Kubernetes版