本文目录导航：
kubernetes 为何弃用docker？
在Kubernetes中弃用Docker?这听起来像是2020年十分抢手的一条消息。
虽然Docker是容器的同义词，但很多人没无看法到作为一个产品，Docker是由多个组件组成的，是一个容器的技术栈。
其中一个组件是容器运转时，是kubernetes与容器交互须要的。
容器运转时可以拆分红high-level运转时和low-level运转时两局部。
两者作用不同，但上班在一块。
high-level运转时关键担任比如从仓库拉取镜像、治理镜像、和处置镜像到low-level运转时的上班。
low-level运转时将依据镜像详细担任创立、删除和运转容器。
high-level和low-level运转时都遵照特定的规范：容器运转时接口（CRI）和开明容器规范协定（OCI）。
容器运转时接口(CRI)是在Kubernetes 1.5中作为alpha版本引入的。
CRI的指标是使Kubernetes生态系统更具可裁减性，为开发人员提供Kubernetes将如何与运转时交互的蓝图。
开发人员如何实践设计和成功运转时齐全取决于他们，只需满足接口。
作为集群保养者，CRI的规范化准许咱们选择在咱们的环境中经常使用哪个容器运转时。
这也使得Kubernetes变得愈加灵敏，由于它如今不须要咱们把握每种特定的运转时。
以后可用的两个盛行容器运转时是containerD和CRI-O。
开明容器规范协定 (OCI)于2015年由Container畛域的指导者动员，他们以为构建容器镜像的模式应该规范化。
依据OCI规范构建的镜像将与任何容器运转时适配，只需运转时遵照并合乎OCI规范。
因此，无论你是用docker还是podman构建容器映像，你的容器镜像都将兼容多个规格，并继续在你的集群中运转。
一些干流的OCI运转时有runC、Kata容器（英特尔Clear Containers和Hyper RunV名目）和Gvisor（goole名目）。
如今让咱们从新回到主题Docker以及它被弃用的要素。
Docker知道如何与容器交互，由于它经常使用ContainerD作为它的high-level运转时，经常使用runC作为它的low-level运转时，这两个运转时都位于Docker的多个内层组件中，并被形象化给用户。
虽然ContainerD和runC都是遵照CRI和OCI规范，咱们也会遇到一个疑问，由于Docker自身不能满足CRI的要求，而CRI是Kubernetes须要与运转时交互的。
随着Dockershim的引入，这个疑问获取了处置。
Dockershim作为Kubernetes和Docker之间的两边件，并且兼容CRI。
但是，Dockershim的一个缺陷是，你正在加载整个Docker堆栈，并让Kubernetes与shim通讯，shim而后与Dock通讯，docker经过调用栈直到它抵达containerD。
这在容器上班流程中参与了不用要的步骤，由于Kubernetes可以间接与containerD或任何其余CRI兼容的运转时交互。
经常使用Dockershim原本是一种暂时的处置计划，但它缓缓地变成了一种累赘，因此不得不弃用它。
总之，Kubernetes须要一种与容器交互的模式。
这是由处置容器生命周期的容器运转时处置的。
Kubernetes可以与任何容器运转时交互，假设它们合乎容器运转时接口(container runtime Interface)，该接口定义了Kubernetes将如何与提供的运转时交互。
此外，一切的镜像/容器和运转时必定遵照OCI，它定义了如何创立镜像或容器。
至于Docker，它是一个形象了一个容器运转时的技术栈，不合乎CRI。
既然有了 Docker，为什么还要 Kubernetes？
“一千个读者眼里有一千个哈姆雷特”。
雷同的话也实用于 Kubernetes，雷同的系统在不同的开发人员眼中也是不同的，甚至在不同阶段关于它的了解也一模一样。
在尚未开局经常使用Kubernetes之前，我以为它是一套十分复杂的系统，各种形象概念以及复杂的装置环节。
差点由于装置不顺，计划就此丢弃。
理由很便捷： 既然有了 Docker，为什么还要 Kubernetes ？
之所以觉得Kubernetes系统复杂、难，关键是不知道它究竟是干啥的？再加上老版本繁琐的装置环节，情愿啃它是须要一点毅力的。如今，就经过一张便捷的对比图通知你，它究竟干了啥！
单看图示上局部，出现的变动仅仅是HOST换成了POD,底层网络由实在网络换成了笼罩网络，即虚构网络。
关于APP运行开发者而言, 即使你齐全疑问容器技术也没相关.这是Kubernetes的凶猛之处,它提供的形象层关于APP运行开发者而言是齐全透明的。
运行在POD中和在HOST服务器上并没有实质区别。
还是老疑问： 既然有了 Docker，为什么还要 Kubernetes ？
回答这个疑问，得从为什么须要引入Docker这个疑问先开局。
你会说，由于须要 容器化部署 。
那为什么须要 容器化部署 呢？就这个疑问还可以走得更远一点。
这里我就偷懒了，先打住。
看看 容器化部署 后出现的新疑问，即容器实例越来越多。
由于容器实例越来越多，就像鸡蛋太多须要一个篮子来装一样，Kubernetes就是那个篮子。
当然这不是一个便捷的篮子，此处也不裁减了。
规范答案就是： 由于有了 Docker，所以才要Kubernetes 。
是不是觉得进入一个loop,我也这觉得。
从图中也可以看出，Docker容器技术是Kubernetes平台的基础。
容器技术关键作用是 隔离 ，经过对系统的关键资源的隔离，成功了 服务器形象 。
Kubernetes平台则是在 形象服务器 的基础上，成功了 集群形象 。
用一句话做个总结，就是：
一篇短文，宿愿可以帮到还徘徊在Kubernetes大门之外的初学者。
当然，新版本Kubernetes曾经十分容易装置了。
docker和k8s的相关
Docker和Kubernetes是互补的技术，理论一同经常使用以构建、部署和治理容器化运行。
一、Docker与Kubernetes的互补性
Docker是一种容器化技术，用于打包、部署和运转运行。
它创立的是轻量级的、可移植的容器，这些容器蕴含运转运行所需的一切资源。
而Kubernetes是一个开源的容器编排平台，用于智能化部署、裁减和治理容器化运行。
它可以轻松处置多个Docker容器之间的依赖相关，成功运行的智能化部署和弹性伸缩。
因此，Docker和Kubernetes联合经常使用可以极大地简化容器化运行的开发和运维环节。
二、Docker与Kubernetes的协同上班
Docker提供了容器的运转环境，而Kubernetes则提供了一个集群环境，可以在其中运转和治理多个Docker容器。
在Kubernetes中，Docker作为容器运转时被经常使用。
开发者可以经常使用Docker构建运行镜像，而后将这些镜像部署到Kubernetes集群中。
在集群中，Kubernetes可以治理这些容器的生命周期，包括部署、裁减、观测和日志治理等。
经过这种模式，Docker和Kubernetes独特提供了从运行开发到消费环境的完整处置计划。
三、总结
简而言之，Docker和Kubernetes是相互单干的相关。
Docker提供了单个容器的创立和运转环境，而Kubernetes则提供了治理这些容器的平台，包括集群治理、智能裁减、服务发现等配置。
两者联合经常使用，可以大大提高开发者的消费效率和运行的牢靠性。
在现代云原生运行的开发中，熟练把握Docker和Kubernetes是十分关键的技艺。
