Docker Containerd與RunC歷史演變促進K8s編排變革深刻研究-Docker商業環境實戰

專一於大數據及容器雲核心技術解密，可提供全棧的大數據+雲原平生臺諮詢方案，請持續關注本套博客。若有任何學術交流，可隨時聯繫。更多內容請關注《數據雲技術社區》公衆號。

1 Docker已不是Docker

1.1 核心大事件

• 2013年：Docker公司在2013年推出Docker後，極大的顛覆了這個行業，也推動了業務容器化過程。
• 2015年：Docker公司主導之下社區推出了容器的第一個行業標準OCI標準（開放容器協議），彼時Docker公司推出了第一個OCI標準的容器運行時runc。
• 2016年，Docker 分拆了 containerd，並將其捐贈給了社區。將這個組件分解爲一個單獨的項目，使得 docker 將容器的管理功能移出 docker 的核心引擎並移入一個單獨的守護進程(即 containerd)。
• 在2017年發佈的Containerd1.0

1.2 Docker發展演變

• Docker 1.9 推出swarm，做爲獨立工具，用於集羣管理和服務編排
• Docker 1.11 推出containerd和runc。（2016）
• Docker 1.12 swarm進入引擎
• Docker 17.06 引擎社區改名爲moby，docker社區版本改名爲docker-ce（相似於紅帽的fedora和rhel）
• Docker 17.12 Docker正式引入containerd 1.0（2017）
• Docker 18.06 正式在engine里加入了buildkit，在設置一個環境變量後可使用buildkit完成docker build過程。
• Docker 18.06.1正式將containerd 1.1引入docker。

1.3 Docker總體架構技術圖

1.4 最新演變架構整體圖

2 containerd項目-CNCF正式宣佈畢業

• (美國時間2019年2月28日，CNCF正式宣佈containerd畢業了！)
• 2014年，containerd誕生於Docker，最初它是Docker引擎的底層運行時管理器。
• 繼2017年3月被CNCF接受以後，containerd已經成爲一個行業標準的容器運行時，它簡單、穩定、有良好的可移植性，最普遍的使用方式是做爲Docker引擎和OCI runc執行器之間的層。
• containerd是繼Kubernetes、Prometheus、Envoy和CoreDNS以後，第五個從CNCF畢業的項目。從孵化成熟階段開始，要想最終畢業，項目必須表現出高度的多樣性，被大量用戶普遍使用，擁有正式的治理過程，而且面向整個開源社區堅持其可持續性及包容性。
• containerd獨立負責容器運行時和生命週期（如建立、啓動、中止、停止、信號處理、刪除等），其餘一些如鏡像構建、卷管理、日誌等由Docker Daemon的其餘模塊處理。

  

2.1 子系統

• distribute子系統 ->該服務實現取去鏡像功能
• bundle子系統 ->該服務容許用戶從磁盤映像中提取鏡像和打包成bundle
• runtime子系統->該服務實現bundles的執行， 包括運行時容器的建立。

2.2 組件

• Executor組件->實際容器運行時的執行器
• Supervisor組件->監視和報告容器狀態
• Metadata組件->將元數據存儲在圖形數據庫中。用於存儲對鏡像和bundle的任何持久性引用。輸入到數據庫的數據將具備在組件之間協調的模式，以提供對任意數據的訪問。其餘功能包括定義了用於磁盤資源的垃圾回收的鉤子。
• Content組件->提供對content addressable storage （鏡像的層文件）的訪問，全部不可變的內容將存儲在這裏，經過內容的hash索引。
• Snapshot組件->管理容器映像的文件系統快照。這相似於Docker中的graphdriver。圖層被解包到快照中
• Events組件->支持事件的收集和使用，以提供一致的，事件驅動的行爲和審計。
• Metrics組件->每一個組件將導出幾個指標，可經過指標API訪問。

2.3 bundle數據流

• 指示Distribution組件拉取一個指定的鏡像；
• Distribution組件將鏡像的content放入content組件中存儲；
• 將鏡像名字和根清單指針向metadata組件存儲註冊；
• bundle組件解壓鏡像爲一個bundle；
• 根據上面content組件中存儲，將鏡像的層文件解壓到snapshot 組件中；
• 當一個容器的rootfs的snapshot準備好時，bundle組件使用鏡像清單指針和配置來準備執行全部的配置；
• 將準備好的bundle傳遞給runtime子系統執行；
• runtime子系統讀取bundle配置，建立一個運行容器。

