Docker 发展历程

2013 年，随着PaaS发展壮大，这个领域的从业者们发现了 PaaS 中最为棘手也最亟待解决的一个问题：究竟如何给应用打包？无论是 Cloud Foundry、OpenShift，还是 Clodify，面对这个问题都没能给出一个完美的答案。一个并不引人瞩目的 PaaS 创业公司 dotCloud，却选择了开源自家的一个容器项目 Docker，正好提供了一种非常便利的打包机制，然后就一发不可收拾，围绕着 Docker 项目进行集成与创新涌现出来，包括Mesosphere公司的Mesos项目等等，Docker 公司也顺势推出了Docker Compose、Swarm 和 Machine“三件套”，docker生态圈很快发展起来了，开启了一个新的容器时代。

2014年6月，谷歌公司正式宣告了Kubernetes项目的诞生。这个时候容器出现多样化，包括google公司lmctfy容器，coreos的rkt容器。Google公司提出和Docker合作，与Docker公司共同推进一个中立的容器运行时库作为Docker项目的核心依赖。此时Docker并不担心，因为它维护的 Docker 社区也足够庞大，Docker项目已是容器生态的标准。于是，2015 年 6 月 22 日，由 Docker 公司牵头，CoreOS、Google、RedHat 等公司共同宣布，Docker 公司将 Libcontainer 捐出，并改名为 RunC 项目，交由一个完全中立的基金会管理，然后以 RunC 为依据，大家共同制定一套容器和镜像的标准和规范，这就是OCI。明显OCI的成立容器玩家们出于自身利益进行干涉的一个妥协结果，所以尽管Docker 是 OCI 的发起者和创始成员，但并没有很积极的去推动，Docker注重是它商业价值。

2015年12月11日，Google、RedHat 等开源基础设施领域玩家们，共同牵头发起了一个名为 CNCF（Cloud Native Computing Foundation）的基金，主要是以kubernetes项目为基础打造一个平台级生态。由于Kubernates项目焕然一新的设计理念和号召力，2016年以后kubernates社区得到了空前的发展。

2016年6月，Docker v.1.12发布，直接内置Docker Swarm（多主机多容器的编排解决方案）
2016年12月， Kubernetes 发布 CRI （Container Runtime Interface， 容器运行时接口）

2017年，Docker 分拆了 Containerd，支持CNI，将这个组件分解为一个单独的项目，使得 Docker 将容器的管理功能移出 Docker 引擎，并移入一个单独的守护进程中，即 Containerd，并将其捐赠给了CNCF社区。同时Docker公司宣布将Docker项目改名为Moby，交给社区自行维护。

2017年10月，Docker公司将自己的主打产品Docker EE 内置Kubernetes项目，预示着Kubernetes的胜出，成为容器编排的标准。

2017年11月 ，K8s支持containerd
2018年 k8s集成containerd，正式GA，把CRI plugin嵌入 containerd中
2019年 rkt 终止使命被CNCF归档
2019 年 Mirantis 收购 Docker 的企业服务

OCI

OCI 代表开放容器标准， 它标准化了容器工具和底层实现（technologies）之间的大量接口。 他们维护了打包容器镜像（OCI image-spec）和运行容器（OCI runtime-spec）的标准规范。 他们还以 runc 的形式维护了一个 runtime-spec 的真实实现， 这也是 containerd 和 CRI-O 依赖的默认运行时。 CRI 建立在这些底层规范之上，为管理容器提供端到端的标准

CRI

全称Container Runtime Interface，（容器运行时接口）是一个用来扩展容器运行时的接口，能让 kubelet 无需重新编译就可以广泛使用各种容器运行时的插件接口。CRI 由 protocol buffers 和 gRPC API 还有 streaming 库构成。用户不需要关心内部通信逻辑，而只需要实现定义的接口就可以，包括 RuntimeService 和 ImageService。

容器就是Docker?

其实准确来讲，Docker和容器不是一回事，但Docker普及了Linux容器这种技术模式，并在开发底层技术方面发挥了重要作用。 容器的生态相比于单纯的 Docker，已经进化到了一个更宽广的领域

