首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

K8S弃用Docker了?Docker 不能用了?别逗了!

Docker 大概没想到,2020 年,它在技术圈内的两次成为(舆论的)焦点,竟然都是因为信息差(说是“标题党”也不为过)。

近几年,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 则可以把不同机器的每份容器进行编排、调度,组成分布式系统。

2013 年

Docker 是在 2013 年的 PyCon 上首次正式对外公布的。它带来了一种先进的软件交付方式,即,通过容器镜像进行软件的交付。工程师们只需要简单的 docker build 命令即可制作出自己的镜像,并通过 docker push 将其发布至 DockerHub 上。通过简单的 docker run命令即可快速的使用指定镜像启动自己的服务。

通过这种办法,可以有效的解决软件运行时环境差异带来的问题,达到其 Build once, Run anywhere 的目标。

从此 Docker 也基本成为了容器的代名词,并成为容器时代的引领者。

2014 年

2014 年 Google 推出 Kubernetes 用于解决大规模场景下 Docker 容器编排的问题。

这是一个逻辑选择,在当时 Docker 是最流行也是唯一的运行时。Kubernetes 通过对 Docker 容器运行时的支持,迎来了大量的用户。

同时,Google 及 Kubernetes 社区与 Docker 也在进行着密切的合作,在其官方博客上有如下内容:

We’ll continue to build out the feature set, while collaborating with the Docker community to incorporate the best ideas from Kubernetes into Docker.

An update on container support on Google Cloud Platform[1]

Kubernetes is an open source manager for Docker containers, based on Google’s years of experience using containers at Internet scale. Docker is delivering the full container stack that Kubernetes schedules into, and is looking to move critical capabilities upstream and align the Kubernetes framework with Libswarm.

Welcome Microsoft, RedHat, IBM, Docker and more to the Kubernetes community[2]

并在同一个月的 DockerCon 上发布演讲,介绍了 Kubernetes 并受到了广泛的关注。

此时 Docker Inc. 也发布了其容器编排工具, libswarm (也就是后来的 swarmkit) 。

2015 年

2015 年 OCI (Open Container Initiative)由 Docker 和其他容器行业领导者共同成立(它也是 Linux 基金会旗下项目)

OCI 主要包含两个规范:

运行时规范(runtime-spec):容器运行时,如何运行指定的 文件系统上的包

容器镜像规范(image-spec):如何创建一个 OCI 运行时可运行的文件系统上的包

Docker 把它自己的容器镜像格式和 runtime (?现在的 runc ) 都捐给了 OCI 作为初始工作。

2016 年

2016 年 6 月,Docker v1.12 发布,带来了 Docker 在多主机多容器的编排解决方案,Docker Swarm 。?这里也需要注意的是,Docker v1.12 的设计原则:

Simple Yet Powerful (简单而强大)

Resilient(弹性)

Secure(安全)

Optional Features and Backward Compatibility(可选功能及向后兼容)

所以你可以通过配置自行选择是否需要使用 Docker Swarm ,而无需担心有什么副作用。

2016 年 12 月, Kubernetes 发布 CRI (Container Runtime Interface)?,这当中一部分原因是由于 Kubernetes 尝试支持另一个由 CoreOS 领导的容器运行时项目 rkt ,但是需要写很多兼容的代码之类的,为了避免后续兼容其他运行时带来的维护工作,所以发布了统一的 CRI 接口,凡是支持 CRI 的运行时,皆可直接作为 Kubernetes 的底层运行时;

当然, Kubernetes 也是在 2016 年逐步取得那场容器编排战争的胜利的。

2017 年

2017 年, Docker 将自身从 v1.11 起开始引入的容器运行时 containerd[3]?捐给了?CNCF[4]

2017 年,Docker 的网络组件 libnetwork 增加了 CNI 的支持;同时通过使用 Docker 为 Docker Swarm 提供的 ipvs 相关的代码[5],也在 Kubernetes 中实现了基于 IPvs 的 service 负载均衡。不过在 v1.18 中开始移除了相关的依赖。

同年 11 月,Kubernetes 中新增了 containerd 的支持[6]

cri-containerd

2018 年

2018 年,?Kubernetes 的 containerd 集成,正式 GA[7]

containerd 1.0 cri-containerd

containerd 1.1 cri-containerd

2019 年

2019 年,上文中提到的另一个容器运行时项目 rkt 被 CNCF 归档,终止使命了;2019 年 Mirantis 收购 Docker 的企业服务。

2020 年

时间回到今年,Docker 主要被误会的两件事:

Docker Inc. 修改 DockerHub 的定价和 TOS 。国内争论较多的主要是关于合规性的问题(但是被标题党带歪了,免不了恐慌);

Kubernetes 宣布开始进入废弃 dockershim 支持的倒计时,被人误以为 Docker 不能再用了;

一切都如此悄悄地开始。作为广受欢迎的容器集群管理工具,在即将发行的Kubernetes 1.20版本说明文件中,Kubernetes(k8s)宣布:"kubelet放弃对Docker的支持,并会在将来的版本中移除。"

是的,实现了对Docker兼容支持其kubelet容器运行时Container Runtime Interface(CRI)标准的dockershim中间件将很快成为历史。所以呢?这没什么大不了的。

谷歌云开发人员助理及著名的Kubernetes导师凯尔西·海托华(Kelsey Hightower)在推特上说:"Docker不等于容器。Docker可以构建容器映像,Docker可以从容器仓库中push和pull,Docker是容器运行时其中一员,Docker可以创建容器进程,但Linux仍然是老大。"

正如著名的"不必恐慌:Kubernetes和Docker"博客文章中所解释的那样,Kubernetes只是在v1.20版本后不推荐将Docker作为容器运行时使用。人们仍然可以使用Docker构建容器,继续在仓库中进行push和pull操作等。实际上是因为Docker并不符合Kubernetes的容器运行时接口标准(CRI)而不被推荐使用,Docker生成的镜像依然可以一如既往地在集群中工作。

简而言之,这就是我们想说的,这没什么大不了的,不必恐慌。

就像Dockershim Deprecation FAQ所说:"在1.20中唯一改变的是,如果使用Docker作为容器运行时,则在kubelet启动时会打印一条警告信息。"

Dockershim中间件会一直保留到2021年末,直到发布Kubernetes 1.23版本为止。Kubernetes团队将与所有人紧密合作,直到所有人都准备好了相关变更,才会将dockershim放飞牧场。

总结

本文主要介绍了 Docker 和 Kubernetes 的发展历程,也解释了本次 Kubernetes 仅仅是放弃其对 dockershim 组件的支持。未来更推荐的 Kubernetes 运行时是 兼容 CRI 的 containerd 之类的底层运行时。

Mirantis 公司将会和 Docker 共同维护 dockershim 并作为开源组件提供。

Docker 仍然是一款最佳的本地开发测试和部署的工具。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20201214A0I2CO00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券
http://www.vxiaotou.com