K8s 终将废弃 docker，TKE 早已支持 containerd

近日 K8s 官方称最早将在 1.23版本弃用 docker 作为容器运行时，并在博客中强调可以使用如 containerd 等 CRI 运行时来代替 docker。本文会做详细解读，并介绍 docker 与 containerd 的关系，以及为什么 containerd 是更好的选择。这里先回答下TKE用户关心的问题：我们的集群该怎么办？

TKE集群该怎么办

• TKE早在 2019年5月就已经支持选择 containerd 作为容器运行时。如果新建集群，推荐选择 containerd 作为容器运行时
• 已有集群在升级到 K8s 1.23（假定 TKE 第一个不支持 dockershim 的 K8s版本，也可能是 1.24）之前，仍然可以继续使用 docker 作为容器运行时
• 已有集群通过 TKE 集群升级功能升级到 1.23时， TKE会提供切换运行时为 containerd 的选项。当然，这种情况下没办法做到 Pod 不受影响，只能采用重装节点的方式来升级
• 已有集群也可以将运行时切换为 containerd ，新增节点会使用 containerd ， 存量节点不受影响仍然使用 docker （注意： 这会造成同一集群中 docker 节点与 containerd 节点共存，如果有使用 Docker in Docker， 或者其他依赖节点上 docker daemon 与 docker.sock 的业务，需要提前采取措施来避免产生问题，例如通过按节点标签调度，保证这类业务调度到 docker 节点；或者采用如前文所述在 containerd 集群运行 Docker in Docker 的方案）
• 当然，在未来 docker 也有可能在内部实现 CRI 或者添加一个 dockershim 进程，如果 docker 做了相应适配，TKE 这边在未来也会进行支持。

解读 K8s 弃用 dockershim

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called “dockershim” which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]

K8s 在 1.20的 change log 中提到 K8s 将于 1.20版本开始逐步放弃对 Docker 的支持。在 K8s 的官方博客中也提到具体的声明和一些 FAQ。

• Don’t Panic: Kubernetes and Docker
• Dockershim FAQ

在博客中提到 K8s 将在 1.20版本中添加不推荐使用 docker 的信息，且最早将于 1.23版本中把 dockershim 从 kubelet 中移除，届时用户将无法使用 docker 作为 K8s 集群的运行时，不过通过 docker 构建的镜像在没有 docker 的 K8s 集群中依然可以使用。

“寄生”在 kubelet 中的 dockershim

本次改动主要内容是准备删除 kubelet 中的 dockershim，当然这种做法也是符合预期的。在早期 rkt 和 docker 争霸时，kubelet 中需要维护两坨代码分别来适配 docker 和 rkt ，这使得 kubelet 每次发布新功能都需要考虑对运行时组件的适配问题，严重拖慢了新版本发布速度。另外虚拟化已经是一个普遍的需求，如果出现了类型的运行时，SIG-Node 小组可能还需要把和新运行时适配的代码添加到 kubelet 中。这种做法并不是长久之计，于是在 2016 年，SIG-Node提出了容器操作接口 CRI（Container Runtime Interface）。 CRI 是对容器操作的一组抽象，只要每种容器运行时都实现这组接口，kubelet 就能通过这组接口来适配所有的运行时。但 Docker 当时并没有（也不打算）实现这组接口， kubelet 只能在内部维护一个称之为“dockershim”组件，这个组件充当了 docker 的 CRI 转接器，kubelet 在创建容器时通过 CRI 接口调用 dockershim ，而 dockershim 在通过 http 请求把请求交给 docker 。于是 kubelet 的架构变成下图这样：

在使用实现了 CRI 接口的组件作为容器运行时的情况下，kubelet 创建容器的调用链如图中红色箭头所示，kubelet 中的 ContainerManager 可以直接通过 CRI 调用到容器运行时，这过程中只需要一次 grpc 请求；而在使用 docker 时，ContainerManager 会走图中蓝色的调用链， CRI 的请求通过 unix:///var/run/dockershim.sock 流向 dockershim，dockershim 做转换后把请求转发给 docker，至于为什么 docker 后面还有个 containerd 稍后会讲到。在 kubelet 中实现 docker 的转接器本来就是一种不优雅的实现，这种做法让调用链变长且不稳定性，还给 kubelet 的维护添加了额外工作，把这部分内容从 kubelet 删掉就是时间问题了。

弃用 Docker 后会有什么不同？

If you’re an end-user of Kubernetes, not a whole lot will be changing for you. This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or shouldn’t, use Docker as a development tool anymore. Docker is still a useful tool for building containers, and the images that result from running docker build can still run in your Kubernetes cluster.

消息一出，大家最关心的事情应该就是弃用 docker 后到底会产生什么影响？

官方的答复是：Don’t Panic！随后又重点解释了几个大家最关心的问题，我们来分析下官方提到的