不必惊慌 - Docker 与 Kubernetes 何去何从

Kubernetes 最新发布的 1.20 版本中弃用未来对 Docker 支持，特指不再维护支持 Docker 的代码，而不是直接在 1.20 版本中弃用 Docker 作为容器运行时的支持。

不必惊慌，根据 Kubernetes 发布周期，最快也是计划在 Kubernetes 1.22 版本弃用 Docker 作为运行时的支持，也就是 Kubelet 弃用 Dockershim。

为什么要弃用 Docker

Docker 作为容器引擎实现技术的代表在一开始就被人们所熟知，在工作中无论是构建开发环境，还是作为容器运行时在生产环境中运行的大量容器，都深受人们喜爱。但突然间为什么 Kuberentes 就宣布放弃 Docker 了呢？

实际上 Kubernetes 不是放弃 Docker，而是在 Kubernetes 的组件 Kubelet 放弃对 Dockershim 的支持了。
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

什么是Kubelet

Kubelet 在 Kubernetes 架构中作为工作节点的其中一个重要的组件，Kubelet 负责对容器进行生命周期的管理，例如创建、删除、监视等，例如在 Kubernetes 创建一个 Pod，而实际的工作流程是 Kubelet 与容器的运行时进行打交道完成的，而两者间需要遵循 CRI（Container Runtime Interface）标准。

Kubernetes 一开始是在 Kubelet 的代码中内嵌了 Docker 运行时支持，但由于当时 rkt、katacontainer 纷纷要作为 Kubernetes 容器运行时瓜分容器的市场，如果全部代码都在 Kubernetes 维护的话，各种兼容性问题的维护量非常让人头疼，而后在 1.5 版本时在推出 CRI 标准，方便更多的容器运行时接入 Kubernetes，但由于 Docker 作为容器运行时的实现代表，并且 Docker 不支持 CRI ，Kubernetes 只能委屈求全在自身组件 Kubelet 代码中使用 dockershim 来满足 Docker 作为 Kubernetes 的运行时。

什么是Dockershim

由于 Docker 不支持 CRI 而无法直接被 Kubernetes 作为容器运行时所使用，而需要中间层 dockershim 进行两者间的兼容。

这种架构的模式在性能上会较差，实际上对于 dokcershim 与 docker daemon来说，两者类似都是划水的角色，而如果 kubelet 直接调用 containerd 去管理容器的话，性能会提高许多。

使用者角度如何去应对该变更

在弃用了 Dockershim 的支持后无法使用 Docker 作为 Kubernetes 的容器运行时，其实这不是什么大不了的问题，我们只需要将 Docker 更改成另外一个支持 CRI（Container Runtime Interface）标准的容器实现技术即可。例如 Podman 、Katacontainer 等容器运行时…

但有人还会说，我使用 Docker Build 构建出来的容器镜像是否就无法被其他容器运行时所支持了呢？

其实不然，Docker 构建出来的容器镜像都会遵循 OCI（Open Container Initiative）的镜像规范, 只需要大家都支持了这个标准，那么就可以将镜像启动成容器进行使用。

未来发展的可能性

Kubernetes 为什么突然要这么做呢，在 Docker 作为容器运行时的老大哥时，Kubernetes 别无选择，只能委曲求全，毕竟 Kubernetes 的核心战略方向是在容器编排管理方面的，而不是实现容器运行时。

但目前由于容器运行时的选择多样性，百花齐放，Kubernetes 在容器编排管理已经是老大哥的地位，用户如果在更换容器运行时和容器编排平台时，最大可能是更换了容器运行时，也就是 Docker ，那么对用户的使用影响是最小的，例如更换了 Podman 对于使用上是没有任何差异的，但是如果更换了容器编排管理也是就是 Kubernetes，那么是毫无可能性的，在2018年的时候 Kubernetes 已经在容器江湖中的地位日益增长，至今以是无法撼动的事实标准。

Docker 社区不可能笨蛋到放弃对 Kubernetes 兼容而放弃了整一个容器运行时市场，所以最有可能的是 Docker 在新版本中支持 CRI 标准，从而继续作为容器运行时与 Kubernetes 共同发展。

其实未来的变动性很大，作为使用者来说，静观其变就好了，但类似作为云服务提供商那么就要考虑提前支持其他的容器运行时来满足用户的需求。但总得来说未来的方向有三个。

用户继续拥抱 Docker
不进行升级 Kubernetes 到 1.22，起码在2年内还是可以继续 Docker 作为 Kubernetes 的容器运行时，但无法享用到新版本的特性及问题维护。

Docker 在新版本中支持 CRI 标准
最有可能的，上面已经分析了 Docker 社区应该不会放弃这个容器运行时市场。

用户放弃 Docker 而转用遵循 CRI 的其他容器运行时。