溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“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，而每次升級也會向后兼容一個小版本。”
通常一個容器運行時需要包括哪些功能特性呢？
這里是containerd的架構圖。中間這一層里包含了三個子系統，從這里可以看出containerd支持哪些能力
Distribution: 和Docker Registry打交道，拉取鏡像
Bundle: 管理本地磁盤上面鏡像的子系統。
Runtime：創建容器、管理容器的子系統。
可以看出containerd非常的干凈，提供的都是運行時真正需要的功能。
Cotainerd 只負責容器運行時 和 基本的鏡像管理，和一些普遍需要的支持。
* 容器管理 * 鏡像管理 * 存儲卷管理 * 性能采集 * 日志管理 * 網絡
特性和路線圖
* 支持OCI鏡像 * 支持OCI運行時（runC） * 支持鏡像的pull/push操作 * 容器運行時和生命周期管理 * 網絡原語：創建/修改/刪除接口 * 讓容器加入已有的Network Namespace * 使用“內容可尋址”存儲支持全局鏡像多租戶共享
由于需要兼容上層多個編排系統，docker 和 k8s 在一個node上可能存在多個containerd。在不同的命名空間，可以有相同名字的容器。當下載不同namespace的鏡像時，可以拿其他namespace的鏡像做軟鏈，以節省存儲空間，無需重復下載。
好處：功能易擴展。當需要對接上層編排系統時，可以通過插件的方式進行對接。 cri-containerd 變成一個插件，可以讓k8s直接對接containerd的功能。
兩種方式集成：原生代碼集成 和 動態庫的方式。 原生代碼集成，顧名思義，就是代碼在一個repo里構建成一個二進制文件。 所謂動態庫的方式，就是把.so文件加入規定的目錄下，在不重新編譯containerd二進制的情況下，加載某個插件。
項目： https://github.com/containerd/cri
原名cri-containerd:目前 cri-conainerd 已經變成containerd的一個插件。
支持K8s CRI規范的所有特性
提供了使用ansible和kubeadm工具部署k8s集群的方法。
-- 插件化前
缺點：實際上通過containerd client調用 containerd ，多了一層grpc的調用，性能上有損耗。
-- 插件化后
功能上沒有變化，性能較大提升。
優點：
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的數據, 圖下半部是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
性能優化部分...
理解這些組件模塊以及之間的關系對修改和擴展系統十分關鍵。
整個架構的目標是為了協調bundles的創建和執行。bundles是指被Runtime使用的,包括配置、元數據、rootfs數據。bundle在文件系統上代表運行時容器，簡化為一個目錄。
Code layout并沒有反映實際的架構。
Subsystems: 外部用戶通過GRPC API暴露的服務來進行交互。
Bundle: bundle服務允許用戶從硬盤鏡像中解壓和打包bundles.
Runtime: runtime服務支持bundles的執行，包括創建容器運行時
每個子系統有一個以上的controller 組件、實現了子系統的行為，并通過服務的方式暴露給外部訪問。
除了子系統之外，還有一些組件可能跨子系統實現。
Executor: 實現了實際容器運行時。
Supervisor: 監控和報告容器狀態。
Metadata: 在graph db中存儲元數據。保存與鏡像和bundles相關的所有文件。保存在數據庫中的數據有schema,包含與模塊間協作入口。還包括回收磁盤空間的垃圾回收hook。
Content: 提供內容可尋址的存儲。所有不可改變的內容通過hash key保存在這里。
Snapshot: 管理文件系統上容器鏡像的快照。類比于Docker中的 graphdriver
Events: 支持收集和消費事件，提供一致地以事件驅動的行為和審計。事件可以以多種模型進行重放。
Metrics: 每個組件會導出多個metrics，通過metrics API訪問。
Distribution: 提供上傳和下載鏡像的功能
到此，相信大家對“Containerd的特性有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
