Kubernetes 团队近日宣布将在最新版本中弃用 Docker 支持的功能，后续版本会陆续删除这些功能。

近日，Kubernetes 团队发布了最新的 1.20 版本，新版本更新了许多内容：

存储卷快照功能趋于稳定；Kubectl Debug 进入 Beta；Beta：API 优先级和公平性；IPV4/IPV6 Alpha 功能更新；GA：限制进程 PID；Dockershim 弃用；Exec 探针超时处理等等（详情可查看：https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/ ）

其 中，有一项更新对于开发者社区来说无疑是一枚重磅炸弹： 正式宣布弃用 Docker 支持的功能。 那么，究竟 Kubernetes 为什么要这么做，以及这么做会有什么影响呢？

Docker 是一种以容器化的方式打包、分发和部署应用程序的方式。自 2013 年 3 月 13 日初始版本发布以来，Docker 已成为容器业界的事实标准。而Kubernetes 是一款由 Google 开发的开源容器编排系统。

Kubernetes 架构示意图，来自维基百科

Docker 与 OpenShift

在 2015 年的峰会上，红帽发布了 OpenShift V3.0，该新版本 OpenShift 底层采用 Docker 容器，同时开始使用 Kubernetes 来编排镜像。然而，在 2016 年的红帽峰会期间，Docker 对红帽的 OpenShift 展开了锋芒毕露的攻击。他们不仅发表了以下推文，还给与会者发放带有“我们不接受模仿”字样的T恤衫：

显然左边的仿制鲸鱼就是在嘲讽红帽的 OpenShift。当时，OpenShift 采用了基于 Docker 的容器。红帽发布的 Docker 一般会比原版落后一点点，而且为了提供所谓的“企业支持”，红帽采取了给旧版本 Docker 打补丁的行为。但相比之下，Docker 总是在发布最新版。

当然，对于维护企业应用应该采用升级还是采用移植补丁的方式，到现在依然众说纷纭，所以对于这一点在此不做评论，但 Docker 在红帽自己的峰会上的这种行为确实有点出乎意料。不得不承认，在此之前 Docker 是一项伟大的技术，毕竟它是 RedShift 的重要组成部分，但从那天起，事情就开始变味了。

平台之争

早期的 PaaS 平台主要是 OpenShift，以及两家竞争对手 Docker 和Pivotal 。Docker 人所共知就不用多说了，Pivotal 是 EMC 和 VMware 于2013 年创建的公司，专注于开源 PaaS 的解决方案。他们的企业解决方案非常成功，原因非常简单：用户体验非常好，尤其是结合 Pivotal Labs 使用的时候。

而 Docker 是企业解决方案的后起之秀，他们的优势就是开发者们早已熟知Docker 引擎了。而当时 Kubernetes 还不知道在哪儿。然而，Docker 对OpenShift 的攻击行为，使红帽不得不将资源投入到了 Kubernetes 上。后来的结果大家都看到了，Kubernetes 大获成功，并且获得了整个行业的拥护。

此时 Docker 为了挽回败局而推出了 Docker Swarm，但为时已晚。2016 年后半年，Kubernetes 超过了 Docker Swarm，成了行业事实上的标准。最终，Docker Swarm 并没有给 Kubernetes 带来任何冲击。可以认为这是Docker 的第一次死亡，从此以后，Docker 不再是企业级的 PaaS 解决方案，只能作为云原生系统中的一部分存在，好在它一直是 Kubernetes 中的一个重要组成部分。

Kubernetes 宣布弃用 Docker

近日 Kubernetes 宣布弃用 Docker。

（官网博客链接：https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/）：

这无疑是第二次宣布了 Docker 的死亡。按照 Kubernetes 自己的说法，Docker 已不再是必须的技术，而是变成了技术债务。1.19 版以前的Kubernetes 需要通过一个名为 Dockershim 的模块连接到 Docker，然后由Docker 连接到 Containerd 来创建容器。从技术上来看，实际的容器运行时是 Containerd，而不是 Docker。Docker 的作用只不过是在 Containerd 上创建容器而已。作为人类用户，只需运行一个 Docker run 就可以创建一个容器，这一点非常方便；然而在方便的同时，Docker 也带来了许多无用的操作和技术债务，对于 Kubernetes 而言，这就是负担。Kubernetes 完全可以绕过Docker，自己在 Containerd 上创建容器，从而获得同样的效果。而Kubernetes 1.20 中就采用了这种做法。

尽管 Docker 公司的商业模式失败了，但我们必须承认 Docker 为整个行业做出的巨大贡献。Docker 公司带来的技术是业内最好的。时至今日，我们的CI/CD 系统还极其依赖 Docker。没有 Docker，也不可能有 Kubernetes 的成功，而且 Kubernetes 依然有 Docker 的影子。

不过也不用担心，Kubernetes 团队已经做了大量的努力，尽可能使升级过程平稳。即使你升级到 1.20，也只会收到一个关于 Docker 已被弃用的警告。目前Kubernetes 的计划是在 2021 年末期发布的 1.22 中彻底移除 Docker 支持，所以开发者必须在那之前切换到其他的容器运行时，比如 Containerd 或 CRI-O 等。

Docker的替代品

弃用 Docker 之后，开发者们对其替代品的讨论逐渐热烈，其中 Containerd 和 Podman 倍受期待。

Containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性。它可以管理容器的生命周期，可以被 Kubernets CRI 等项目使用，并为广泛的行业合作打下基础等。

Podman 原来是 CRI-O 项目的一部分，后来被分离成一个单独的项目叫 libpod。Podman 的使用体验和 Docker 类似，不同的是 Podman 没有 daemon。直接通过 OCI runtime（默认也是 runc）来启动容器，所以容器的进程是 Podman 的子进程。这比较像 Linux 的 fork/exec 模型，而 Docker 采用的是 C/S（客户端/服务器）模型。

虽然目前容器市场 Docker 还是占用很大的比例，但被弃用的结局已定，在这个过渡期中，不妨去拥抱 Containerd 和 Podman 吧！

到此这篇关于被弃用的 Docker 会被 Podman 取代吗？的文章就介绍到这了,更多相关Docker替代Podman内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！