-
早在2016年3月，Docker 1.11的Docker Engine里就包含了containerd，而现在则是把containerd从Docker Engine里彻底剥离出来，作为一个独立的开源项目独立发展，目标是提供一个更加开放、稳定的容器运行基础设施。和原先包含在Docker Engine里containerd相比，独立的containerd将具有更多的功能，可以涵盖整个容器运行时管理的所有需求。
-
containerd并不是直接面向最终用户的，而是主要用于集成到更上层的系统里，比如Swarm, Kubernetes, Mesos等容器编排系统。
-
containerd以Daemon的形式运行在系统上，通过暴露底层的gRPC API，上层系统可以通过这些API管理机器上的容器。
-
每个containerd只负责一台机器，Pull镜像，对容器的操作（启动、停止等），网络，存储都是由containerd完成。具体运行容器由runC负责，实际上只要是符合OCI规范的容器都可以支持。
-
对于容器编排服务来说，运行时只需要使用containerd+runC，更加轻量，容易管理。
2013年docker公司在推出docker产品后,由于其对全球技术产生了一定的影响力，Google公司明显感觉到自己公司内部所使用的Brog系统江湖地位受到的威胁，希望Docker公司能够与自己联合打造一款开源的容器运行时作为Docker核心依赖，但Docker公司拒绝了；接着Google公司联合RedHat、IBM等公司说服Docker公司把其容器核心技术libcontainer捐给中立社区(OCI,Open Container Intiative)，并更名为runC。
为了进一步遏制Docker在未来技术市场影响力，避免在容器市场上Docker一家独大，Google公司带领导RedHat、IBM等成立了CNCF(Cloud Native Computing Fundation)基金会，即云原生计算基金会。CNCF的目标很明确，既然在容器应用领域无法与Docker相抗衡，那就做Google更有经验的技术市场------大规模容器编排应用场景，Google公司把自己内部使用的Brog系统开源------Kubernetes，也就是我们今天所说的云原生技术生态。
2016年Docker公司推出了Docker Swarm，意在一统Docker生态，让Docker既可以实现容器应用管理，也可以实现大规模容器编排，经过近1年左右时间的市场验证后，发现在容器编排方面无法独立抗衡kubernetes,所以Docker公司于2017年正式宣布原生支持Kubernetes,至此，Docker在大规模容器编排应用市场败下阵来，但是Docker依然不甘心失败，把Docker核心依赖Containerd捐给了CNCF，依此说明Docker依旧是一个PaaS平台。
2020年CNCF基金会宣布Kubernetes 1.20版本将不再仅支持Docker容器管理工具，此事的起因主要也与Docker捐给CNCF基金会的Containerd有关，早期为了实现Kubernetes能够使用Docker实现容器管理，专门在Kubernetes组件中集成一个shim（垫片）技术，用来将Kubernetes容器运行时接口（CRI，Container Runntime Interface）调用翻译成Docker的API,这样就可以很好地使用Docker了，但是随着Kubernetes在全球技术市场的广泛应用，有更多的容器管理工具的出现，它们都想能够借助于Kubernetes被用户所使用，所以就提出标准化容器运行时接口，只要适配了这个接口就可以集成到Kubernetes生态当中，所以Kubernetes取消了对shim的维护，并且由于Containerd技术的成功，可以实现无缝对接Kubernetes，所以接下来Kubernetes容器运行时的主角是Containerd。
1.2.1 架构图
Containerd设计的目的是为了嵌入到Kubernetes中使用，它是一个工业级的容器运行时，不提供给开发人员和终端用户直接使用，这样就避免了与Docker产生竞争，但事实上，Containerd已经实现大多数容器管理功能，例如：容器生命周期管理、容器镜像传输和管理、容器存储与网络管理等。
-
Containerd 采用标准的 C/S 架构
- 服务端通过 GRPC 协议提供稳定的 API
- 客户端通过调用服务端的 API 进行高级的操作
-
为了实现解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。
-
Containerd 两大子系统为：
- Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。
- Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。
其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。
例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。
1.2.2 常用插件
- Content Plugin : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。
- Snapshot Plugin : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 。
- Metrics : 暴露各个组件的监控指标。
1.2.3 架构缩略图
1.2.4 与其它容器运行时工具性能对比
这是使用 bucketbench 对 Docker、crio 和 Containerd 的性能测试结果，包括启动、停止和删除容器，以比较它们所耗的时间：
结论： Containerd 在各个方面都表现良好，总体性能优于 和 。
课程操作系统环境为 ubuntu 20.04
2.1.1 获取YUM源
获取阿里云YUM源
查看YUM源中Containerd软件
2.1.2 使用yum命令安装
安装Containerd.io软件，即可安装Containerd
2.1.3 验证安装及启动服务
使用rpm -qa命令查看是否安装
设置containerd服务启动及开机自启动
查看containerd服务启动状态
2.1.4 验证可用性
安装Containerd时ctr命令亦可使用，ctr命令主要用于管理容器及容器镜像等。
使用ctr命令查看Containerd客户端及服务端相关信息。
Containerd有两种安装包：
- 第一种是,这种包用于单机测试没问题，不包含runC，需要提前安装。
- 第二种是，包含runc和k8s里的所需要的相关文件。k8s集群里需要用到此包。虽然包含runC，但是依赖系统中的seccomp（安全计算模式，是一种限制容器调用系统资源的模式。）
2.2.1 下载安装Containerd
2.2.2 下载安装runc
验证安装结果
2.2.3 下载安装crictl
验证安装结果
2.2.4 下载安装nerdctl
验证安装结果
2.2.5 下载安装cni组件
2.2.6 启动containerd
2.2.7 生成containerd模块配置文件
2.2.7.1 生成默认模块配置文件
Containerd 的默认配置文件为 ，可以使用命令创建一份模块配置文件
创建配置文件目录
生成配置文件
查看配置文件
2.2.7.2 替换默认配置文件
但上述配置文件后期改动的地方较多，这里直接换成可单机使用也可k8s环境使用的配置文件并配置好镜像加速器。
重新启动containerd服务
2.2.8 配置Containerd的内核
通过运行以下说明验证是否已加载 、 模块：
通过运行以下指令，验证在您的配置中，系统变量被设置为1:net.bridge.bridge-nf-call-iptablesnet.bridge -nf-call-ip6tablesnet.ipv4.ip_forwardsysctl
重新启动containerd服务
- docker使用docker images命令管理镜像
- 单机containerd使用ctr images命令管理镜像,containerd本身的CLI
- k8s中containerd使用crictl images命令管理镜像,Kubernetes社区的专用CLI工具
获取命令帮助
获取命令帮助
列出镜像
containerd支持oci标准的镜像，所以可以直接使用docker官方或dockerfile构建的镜像
说明：
这里ctr命令pull镜像时，不能直接把镜像名字写成
查看已下载容器镜像
指定平台下载容器镜像
方便查看镜像中包含的内容。
把已下载的容器镜像挂载至当前文件系统
卸载
把容器镜像导出
说明
–all-platforms,导出所有平台镜像，本版本为1.6版本，1.4版本不需要添加此选项。
查看已导出容器镜像
删除指定容器镜像
4.1.1 获取创建静态容器命令帮助
说明：
使用命令创建容器后，容器并没有处于运行状态，其只是一个静态的容器。这个 container 对象只是包含了运行一个容器所需的资源及配置的数据结构，例如： namespaces、rootfs 和容器的配置都已经初始化成功了，只是用户进程(本案例为nginx)还没有启动。需要使用命令才能获取一个动态容器。
4.1.2 获取动态容器命令帮助
说明：
使用命令可以创建一个静态容器并使其运行。一步到位运行容器。
container表示静态容器，可用c缩写代表container
或
task表示容器里跑的进程, 可用t缩写代表task
或
启动task，即表时在容器中运行了进程，即为动态容器。
说明：
-d表示daemon或者后台的意思，否则会卡住终端
查看容器所在宿主机进程，是以宿主机进程的方式存在的。
查看容器的进程(都是物理机的进程)
物理机查看到相应的进程
说明：
- -d 代表dameon，后台运行
- –net-host 代表容器的IP就是宿主机的IP(相当于docker里的host类型网络)
查看已运行容器
查看已运行容器中运行的进程,既tasks
进入容器
在宿主机上访问网站
查看容器状态
暂停容器
再次查看容器状态，看到其状态为PAUSED，表示停止。
使用resume命令恢复容器
查看恢复后状态
在宿主机上访问容器中提供的服务
使用kill命令停止容器中运行的进程，既为停止容器
查看容器停止后状态，STATUS为STOPPED
必须先停止tasks或先删除task，再删除容器
查看静态容器，确认其还存在于系统中
删除容器
5.2.1 Harbor主机名解析
在所有安装containerd宿主机上添加此配置信息。
说明
- 172.18.0.51是harbor的IP
- docker.vms.weijc建议用FQDN形式，如果用类似harbor这种短名，后面下载镜像会出问题
5.2.2 修改Containerd配置文件
重启containerd，以便于重新加载配置文件。
5.2.3 ctr下载镜像
下载容器镜像
说明:
- –platform linux/amd64 指定系统平台，也可以使用–all-platforms指定所有平台镜像。
查看已下载容器镜像
5.2.4 ctr上传镜像
上传到Harbor library公有项目
重新生成新的tag
查看已生成容器镜像
推送容器镜像至Harbor
说明:
- 先tag再push
- 如果harbor是http协议，就需要加上
- 指定harbor的用户名与密码
containerd中namespace的作用为:隔离运行的容器，可以实现运行多个容器。
查看命令帮助
列出已有namespace
创建namespace
删除namespace
查看指定namespace中是否有用户进程在运行
在指定namespace中下载容器镜像
在指定namespace中创建静态容器
查看在指定namespace中创建的容器
默认Containerd管理的容器仅有lo网络，无法访问容器之外的网络，可以为其添加网络插件，使用容器可以连接外网。CNI（Container Network Interface）
7.1.1 准备CNI网络配置文件
准备容器网络配置文件，用于为容器提供网关、IP地址等。
创建名为mynet的网络，其中包含名为cni0的网桥
7.1.2 生成CNI网络
安装jq
进入cni工具目录
必须在scripts目录中执行，需要依赖exec-plugins.sh文件，再次进入scripts目录
执行脚本文件，基于/etc/cni/net.d/目录中的*.conf配置文件生成容器网络
在宿主机上查看是否生成容器网络名为cni0的网桥
在宿主机上查看其路由表情况
7.2.1 创建一个容器
7.2.2 进入容器查看其网络情况
7.2.3 获取容器进程ID及其网络命名空间
在宿主机中完成指定容器进程ID获取
在宿主机中完成指定容器网络命名空间路径获取
7.2.4 为指定容器添加网络配置
确认执行脚本文件时所在的目录
执行脚本文件为容器添加网络配置
进入容器确认是否添加网卡信息
在容器中开启httpd服务
在宿主机访问容器提供的httpd服务
实现把宿主机目录挂载至Containerd容器中，实现容器数据持久化存储
说明：
创建一个静态容器，实现宿主机目录与容器挂载
src=/mnt/busybox1 为宿主机目录
dst=/hostdir 为容器中目录
运行用户进程
进入容器，查看是否挂载成功
当需要与其它Containerd管理的容器共享命名空间时，可使用如下方法。
目前Containerd主要任务还在于解决容器运行时的问题，对于其周边生态还不完善，所以可以借助Docker结合Containerd来实现Docker完整的功能应用。
准备Docker安装YUM源
修改Docker服务文件，以便使用已安装的containerd。
设置docker daemon启动并设置其开机自启动
查看其启动后进程
使用docker运行容器
使用docker ps命令查看正在运行的容器
使用ctr查看是否添加一个新的namespace，本案例中发现添加一个moby命名空间，即为docker使用的命名空间。
查看moby命名空间，发现使用docker run运行的容器包含在其中。
使用ctr能够查看到一个正在运行的容器，既表示docker run运行的容器是被containerd管理的。
使用docker stop停止且使用docker rm删除容器后再观察，发现容器被删除。