腾讯云：K8s终将废弃docker，TKE早已支持containerd

小提示：您能找到这篇{腾讯云：K8s终将废弃docker，TKE早已支持containerd}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的腾讯云：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 CR银行微博危机公关I(v1alpha1 or v1 compliant)as they become available.(#94624[1],dims[2])[SIG Node]

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

< ">Don't Panic:Kubernetes and Docker[3]

< ">Dockershim FAQ[4]

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

“寄生”在kubelet中的dockershim

< ">本次改动主要内容是准备删除kubelet中的dockershtop大麻危机公关im，当然这种做法也是符合预期的。

< ">在早期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！随后又重点解释了几个大家最关心的问题，我们来分析下官方提到的这些方面：

< ">正常的K8s用户不会有任何影响

< ">是的，生产环境中高版本的集群只需要把运行时从docker切换到其他的runtime（如containerd）即可。containerd是docker中的一个底层组件，主要负责维护容器的生命周期，跟随docker经历了长期考验。同时2019年初就从CNCF毕业，可以单独作为容器运行时用在集群中。TKE也早在2019年就已经提供了containerd作为运行时选项，因此把runtime从docker转换到containerd是一个基本无痛的过程。CRI-O是另一个常被提及的运行时组件，由redhat提供，比containerd更加轻量级，不过和docker的区别较大，可能转换时会有一些不同之处。

< ">开发环境中通过docker build构建出来的镜像依然可以在集群中使用

< ">镜像一直是容器生态的一大优势，虽然人们总是把镜像称之为“docker镜像”，但镜像早就成为了一种规范了。具体规范可以参考image-spec[5]。在任何地方只要构建出符合Image Spec的镜像，就可以拿到其他符合Image Spec的容器运行时上运行。

< ">在Pod中使用DinD（Docker in Docker）的用户会受到影响

< ">有些使用者会把docker的socket(/r公关危机管理的主体un/docker.sock)挂载到Pod中，并在Pod中调用docker的api构建镜像或创建编译容器等，官方在这里的建议是使用Kaniko、Img或Buildah。我们可以通过把docker daemon作为DaemonSet或者给想要使用docker的Pod添加一个docker daemon的sidecar的方式在任意运行时中使用DinD的方案。TKE也专门为在containerd集群中使用DinD提供了方案，详见在containerd中使用DinD[6]。

containerd的今生前世

< ">所以containerd到底是个啥？和docker又是什么关系？可能有些同学看到博客后会发出这样的疑问，接下来就给同学们讲解下containerd和docker的渊源。

docker与containerd

< ">2016年，docker把负责容器生命周期的模块拆分出来，并将其捐赠给了社区，也就是现在的containerd。docker拆分后结构如下图所示（当然docker公司还在docker中添加了部分编排的代码）。

< ">在我们调用docker命令创建容器后，docker daemon会通过Image模块下载镜像并保存到Graph Driver模块中，之后通过client调用containerd创建并运行容器。我们在使用docker创建容器时可能需要使用--volume给容器添加持久化存储；还有可能通过--network连接我们用docker命令创建的几个容器，当然，这些功能是docker中的Storage模块和Networking模块提供给我们的。但K8s提供了更强的卷挂载能力和集群级别的网络能力，在集群中kubelet只会使用到docker提供的镜像下载和容器管理功能，而编排、网络、存储等功能都不会用到。下图中可以看出当前的模式下各模块的调用链，同时图中被红框标注出的几个模块就是kubelet创建Pod时所依赖的几个运行时的模块。

< ">containerd被捐赠给CNCF社区后，社区给其添加了镜像管理模块和CRI模块，这样containerd不只可以管理容器的生命周期，还可以直接作为K8s的运行时使用。于是containerd在2019年2月从CNCF社区毕业，正式进入生产环境。下图中能看出以containerd作为容器运行时，可以给kubelet带来创建Pod所需的全部功能，同时还得到了更纯粹的功能模块以及更短的调用链。

< ">从上面的对比可以看出从containerd被捐赠给社区开始，就一直以成为简单、稳定且可靠的容器运行时为目标；而docker则是希望能成为一个完整的产品。官方文档中也提到了这一点，docker为了给用户更好的交互和使用体验以及更多的功能，提供了很多开发人员所需要的特性，同时为了给swarm做基础，提供了网络和卷的功能。而这些功能其实都是是K8s用不上的；containerd则相反，仅提供了kubelet创建Pod所需要的基础功能，当然这换来的就是更高的鲁棒性以及更好的性能。在一定程度上讲，即使在kubelet 1.23版本之后docker提供了CRI接口，containerd仍然是更好的选择。

在Kubernetes集群中使用containerd

< ">当然现在有诸多的CRI实现者，比较主要的除了containerd还有CRI-O。CRI-O是主要由Red Hat员工开发的CRI运行时，完全和docker没有关系，因此从docker迁移过来可能会比较困难。无疑containerd才是docker被抛弃后的CRI运行时的最佳人选，对于开发同学来说整个迁移过程应该是无感知的，不过对于部分运维同学可能会比较在意部署和运行中细节上的差异。接下来我们重点介绍下在K8s中使用containerd和docker的几处区别。

< ">容器日志对比项

< ">

< ">cni配置方式的区别在使用docker时，kubelet中的dockershim负责调用cni插件，而containerd的场景中containerd中内置的containerd-cri插件负责调用cni，因此关于cni的配置文件需要放在containerd的配置文件中（/etc/containerd/containerd.toml）：

 [plugins.cri.cni]

      bin_dir = "/opt/cni/bin"

      conf_dir = "/etc/cni/net.d"

< ">stream服务的区别

说明：

Kubectl exec/logs等命令需要在apiserver跟容器运行时之间建立流转发通道。

< ">如何在containerd中使用并配置Stream服务？

< ">Docker API本身提供stream服务，kubelet内部的docker-shim会通过docker API做流转发。而containerd的stream服务需要单独配置：

[plugins.cri]

stream_server_address="127.0.0.1"

stream_server_port="0"

enable_tls_streaming=false[plugins.cri]stream_server_address="127.0.0.1"stream_server_port="0"enable_tls_streaming=false

K8s 1.11前后版本配置区别是什么？

< ">containerd的stream服务在K8s不同版本运行时场景下配置不同。

< ">在K8s 1.11之前：kubelet不会做stream proxy，只会做重定向。即kubelet会将containerd暴露的stream server地址发送给apiserver，并让apiserver直接访问containerd的stream服务。此时，您需要给stream服务转发器认证，用于安全防护。

< ">在K8s 1.11之后：K8s1.11引入了kubelet stream proxy[7]，使containerd stream服务只需要监听本地地址即可。

在TKE集群中使用containerd

< ">从2019年5月份开始，TKE就开始支持把containerd作为容器运行时选项之一。随着TKE逐步在containerd集群中支持日志收集服务和GPU能力，2020年9月份containerd在TKE也摘掉了Beta版本的标签，可以正式用于生产环境中了。在长期使用中，我们也发现了一些containerd的问题并且及时进行了修复，如：

< ">由于错误处理问题导致的Pod Terminating

< ">由于内核版本问题导致镜像文件丢失

< ">想要在TKE集群中使用containerd作为运行时有三种方式：

< ">1.在创建集群时，选择1.12.4及以上版本的K8s后，选择containerd为运行时组件即可

< ">2.在已有docker集群中，通过创建运行时为containerd的节点池来创建一部分containerd节点（新建节点池>更多设置>运行时组件）

< ">3.在已有docker集群中，修改集群或者节点池的"运行时组件"属性为"containerd"

< ">注意：后两种方式会造成同一集群中docker节点与containerd节点共存，如果有使用Docker in Docker，或者其他依赖节点上docker daemon与docker.sock的业务，需要提前采取措施来避免产生问题，例如通过按节点标签调度，保证这类业务调度到docker节点；或者采用如前文所述在containerd集群运行Docker in Docker的方案。

< ">现阶段关于containerd和docker选择问题可以查看文档如何选择Containerd和Docker[8]。

参考资料

[1]#94624:https://github.com/kubernetes/kubernetes/pull/94624

[2]dims:https://github.com/dims

[3]Don't Panic:Kubernetes and Docker:https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

[4]Dockershim FAQ:https://kubernetes.io/blog/2020/12/02/dockershim-faq/

[5]image-spec:https://github.com/opencontainers/image-spec

[6]在containerd中使用DinD:https://tencentcloudcontainerteam.github.io/2020/12/08/dind-in-containerd/

[7]kubelet stream proxy:https://github.com/kubernetes/kubernetes/pull/64006

[8]如何选择Containerd和Docker:https://cloud.tencent.com/document/product/457/35747

[9]Dockershim Removal Kubernetes Enhancement Proposal:https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim

[10]kubernetes CHANGELOG-1.20:https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation