K8S Runtime CRI OCI contained dockershim 理解 1.23弃用docker - 含docker containerd通用工具 nerdctl

一 实践
contained实用管理工具
http://www.ciscoedu.com.cn/details/id/252.html

containerd的默认命令行工具（crictl）也不是很好用，和docker也不兼容。

nttlabs贡献了一个名为nerdctl的containerd客户端，可以兼容docker命令行工具。于是我们就可以使用nerdctl来作为docker的替代品了。

nerdctl不仅与docker兼容，而且还支持了更多的功能：

1.支持containerd的命名空间查看，nerdctl不仅可以管理Docker容器，也可以直接管理本地的的Kubernetes pod。

2.支持将Docker Image Manifest镜像转换为OCI镜像、estargz镜像。

3.支持OCIcrypt（镜像加密）。

# 下载nerdctl
wget https://breezey-public.oss-cn-zhangjiakou.aliyuncs.com/softwares/linux/kubernetes/nerdctl-full-0.14.0-linux-amd64.tar.gz
# 解压nerdctl
tar xf nerdctl-full-0.14.0-linux-amd64.tar.gz  -C /usr/
# 验证
nerdctl ps --namespace k8s.io # --namespace string         containerd namespace, such as "moby" for Docker, "k8s.io" for Kubernetes [$CONTAINERD_NAMESPACE] (default "default")

二 理论
原文：https://blog.csdn.net/u011563903/article/details/90743853

容器历史小叙
早期的k8s runtime架构，远没这么复杂，kubelet创建容器，直接调用docker daemon，docker daemon自己调用libcontainer就把容器运行起来。

但往往，事情不会如此简单，一系列政治斗争开始了，先是大佬们认为运行时标准不能被 Docker 一家公司控制，于是就撺掇着搞了开放容器标准 OCI。Docker 则把 libcontainer 封装了一下，变成 runC 捐献出来作为 OCI 的参考实现。

再接下来就是 rkt(coreos推出的，类似docker) 想从 Docker 那边分一杯羹，希望 Kubernetes 原生支持 rkt 作为运行时，而且 PR 还真的合进去了。维护过一块业务同时接两个需求方的读者老爷应该都知道类似的事情有多坑，Kubernetes 中负责维护 kubelet 的小组 sig-node 也是被狠狠坑了一把。

大家一看这么搞可不行，今天能有 rkt，明天就能有更多幺蛾子出来，这么搞下去我们小组也不用干活了，整天搞兼容性的 bug 就够呛。于是乎，Kubernetes 1.5 推出了 CRI 机制，即容器运行时接口（Container Runtime Interface），Kubernetes 告诉大家，你们想做 Runtime 可以啊，我们也资瓷欢迎，实现这个接口就成，成功反客为主。

不过 CRI 本身只是 Kubernetes 推的一个标准，当时的 Kubernetes 尚未达到如今这般武林盟主的地位，容器运行时当然不能说我跟 Kubernetes 绑死了只提供 CRI 接口，于是就有了 shim（垫片）这个说法，一个 shim 的职责就是作为 Adapter 将各种容器运行时本身的接口适配到 Kubernetes 的 CRI 接口上。

接下来就是 Docker 要搞 Swarm 进军 PaaS 市场，于是做了个架构切分，把容器操作都移动到一个单独的 Daemon 进程 containerd 中去，让 Docker Daemon 专门负责上层的封装编排。可惜 Swarm 在 Kubernetes 面前实在是不够打，惨败之后 Docker 公司就把 containerd 项目捐给 CNCF 缩回去安心搞 Docker 企业版了。

最后就是我们在上一张图里看到的这一坨东西了，尽管现在已经有 CRI-O，containerd-plugin 这样更精简轻量的 Runtime 架构，dockershim 这一套作为经受了最多生产环境考验的方案，迄今为止仍是 Kubernetes 默认的 Runtime 实现。
————————————————

OCI, CRI
OCI（开放容器标准），规定了2点：

容器镜像要长啥样，即 ImageSpec。里面的大致规定就是你这个东西需要是一个压缩了的文件夹，文件夹里以 xxx 结构放 xxx 文件；
容器要需要能接收哪些指令，这些指令的行为是什么，即 RuntimeSpec。这里面的大致内容就是“容器”要能够执行 “create”，“start”，“stop”，“delete” 这些命令，并且行为要规范。
————————————————
强隔离容器：Kata，gVisor，Firecracker
一直以来，K8S都难以实现真正的多租户。
理想来说，平台的各个租户（tenant）之间应该无法感受到彼此的存在，表现得就像每个租户独占这整个平台一样。具体来说，我不能看到其它租户的资源，我的资源跑满了不能影响其它租户的资源使用，我也无法从网络或内核上攻击其它租户。
Kubernetes 当然做不到，其中最大的两个原因是：

kube-apiserver 是整个集群中的单例，并且没有多租户概念
默认的 oci-runtime 是 runC，而 runC 启动的容器是共享内核的
kata：

————————————————
说完了 Kata，其实 gVisor 和 Firecracker 都不言自明了，大体上都是类似的，只是：

gVisor 并不会去创建一个完整的 VM，而是实现了一个叫 “Sentry” 的用户态进程来处理容器的 syscall，而拦截 syscall 并重定向到 Sentry 的过程则由 KVM 或 ptrace 实现。
Firecracker 称自己为 microVM，即轻量级虚拟机，它本身还是基于 KVM 的，不过 KVM 通常使用 QEMU 来虚拟化除 CPU 和内存外的资源，比如 IO 设备，网络设备。Firecracker 则使用 rust 实现了最精简的设备虚拟化，为的就是压榨虚拟化的开销，越轻量越好。
————————————————
版权声明：本文为CSDN博主「Frank范」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u011563903/article/details/90743853

二 1.23弃用docker 理解

https://blog.csdn.net/justlpf/article/details/120530870