对于开发人员
不用过分惊慌，Docker容器和映像仍然存在。不是说世界末日来了，实际上它不会改变一切。git
可是值得一读背后的缘由：github
https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/web
https://kubernetes.io/blog/2020/12/02/dockershim-faq/docker
对于K8s管理员
仔细阅读并开始考虑Docker替代方案json
是标题党吗
不，这是真的发生了。Docker如今在Kubernetes中已弃用。安全
参考
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation微信
kubelet中的Docker支持现已弃用，并将在之后的版本中删除。Kubelet使用一个名为“ dockershim”的模块，该模块实现了对Docker的CRI支持，而且在Kubernetes社区中看到了维护问题。咱们鼓励您评估在可用的容器运行时，它是CRI的完整实现（兼容v1alpha1或v1）。网络
简而言之，这意味着Docker不支持称为CRI（容器运行时接口）的Kubernetes运行时API，而且Kubernetes人们一直在使用名为“ dockershim”的桥接服务。它转换了Docker API和CRI，但在一些次要版本中将再也不从Kubernetes方面提供它。架构
固然，本地Docker是一个很是强大的工具，能够用来建立开发环境，可是为了了解形成这种状况的缘由，您须要了解Docker在当前Kubernetes体系结构中的做用。app
Kubernetes是一种基础架构工具，可对许多不一样的计算资源（例如虚拟/物理机）进行分组，使它看起来像是巨大的计算资源，可以让您的应用程序运行并与他人共享。在这种架构中，Docker（或容器运行时）仅用于经过Kubernetes控制平面进行调度，从而在实际主机中运行这些应用程序。
看一下架构图。您能够看到每一个Kubernetes节点都与控制平面通讯。kubelet在每一个节点上获取元数据，并执行CRI以在该节点上运行建立/删除容器。
可是为何再也不使用Docker？
一样，Kubernetes仅使用CRI进行内部通讯，而与Docker通讯则须要桥接服务。这就是缘由一。
为了解释下一个缘由，咱们必须稍微了解一下Docker架构。这是Docker的架构图。
是的，Kubernetes实际上须要在红色区域内运行，可是Kubernetes不使用Docker Network和Volume。
若是一个东西拥有不少用户不用的功能，这自己可能会带来安全隐患。您拥有的功能越少，攻击面就越小。
所以，这是后面社区提出来考虑替代方案的地方，称为CRI运行时。
CRI运行时
有两种主要的CRI运行时实现。
containerd
若是您只想从Docker迁移，这是最好的选择，由于容器其实是在Docker内部使用的，能够完成全部“运行时”工做，如上图所示。他们提供了CRI，这也是Docker提供的100％。
containerd是100％开放源代码，所以您能够在GitHub上查看文档，甚至也能够为此作出贡献。
https://github.com/containerd/containerd/
CRI-O
CRI-O是主要由Red Hat员工开发的CRI运行时。实际上，此运行时如今已在Red Hat OpenShift中使用。是的，他们再也不依赖Docker。
有趣的是，RHEL 7也开始不正式支持Docker。相反，它们为容器环境提供Podman，Buildah和CRI-O。
https://github.com/cri-o/cri-o
我认为CRI-O的优点在于它的极简风格，由于它被建立为“ CRI”运行时。尽管容器化做为Docker的一部分试图变得更加开源，但它们是纯CRI运行时，所以CRI-O没有CRI不须要的任何内容。
从Docker迁移到CRI-O可能会更具挑战性，由于它仍然能够提供在Kubernetes上运行应用程序所需的功能。
还有一件事...
当咱们谈论容器运行时时，咱们须要注意您在谈论哪一种类型的运行时。咱们确实有两种类型的运行时；CRI运行时和OCI运行时。
CRI运行时
正如我所描述的，CRI是Kubernetes提供的API，用于与容器运行时进行对话，以建立/删除容器化的应用程序。
它们经过IPC在gRPC中做为kubelet进行通讯，而且运行时在同一主机上运行，而且CRI运行时负责从kubelet获取请求并执行OCI容器运行时以运行容器。等一下 也许我应该用一张图表来解释。
所以，CRI运行时将执行如下操做
从kubelet获取gRPC请求
按照规范建立OCI json配置
OCI运行时
OCI运行时负责使用Linux内核系统调用（例如cgroups和命名空间）生成容器。您可能据说过runc或gVisor。
附录1：runC如何工做
CRI经过调用Linux系统调用执行二进制文件后，runC生成容器。这代表runC依赖Linux计算机上运行的内核。
这也意味着，若是您发现runC的漏洞得到了主机的root特权，那么容器化的应用程序也能够这样作。一个厉害的黑客可能会使您的主机完全报废！事情确定会变糟。这就是为何您也应该不断更新Docker（或任何其余容器运行时）的缘由之一，而不只仅是容器化的应用程序。
附录2：gVisor的工做方式
gVisor最初由Google员工建立的OCI运行时。它实际上在其基础结构上运行，以运行其云服务，例如Google Cloud Run，Google App Engine（第二代）和Google Cloud Functions（甚至更多！）。
这里有趣的是gVisor具备“guest 内核”层，这意味着容器化的应用程序没法直接接触主机内核层。即便他们认为这样作，也只能接触gVisor的guest内核。
gVisor的安全模型实际上很是有趣，值得阅读官方文档，与runC的显着区别以下。
性能较差
Linux内核层不是100％兼容的
查看官方文档的兼容性部分
默认不支持
总结
Docker 确被弃用，你们应该开始考虑使用 CRI 运行时，例如 containerd 与 CRI-O。
containerd 与 Docker 相兼容，两者共享相同的核心组件。
若是您主要使用 Kubernetes 的最低功能选项，CRI-O 可能更为适合。
明确理解 CRI 运行时与 OCI 运行时之间的功能与做用范围差别。
根据您的实际工做负载与业务需求，runC 可能并不老是最好的选择，请酌情作出考量！
原文连接：
https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
最后，你们若是想加群和各路大拿交流，能够识别下面的二维码加入：
后台回复“加群”，带你进入高手如云交流群
推荐阅读：
10T 技术资源大放送！包括但不限于：云计算、虚拟化、微服务、大数据、网络、Linux、Docker、Kubernetes、Python、Go、C/C++、Shell、PPT 等。在公众号内回复「1024」，便可免费获取！！
本文分享自微信公众号 - Linux云计算网络（cloud_dev）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。