Kube.NETes1.24版本發布時，正式宣布棄用Dockershim，轉向ContAInerd作為默認的容器運行環境。Kubernetes以CRI(Container Runtime Interface)容器運行時接口制定接入準則，用戶可以使用Containerd、CRI-O、CRI- Dockerd及其他容器運行時作為Kubernetes的容器引擎。
Kubernetes為何棄用Dockershim？
Docker在早期沒有實現Container Runtime Interface (CRI)，而CRI是Kubernetes后來增加的對額外運行時的支持標準。Dockershim的存在是為了支持將Docker硬編碼到Kubernetes中，但隨著容器化成為行業標準，Kubernetes項目增加了對額外運行時的支持，比如通過Container Runtime Interface (CRI)容器運行時接口來支持運行容器。因此，在Kubernetes1.20版本發布的時候提到未來會棄用Dockershim引擎，而在Kubernetes1.24版本發布時， 正式棄用之。
什么是 Containerd ？
containerd是一種容器運行時引擎，原屬于Docker的組件的一部分，主要提供容器生命周期管理（從創建到銷毀容器）、拉取和推送鏡像、存儲管理（管理鏡像及容器數據的存儲）、調用runc容器運行等，現已由開源社區拆分脫離出來單獨作為容器運行時項目。
在Kubernetes中，Containerd作為容器運行環境，負責管理Pod的生命周期，包括容器的創建、啟動、停止和刪除等操作。與Dockershim相比，Containerd具有更好的性能、更強的可擴展性以及更簡潔的架構。
容器運行底層組件有哪些關系？
Docker Client和Docker Daemon：Docker Client是Docker的客戶端，它可以通過命令行或API向Docker Daemon發送請求。Docker Daemon是Docker的核心組件，負責管理鏡像、容器、網絡和卷等資源，并將Docker API暴露給客戶端。
Docker鏡像和Docker容器：Docker鏡像是只讀的模板，包含了所有用于運行應用程序所需要的代碼、庫文件、環境變量和配置文件等內容。Docker容器是基于Docker鏡像創建的可運行實例。每個容器都是一個獨立的、輕量級的操作系統，它們之間相互隔離并且可以共享主機的內核。
CRI（Container Runtime Interface）和容器運行時：CRI是Kubernetes的容器運行時標準接口，滿足這個標準的所有容器運行時都可以被使用。容器運行時則提供了一個輕量級的容器運行環境，用于創建、啟動和停止容器。
OCI（Open Container Initiative）和runc：OCI是一個開放的容器組織，它制定了容器運行時的規范，包括運行時規范、容器鏡像規范等。runc是OCI標準的一個參考實現，它與容器所依賴的cgroup/linux kernel等進行交互，是容器最終運行的形態之一。
Containerd在Kubernetes的運行變化
在Kubernetes 1.24版本以前，Kubernetes通過調用Docker命令來創建容器。具體來說，Kubernetes將任務發送給Docker客戶端，然后Docker客戶端通過與Docker守護進程（daemon）通信來創建容器。Docker守護進程會通過Image模塊下載鏡像并保存，然后通過client調用containerd創建并運行容器。在這個過程中，如果需要給容器添加持久化存儲，可以使用volume參數；如果需要配置容器網絡，可以通過network參數來實現。
然而，Kubernetes提供了更強大的卷掛載能力和集群級別的網絡能力。在集群中，kubelet只會使用到Docker提供的鏡像下載和容器管理功能，而編排、網絡、存儲等功能都不會用到。
在Kubernetes 1.24版本以后，Containerd作為容器運行時被引入，帶來了創建Pod所需的所有功能。與之前的方案相比，這不僅帶來了更純粹的功能模塊，而且縮短了調用鏈，提高了系統的效率和穩定性。因此，用戶可以使用Containerd、CRI-O、CRI-Dockerd及其他容器運行時作為Kubernetes的容器引擎。
Containerd在Kubernetes中的工作流
- Kubelet通過CRI運行時服務API調用CRI插件來創建Pod。
- CRI創建一個特殊的沙箱容器（pause容器），并將其放置在Pod的Cgroups和NameSpace命名空間中。
- CRI使用CNI配置Pod的網絡命名空間。
- Kubelet隨后通過CRI鏡像服務API調用CRI插件來拉取應用容器鏡像。如果鏡像不存在于節點上，CRI會進一步使用Containerd來拉取鏡像。
- Kubelet通過CRI運行時服務API調用CRI，并使用拉取的容器鏡像在Pod內創建和啟動應用程序容器。
- CRI創建應用程序容器，將其放入Pod的Cgroups和NameSpace中，然后啟動Pod的新應用容器。
在這些步驟之后，一個Pod及其相應的應用程序容器被創建并運行。
Kubernetes棄用Dockershim的影響
容器鏡像，由于Docker鏡像符合OCI規范，因此可以直接使用而不受影響。此外，原鏡像打包方式仍然可用，即使用docker build方式打包鏡像。這意味著用戶在構建和打包鏡像時不需要做出任何改變
Kubernetes中的運行過程，作為終端用戶（Kubernetes使用者）基本也不會有任何影響，因為Kubernetes的使用邏輯沒有任何變化。然而，與Dockershim相關的API接口已經棄用，如果創建了此類CRD，需要注意修改相關代碼。
運維方式，節點后端運維時使用的命令由docker命令改為containerd。如果舊環境使用的是Dockershim引擎，需要先改為containerd運行時再進行升級。運維人員則需要適應新的命令行工具和運行時環境。
Kubernetes棄用Dockershim而采用containerd作為容器運行時對用戶和運維方式會有一些影響，但對于已經符合OCI規范的鏡像和使用docker build方式打包鏡像的用戶來說，基本無感知。
Kubernetes用戶如何應對？
用戶需要按照Kubernetes官方提供的遷移指南進行操作。這包括更新Kubernetes版本、修改Pod配置文件、調整部署流程、更換鏡像管理工具以及重新配置監控和日志采集工具等步驟。在遷移過程中，用戶還需要注意測試新環境的穩定性和性能，確保遷移成功。
在遷移過程中，用戶可能會遇到各種問題，如配置錯誤、兼容性問題、性能下降等。為了解決這些問題，用戶可以參考Kubernetes官方文檔和社區資源，或者向靈雀云的服務團隊尋求幫助和支持。此外，用戶還可以在測試環境中模擬遷移過程，提前發現和解決問題。
遷移到Containerd后，用戶可以對系統進行一系列優化和改進，以提高性能和穩定性。例如，優化Pod的配置和部署流程、使用更高效的網絡配置方式、改進監控和日志采集策略等。此外，用戶還可以關注Kubernetes和Containerd的最新版本和功能更新，及時跟進技術發展趨勢。
結論與展望
Kubernetes棄用Dockershim并轉向Containerd已經成為一個明顯的趨勢信號。對于現有的Kubernetes用戶來說，應盡快了解這一變化的影響和應對策略，找到適合自己的方案并盡早進行改進。未來，Kubernetes與Containerd的發展趨勢將更加緊密地結合在一起，共同推動容器技術的不斷創新和發展。
參考文檔：
- https://kubernetes.io/zh-cn/blog/2022/02/17/dockershim-faq/
- https://kubernetes.io/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/
