近日 K8s 官方稱最早將在 1.23版本棄用 docker 作為容器執行時，並在部落格中強調可以使用如 containerd 等 CRI 執行時來代替 docker。本文會做詳細解讀，並介紹 docker 與 containerd 的關係，以及為什麼 containerd 是更好的選擇。這裡先回答下TKE使用者關心的問題：我們的叢集該怎麼辦？

## TKE叢集該怎麼辦

- TKE早在 2019年5月就已經支援選擇 containerd 作為容器執行時。如果新建叢集，推薦選擇 containerd 作為容器執行時
- 已有叢集在升級到 K8s 1.23（假定 TKE 第一個不支援 dockershim 的 K8s版本，也可能是 1.24）之前，仍然可以繼續使用 docker 作為容器執行時
- 已有叢集透過 TKE 叢集升級功能升級到 1.23時， TKE會提供切換執行時為 containerd 的選項。當然，這種情況下沒辦法做到 Pod 不受影響，只能採用重灌節點的方式來升級
- 已有叢集也可以將執行時切換為 containerd ，新增節點會使用 containerd ， 存量節點不受影響仍然使用 docker （注意： 這會造成同一叢集中 docker 節點與 containerd 節點共存，如果有使用 Docker in Docker， 或者其他依賴節點上 docker daemon 與 docker.sock 的業務，需要提前採取措施來避免產生問題，例如透過按節點標籤排程，保證這類業務排程到 docker 節點；或者採用如前文所述在 containerd 叢集執行 Docker in Docker 的方案）
- 當然，在未來 docker 也有可能在內部實現 CRI 或者新增一個 dockershim 程式，如果 docker 做了相應適配，TKE 這邊在未來也會進行支援。

## 解讀 K8s 棄用 dockershim

> Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. ([#94624](https://github.com/kubernetes/kubernetes/pull/94624), [@dims](https://github.com/dims)) [SIG Node]

K8s 在 1.20的 change log 中提到 K8s 將於 1.20版本開始逐步放棄對 Docker 的支援。在 K8s 的官方部落格中也提到具體的宣告和一些 FAQ。

- [Don't Panic: Kubernetes and Docker](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)
- [Dockershim FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/)

在部落格中提到 K8s 將在 **1.20**版本中新增不推薦使用 docker 的資訊，且最早將於 **1.23**版本中把 dockershim 從 kubelet 中移除，屆時使用者將無法使用 docker 作為 K8s 叢集的執行時，不過透過 docker 構建的映象在沒有 docker 的 K8s 叢集中依然可以使用。

### “寄生”在 kubelet 中的 dockershim

本次改動主要內容是準備刪除 kubelet 中的 dockershim，當然這種做法也是符合預期的。在早期 rkt 和 docker 爭霸時，kubelet 中需要維護兩坨程式碼分別來適配 docker 和 rkt ，這使得 kubelet 每次釋出新功能都需要考慮對執行時元件的適配問題，嚴重拖慢了新版本釋出速度。另外虛擬化已經是一個普遍的需求，如果出現了型別的執行時，SIG-Node 小組可能還需要把和新執行時適配的程式碼新增到 kubelet 中。這種做法並不是長久之計，於是在 2016 年，SIG-Node提出了容器操作介面 **CRI**（Container Runtime Interface）。 CRI 是對容器操作的一組抽象，只要每種容器執行時都實現這組介面，kubelet 就能透過這組介面來適配所有的執行時。但 Docker 當時並沒有（也不打算）實現這組介面， kubelet 只能在內部維護一個稱之為“dockershim”元件，這個元件充當了 docker 的 CRI 轉接器，kubelet 在建立容器時透過 CRI 介面呼叫 dockershim ，而 dockershim 在透過 http 請求把請求交給 docker 。於是 kubelet 的架構變成下圖這樣：
![](https://main.qcloudimg.com/raw/09825f094a71cebddc01a101ff35a795.png)
 在使用實現了 CRI 介面的元件作為容器執行時的情況下，kubelet 建立容器的呼叫鏈如圖中紅色箭頭所示，kubelet 中的 ContainerManager 可以直接透過 CRI 呼叫到容器執行時，這過程中只需要一次 grpc 請求；而在使用 docker 時，ContainerManager 會走圖中藍色的呼叫鏈， CRI 的請求透過 unix:///var/run/dockershim.sock 流向 dockershim，dockershim 做轉換後把請求轉發給 docker，至於為什麼 docker 後面還有個 containerd 稍後會講到。在 kubelet 中實現 docker 的轉接器本來就是一種不優雅的實現，這種做法讓呼叫鏈變長且不穩定性，還給 kubelet 的維護新增了額外工作，把這部分內容從 kubelet 刪掉就是時間問題了。

### 棄用 Docker 後會有什麼不同？

> If you’re an end-user of Kubernetes, not a whole lot will be changing for you. This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or shouldn’t, use Docker as a development tool anymore. Docker is still a useful tool for building containers, and the images that result from running `docker build` can still run in your Kubernetes cluster.

訊息一出，大家最關心的事情應該就是棄用 docker 後到底會產生什麼影響？

官方的答覆是：Don't Panic！隨後又重點解釋了幾個大家最關心的問題，我們來分析下官方提到的這些方面：

- 正常的 K8s 使用者不會有任何影響

是的，生產環境中高版本的叢集只需要把執行時從 docker 切換到其他的 runtime（如 containerd）即可。containerd 是 docker 中的一個底層元件，主要負責維護容器的生命週期，跟隨 docker 經歷了長期考驗。同時 2019年初就從 CNCF 畢業，可以單獨作為容器執行時用在叢集中。TKE 也早在 2019 年就已經提供了 containerd 作為執行時選項，因此把 runtime 從 docker 轉換到 containerd 是一個基本無痛的過程。CRI-O  是另一個常被提及的執行時元件，由 redhat 提供，比 containerd 更加輕量級，不過和 docker 的區別較大，可能轉換時會有一些不同之處。

- 開發環境中透過`docker build`構建出來的映象依然可以在叢集中使用

映象一直是容器生態的一大優勢，雖然人們總是把映象稱之為“docker映象”，但映象早就成為了一種規範了。具體規範可以參考[image-spec](https://github.com/opencontainers/image-spec)。在任何地方只要構建出符合 Image Spec 的映象，就可以拿到其他符合 Image Spec 的容器執行時上執行。

- 在 Pod 中使用 DinD（Docker in Docker）的使用者會受到影響

有些使用者會把 docker 的 socket (/run/docker.sock)掛載到 Pod 中，並在 Pod 中呼叫 docker 的 api 構建映象或建立編譯容器等，官方在這裡的建議是使用 Kaniko、Img 或 Buildah。我們可以透過把 docker daemon 作為 DaemonSet 或者給想要使用 docker 的 Pod 新增一個 docker daemon 的 sidecar 的方式在任意執行時中使用 DinD 的方案。TKE 也專門為在 containerd 叢集中使用 DinD 提供了方案，詳見 [在containerd中使用DinD](https://iwiki.woa.com/pages/viewpage.action?pageId=434358993)。

## containerd 的今生前世

所以 containerd 到底是個啥？和 docker 又是什麼關係？可能有些同學看到部落格後會發出這樣的疑問，接下來就給同學們講解下 containerd 和 docker 的淵源。

### docker 與 containerd

2016年，docker 把負責容器生命週期的模組拆分出來，並將其捐贈給了社群，也就是現在的 containerd。docker 拆分後結構如下圖所示（當然 docker 公司還在 docker 中新增了部分編排的程式碼）。
![](https://main.qcloudimg.com/raw/77f7de41b247d5cad5b605d1a209d0ee.png)
 在我們呼叫 docker 命令建立容器後，docker daemon 會透過 Image 模組下載映象並儲存到 Graph Driver 模組中，之後透過 client 呼叫containerd 建立並執行容器。我們在使用 docker 建立容器時可能需要使用`--volume`給容器新增持久化儲存；還有可能透過`--network`連線我們用 docker 命令建立的幾個容器，當然，這些功能是 docker 中的 Storage 模組和 Networking 模組提供給我們的。但 K8s 提供了更強的卷掛載能力和叢集級別的網路能力，在叢集中 kubelet 只會使用到 docker 提供的映象下載和容器管理功能，而編排、網路、儲存等功能都不會用到。下圖中可以看出當前的模式下各模組的呼叫鏈，同時圖中被紅框標註出的幾個模組就是 kubelet 建立 Pod 時所依賴的幾個執行時的模組。
![](https://main.qcloudimg.com/raw/d68f145088728809cfd3c96110f55b51.png)
 containerd 被捐贈給CNCF社群後，社群給其新增了映象管理模組和 CRI 模組，這樣 containerd 不只可以管理容器的生命週期，還可以直接作為 K8s 的執行時使用。於是 containerd 在 2019年2月從 CNCF 社群畢業，正式進入生產環境。下圖中能看出以 containerd 作為容器執行時，可以給 kubelet 帶來建立 Pod 所需的全部功能，同時還得到了更純粹的功能模組以及更短的呼叫鏈。
![](https://main.qcloudimg.com/raw/4bfa0c8427971843144fe452c6c329da.png)
 從上面的對比可以看出從 containerd 被捐贈給社群開始，就一直以成為簡單、穩定且可靠的容器執行時為目標；而 docker 則是希望能成為一個完整的產品。官方文件中也提到了這一點，docker 為了給使用者更好的互動和使用體驗以及更多的功能，提供了很多開發人員所需要的特性，同時為了給 swarm 做基礎，提供了網路和卷的功能。而這些功能其實都是是 K8s 用不上的；containerd 則相反，僅提供了 kubelet 建立 Pod 所需要的基礎功能，當然這換來的就是更高的魯棒性以及更好的效能。在一定程度上講，即使在 kubelet 1.23 版本之後 docker 提供了 CRI 介面，containerd 仍然是更好的選擇。

### 在 Kubernetes 叢集中使用 containerd

當然現在有諸多的 CRI 實現者，比較主要的除了 containerd 還有 CRI-O。CRI-O 是主要由 Red Hat 員工開發的 CRI 執行時，完全和 docker 沒有關係，因此從 docker 遷移過來可能會比較困難。無疑 containerd 才是 docker 被拋棄後的 CRI 執行時的最佳人選，對於開發同學來說整個遷移過程應該是無感知的，不過對於部分運維同學可能會比較在意部署和執行中細節上的差異。接下來我們重點介紹下在 K8s 中使用 containerd 和 docker 的幾處區別。

- 容器日誌對比項

| 對比項                 | Docker                                                       | Containerd                                                   |
| ---------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 儲存路徑               | 如果 docker 作為 K8s 容器執行時，容器日誌的落盤將由 docker 來完成，儲存在類似/var/lib/docker/containers/$CONTAINERID 目錄下。kubelet 會在 /var/log/pods 和 /var/log/containers 下面建立軟連結，指向 /var/lib/docker/containers/$CONTAINERID 該目錄下的容器日誌檔案。 | 如果 Containerd 作為 K8s 容器執行時， 容器日誌的落盤由 kubelet 來完成，儲存至 /var/log/pods/$CONTAINER_NAME 目錄下，同時在 /var/log/containers 目錄下建立軟連結，指向日誌檔案。 |
| 配置引數               | 在 docker 配置檔案中指定："log-driver": "json-file","log-opts": {"max-size": "100m","max-file": "5"} | 方法一：在 kubelet 引數中指定：--container-log-max-files=5 --container-log-max-size="100Mi" 方法二：在 KubeletConfiguration 中指定： "containerLogMaxSize": "100Mi", "containerLogMaxFiles": 5, |
| 把容器日誌儲存到資料盤 | 把資料盤掛載到 “data-root”（預設是 /var/lib/docker）即可。   | 建立一個軟連結 /var/log/pods 指向資料盤掛載點下的某個目錄。在 TKE 中選擇“將容器和映象儲存在資料盤”，會自動建立軟連結 /var/log/pods。 |

- cni 配置方式的區別
  在使用 docker 時，kubelet 中的 dockershim 負責呼叫 cni 外掛，而 containerd 的場景中 containerd 中內建的 containerd-cri 外掛負責呼叫 cni，因此關於 cni 的配置檔案需要放在 containerd 的配置檔案中（/etc/containerd/containerd.toml）：

```
   [plugins.cri.cni]
        bin_dir = "/opt/cni/bin"
        conf_dir = "/etc/cni/net.d"
  ```

- stream 服務的區別

> 說明：
  >
  > Kubectl exec/logs 等命令需要在 apiserver 跟容器執行時之間建立流轉發通道。

**如何在 containerd 中使用並配置 Stream 服務？**

Docker API 本身提供 stream 服務，kubelet 內部的 docker-shim 會透過 docker API 做流轉發。而containerd 的 stream 服務需要單獨配置：

```
    [plugins.cri]
    stream_server_address = "127.0.0.1"
    stream_server_port = "0"
    enable_tls_streaming = false  [plugins.cri]  stream_server_address = "127.0.0.1"  stream_server_port = "0"  enable_tls_streaming = false
  ```

### K8s 1.11 前後版本配置區別是什麼？

containerd 的 stream 服務在 K8s 不同版本執行時場景下配置不同。

- 在 K8s 1.11 之前：
  kubelet 不會做 stream proxy，只會做重定向。即 kubelet 會將 containerd 暴露的 stream server 地址傳送給 apiserver，並讓 apiserver 直接訪問 containerd 的 stream 服務。此時，您需要給 stream 服務轉發器認證，用於安全防護。
- 在 K8s 1.11 之後：
  K8s1.11 引入了 [kubelet stream proxy](https://github.com/kubernetes/kubernetes/pull/64006)， 使 containerd stream 服務只需要監聽本地地址即可。

## 在 TKE 叢集中使用 containerd

從 2019年5月份開始，TKE就開始支援把 containerd 作為容器執行時選項之一。隨著TKE逐步在 containerd 叢集中支援日誌收集服務和 GPU 能力，2020年 9月份 containerd 在 TKE 也摘掉了 Beta 版本的標籤，可以正式用於生產環境中了。在長期使用中，我們也發現了一些 containerd 的問題並且及時進行了修復，如：

- [由於錯誤處理問題導致的 Pod Terminating](https://mp.weixin.qq.com/s/vh0Q0w0FSmYFTKrevGVxBg)
- [由於核心版本問題導致映象檔案丟失](https://mp.weixin.qq.com/s/6e8E1-NBGgZm-Q_mS6tPzg)

想要在TKE叢集中使用 containerd 作為執行時有三種方式：

1. 在建立叢集時，選擇 1.12.4 及以上版本的 K8s 後，選擇 containerd 為執行時元件即可

![](https://main.qcloudimg.com/raw/c0a0ee13cb245b978be08a2a4d9f1f99.png)

2. 在已有 docker 叢集中，透過建立執行時為 containerd 的節點池來建立一部分 containerd 節點（新建節點池 > 更多設定 > 執行時元件）

![](https://main.qcloudimg.com/raw/de8eaa20103374bfad04390b06d5a980.png)

3. 在已有 docker 叢集中，修改叢集或者節點池的"執行時元件"屬性為"containerd"
   ![](https://main.qcloudimg.com/raw/a3c101a58e2041eada96eec5cf0bd077.png)

**注意：** 後兩種方式會造成同一叢集中 docker 節點與 containerd 節點共存，如果有使用 Docker in Docker， 或者其他依賴節點上 docker daemon 與 docker.sock 的業務，需要提前採取措施來避免產生問題，例如透過按節點標籤排程，保證這類業務排程到 docker 節點；或者採用如前文所述在 containerd 叢集執行 Docker in Docker 的方案。

現階段關於 containerd 和 docker 選擇問題可以檢視[這裡](https://cloud.tencent.com/document/product/457/35747)。

## 參考

[1] [Don't Panic: Kubernetes and Docker](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/)

[2] [Dockershim FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/)

[3] [Dockershim Removal Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim)

[4] [kubernetes CHANGELOG-1.20](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)

K8s 終將廢棄 docker，TKE 早已支援 containerd

相關文章