Kubernetes并没有 "杀死 "Docker!

Dec 8, 2020- 3 min read

最近，互联网上到处都是关于Kubernetes将Docker从其平台上剔除的最后一招的恐慌。

像 "一个Docker的终结"、"Kubernetes杀死了Docker "这样闪亮的标题，以及无限量的点击诱饵，散布在讨论这个问题的网络上。

事实是，这些说法并不那么夸张，当然也不准确。

在这篇短文中，我将省去那些不必要的超级术语和过多的数据，而只是向你解释Docker和Kubernetes在不久的将来会发生什么。

剧透一下-- 没那么多；)

Docker的定义

Docker是一套 "平台即服务 "的产品，它使用操作系统级的虚拟化来提供被称为容器的软件包--wikipeida

我最喜欢用一句话向我的客户和学生解释Docker：
"总的来说，Docker是一个非常舒适的容器包装器。"

关于这个话题的大部分困惑源于对Docker作为一个产品的功能缺乏了解。

总的来说，Docker作为一个产品主要实现了三个功能。

- 镜像的开发环境

- 容器的用户体验管理界面

- 容器的运行时间环境

Kubernetes本质上是一个容器协调器，这意味着它的工作或称号主要是以冗余和高效的方式运行容器，因此Kubernetes最终从Docker那里 "需要 "的只是他的 "运行时环境 "功能。

因此，其他功能对Kubernetes生态系统造成了负担，并降低了其性能。
此外，Docker的运行环境与负责在Kubernetes中运行容器的组件不兼容，名为 CRI.
因此，一个名为Dockershim 的特殊接口抽象层被引入，并造成了以下问题：
兼容性问题、开发开销和性能低下。

因此，Kubernetes团队做出了一个公正但艰难的决定，从1.22版本开始，将Dockershim从Kubernetes的较新版本中移除。

对终端用户的影响几乎不存在，因为由Docker构建的镜像仍然可以正常工作，而由Kaniko、IMG和Buildah等其他工具构建的镜像也是如此。

对管理的Kubernetes服务的影响相当小，而且很容易在短时间内将节点升级到与不同的Runtime环境一起工作。
目前，大多数供应商正在努力为旧集群进行舒适的过渡。

例如，
在Google已经内置了这个功能
cloud.google.com/kubernetes-…

在AKS，"Containerd "已经被自动安装。

Kubernetes On-prem的影响更大，因为你需要为所有集群的服务器更换Runtime环境，使用新的容器运行时CRI 批准的组件，如。

- 容器的

- CRI-O

这个转换过程确实会比管理服务花费更多的时间（取决于你的集群的规模和复杂性），但仍然没有多复杂。

你没有什么可担心的!

2.在Kubernetes版本废弃Docker容器引擎之前，你还有一年多的时间，所以你有足够的时间为这个小变化做准备。

3.归根结底，这是Kubernetes生态系统中的一个小变化，它将带来更高的性能，并防止未来出现故障。

不要担心，一切都很好 :)

希望这对你有帮助。

Or Maman