2.4 K3s誕生

• 史上最輕量的、開源Kubernetes發行版，正是使用containerd代替Docker做爲運行時的容器引擎。K3s只有40M大小，經過用containderd替換Docker，K3s顯著減小了運行時佔用空間，刪除libnetwork、swarm、Docker存儲驅動程序和其餘插件等功能。

  

3 runC項目-OCI標準的參考實現

• OCI定義了容器運行時標準，runC是Docker按照開放容器格式標準（OCF, Open Container Format）制定的一種具體實現。
• Open Container Initiative，也就是常說的OCI，是由多家公司共同成立的項目，並由linux基金會進行管理，致力於container runtime的標準的制定和runc的開發等工做。
• OCI的runtime spec標準中對於容器的狀態描述，以及對於容器的建立、刪除、查看等操做進行了定義。
• runc，是對於OCI標準的一個參考實現，是一個能夠用於建立和運行容器的CLI(command-line interface)工具。runc直接與容器所依賴的cgroup/linux kernel等進行交互，負責爲容器配置cgroup/namespace等啓動容器所需的環境，建立啓動容器的相關進程。

4 kubernetes與容器的演變

4.1 核心大事件

• 2017年1.5版本cri接口的推出

4.2 CRI演變階段劃分

• 階段一
• kubernetes在初期版本里，就對多個容器引擎作了兼容，所以可使用docker、rkt對容器進行管理。以docker爲例，kubelet中會啓動一個docker manager，經過直接調用docker的api進行容器的建立等操做。
• 階段二
• 在k8s 1.5版本以後，kubernetes推出了本身的運行時接口api--CRI(container runtime interface)。cri接口的推出，隔離了各個容器引擎之間的差別，而經過統一的接口與各個容器引擎之間進行互動。
• 階段三
• docker獨立出來了containerd。kubernetes也順應潮流，孵化了cri-containerd項目，用以將containerd接入到cri的標準中。

  

• 階段四(持續關注)
• 爲了進一步與oci進行兼容，kubernetes還孵化了cri-o，成爲了架設在cri和oci之間的一座橋樑。經過這種方式，能夠方便更多符合oci標準的容器運行時，接入kubernetes進行集成使用。能夠預見到，經過cri-o，kubernetes在使用的兼容性和普遍性上將會獲得進一步增強。

  

4.3 containerd輕量化的優點

• Containerd的範圍比Docker小得多，它提供golang的客戶端API，更加關注於可嵌入化。更小的範圍意味着更小的代碼基，更易於維護和支持，和Kubernetes的需求匹配見下表：

  

4.4 Cri-containerd項目發佈及做用

• Cri-containerd v1.0.0-alpha.0在2017年9月25號發佈。
• Cri-containerd使用containerd來管理完整的容器生命週期和全部容器鏡像。正以下圖所示，Cri-containerd經過CNI（另外一個CNCF的項目）管理pod網絡。

  

• Kubelet調用Cri-containerd，經過CRI運行時服務API，來建立pod；
• Cri-containerd使用containerd建立而且啓動一個特定的pause容器（沙箱容器），而且將該容器放到pod的cgroup和命名空間裏（簡化起見跳過這裏的詳細步驟）；
• Cri-containerd使用CNI配置pod的網絡命名空間；
• Kubelet接下來經過CRI鏡像服務API調用Cri-containerd，來拉取應用程序容器鏡像；
• 若是該鏡像不在這個節點上，Cri-containerd就會使用containerd來拉取鏡像；
• Kubelet隨後經過CRI運行時服務API來調用Cri-containerd，在pod內部，使用拉取下來的容器鏡像，建立而且啓動應用程序容器；
• Cri-containerd最終調用containerd建立出應用程序容器，將其放入pod的cgroup和命名空間裏，而且啓動pod的全新的應用程序容器。

總結

專一於大數據及容器雲核心技術解密，可提供全棧的大數據+雲原平生臺諮詢方案，請持續關注本套博客。若有任何學術交流，可隨時聯繫。更多內容請關注《數據雲技術社區》公衆號。