![](https://img-blog.csdnimg.cn/20210701100626307.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

作者 ｜ 張攀（豫哲）
來源 ｜ [爾達 Erda 公眾號](https://mp.weixin.qq.com/s/mE31G8L3a0G75YrZXqMp8Q)

> **導讀**：Erda 作為一站式雲原生 PaaS 平臺，現已面向廣大開發者完成 70w+ 核心程式碼全部開源！**在 Erda 開源的同時，我們計劃編寫《基於 K8s 的雲原生 PaaS 平臺基礎架構》系列文章，希望我們的一點經驗可以幫助更多企業完善 PaaS 平臺基礎架構的建設。本文為系列文的第一篇。

## 緣起
> Kubernetes 在 1.20 版本之後將棄用 Docker 作為容器執行時：
> [https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)

2020 年底，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 進行通訊。這樣就可以愉快地工作了。如下圖所示：

![image.png](https://img-blog.csdnimg.cn/img_convert/18da8c75eca3302218074856d5d796ee.png#clientId=u58469417-2062-4&from=paste&height=86&id=aZoNn&name=image.png&originHeight=86&originWidth=777&originalType=binary&ratio=1&size=20270&status=done&style=none&taskId=u4cf9dc1d-89be-4506-b849-66acb0755ac&width=775.5)

- 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 的棄用，對我們有哪些影響？又有哪些替代方案呢？

> 1. 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.
> 1. Make sure no privileged Pods execute Docker commands.
> 1. Check that scripts and apps running on nodes outside of Kubernetes infrastructure do not execute Docker commands. 
> 1. Third-party tools that perform above mentioned privileged operations.
> 1. Make sure there is no indirect dependencies on dockershim behavior.

對使用者來說，Kbernetes 的此舉決定會影響依賴 docker.sock 的應用程式及事件流（比如 kubelet 的 container-runtime-endpoint 引數），影響執行 docker 命令和那些對 dockershim 元件的依賴。

## 緣生
### 有哪些替代方案呢？

#### 替代方案 1：Containerd

Containerd （[https://containerd.io](https://containerd.io/)）是 Docker 公司在 OCI 成立時，捐獻給 CNCF，目前已經從 CNCF 畢業的開源專案。Containerd 是一個行業標準的容器執行時，強調簡單性、健壯性和可移植性，旨在嵌入到更大的系統中，而不是由開發人員或終端使用者直接使用。Kubernetes 透過 CRI 介面的形式將 Containerd 用作 Kubernetes 叢集的容器執行時，如下圖所示：

![image.png](https://img-blog.csdnimg.cn/img_convert/37d4edc15e942b927ca1034a19ffd3f2.png#clientId=u58469417-2062-4&from=paste&height=86&id=ubf6ed301&name=image.png&originHeight=86&originWidth=543&originalType=binary&ratio=1&size=11875&status=done&style=none&taskId=uc2960eed-e233-4d2a-94cc-cd849ecba31&width=543)

- cri plugin 是 containerd 的原生外掛，從 containerd v1.1 開始， CRI 外掛內建在釋出的 containerd 二進位制檔案中。

**containerd 部署**
****

```
cat <<eof sudo="" tee="" overlay="" br_netfilter="" eof="" modprobe="" sysctl="" cat="" net.bridge.bridge-nf-call-iptables="1" net.ipv4.ip_forward="1" net.bridge.bridge-nf-call-ip6tables="1" docker-ce="" yum="" yum-config-manager="" http:="" containerd="" install="" containerd.io="" mkdir="" config="" default="" true="" ...="" systemdcgroup="true" systemctl="" restart="" crictl="" cri="" k8s="" kubelet="" socket="" docker="" kubernetes="" cri-o="" oci="" container="" initiative="" .conf="" cri-="" o="" version="1.21" os="CentOS_8" curl="" https:="" daemon-reload="" start="" crio="" enable="" kubelet_kubeadm_args="--container-runtime=remote --container-runtime-endpoint=/run/crio/crio.sock --pod-infra-container-image=k8s.gcr.io/pause:3.4.1" registry="" pause="" image="" pod="" node="" kubectl="" drain="" get="" uncordon="" setp1="" setp2="" izj6cco138rpkaoqqn6ldnz="" cordoned="" warning:="" ignoring="" daemonset-managed="" pods:="" calico-system="" kube-system="" evicting="" evicted="" setp3="" setp4="" setp5="" container-runtime-endpoint="" vim="" setp6="" setp7="" master="" pods="" kubeadm.alpha.kubernetes.io="" panic:="" and="" deprecation="" faq="" started="" with="" github="" erda="" paas="" devops="" star="" cloud="">
                        </eof>

系列好文｜ Kubernetes 棄用 Docker，我們該何去何從？

相關文章

系列好文 ｜ Kubernetes 棄用 Docker，我們該何去何從？

相關文章

系列好文｜ Kubernetes 棄用 Docker，我們該何去何從？