K8s弃用docker的原因
2022/06/03 23:43:48
原因如下：
docker比k8s发布的早；
Docker 本身不兼容 CRI 接口，官方并没有实现 CRI 的打算，同时也不支持容器的一些新需求，社区想要摆脱Dockershim的高维护成本，。
k8s不能直接与docker通信，只能与 CRI 运行时通信，要与 Docker 通信，就必须使用桥接服务(dockershim)，k8s要与docker通信是通过节点代理Kubelet的Dockershim（k8s社区维护的）将请求转发给管理容器的 Docker 服务。
Dockershim 一直都是 Kubernetes 为了兼容 Docker 获得市场采取的临时方案（决定）。
k8s在过去因为 Docker 的热门而选择它，现在又因为高昂的维护成本而放弃它，我们能够从这个过程中体会到容器领域的发展和进步。
对于已经统治市场的k8s来说，Docker 的支持显得非常鸡肋，移除代码也就顺理成章。
在集群中运行的容器运行时往往不需要docker这么复杂的功能，k8s需要的只是 CRI 中定义的那些接口。
不用担心，Mirantis公司未来会和Docker共同维护Dockershim,并作为一个开源组件提供；对于正式生产环境还是建议采用兼容CRI的containerd之类的底层运行时。
下面详细聊聊知识点
K8s决定在 1.20 开始放弃 Docker，并在1.21完全抛弃 Docker 的支持。
2020 年 12 月，Kubernetes 社区决定着手移除仓库中 Dockershim 相关代码，对于k8s和 Docker 两个社区来说都意义重大。
如上图所示，Kubernetes节点代理 Kubelet为了访问Docker提供的服务需要先经过社区维护的 Dockershim，Dockershim 会将请求转发给管理容器的 Docker 服务。
可扩展性
Kubernetes 通过引入新的容器运行时接口将容器管理与具体的运行时解耦，不再依赖于某个具体的运行时实现。
Kubernetes 通过下面的一系列接口为不同模块提供扩展性：
Kubernetes 在较早期的版本中就引入了 CRD、CNI、CRI 和 CSI 等接口，只有用于扩展调度器的调度框架是 Kubernetes 中比较新的特性。
Kubernetes 早在 1.3 就在代码仓库中同时支持了 rkt 和 Docker 两种运行时。
但这些代码为 Kubelet 组件的维护带来了很大的困难，不仅需要维护不同的运行时，接入新的运行时也很困难。
容器运行时接口(Container Runtime Interface、CRI)是 Kubernetes 在 1.5 中引入的新接口，Kubelet 可以通过这个新接口使用各种各样的容器运行时。
其实 CRI 的发布就意味着 Kubernetes 一定会将 Dockershim 的代码从仓库中移除。
CRI 是一系列用于管理容器运行时和镜像的 gRPC 接口，我们能在它的定义中找到 RuntimeService 和 ImageService 两个服务。
不兼容接口
与容器运行时相比，Docker 更像是一个复杂的开发者工具，它提供了从构建到运行的全套功能。
开发者可以很快地上手 Docker 并在本地运行并管理一些 Docker 容器，然而在集群中运行的容器运行时往往不需要这么复杂的功能，Kubernetes 需要的只是 CRI 中定义的那些接口。
虽然 Docker 中包含 CRI 需要的所有功能，但是都需要实现一层包装以兼容 CRI。
社区提出的很多新功能都没有办法在 Dockershim 中实现，例如 cgroups v2 以及用户命名空间。
Kubernetes 作为比较松散的开源社区，每个成员尤其是各个 SIG 的成员都只会在开源社区上花费有限的时间。
而维护 Kubelet 的 sig-node 又尤其繁忙，很多新的功能都因为维护者没有足够的精力而被搁置。
既然 Docker 社区看起来没有打算支持 Kubernetes 的 CRI 接口，维护 Dockershim 又需要花费很多精力，就能理解为什么 Kubernetes 会移除 Dockershim 了。
Kubelet 之前使用一个名为 dockershim 的模块，用以实现对 Docker 的 CRI 支持。但 Kubernetes 社区发现了与之相关的维护问题，建议大家考虑使用包含 CRI 完整实现（兼容 v1alpha1 或 v1）的可用容器运行时。
Docker 并不支持 CRI（容器运行时接口）这一 Kubernetes 运行时 API，而 Kubernetes 用户一直以来所使用的其实是名为“dockershim”的桥接服务。Dockershim 能够转换 Docker API 与 CRI。
Docker 本身也是一款非常强大的工具，可用于创建开发环境。为了解造成当前状况的原因，需要全面分析 Docker 在现有 Kubernetes 架构中的作用。
Docker公司把containerd和runc拆出来变成了开源项目,docker的底层是containerd+runc .
docker比k8s发布的早；
Docker 本身不兼容 CRI 接口，官方并没有实现 CRI 的打算，同时也不支持容器的一些新需求，社区想要摆脱Dockershim的高维护成本，。
k8s不能直接与docker通信，只能与 CRI 运行时通信，要与 Docker 通信，就必须使用桥接服务(dockershim)，k8s要与docker通信是通过节点代理Kubelet的Dockershim（k8s社区维护的）将请求转发给管理容器的 Docker 服务。
Dockershim 一直都是 Kubernetes 为了兼容 Docker 获得市场采取的临时方案（决定）。
k8s在过去因为 Docker 的热门而选择它，现在又因为高昂的维护成本而放弃它，我们能够从这个过程中体会到容器领域的发展和进步。
对于已经统治市场的k8s来说，Docker 的支持显得非常鸡肋，移除代码也就顺理成章。
在集群中运行的容器运行时往往不需要docker这么复杂的功能，k8s需要的只是 CRI 中定义的那些接口。
不用担心，Mirantis公司未来会和Docker共同维护Dockershim,并作为一个开源组件提供；对于正式生产环境还是建议采用兼容CRI的containerd之类的底层运行时。
下面详细聊聊知识点
K8s决定在 1.20 开始放弃 Docker，并在1.21完全抛弃 Docker 的支持。
2020 年 12 月，Kubernetes 社区决定着手移除仓库中 Dockershim 相关代码，对于k8s和 Docker 两个社区来说都意义重大。
如上图所示，Kubernetes节点代理 Kubelet为了访问Docker提供的服务需要先经过社区维护的 Dockershim，Dockershim 会将请求转发给管理容器的 Docker 服务。
可扩展性
Kubernetes 通过引入新的容器运行时接口将容器管理与具体的运行时解耦，不再依赖于某个具体的运行时实现。
Kubernetes 通过下面的一系列接口为不同模块提供扩展性：
Kubernetes 在较早期的版本中就引入了 CRD、CNI、CRI 和 CSI 等接口，只有用于扩展调度器的调度框架是 Kubernetes 中比较新的特性。
Kubernetes 早在 1.3 就在代码仓库中同时支持了 rkt 和 Docker 两种运行时。
但这些代码为 Kubelet 组件的维护带来了很大的困难，不仅需要维护不同的运行时，接入新的运行时也很困难。
容器运行时接口(Container Runtime Interface、CRI)是 Kubernetes 在 1.5 中引入的新接口，Kubelet 可以通过这个新接口使用各种各样的容器运行时。
其实 CRI 的发布就意味着 Kubernetes 一定会将 Dockershim 的代码从仓库中移除。
CRI 是一系列用于管理容器运行时和镜像的 gRPC 接口，我们能在它的定义中找到 RuntimeService 和 ImageService 两个服务。
不兼容接口
与容器运行时相比，Docker 更像是一个复杂的开发者工具，它提供了从构建到运行的全套功能。
开发者可以很快地上手 Docker 并在本地运行并管理一些 Docker 容器，然而在集群中运行的容器运行时往往不需要这么复杂的功能，Kubernetes 需要的只是 CRI 中定义的那些接口。
虽然 Docker 中包含 CRI 需要的所有功能，但是都需要实现一层包装以兼容 CRI。
社区提出的很多新功能都没有办法在 Dockershim 中实现，例如 cgroups v2 以及用户命名空间。
Kubernetes 作为比较松散的开源社区，每个成员尤其是各个 SIG 的成员都只会在开源社区上花费有限的时间。
而维护 Kubelet 的 sig-node 又尤其繁忙，很多新的功能都因为维护者没有足够的精力而被搁置。
既然 Docker 社区看起来没有打算支持 Kubernetes 的 CRI 接口，维护 Dockershim 又需要花费很多精力，就能理解为什么 Kubernetes 会移除 Dockershim 了。
Kubelet 之前使用一个名为 dockershim 的模块，用以实现对 Docker 的 CRI 支持。但 Kubernetes 社区发现了与之相关的维护问题，建议大家考虑使用包含 CRI 完整实现（兼容 v1alpha1 或 v1）的可用容器运行时。
Docker 并不支持 CRI（容器运行时接口）这一 Kubernetes 运行时 API，而 Kubernetes 用户一直以来所使用的其实是名为“dockershim”的桥接服务。Dockershim 能够转换 Docker API 与 CRI。
Docker 本身也是一款非常强大的工具，可用于创建开发环境。为了解造成当前状况的原因，需要全面分析 Docker 在现有 Kubernetes 架构中的作用。
Docker公司把containerd和runc拆出来变成了开源项目,docker的底层是containerd+runc .