Kubernetes弃用Docker运行时,小甜甜变牛夫人影响了谁?

由于Kubernetes已成为当前云原生基础设施的事实标准,Kubernetes在1.20版本后弃用Docker作为容器运行时引发了开发人员的关注。针对此事,网易数帆资深架构师、网易轻舟容器编排技术负责人王新勇给出了自己的见解。他认为,Kubernetes移除dockershim的代码确实有其合理之处,同时此事对绝大多数开发者没有多大的影响。
  • 从Kubernetes运行时提供统一的接口抽象这个角度来说,移除dockershim的代码确实有其合理之处,毕竟之前dockershim是由于历史原因,属于特例的。
  • Kubernetes编排是事实标准,容器的镜像格式遵守OCI,所有之前的交付的构件,无论容器运行时怎样变化,都不会有影响。
  • 容器平台提供商需要做一些适配、整合、测试等,需要提供kubernetes支持的容器运行时。也可以通过额外维护和引入一个新的不属于kubernetes项目的“dockershim”中间层来继续支持docker作为运行时。不过无论怎么做,绝大部分开发人员都是感知不到的。

插播:12月16-17日,2020 Cloud Native Day,网易PingCAP阿里VMware大咖云集,详见文末,欢迎报名

Kubernetes和Docker的关系

  • Docker最初只是一个容器引擎,应该是很多人进入容器领域时最早接触的东西,Docker为普及Linux的容器技术做出了很大的贡献(虽然Linux容器上,LXC更早,而且早期版本的Docker就是基于LXC实现的,但是Docker的最大创新就是提出了镜像的概念)。

  • 在2015年,我们探索容器技术做蜂巢产品的时候,那时候很多人的理解里面,容器基本就是Docker,Docker就是容器。直到现在应该好多开发者还是这个认知。

  • Kubernetes是做容器编排的,本身跟最初Docker解决的问题领域是不冲突的,而且很多人都是从Docker入手才开始接触Kubernetes的。不过后来Docker也想做容器编排的事情,推出了Docker Swarm,Docker Swarm跟Kubernetes就构成了竞争的关系了。Docker从此以后就不仅仅是运行时了,而是一整套容器技术栈了。现在Docker公司又推出了企业服务Mirantis Kubernetes Engine,同时支持了Kubernetes和Swarm两种编排技术。

  • 总结来看: 1. Docker作为一定意义上早期容器技术的代名词,对于Linux容器,对于kubernetes的普及都起到了重要的作用,如果仅仅把docker当作一个容器运行时、镜像构建管理、本地开发测试容器工具套件的使用功能上来说(而且实际上,绝大部分开发者目前也就是这么干的),跟kubernetes做编排在功能上是相辅相成的,Docker负责制作相关的软件构建并将其运行起来,Kubernetes用来控制如何运行这些容器。 2. 如果说有竞争关系,其实随着Docker自己的编排引擎Swarm的影响力越来越弱,已经基本上丧失了竞争能力了。但是Docker公司推出的企业服务Mirantis Kubernetetes Engine确实是会跟Google的一些服务形成竞争关系。

Kubernetes和Docker的场景与用户

  • kubernetes是一个大而全的容器编排引擎,不仅仅是运行容器,还有存储、网络,还提供了配置管理、服务发现等功能,而且还提供了非常灵活的扩展性。

  • 而且现在基于Kubernetes,已经构成了一整套生态,各种基于Kubernetes的解决方案很多,像微服务、Operator化的中间件服务,service mesh,serverless等,这些技术的引入可以达到提高运维自动化能力,提升开发效率等。因此,如果业务规模足够大,对于这些功能的需求比较迫切,是应该考虑使用Kubernetes的。例如网易数帆构建云OS支撑集团多元化业务,解决集群生命周期自动化管理、简化运行时环境运维、提升资源利用率等问题,Kubernetes因其对云基础设施抽象、融合及生态的优势,成为我们的首选技术。

  • 当然,强大的功能,灵活的可定制性自然而然就带来了使用上的复杂性,概念很多,配置参数很多,运维复杂。因此使用kubernetes相比较来说比较重,一般DIY一个kubernetes集群会比较复杂。所以大家实际在使用Kubernetes的时候,一般不会自己去DIY Kubernetes。公有云上一般都是会去买托管的K8S服务,像GKE,EKS这种,对于on-premise情况下,在自己的IDC中,一般都会去购买像轻舟容器云这样的成熟的容器服务,这类服务提供了比较友好的使用方式,而且又将运维部署的复杂性对客户进行了屏蔽,可以让客户更好的使用Kubernetes。

  • 如果用户的业务部署比较简单,规模也较小,仅仅是为了使用容器做应用交付的便利,也没有其他的功能需求的话,仅仅通过docker run/docker-compose这种方式也能管得好的话,实际上是没必要非得引入Kubernetes这样非常重的编排组件的。反而直接仅仅使用docker会更轻量,也更好运维。比如toB的软件交付的情况,如果要部署的软件的部署架构比较简单的话,仅仅涉及少量几台机器,服务进程也不多的情况下,也有不少是直接使用docker,而不引入Kubernetes的,比较轻量、简单。(当然我这里没有专门提Docker Swarm,因为实际上我们使用Docker Swarm几乎没有,也不太有啥场景非Docker Swarm不可的,除非是早期遗留)

  • 还有一个就是,使用kubernetes做编排引擎的情况下,实际开发者在日常的开发中,也会比较多地使用Docker。