弃用Docker

2020年 Kubernates 宣布移除dockershim，现在1.20版本以后，能使用但是kubelet会打印警告日志。最新消息dockershim 计划在 Kubernetes 1.24 版被移除， 请参阅移除 Kubernetes 增强方案 Dockershim

CRI发展

容器运行时

主流的容器运行时有 containerd，docker engine，cri-o，Mirantis Container Runtime（商业版）

CRI	维护者	主要特性	容器引擎	描述
dockershim	Kubernetes	内置实现、特性最新	Docker	后面被废弃了
cri-o	cri-o	OCI 标准不需要 Docker	OCI（runc、kata、gVisor…）
cri-containerd	Containerd	OCI 标准不需要 Docker	OCI（runc、kata、gVisor…）	主流的，使用最广泛
cri-dockerd	Mirantis	内置实现	Docker EE	商业版，前身是Docker EE

Containerd

Containerd是一个工业标准的容器运行时，它强调简单性、健壮性和可移植性。它可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等，是目前适用最广泛。

安装

yum install containerd.io #使用yum 直接安装
# 也可以直接从 github 下载 containerd 包，然后解压
# 网址:https://github.com/containerd/containerd/releases

#查看版本
containerd -v 
#查看帮助命令
containerd -h

配置

Containerd 的配置文件默认为 /etc/containerd/config.toml[^ssh-copy-id]

containerd config default > /etc/containerd/config.toml #生成配置文件
#配置cgroup driver 为 systemd

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true
#配置镜像仓库
[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://registry-1.docker.io"]
     [plugins."io.containerd.grpc.v1.cri".registry.configs]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."docker.io".tls]
           insecure_skip_verify = true
         [plugins."io.containerd.grpc.v1.cri".registry.configs."docker.io".auth]
           username = "xxxx"
           password = "xxxx"

#把docker.io 换成内部镜像仓库

每一个顶级配置块的命名都是 plugins."io.containerd.xxx.vx.xxx" 这种形式，表示一个插件，其中 io.containerd.xxx.vx 表示插件的类型，vx 后面的 xxx 表示插件的 ID，我们可以通过 ctr plugin ls 查看插件列表

#设置开启启动
systemctl enable cotnainerd
#启动
systemctl start containerd
#查看状态
systemctl status containerd

存储

containerd 将容器相关的数据持久化在 /var/lib/containerd/中（docker 默认在 /var/lib/docker/）

如何使用

containerd 提供ctr CLI。
containerd 相比docker, 多了namespace概念, 每个image和container 都会在各自的namespace下可见, 目前k8s会使用k8s.io 作为命名空间。

命名空间管里

ctr ns ls #查看命名空间列表，ctr ns -h 查看管理命名空间的相关命令
export CONTAINERD_NAMESPACE=k8s.io #修改默认命名空间

镜像管理

不支持build，commit 镜像

ctr i ls #查看镜像列表，ctr i -h查看管理镜像的相关命令
#拉取镜像
ctr -n k8s.io i pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 # 
#镜像标记tag
ctr -n k8s.io i tag registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 k8s.gcr.io/pause:3.2 # tag镜像

#镜像导入
ctr -n k8s.io i import kube-apiserver.tar #从tar 文件导入镜像，tar可以由docker save 
#镜像导出
ctr -n k8s.io i export pause.tar k8s.gcr.io/pause:3.2 # 

#镜像推送
ctr -n k8s.io i push -k k8s.gcr.io/pause:3.2

容器管理

容器时依赖task，task 管理容器，删除容器，得先终止task

ctr c ls # 查看容器列表， ctr c -h 查看管理容器 的相关命令

#运行容器
ctr  run -d nginx:1.21 nginx1 #运行容器，有下面两步组成
#创建容器
ctr c create nginx:1.21 nginx1
#创建任务指定容器
ctr task start -d nginx1

#进入容器
ctr task exec --exec-id $RANDOM -t nginx1 sh #相当于docker exec

