容器技术发扬光大

都知道 Docker 开启了容器时代，但是 Docker 的使用的 namespace、cgroups 并不是啥新鲜技术，这两项东西在 Linux 内核里面早已准备好了。话虽如此，容器技术在当时并不流行，和人们想象中的 PAAS 还有差距。

那 Docker 的创新点在哪？UnionFS，这是 Docker 相较于当时其他容器化技术创新的一点，搞定了容器运行时的环境问题，rootfs 可以为程序提供一个类似于宿主机的文件环境，UnionFS 方便了容器的构建、分发，使用。要知道在当时早已有基于 namespace 和 cgroups 的 LXC 容器化技术，但和其他容器化技术一样，早已不温不火了。

容器编排花落谁家

Docker 虽然把容器化技术发扬光大，让 PAAS 平台都接纳了 Docker 这个容器运行时，但当时 Docker 是没有官方的编排系统的，而且 当时 Docker 很多东西都是闭源的，没有提供 API 可用于编排系统开发，导致社区也无法去提供相关方案，在当时， PAAS 厂商只能自行实现自己的方案，Docker Compose 都是后来自救的产物。

恰逢此时，Google 发现了 Docker 在容器编排领域的劣势，基于 Google 自己的编排系统 Borg，吸收其精华开发了现在大名鼎鼎的 Kubernetes（k8s）。相较于 Docker 的闭源，k8s 在一开始就取得了开发者的青睐，在良好的社区领导下，开源社区的力量让 k8s 的发展速度非常之快，也是 CNCF 第一个毕业项目。当然 Docker 此时也没坐以待毙，开发了适用于单机编排的 Compose，集群编排的 Swarm，当然，从结果就知道了，Swarm 并未掀起什么浪花。同期还有其他容器编排系统，比如 Mesos。Docker 为了自救还把自己的容器引擎独立了出来，也就是后来的 Containerd ，捐赠给了 CNCF。至此（Docker 赔了夫人又折兵，被榨干了），以后也就 Dockerhub 这个容器仓库、Compose这个单机编排工具耳熟能详了，至于 Swarm，基本没有市占率。群雄逐鹿，k8s 成为了最后的王者，企业容器编排的首选方案。

个人学习之路

小故事讲完了，我个人的集群学习之路反而不是从 k8s 开始的，而是 Docker Swarm。它开启了我对集群的认识，让我感受到原来跨主机编排（集群编排）的魅力，虽然引入了一堆新的问题，但是集群网络的互联互通是真的很舒服。一个节点的容器可以访问另一个节点的容器，而不是通过 gateway(apisix/nginx)等中间件来暴露两者来进行互联。Docker Swarm 操作也简单，Docker 软件套件自带，非常适合入门学习集群相关的理念，作为跳板上手 k8s。

现在的 k8s 调用链，kubelet -> containerd -> containerd-runc-shim -> runc

曾经的 k8s 调用链，kubelet -> docker-shim -> docker -> containerd -> containerd-runc-shim -> runc

runc 也是最底层的容器运行时，负责最基础的运行时功能，可以看到在这里面有两个 shim（垫片），其实就是个中间件，用来翻译 API 调用，也保证了底层组件对上层是透明的。

可以看到在 Containerd 成熟之后，k8s 果断抛弃了 Docker。一部分是竞争，一部分是维护起来太费力了，Docker 发版的话，kubelet 为了兼容，必须跟着强制发版，而且 Docker 自己也是调用 Containerd，那为啥不直接用 Containerd 呢？还减少一层调用。