技术交流

Kubernetes竟弃用Docker?
北大青鸟总部

摘要:Kubernetes竟弃用Docker?

还没好好的感受,Kubernetes与Docker一起使用的时候,Kubernetes已经弃用Docker了。有时候,我们都要相信,没有什么会永垂不朽,即使是当年一起紧密使用的Kubernetes和Docker,也最终是分道扬镳了。那么Docker为什么需要Kubernetes?在Kubernetes中又是如何使用Docker?为何最后Kubernetes又会废弃Docker呢?如果我们想Kubernetes与Docker一起使用应该怎么办?我们一起来看看~
在介绍Docker为什么需要Kubernetes之前,我们先来看看为什么我们需要Docker?在Docker容器技术出现之前,我们开发、测试、发布服务需要多个环境,开发环境用于开发人员写代码、调试、自测,测试环境用于测试人员进行功能测试、性能测试,生产环境用于发布正式版本,给用户使用。在我们从开发到上线的过程中,都在和环境打交道,在装环境之前还得先申请资源,安装操作系统、数据库、应用程序,并修改配置文件链接起来,这个过程是非常繁琐的,每次修改内容都还得重新部署一次,如果换个机器,不好意思,那就还得再来一轮。

Docker的出现解放了这个过程。Docker将应用运行的一整套环境,包括操作系统、数据库、消息队列等全都封装成镜像,研发人员可以在封装的镜像上面继续封装业务模块,交付给测试和运维人员。测试开展测试工作时,只聚焦于业务就好,由于环境不同带来的问题已经不存在了。并且Docker容器之间是进程隔离的,在利用好服务器资源的同时,谁也不会影响到谁。这也是为什么阿里、头条、美团等互联网巨头都纷纷把基础设施容器化的原因。




在微服务架构的趋势下,服务拆分成了微服务模式,为了保障高可用,核心微服务按照分布式进行部署。以淘宝系统来说,包含上千个微服务,一个节点部署一个容器,再按照分布式集群部署,整个淘宝系统估计得上万个节点,逢年过节,节点数还在不断的增加,那就需要管理了呀,不然怎么保障节点之间的正常通信,问题快速解决呢?于是Kubernetes产生了,它提供应用级的集群抽象,把每个微服务抽象成service,以Pod运行,Pod底层是Docker,对外提供能力。

在Kubernetes中包含masternodeworknode两部分。MasterNode为控制节点,负责对集群资源进行调度,用户在KubeControllerManager中可以管控整个资源情况,比如执行资源的创建与释放;ApiServer类似Kubernetes的网关,对外接受客户端的调用命令,对内把调用请求传递给到对应的WorkNode。WorkNode是真正干活的,真正运行业务应用,通过kubectl接受ApiServer的命令,使用ContainerRuntime下载镜像和运行容器。




问题出现了,Kubernetes本身是不提供容器运行环境的,而是使用CRI(ContainerRuntimeInterface容器运行接口)在工作节点创建和删除容器,因为Docker不符合Kubernetes的容器运行时接口标准(CRI),所以官方必须要维护一个名为Dockershim的中间件才能够把Docker当作Kubernetes的容器运行时来使用。此外Kubernetes使用的是Docker容器中的Cgroup能力,其它的模块如网络、存储卷都不需要使用,然而它们却随Docker一起在Kubernetes中运行,这就容易产生安全隐患了。综上所述,这就是为什么Kubernetes要废弃Docker了




作为Kubernetes与Docker容器的用户,不必要惊慌,使用CRI运行时替代方案即可。CRI的实现方案有两种,分别是Containerd和CRI-O。Containerd是CNCF云原生计算基金会开源项目,在GitHub(https://github.com/containerd/containerd/)可直接下载使用,它是容器虚拟化技术,从Docker中剥离出来,形成开放容器接口(OCI)的一部分,容器引擎使用它可以进行整个容器生命周期管理(创建)、拉取/推送容器镜像、存储管理镜像、管理容器网络接口及网络。它生于Docker,可以完成所有的运行时工作,使用它是很好的选择。




与Containerd相比,CRI-O就不那么友好了,它是由红帽开发的纯CRI运行时,对于RedHatOpenshit支持的比较好,不支持Docker,因此从Docker迁移到CRI-O是比较麻烦的。

Kubernetes官方表示Docker作为一个完整的容器技术栈,在创建之初就不是为了Kubernetes而设计的。Kubernetes只是在v1.20版本后不推荐将Docker作为容器运行时使用,用户今后依然可以使用Docker来构建容器镜像,而Docker生成的镜像实际上也是一个OCI(OpenContainer Initiative)镜像。可以说无论使用什么工具来构建镜像,任何符合OCI标准的镜像在Kubernetes看来都是一样的。Containerd和CRI-O则可以提取这些镜像并运行它们。技术的升级一般来说都是好事,它始终是为了更好的服务才做改动。无论是开发人员、运维人员,我们都需要拥抱变化。

来源课工场

相关阅读
Kubernetes中如何部署一个应用?
热门推荐