共計 3317 個字符，預計需要花費 9 分鐘才能閱讀完成。
本篇內容主要講解“Containerd 的特性有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“Containerd 的特性有哪些”吧!
Containerd 概述
“早在 16 年 3 月，Docker 1.11 的 Docker Engine 里就包含了 containerd，而現在則是把 containerd 從 Docker Engine 里徹底剝離出來，作為一個獨立的開源項目獨立發展，目標是提供一個更加開放、穩定的容器運行基礎設施。和原先包含在 Docker Engine 里 containerd 相比，獨立的 containerd 將具有更多的功能，可以涵蓋整個容器運行時管理的所有需求。
containerd 并不是直接面向最終用戶的，而是主要用于集成到更上層的系統里，比如 Swarm, Kubernetes, Mesos 等容器編排系統。containerd 以 Daemon 的形式運行在系統上，通過 unix domain docket 暴露很低層的 gRPC API，上層系統可以通過這些 API 管理機器上的容器。每個 containerd 只負責一臺機器，Pull 鏡像，對容器的操作（啟動、停止等），網絡，存儲都是由 containerd 完成。具體運行容器由 runC 負責，實際上只要是符合 OCI 規范的容器都可以支持。
對于容器編排服務來說，運行時只需要使用 containerd+runC，更加輕量，容易管理。而獨立之后 containerd 的特性演進可以和 Docker Engine 分開，專注容器運行時管理，可以更穩定。在向后兼容上也可以做的更好，containerd 第一個正式版本 1.0 Release 之后將提供一年的支持，包括安全更新和 Bugfix，而每次升級也會向后兼容一個小版本?！?/p>
Containerd 特性職能單一
通常一個容器運行時需要包括哪些功能特性呢？
這里是 containerd 的架構圖。中間這一層里包含了三個子系統，從這里可以看出 containerd 支持哪些能力
Distribution: 和 Docker Registry 打交道，拉取鏡像
Bundle: 管理本地磁盤上面鏡像的子系統。
Runtime：創建容器、管理容器的子系統。
可以看出 containerd 非常的干凈，提供的都是運行時真正需要的功能。
Cotainerd 只負責容器運行時 和 基本的鏡像管理，和一些普遍需要的支持。
* 容器管理
* 鏡像管理
* 存儲卷管理
* 性能采集
* 日志管理
* 網絡 特性和路線圖
* 支持 OCI 鏡像
* 支持 OCI 運行時（runC）* 支持鏡像的 pull/push 操作
* 容器運行時和生命周期管理
* 網絡原語：創建 / 修改 / 刪除接口
* 讓容器加入已有的 Network Namespace
* 使用“內容可尋址”存儲支持全局鏡像多租戶共享 Namespace 支持
由于需要兼容上層多個編排系統，docker 和 k8s 在一個 node 上可能存在多個 containerd。在不同的命名空間，可以有相同名字的容器。當下載不同 namespace 的鏡像時，可以拿其他 namespace 的鏡像做軟鏈，以節省存儲空間，無需重復下載。
Plugin 模式
好處：功能易擴展。當需要對接上層編排系統時，可以通過插件的方式進行對接。cri-containerd 變成一個插件，可以讓 k8s 直接對接 containerd 的功能。
兩種方式集成：原生代碼集成 和 動態庫的方式。原生代碼集成，顧名思義，就是代碼在一個 repo 里構建成一個二進制文件。所謂動態庫的方式，就是把.so 文件加入規定的目錄下，在不重新編譯 containerd 二進制的情況下，加載某個插件。
Containerd 的 CRI 實現
項目：https://github.com/containerd/cri
原名 cri-containerd: 目前 cri-conainerd 已經變成 containerd 的一個插件。
支持 K8s CRI 規范的所有特性
提供了使用 ansible 和 kubeadm 工具部署 k8s 集群的方法。
Containerd 的 CRI 實現
— 插件化前
缺點：實際上通過 containerd client 調用 containerd，多了一層 grpc 的調用，性能上有損耗。
— 插件化后
功能上沒有變化，性能較大提升。
Containerd CRI 現狀 — Containerd vs docker
優點：
Stability 職責單一，更容易穩定
Compatibility 跟隨 kubernetes 的需求
Neutral Foundation 中立，CNCF 項目之一
Performance
dockershim 的代碼是集成在 kubelet 內部的，dockershim 的作用是把 docker 的接口用 CRI 標準封裝起來。
docker 17.11 版本開始使用 Containerd v1.0
cri-conainerd 已經變成 containerd 的一個插件。
缺點：
User Adaption 調試工具手段相比 docker 還有差距
Maturity 需要時間成熟
性能對比（docker vs containerd）
圖上半部是 docker 的數據, 圖下半部是 containerd 的數據。
第一列，對比 Pod 創建時延，使用 k8s 測試工具 density 創建 50%，90%，99% 的 pod 花費的時間。
第二列，單位時間內能創建多少 pod。
上圖測試創建 105 個 pod，對機器資源的消耗。
分析：一個容器對應一個 dockershim，在 docker 中 dockershim 占用的內存與 containerd 占用內存對比，更小。
未來規劃
進一步優化 * cri-containerd 插件化后再瘦身 * containerd-shim 耗費內存比較多 換一種語言實現？
重要事件
Containerd 原生支持 CRI
項目已經合并，cri-containerd 作為 Containerd 的一個插件，改名 cri，不再獨立存在。
版本：伴隨 kubernetes 1.10，發布 cri-containerd 1.0.0-rc.0 , Containerd 1.1
Plan 2018
secure Pod (kata container etc)
Windows container
性能優化部分 …
Containerd 架構圖
理解這些組件模塊以及之間的關系對修改和擴展系統十分關鍵。
整個架構的目標是為了協調 bundles 的創建和執行。bundles 是指被 Runtime 使用的, 包括配置、元數據、rootfs 數據。bundle 在文件系統上代表運行時容器，簡化為一個目錄。
Code layout 并沒有反映實際的架構。
Subsystems: 外部用戶通過 GRPC API 暴露的服務來進行交互。
Bundle: bundle 服務允許用戶從硬盤鏡像中解壓和打包 bundles.
Runtime: runtime 服務支持 bundles 的執行，包括創建容器運行時
每個子系統有一個以上的 controller 組件、實現了子系統的行為，并通過服務的方式暴露給外部訪問。
Modules
除了子系統之外，還有一些組件可能跨子系統實現。
Executor: 實現了實際容器運行時。
Supervisor: 監控和報告容器狀態。
Metadata: 在 graph db 中存儲元數據。保存與鏡像和 bundles 相關的所有文件。保存在數據庫中的數據有 schema, 包含與模塊間協作入口。還包括回收磁盤空間的垃圾回收 hook。
Content: 提供內容可尋址的存儲。所有不可改變的內容通過 hash key 保存在這里。
Snapshot: 管理文件系統上容器鏡像的快照。類比于 Docker 中的 graphdriver
Events: 支持收集和消費事件，提供一致地以事件驅動的行為和審計。事件可以以多種模型進行重放。
Metrics: 每個組件會導出多個 metrics，通過 metrics API 訪問。
Client-side Subsystems
Distribution: 提供上傳和下載鏡像的功能
創建 bundle 的 data-flow
到此，相信大家對“Containerd 的特性有哪些”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
