从Docker到Kubernetes
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
节点要维护， 比如我们需要变更节点配置、升级内核等操作的时候都可以先将节点进行驱逐，然后再进行维护，再恢复
