首页 > 行业资讯 > 如何解读“K8S不支持Docker”？

如何解读“K8S不支持Docker”？

时间：2023-03-15 来源：浏览：

如何解读“K8S不支持Docker”？

JanXC twt企业IT社区

twt企业IT社区

微信号 talkwithtrend

功能介绍 talkwithtrend.com社区（即twt社区）官方公众号，持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群，让您时刻和国内企业IT同行保持信息同步。

收录于合集

来自社区会员分享，欢迎大家来探讨

@zhanxuechao 咨询专家：

容器不只是 Docker ，但不可否认 Docker 是容器的代名词、容器时代的引领者。实际上 K8S 出现并得以快速发展，也是由于 Docker 的强大优势和快速发展， 2014 年 Google 推出 Kubernetes 也主要用于解决大规模场景下 Docker 容器编排的问题。

2015 年，由 Docker 公司和其他容器行业领导者共同成立（它也是 Linux 基金会旗下项目） OCI （ Open Container Initiative ）， OCI 主要包含两个规范：（ 1 ）运行时规范（ runtime-spec ）：容器运行时，如何运行指定的文件系统上的包；（ 2 ）容器镜像规范（ image-spec ）：如何创建一个 OCI 运行时可运行的文件系统上的包。Docker 把它自己的容器镜像格式和 runtime ( 现在的 runc ) 都捐给了 OCI 作为初始工作。2016 年 6 月， Docker v1.12 发布，推出 Docker 多主机多容器编排解决方案，即 Docker Swarm ，意在完善其容器生态圈技术框架，并且尝试撼动 K8S 在容器编排的地位。

2016 年 12 月， Kubernetes 未解决不同容器运行时产品 / 项目的兼容性问题时（此时 K8S 已在尝试支持其他容器运行时，如 rkt 、 cri-o 、 containerd 等），发布统一标准的 CRI （ Container Runtime Interface ），凡是支持 CRI 的运行时，皆可直接作为 Kubernetes 的底层运行时。为了将自己运行时产品或项目运行在 K8S 下，有些 runtime 厂商或社区就开发了符合 CRI 标准的转接线就是一个 shim ，叫做 CRI-shim 。但对 Docker 而言，其自身在容器方面过于强大且自信，为提供符合 K8S 的 CRI 接口规范的 shim ，不过考虑到 Docker 的用户群体庞大， K8S （其实是 kubelet ）里继续内置了连接 docker 的代码叫做（ dockershim ）。

所谓 K8S 不再支持 Docker ，实质上是 K8S 要放弃对现在 K8S 代码仓库中的 dockershim 的维护支持，以便其可以像计划的那样，仅负责维护其 CRI ，任何兼容 CRI 的运行时，皆可作为 K8S 的 runtime 。实际上，在 K8S 提出 CRI 时， Docker 在技术方面是可以实现的，但这也会带来一个新的问题，即使 Docker 实现了 CRI ，但它仍然不是一个单纯的容器运行时，它本身包含了大量的非 “ 纯底层容器运行时 ” 所具备的功能。所以后来 Docker 分离出来 containerd 项目，作为一个底层容器运行时出现了，它是 K8S 容器运行时更好的选择。目前， Docker 使用 containerd 作为其底层容器运行时以及众多的云厂商及公司在生产环境中使用 containerd 作为其 K8S 的运行时，这也从侧面验证了 containerd 的稳定性。现在 K8S 和 Docker 社区都相信 containerd 已经足够成熟可直接作为 K8S 的运行时了，而无需再通过 dockershim 使用 Docker 作为 K8S 的运行时了。这也标志着 Docker 为 K8S 提供一个现代化的容器运行时的承诺最终兑现了。同时， K8S 代码仓库中的 dockershim 将会在未来版本中移除，但是 Mirantis 公司（ 2019 年 Mirantis 收购 Docker 的企业服务）已经和 Docker 达成合作，在未来会共同维护一份 dockershim 组件，以便支持 Docker 作为 K8S 的容器运行时。

综上， Kubernetes 放弃对 dockershim 的维护，对于用户以及 K8S 开发工程师而言，实质上并未有影响；对于容器集群管理员，则需要考虑是否要在未来版本中，将容器运行时，升级为支持 CRI 的运行时，比如 containerd 。当然，如果你并不想切换容器运行时，那也没关系， Mirantis 公司未来会和 Docker 共同维护 dockershim , 并作为一个开源组件提供。

@顾黄亮技术总监畅销书作者：

从技术层面上而言，Docker的确被Kubernetes弃用，因为，当我们开始考虑使用CRI运行时，例如 containerd 与 CRI-O。containerd 与 Docker 相兼容，二者共享相同的核心组件。如果你主要使用 Kubernetes 的最低功能选项，CRI-O 可能更为适合。明确理解 CRI 运行时与 OCI 运行时之间的功能与作用范围差异。根据官方描述，在 1.20 版本之后，Kubernetes 将不再支持把 Docker 作为容器运行时使用。但是，官方说明中，只是不建议将 Docker 作为底层运行，我们仍然可以使用专为Kubernetes创建的容器运行时接口(CRI)一如既往地在集群中运行 Docker 镜像。对于 Kubernetes 最终用户，此次调整同样不会有太大影响。Docker 不会就此消亡，你也仍然可以继续将 Docker 作为开发工具使用。Docker 会继续构建起不计其数的容器，而运行 docker build 命令所生成的镜像仍可在 Kubernetes 集群内正常运行。如果你使用的是 GKE 或者 EKS 等托管 Kubernetes 服务，则需要确保在未来的 Kubernetes 版本彻底去除 Docker 支持之前，为你的工作节点引入受支持的容器运行时。

@annoymous：

作为容器云平台管理员，了解OCI、CRI、dockershim、containerd的历史，了解k8s支持dockershim的版本，在项目中，根据k8s版本选择推荐的容器运行时即可。

欢迎探讨