Kubernetes决定弃用Docker，到底会影响到谁？.docxVIP

Kubernetes打算弃用Docker，到底会影响到谁？ 杨明越 2021-12-22 近几年，Kubernetes 已经成为自有机房、云上广泛使用的容器编排方案，最广泛的使用方式是 Kubernetes+Docker。从 DevOps 人员的角度，一面用 kubctl 命令、k8s API 来操作集群，一面在单机用 Docker 命令来管理镜像、运转镜像。 单独用 Docker 的情况，在一些公司的场景里面也是有的。一种场景是“只分不合”，把一台机器用 Docker 做资源隔离，但是不需要将多容器“编排”。单独用 Kubernetes，下层不是 Docker 的情况，并不算很多。 Kubernetes 和 Docker 的关系，简约来说，有互补，也有竞争。在一般的认知中，Kubernetes 和 Docker 是互补关系： · Dockers属于下层——容器引擎； · Kubernetes属于上层——编排调度层。 Docker 源于 Linux Container，可以将一台机器的资源分成 N 份容器，做到资源的隔离，并将可运转的程序定义为标准的 docker image；Kubernetes 则可以把不同机器的每份容器进行编排、调度，组成分布式系统。 Kubernetes 和 Docker 并不完全是“泾渭分明”的互补关系，它之间有堆叠部分，也可以说成是竞争，次要在于几个点： 系统三大移植资源是计算、存储、网络，从Kubernetes角度Docker属于“Runtime（运转时）”，也就是计算资源；但是Docker技术体系里面，本身也包括存储层、网络层。上下层职责的堆叠，也可以看作竞争。 Docker本来有个原生的调度引擎——Swarm，几年前在调度编排领域，还是Kubernetes、Mesos、Swarm三者并存，Kubernetes最终胜出，但Docker仍有“连续向上做一层的意愿”。 Kubernetes 在如何使用 Docker 方面，存在争议和变数。kubernetes 1.20 ChangeLog 中所谓要废弃 Docker 的传言，也是无风不起浪。换句话说，即便 Kubernetes 一直用 Docker，也不是用 Docker 的全部，多少是不一样的。 而且，“弃用 Docker”这个词本身有多重的含义，Docker 并非一个单层软件，Kubernetes 1.20 启用 dockershim 并不代表弃用了 Docker 的全部，仍有 containerd 可以对接 docker。 Kubernetes 有 CRI、OCI 两个容器标准 在目前广泛使用 kubernetes 与 Runtime 的桥接方案，CRI（Container Runtime Interface）与 OCI（Open Container Initiative）是“套娃“关系。Kubernetes 的 kubelet 调用 CRI，OCI 的实现者然后再调用 OCI。 下图也说明白 CRI 与 OCI 的关系： 从 Kubernetes 的角度，CRI 是与 CNI（网络）、CSI（存储）相同层级的接口。 OCI 是个自下而上的标准，也就是从实现笼统出接口，它是 Linux Foundation 主导的。Docker 实现的核心 RunC，也就是 OCI 的典型实现、标准实现。 CRI 是个自上而下的标准，源于 Kubernetes 对移植层（运转时）的要求。 容器引擎层自下而上定义 OCI，容器编排层自上而下定义 CRI，这也让它们消灭了“套娃“运转情况。 在 Kubernetes 的 dockershim、cri-containerd、cri-o 三种实现中，RedHat 推崇的 cri-o 已经比较主流，它虽然仍是“套娃“，但已经比较精简。 下面是从 kubernetes 集群运转的全景图看 cri-o 的位置： Docker 本源于 Linux Container Docker 作为容器引擎，其实现的基础是 Linux Container——从内核到用户空间的机制。 Linux Container 可以分成两个部分，内核里面的 cgroup，用户空间的 lxc。Docker 最后实现的时候，也是完全基于 Linux Container 的，基于 lxc 做更上层的东西。 这张很多人认为“与现实不符“的图，其实代表了过去： 在 Docker 的进展过程中，最终启用了 C 言语写成 lxc，换成了 go 言语写成的 libcontainer。 下面的图也不是很新，但它更能表示 Docker 后续典型的架构，这里面已经没有了 lxc。 然而，万变不离其宗，Docker 实现的本源，还是 Linux Container