不要惊慌：Kubernetes 和 Docker 没有脱钩

作者：Jorge Castro、Duffie Cooley、Kat Cosgrove、Justin Garrison、Noah Kantrowitz、Bob Killen、Rey Lejano、Dan "POP" Papandrea、Jeffrey Sica、Davanum "Dims" Srinivas

Kubernetes 在1.20版本之后将弃用 Docker 作为容器运行时。

• https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

你不需要惊慌，这并不像听起来那么戏剧化。

简单来讲：Docker 作为底层运行时正在被弃用，取而代之的是使用为 Kubernetes 创建的CRI（Container Runtime Interface，容器运行时接口）的运行时。Docker 生成的镜像将继续在你的集群中与所有运行时一起工作，就像它们一直那样。

• https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/

如果你是 Kubernetes 的最终用户，那么不会有太多的变化。这并不意味着 Docker 的消亡，也不意味着你不能或不应该再使用 Docker 作为开发工具。Docker 仍然是构建容器的有用工具，运行 Docker build 产生的镜像仍然可以在 Kubernetes 集群中运行。

 

如果你正在使用像 GKE 或 EKS 这样的托管 Kubernetes 服务，那么在 Kubernetes 的未来版本中删除 Docker 支持之前，你需要确保你的工作节点使用的是受支持的容器运行时。如果你有节点自定义，则可能需要根据环境和运行时需求更新它们。请与你的服务提供商合作，以确保适当的升级测试和计划。

 

如果你在创建自己的集群，你还需要进行更改，以避免集群崩溃。在v1.20，你将收到 Docker 的弃用警告。当 Docker 运行时支持在 Kubernetes 的未来发行版（目前计划在2021年底的1.23发行版）中被移除时，它将不再受支持，你将需要切换到其他兼容的容器运行时，如 containerd 或 CRI-O。只要确保你选择的运行时支持你当前使用的 docker 守护进程配置（例如日志）。

 

那么，为什么会有这种困惑呢？每个人都在担心什么呢？

 

我们在这里讨论的是两种不同的环境，这就造成了混淆。在 Kubernetes 集群中，有一个称为容器运行时的东西，它负责提取和运行容器镜像。Docker 是该运行时的流行选择（其他常见选项包括 containerd 和 CRI-O），但是 Docker 并不是被设计成嵌入到 Kubernetes 中，这就导致了一个问题。

 

你看，我们称为“Docker”的东西实际上并不只是一个东西--它是一个完整的技术堆栈，其中一部分是一个叫做“containerd”的东西，它本身是一个高级的容器运行时。Docker 很酷，也很有用，因为它有很多UX增强，使得在我们进行开发工作时很容易与人交互，但是这些 UX 增强对 Kubernetes 来说不是必需的，因为它不是人。

 

由于有了这个对人友好的抽象层，你的 Kubernetes 集群必须使用另一个称为 Dockershim 的工具来获得它真正需要的东西，它包含在其中。这不太好，因为它给了我们另一个需要维护的东西，而且可能会损坏。这里实际发生的是，Dockershim 最早将在v1.23版本就从 Kubelet 中删除了，从而取消了对 Docker 作为容器运行时的支持。你可能会想，如果 containerd 包含在 Docker 堆栈中，为什么 Kubernetes 需要 Dockershim 呢？

 

Docker 与 CRI（容器运行时接口）不兼容。如果是的话，我们就不需要垫片了，这就不成问题了。但这并不是世界末日，你也不必惊慌--你只需要将容器运行时从 Docker 更改为另一个受支持的容器运行时。

• https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/

 

需要注意的一点是：如果你现在在集群中依赖底层 docker socket（/var/run/docker.sock）作为工作流程的一部分，迁移到不同的运行时将会破坏你使用它的能力。这种模式通常称为 Docker in Docker。对于这个特定的用例，有很多选择，包括 kaniko、img 和 buildah。

• https://github.com/GoogleContainerTools/kaniko

• https://github.com/genuinetools/img

• https://github.com/containers/buildah

 

但是，这种变化对开发人员意味着什么呢？我们还在写 Dockerfile 吗？我们还用 Docker 构建东西吗？

 

这一改变解决了一个与大多数人使用 Docker 进行交互的不同环境。你在开发中使用的 Docker 安装与 Kubernetes 集群中的 Docker 运行时无关。我知道这很令人困惑。作为一名开发人员，Docker 仍然对你很有用，就像在这项更改宣布之前一样。Docker 生成的镜像实际上并不是一个特定于 Docker 的镜像--它是一个 OCI（Open Container Initiative）镜像。无论你使用什么工具构建它，任何符合 OCI 标准的镜像在 Kubernetes 看来都是一样的。containerd 和 CRI-O 都知道如何提取这些镜像并运行它们。这就是为什么我们有一个容器应该是什么样的标准。

• https://opencontainers.org/

 

所以，这种变化正在到来。这会给一些人带来问题，但这不是灾难性的，而且一般来说这是件好事。取决于你如何与 Kubernetes 交互，这可能对你毫无意义，也可能意味着需要进行一些工作。从长远来看，这会让事情变得更简单。如果这仍然让你感到困惑，那也没关系--这里发生了很多事情，Kubernetes 有很多变动的部分，没有人是100%的专家。我们鼓励任何和所有的问题，无论经验水平或复杂性！我们的目标是确保每个人都尽可能多地了解即将到来的变化。我们希望这已经回答了你的大部分问题，缓解了你的一些焦虑！