> 原文連結：[https://fuckcloudnative.io/posts/getting-started-with-containerd/](https://fuckcloudnative.io/posts/getting-started-with-containerd/) ## 1. Containerd 的前世今生 很久以前，Docker 強勢崛起，以“映象”這個大招席捲全球，對其他容器技術進行致命的降維打擊，使其毫無招架之力，就連 Google 也不例外。Google 為了不被拍死在沙灘上，被迫拉下臉面（當然，跪舔是不可能的），希望 Docker 公司和自己聯合推進一個開源的容器執行時作為 Docker 的核心依賴，不然就走著瞧。Docker 公司覺得自己的智商被侮辱了，走著瞧就走著瞧，誰怕誰啊！ 很明顯，Docker 公司的這個決策斷送了自己的大好前程，造成了今天的悲劇。 緊接著，Google 聯合 Red Hat、IBM 等幾位巨佬連哄帶騙忽悠 Docker 公司將 `libcontainer` 捐給中立的社群（OCI，Open Container Intiative），並改名為 `runc`，不留一點 Docker 公司的痕跡~~ 這還不夠，為了徹底扭轉 Docker 一家獨大的局面，幾位大佬又合夥成立了一個基金會叫 `CNCF`（Cloud Native Computing Fundation），這個名字想必大家都很熟了，我就不詳細介紹了。CNCF 的目標很明確，既然在當前的維度上幹不過 Docker，乾脆往上爬，升級到大規模容器編排的維度，以此來擊敗 Docker。 Docker 公司當然不甘示弱，搬出了 Swarm 和 Kubernetes 進行 PK，最後的結局大家都知道了，Swarm 戰敗。然後 Docker 公司耍了個小聰明，將自己的核心依賴 `Containerd` 捐給了 CNCF，以此來標榜 Docker 是一個 PaaS 平臺。 很明顯，這個小聰明又大大加速了自己的滅亡。  巨佬們心想，想當初想和你合作搞箇中立的核心執行時，你死要面子活受罪，就是不同意，好傢伙，現在自己搞了一個，還捐出來了，這是什麼操作？也罷，這倒省事了，我就直接拿 `Containerd` 來做文章吧。 首先呢，為了表示 Kubernetes 的中立性，當然要搞個標準化的容器執行時介面，只要適配了這個介面的容器執行時，都可以和我一起玩耍哦，第一個支援這個介面的當然就是 `Containerd` 啦。至於這個介面的名字，大家應該都知道了，它叫 CRI（Container Runntime Interface）。 這樣還不行，為了蠱惑 Docker 公司，Kubernetes 暫時先委屈自己，專門在自己的元件中集成了一個 `shim`（你可以理解為墊片），用來將 CRI 的呼叫翻譯成 Docker 的 API，讓 Docker 也能和自己愉快地玩耍，溫水煮青蛙，養肥了再殺。。。 就這樣，Kubernetes 一邊假裝和 Docker 愉快玩耍，一邊背地裡不斷優化 Containerd 的健壯性以及和 CRI 對接的絲滑性。現在 Containerd 的翅膀已經完全硬了，是時候卸下我的偽裝，和 Docker say bye bye 了。後面的事情大家也都知道了~~ Docker 這門技術成功了，Docker 這個公司卻失敗了。 ## 2. Containerd 架構 時至今日，Containerd 已經變成一個工業級的容器執行時了，連口號都有了：超簡單！超健壯！可移植性超強！ 當然，為了讓 Docker 以為自己不會搶飯碗，Containerd 聲稱自己的設計目的主要是為了嵌入到一個更大的系統中（暗指 Kubernetes），而不是直接由開發人員或終端使用者使用。 事實上呢，Containerd 現在基本上啥都能幹了，開發人員或者終端使用者可以在宿主機中管理完整的容器生命週期，包括容器映象的傳輸和儲存、容器的執行和管理、儲存和網路等。大家可以考慮學起來了。 **學習 Containerd 最好的時機是關注公眾號 雲原生實驗室 後，其次是現在，看完了再關注公眾號也不遲