#删除容器
ctr task kill nginx1 #终止任务 相当于 docker stop
ctr c rm nginx1 #删除容器 相当于 docker rm

#容器暂停/继续
ctr task pause nginx1 #暂停任务  相当于docker pause
ctr task resume nginx1 #恢复任务 

#日志查看
ctr event nginx1

#复制容器文件
ctr  snapshot mounts /usr/share/nginx/html

CRI Tools

CRI Tools是社区针对 CRI 接口开发的CLI及验证工具。

它包括两个工具：crictl 和 critest。crictl 是一个容器运行时命令行接口，适用所有CRI兼容的容器运行时，与Docker cli类似功能，但是docker cli只适用于Docker运行时。由于Kubernetes 是支持所有CRI兼容的容器运行时，所以推荐crictl用于 Kubernetes 节点上 pod、容器以及镜像的除错工具。

#查看命令详细帮助
crictl -h 

vim /etc/crictl.yaml #编辑文件，修改默认配置
runtime-endpoint: unix:///var/run/containerd/containerd.sock
image-endpoint: unix:///var/run/containerd/containerd.sock
timeout: 10
debug: true

针对pod操作如下：

#打印所有pod清单
crictl pods

#根据标签打印pod
crictl pods --label run=nginx

#详细帮助命令
crictl pods -h

critest 则是一个容器运行时的验证测试工具，用于验证容器运行时是否符合 Kubelet CRI 的要求。除了验证测试，critest 还提供了 CRI 接口的性能测试，比如 critest -benchmark

常用命令对比

crictl(kubernetes)	ctr(containerd)	docker	说明
crictl ps	ctr task ls/ctr container ls	docker ps	查看运行容器
crictl exec	ctr task exec --exec-id	docker exec	进入容器
crictl images	ctr i ls	docker images	查看镜像
crictl logs	无	docker logs	查看日志
crictl inspect/inspecti	ctr container info	docker inspect	查看容器/镜像信息
crictl stats	无	docker stats	查看容器资源
crictl start/stop	ctr task start/kill	docker start/stop	启动/关闭已有的容器
无	ctr image tag	docker tag	修改镜像标签
无	ctr image import/export	docker load/save	镜像导入导出
crictl pull	ctr image pull	docker pull	拉取镜像
无	ctr image push	docker push	推送镜像

crictl 命令行工具基本与docker 命令行工具保持一致，只是docker关键换成crictl，对于之前使用docker的人员来说，可以说是无缝切换

运行时Docker切成Containerd

• 先隔离要切换的docker节点，置成不可以调度状态（unschedulable ）

kubectl cordon test1

• .再驱逐节点上pod，保留DaemonSet控制管理的pod,因为这些pods不用驱逐到其它节点。

kubectl drain test1 --ignore-daemonsets

• 切换containerd
  停止kubelet和docker

systemctl stop kubelet
systemctl stop docker
systemctl stop containerd

根据上文内容知道Docker也是依赖Containerd，因此安装Docker同时也安装Containerd，那么切Containerd就可以不用再安装，当然你也可以将 Docker 和 containerd 完全卸载掉，然后重新安装。

Containerd 中默认已经实现了 CRI，但是是以 plugin 的形式配置的，之前 Docker 中自带的 containerd 默认是将 CRI 这个插件禁用掉了的（使用配置 disabled_plugins = ["cri"]），所以这里我们重新生成默认的配置文件来覆盖掉, 具体查看上面Containerd 配置

接下来配置kubelet，修改/etc/sysconfig/kubelet，container-runtime指定容器运行时，默认值是docker， --container-runtime-endpoint指定运行时套接字地址，containerd套接字unix:///run/containerd/containerd.sock

KUBELET_EXTRA_ARGS="--container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock"

配置完成后启动containerd和kubelet

systemctl daemon-reload
systemctl start containerd
systemctl start kubelet

重启完成后查看节点状态

kubectl get node -o wide

image.png

• 节点恢复使用

kubectl uncordon test1

节点要维护， 比如我们需要变更节点配置、升级内核等操作的时候都可以先将节点进行驱逐，然后再进行维护，再恢复