影响到哪些开发者和企业

  • 对于一般的应用开发者来说,他们一般不会直接去面对Kubernetes的,因此,对于他们来说,可能压根就是无感知的 ,应用开发者甚至都不用知道他们的业务是用容器运行的。以轻舟容器云产品为例,我们提供了自动从代码编译构建,到运行上线的一条龙服务。应用开发者可以完全不知道容器,仅仅写好代码、提交代码,剩下的工作就交给轻舟容器云平台来进行了,容器云平台会按照预先定义的动作模板,完成接下来的所有工作。

  • 对于整个基于Kubernetes生态的各个解决方案提供商来说,由于当前基于Kubernetes的编排是事实标准,容器的镜像格式又是都遵守OCI的,因此可以说所有的之前的交付的构件,无论容器运行时怎样变化,实际上都不会有啥影响。

  • 对于容器平台提供商来说,可能需要一些适配和准备动作。就拿轻舟容器平台来说,我们是有比较好的准备的,实际上Kubernetes弃用docker从很早就开始讨论了,我们也一直有关注相关的信息。很早我们就开始关注和使用Containerd作为我们的容器运行时的一个选项了,目前也在网易内部的部分服务中进行了比较长时间的运行,后续也会在轻舟容器云平台中,提供相关的运行时多个选项 ,并逐步过渡到使用containerd作为运行时。

  • 当然,即使按照当前的计划,到kubernetes v1.22版本,从kubernetes中删除了dockershim的支持,我们还可以通过将dockershim从kubernetes中抠出来,独立运行,作为kubernetes的cri到docker api的适配器,实现kubernetes继续支持docker,从而保持之前的使用习惯。

迁移到containerd、CRI-O复杂度如何

参见上个问题,不同的开发人员感知上可能是不一样的。

对于一般应用开发,可能自己从来都不会去写一个Dockerfile,那么对于他们来说是没有复杂度的。

对于之前可能需要跟Docker打交道的,往往也就是在开发调试阶段打交道,主要就是制作容器镜像和本地调试的。这种情况也是不需要进行迁移的,因为使用Docker制作的镜像,在其他运行时下同样能够正常跑。所有的工作流程都可以保持不变,没有迁移复杂度。

对于容器平台提供商来说,需要做的动作会大一点,需要做一些适配、整合、测试等,需要提供kubernetes支持的容器运行时。当然也可以通过额外维护和引入一个新的不属于kubernetes项目的“dockershim”中间层来继续支持docker作为运行时。不过无论怎么做,这个也是绝大部分开发人员都感知不到的。

当然,如果开发人员有兴趣的话,去学习一下crictl的操作也是可以的。有了使用docker的基础,上手还是很快的。

主要目的分析

docker的API比较早,跟CRI不兼容,因此kubernetes中实现了docker到CRI的适配层dockershim。根据KEP,CRI已经是容器运行时标准接口了,而docker作为容器运行时也不应该享受特权。同时去除掉dockershim支持,还能实现kubernetes与docker的解耦,减少kubernetes社区的负担,也能够使得kubernetes的运行时支持上可以有更好的演进和发展。

其实类似的事情,之前在kubernetes中已经发生过,那就是把很多厂商的in-tree的Volume相关的代码移除,而改为统一的基于CSI的实现,而kubernetes就专注于CSI就行了,不用再跟很多厂商的代码耦合了。

从kubernetes运行时提供统一的接口抽象这个角度来说,移除dockershim的代码确实有其合理之处,毕竟之前dockershim是由于历史原因,属于特例的。但是毕竟Docker是容器技术的“前辈”,昨天还是“小甜甜”,今天就成“牛夫人”了,还是有点唏嘘的。

Docker会逐渐消亡吗

还是将docker项目和docker公司分开来看吧。

docker项目的未来,我认为不会消亡,会使用docker命令可能会成为一个开发人员的必备技能,毕竟技术的惯性是很强大的,太多的开发人员直到现在可能还是认为容器就是docker,docker就是容器,日常开发过程中,docker命令有比较好用,用得又比较熟,没有必要换。

docker公司的处境和未来,我自己不懂公司经营,没法给出分析。不过就算docker公司处境不乐观,还是有强大的开源社区的,应该是不影响 docker项目的。

对云原生技术的影响

可能只是一个小插曲。


云原生技术分享预告

2020年12月16-17日,来自CNCF、VMware、PingCAP、网易数帆、阿里云等17位重磅演讲嘉宾,带来2天主题分享,立体化解析云原生前沿技术与实践。活动详情如图,名额有限,欢迎点击这里,或识别下图二维码报名。

Kubernetes弃用Docker运行时,小甜甜变牛夫人影响了谁?_第1张图片

 

你可能感兴趣的:(云原生,kubernetes,docker,云原生)