在使用kubernetes的时候，常常不太会关注docker这层, 在Node节点查看docker的进程, 会发现在docker-client、dockerd、containerd、containerd-shim、runC, 傻傻分不清楚这几个跟docker相关的进程到底扮演着什么角色.
CRI
在docker的最初版本, docker就是client+daemonset架构, 非常简洁
只不过到后来Kubernetes的兴起, 容器厂商的技术对战也变得非常激烈, 再到后来Kubernetes取得完全的胜利, 再到后来几家大佬公司一起制定了CRI(container runtime interface), docker为了适配才成了今天所看到的架构
关于容器时代几家大佬公司之间的竞争, 有兴趣的可以看下这篇文章.
CRI在Kubernetes的架构中也是个很重要的部分, 至于为何需要这个, 不再这里详细, 今天只学一学docker(这里说的docker会存在歧义)做为CRI
先来看看CRI在Kubernetes的位置
Kubernetes中的docker那层的架构分为以下几层:
而ContainerRuntime(docker)的结构如下
Client
最上面那一层是个client，就是我们经常使用的docker ps等命令行的时候, 相当于我们做为client去请求docker的服务端, 那必须存在一个daemonset的进程一直来监听主机上发出的命令
dockerEngine
这个其实就相当于是docker daemon, 负责监听主机上docker相关的命令,将相关命令发送给containerd.
containerd
先看下官方的说明:
containerd is available as a daemon for Linux and Windows. It manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond.
翻译一下: containerd在linux跟windows是一个守护进程我, 通过它管理容器的生命周期, 从图像传输和存储到容器执行和监督，再到低级存储再到网络附件等等
containerd 向上为 Docker Daemon 提供了 gRPC 接口，使得 Docker Daemon 屏蔽下面的结构变化，确保原有接口向下兼容。向下通过 containerd-shim 结合 runC，使得引擎可以独立升级，避免之前 Docker Daemon 升级会导致所有容器不可用的问题
其实 containerd 就包含了我们常用的 docker 的命令， 所以可以通过Client不经过docker daemon直接与containerd进行通信
containerd-shim
containerd 通过 shim 调用 runc 的包函数来启动容器， 也就是说containerd通过shim操作runc，runc真正控制容器生命周期
启动一个容器就会启动一个shim进程，因此会在Node上看到大量的shim进程
引入shim, 主要有以下几点考虑.
- 允许runc在创建&运行容器之后退出
- 用shim作为容器的父进程，而不是直接用containerd作为容器的父进程，是为了防止这种情况：当containerd挂掉的时候，shim还在，因此可以保证容器打开的文件描述符不会被关掉
- 依靠shim来收集&报告容器的退出状态，这样就不需要containerd来wait子进程
runC
runc是OCI(Open Container Initiative, 开放容器标准)的一个参考实现. 于是, containerd-shim 在这一步需要调用 runc 这个命令行工具, 来启动容器;
runc 启动完容器后本身会直接退出, containerd-shim 则会成为容器进程的父进程, 负责收集容器进程的状态, 上报给 containerd, 并在容器中 pid 为 1 的进程退出后接管容器中的子进程进行清理, 确保不会出现僵尸进程
平时也不怎么去关注docker， 都不知道一个docker居然涉及到这么多的东西
不过由于containerd的发展, 现在已经完全有能力跟client直接交互,
相信不久以后,containerd很可能马上就会替代docker，成为Kubernetes首选的容器运行时, 这样架构上相对简洁一点.
