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

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

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的全新的應用程序容器。

總結

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

相關文章
相關標籤/搜索