K8s 弃用 Docker? 看看 K8s 开发者怎么说?

这几天 K8s 将弃用的 docker 各种刷屏

包括本拐也很疑惑,类似的文章有:

重磅!Kubernetes 将弃用 Docker!

Kubernetes 要弃用docker了，我们该怎么办？

恰巧最近翻看 K8s 的官网比较多,看到了官方对于这一改动的详尽解释,于是搬一下.

也是本拐的处女译! 哈哈

Don't Panic: Kubernetes and Docker

本文译自:

https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

原作:

 Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas

在v1.20后,Kubernetes将弃用 docker 作为容器的运行时.

不用害怕,不要慌张

Kubneretes 将只支持实现了CRI( Container Runtime Interface)接口的容器运行时,而docker 作为低层的容器运行时,将被弃用.当然,用 docker 构建的镜像仍然可以在 K8S 的集群中使用.

如果你是 K8S的终端用户,这个改动对你没有太大的影响. 这并不意味着 docker 将死,也不是说 docker 作为一个开发工具将被弃用.它仍然是一个强大运行容器,而且通过docker build 构建的镜像仍然可以运行在你的 K8S 集群中.

如果你是K8s 集群服务(比如GKE,EKS 或AKS)的使用者,在docker 运行的支持被移除前,你要保证你的节点已经具备了K8s支持的运行时. 如果你对节点进行了定制,升级前要与运营厂商确认已在现有的环境上进行了升级,并已经做了充足的测试和预案.

如果你在运维着自建集群,要做好准备以避免升级导致集群 down 掉.在1.20时,你会收到不建议使用 docker 的警告.在 K8s 的下一个版本(初步计划为2021年尾的1.21)时docker 作为运行时将被移除.你需要将其迁移到其他的的容器技术,比如 containered 或 CRI-O.只要确保能支持你当前 docker守护程序的配置即可(比如日志相关等).

所以为什么会担忧?在担忧什么呢?

我们其实说的是两种不同的情况(Docker 作为开发工具和 Docker 作为运行时),这两种情况混为一谈导致了你的困惑.在K8s 中,作为一种容器技术的 Docker,负责了镜像的拉取和运行.Docker 作为一种容器运行时确实有广泛的应用(对比 containerd 和 CRI-O),但问题在于,Docker 并不是为集成在 K8s 中而产生的.

事实上,我们称之为 Docker 的并不是并某一种特定技术,它是一套完整的技术栈,其中由它实现的一套高度抽象的容器运行时,我们称之为"containerd".除此之外,Docker 有一整套人机交互的工具,这些工具极大的提高了人们的开发效率,使它很酷,也很实用.但是,这些工具对 K8s 并没有用,因为 K8s 是一个系统,而不是一个人.

反而正是这些人机友好的交互工具,导致 K8s 需要额外的一个称之为Dockershim的工具来实现其真正的需求,即调度使用 docker 的"containerd"运行. 这并不完美,它引入了额外的成本,同时增加了系统的不稳定性.我们真正要做的是在 v1.23之前移除Dockershim,导致的表层结果,就是不再采用 docker 作为运行时.那么,即然 Docker 已经有了containerd这种运行时,为什么 K8s 需要额外的Dockershim?

问题在于,Docker 与 CRI(Container Runtime Interface)规范并不兼容,如果没有 shim,那么 Docker就无法在 K8s 上工作.然而你也没必要因此难过,更不是世界末日----你所有要做的只是换一个运行时而已.

注意的一点是,如果你的集群工作流中某一部分依赖于 docker  socket(/var/run/docker.sock), 那么迁移到其他运行时会导致这部分不可用.这种模式称之为 docker in docker . 实现这个特性有很多其他选项,比如 kaniko,img和 buildah.

开发者应该如何?继续 dockerfile 和 docker build 么?

所以,这次更改(移除 K8s中的 docker 运行时支持)并不是大多数人使用 docker 的场景.你的 docker 开发环境与 K8s 里的 Docker 运行时是无关的. 我知道这么说会让人困惑.作为开发者,这次改动对你的 docker 的使用没有影响.要知道,docker build 生成的image不是 docker 专用的 image ,而是一个 OCI image. 即,只要是 OCI 兼容的 image,不管你用什么方式构建,对 K8s 都是一样的,Containered和 CRI-O 都可以拉取和运行. 这也是为什么说容器是一种标准技术.

所以,这个更改只会给很少的人带来问题.它并不是灾难性的,事实上喧是一件好事. 根据使用 K8s 方式的不同,它对你几乎无影响,或只有很少的工作.长期看来,这个改动使事情更加简单(少了 dockershim).如果你还是表示担忧,那么也没毛病,因为事情不是一直不变,K8s 也是一样,没有人敢说自己百分之百的精通它.

我们期待与大家沟通任何问题,无论这些问题的复杂与否.我们的目标是让每个人尽可能多的了解可能的变化(少于3个),希望这篇文章解答了你的困惑,缓解了你的焦虑.

更多问题请参考   Dockershim Deprecation FAQ. 

https://kubernetes.io/blog/2020/12/02/dockershim-faq/