系列好文 ｜ Kubernetes 弃用 Docker，我们该何去何从？

系列好文 ｜ Kubernetes 弃用 Docker，我们该何去何从？

导读：Erda 作为一站式云原生 PaaS 平台，现已面向广大开发者完成 70w+ 核心代码全部开源！**在 Erda 开源的同时，我们计划编写《基于 K8s 的云原生 PaaS 平台基础架构》系列文章，希望我们的一点经验可以帮助更多企业完善 PaaS 平台基础架构的建设。本文为系列文的第一篇。

缘起

Kubernetes 在 1.20 版本之后将弃用 Docker 作为容器运行时：年底，Kubernetes 官方发布公告，宣布自 v1.20 起放弃对 Docker 的支持，届时用户在 kubelet 启动日志中将收到 docker 弃用警告。这个大瓜的爆出，对还在使用 Kubernetes 的 docker开发者和工程师来说无疑是一项沉重的负担。那么 Kubernetes 弃用 docker ，对我们有哪些影响呢？别慌，这件事情，没有想象中的那么可怕。​

If you’re rolling your own clusters, you will also need to make changes to avoid your clusters breaking. At v1.20, you will get a deprecation warning for Docker. When Docker runtime support is removed in a future release (currently planned for the 1.22 release in late 2021) of Kubernetes it will no longer be supported and you will need to switch to one of the other compliant container runtimes, like containerd or CRI-O. Just make sure that the runtime you choose supports the docker daemon configurations you currently use (e.g. logging).

这段话翻译过来大致是说，在 v1.20 的版本中，只会收到一个 docker 的弃用警告，在未来 v1.22 版本之前是不会删除的，这意味着到 2021 年底的 v1.23 版本，我们还有 1 年的 buffer 时间来寻找合适的 CRI 运行时来确保顺利的过渡，比如 containerd 和 CRI- O。​

缘灭

为什么 Kubernetes 要放弃 docker ，改用其它 CRI 呢？​我们知道，CRI 是 Kubernetes 在 v1.5 版本中引入的，充当 kubelet 和容器运行时之间的桥梁。简单概述：CRI 是以容器为中心的 API，设计的初衷是不希望向容器（比如 docker）暴露 pod 信息或 pod 的 api 接口，通过这种接口模式，Kubernetes 无须重新编译就可以使用更多的容器运行时。但是呢，Docker 与 CRI 不兼容，为了适配 Docker ，Kubernetes 就搞出来了 dockershim 这么个东东，将 CRI 转换成 Docker API，kubelet 使用 dockershim 和 docker 进行通信，docker 再和下面的 containerd 进行通信。这样就可以愉快地工作了。如下图所示：

Dockershim 为了支持多种 OCI Runtime ，负责为每个启动的容器拉起一个新的 docker-shim 进程，指定容器 ID、Bundle 目录、运行时的二进制（runc），dockershim 允许 kubelet 与 docker 交互，就好像 docker 是一个 CRI 兼容的运行时一样。

​本来大家相安无事，直到去年年底，这场平衡被 Kubernetes 公开打破了。Kubernetes 介绍说是因为维护 dockershim 已经成为 Kubernetes 维护者的沉重负担。dockershim 一直都是 Kubernetes 社区为了能让 docker 成为其支持的容器运行时，所维护的一个兼容程序。本次所谓的废弃，也仅仅是 Kubernetes 要放弃对现在 Kubernetes 代码仓库中的 dockershim 的维护支持。而 Docker 本身目前没有实现 CRI，因此是本次事件的问题所在。​

简单了解过 Kubernetes 为什么要弃用 docker 以后，我们需要知道 docker 的弃用，对我们有哪些影响？又有哪些替代方案呢？​

If you are relying on the underlying docker socket (/var/run/docker.sock) as part of a workflow within your cluster today, moving to a different runtime will break your ability to use it. Make sure no privileged Pods execute Docker commands. Check that scripts and apps running on nodes outside of Kubernetes infrastructure do not execute Docker commands. Third-party tools that perform above mentioned privileged operations. Make sure there is no indirect dependencies on dockershim behavior.

对使用者来说，Kbernetes 的此举决定会影响依赖 docker.sock 的应用程序及事件流（比如 kubelet 的 container-runtime-endpoint 参数），影响执行 docker 命令和那些对 dockershim 组件的依赖。​

缘生

有哪些替代方案呢？

替代方案 1：Containerd

cri plugin 是 containerd 的原生插件，从 containerd v1.1 开始， CRI 插件内置在发布的 containerd 二进制文件中。

containerd 部署​

cat <

替代方案 2：CRI-O

CRI-O 部署​

# 创建 .conf 文件以在启动时加载模块 cat <

用在当下

对于当前正在运行的 K8s 集群，如何更改容器运行时呢？我们以 cri-o 为例：​

pod 迁移

# 为需要更改 CRI 的 node 节点添加污点，释放节点上的所有 pod ，并且不在接收新的 pod 请求 kubectl drain [node-name] --force --ignore-daemonsets --delete-local-data # 停用 docker ，启用 cri-o，更改 kubelet --container-runtime-endpoint=/run/crio/crio.sock # 查看 node 状态，确认无问题后， kubectl get node # 恢复 node 节点，接收新的 pod 请求 kubectl uncordon [node-name]

# kubectl drain izj6cco138rpkaoqqn6ldnz --force --ignore-daemonsets --delete-local-data node/izj6cco138rpkaoqqn6ldnz cordoned WARNING: ignoring DaemonSet-managed Pods: calico-system/calico-node-7l4gc, kube-system/kube-proxy-kztbh evicting pod default/kube-demo-7456947cdc-wmqb5 evicting pod default/kube-demo-7456947cdc-kfrqr evicting pod calico-system/calico-typha-5f84f554ff-hzxbg pod/calico-typha-5f84f554ff-hzxbg evicted pod/kube-demo-7456947cdc-wmqb5 evicted pod/kube-demo-7456947cdc-kfrqr evicted node/izj6cco138rpkaoqqn6ldnz evicted

# vim /var/lib/kubelet/kubeadm-flags.env KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k9s.gcr.io/pause:3.2 --resolv-conf=/run/systemd/resolve/resolv.conf --container-runtime=remote --container-runtime-endpoint=/run/crio/crio.sock"

参考资料

《Don't Panic: Kubernetes and Docker》：

Deprecation FAQ》：

started with containerd》：

GitHub 地址：

GitHub 地址：

欢迎参与开源

Erda Github 地址：https://github.com/erda-project/erda Erda Cloud 官网：https://erda.cloud/

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。