前景提要

Docker 技術使用 Linux 內核和內核功能（例如 Cgroups 和 namespaces）來分隔進程，以便各進程相互獨立運行。這種獨立性正是采用容器的目的所在；它可以獨立運行多種進程、多個應用，更加充分地發揮基礎設施的作用，同時保持各個獨立系統的安全性。

為了防止docker一家獨大，docker當年的實現被拆分出了幾個標準化的模塊，標準化的目的是模塊是可被其他實現替換的，不由任何一個廠商控制。

docker由 docker-client ,dockerd,containerd,docker-shim,runc組成，所以containerd是docker的基礎組件之一，docker 對容器的管理和操作基本都是通過 containerd 完成的。那么，containerd 是什么呢？

Containerd 是一個工業級標準的容器運行時（Container Runtime Interface），它強調簡單性、健壯性和可移植性。Containerd 可以在宿主機中管理完整的容器生命周期：容器鏡像的傳輸和存儲、容器的執行和管理、存儲和網絡等。詳細點說，Containerd 負責干下面這些事情：

管理容器的生命周期(從創建容器到銷毀容器)

拉取/推送容器鏡像

存儲管理(管理鏡像及容器數據的存儲)

調用 runC 運行容器(與 runC 等容器運行時交互)

管理容器網絡接口及網絡

從k8s的角度看，可以選擇 containerd 或 docker 作為運行時組件：Containerd 調用鏈更短，組件更少，更穩定，占用節點資源更少調用鏈

containerd 跟 docker 調用關系

配置參數區別

日志配置

stream server
kubectl exec/logs等命令需要在apiserver跟容器運行時之間建立流轉發通道。
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

在k8s 1.11之前，kubelet并不會做stream proxy, 只會做redirect。也就是把containerd暴露的stream server地址告訴apiserver, 讓apiserver直接來訪問containerd的stream server。這種情況下，需要給stream server使能tle認證來做安全防護。

從k8s1.11引入了kubelet stream proxy (https://github.com/kubernetes/kubernetes/pull/64006)， 從而使得containerd stream server只需要監聽本地地址即可。

CNI網絡

命令對比

containerd不支持docker API和docker CLI， 但是可以通過cri-tool實現類似的功能。

拓展閱讀

接下來就是crictl的的常見命令，其中能完全替代docker命令的參照下列表格

crictl對容器生命周期的管理基本已經覆蓋，不過在crictl我們不能完成操作也比較多，比如對鏡像的管理就不屬于它的管理范圍。這部分還得依靠ctr來實現，操作方式同樣可以參照下表

需注意的是，由于Containerd也有namespaces的概念，對于上層編排系統的支持，主要區分了3個命名空間分別是k8s.io、moby和default，以上我們用crictl操作的均在k8s.io命名空間完成如查看鏡像列表就需要加上-n參數

ctr -n k8s.io images list

鏈接：https://www.cnblogs.com/xiexun/p/18268677