容器技術(shù)的發(fā)展背景

近些年來(lái)，容器技術(shù)迅速席卷全球，顛覆了應(yīng)用的開(kāi)發(fā)、交付和運(yùn)行模式，在云計(jì)算、互聯(lián)網(wǎng)等領(lǐng)域得到了廣泛應(yīng)用。其實(shí)，容器技術(shù)在約二十年前就出現(xiàn)了，但直到2013年Docker推出之后才遍地開(kāi)花，其中有偶然因素，也有大環(huán)境造就的必然因素。這里回顧一下容器的產(chǎn)生的背景和發(fā)展過(guò)程。

在電子計(jì)算機(jī)剛出現(xiàn)時(shí)，由于硬件成本高昂，人們?cè)噲D尋找能夠多用戶共享計(jì)算資源的方式，以提高資源利用率和降低成本。在20世紀(jì)60年代，基于硬件技術(shù)的主機(jī)虛擬化技術(shù)出現(xiàn)了。一臺(tái)物理主機(jī)可以被劃分為若干個(gè)小的機(jī)器，每個(gè)機(jī)器的硬件互不共享，并可以安裝各自的操作系統(tǒng)來(lái)使用。20世紀(jì)90年代后期，X86架構(gòu)的硬件虛擬化技術(shù)逐漸興起，可在同一臺(tái)物理機(jī)上隔離多個(gè)操作系統(tǒng)實(shí)例，帶來(lái)了很多的優(yōu)點(diǎn)，目前絕大多數(shù)的數(shù)據(jù)中心都采用了硬件虛擬化技術(shù)。

雖然硬件虛擬化提供了分隔資源的能力，但是采用虛擬機(jī)方式隔離應(yīng)用程序時(shí)，效率往往較低，畢竟還要在每個(gè)虛擬機(jī)中安裝或復(fù)制一個(gè)操作系統(tǒng)實(shí)例，然后把應(yīng)用部署到其中。因此人們探索出一種更輕量的方案——操作系統(tǒng)虛擬化，使面向應(yīng)用的管理更便捷。所謂操作系統(tǒng)虛擬化，就是由操作系統(tǒng)創(chuàng)建虛擬的系統(tǒng)環(huán)境，使應(yīng)用感知不到其他應(yīng)用的存在，仿佛在獨(dú)自占有全部的系統(tǒng)資源，從而實(shí)現(xiàn)應(yīng)用隔離的目的。在這種方式中不需要虛擬機(jī)，也能夠?qū)崿F(xiàn)應(yīng)用彼此隔離，由于應(yīng)用是共享同一個(gè)操作系統(tǒng)實(shí)例的，因此比虛擬機(jī)更節(jié)省資源，性能更好。操作系統(tǒng)虛擬化在不少系統(tǒng)里面也被稱為容器(Container)，下面也會(huì)以容器來(lái)指代操作系統(tǒng)虛擬化。

操作系統(tǒng)虛擬化最早出現(xiàn)在2000年，F(xiàn)reeBSD 4.0推出了Jail。Jail加強(qiáng)和改進(jìn)了用于文件系統(tǒng)隔離的chroot環(huán)境。到了2004年，Sun公司發(fā)布了Solaris 10的Containers，包括Zones和Resource management兩部分。Zones實(shí)現(xiàn)了命名空間隔離和安全訪問(wèn)控制，Resource management實(shí)現(xiàn)了資源分配控制。2007年，Control Groups(簡(jiǎn)稱cgroups)進(jìn)入Linux內(nèi)核，可以限定和隔離一組進(jìn)程所使用的資源(包括CPU、內(nèi)存、I/O和網(wǎng)絡(luò)等)。

2013年，Docker公司發(fā)布Docker開(kāi)源項(xiàng)目，提供了一系列簡(jiǎn)便的工具鏈來(lái)使用容器。毫不夸張地說(shuō)，Docker公司率先點(diǎn)燃了容器技術(shù)的火焰，拉開(kāi)了云原生應(yīng)用變革的帷幕，促進(jìn)容器生態(tài)圈一日千里地發(fā)展。截至2020年，Docker Hub中的鏡像累計(jì)下載了1300億次，用戶創(chuàng)建了約600萬(wàn)個(gè)容器鏡像庫(kù)。從這些數(shù)據(jù)可以看到，用戶正在以驚人的速度從傳統(tǒng)模式切換到基于容器的應(yīng)用發(fā)布和運(yùn)維模式。

2015年，OCI(Open Container Initiative)作為L(zhǎng)inux基金會(huì)項(xiàng)目成立，旨在推動(dòng)開(kāi)源技術(shù)社區(qū)制定容器鏡像和運(yùn)行時(shí)規(guī)范，使不同廠家的容器解決方案具備互操作能力。同年還成立了CNCF，目的是促進(jìn)容器技術(shù)在云原生領(lǐng)域的應(yīng)用，降低用戶開(kāi)發(fā)云原生應(yīng)用的門檻。創(chuàng)始會(huì)員包括谷歌、紅帽、Docker、VMware等多家公司和組織。

CNCF成立之初只有一個(gè)開(kāi)源項(xiàng)目，就是后來(lái)大名鼎鼎的Kubernetes。Kubernetes是一個(gè)容器應(yīng)用的編排工具，最早由谷歌的團(tuán)隊(duì)研發(fā)，后來(lái)開(kāi)源并捐贈(zèng)給了CNCF成為種子項(xiàng)目。由于Kubernetes是廠家中立的開(kāi)源項(xiàng)目，開(kāi)源后得到了社區(qū)用戶和開(kāi)發(fā)者的廣泛參與和支持。到了2018年，Kubernetes已成為容器編排領(lǐng)域事實(shí)上的標(biāo)準(zhǔn)，并成為首個(gè)CNCF的畢業(yè)(graduated)項(xiàng)目。2020年8月，CNCF旗下的開(kāi)源項(xiàng)目增加到了63個(gè)，包括原創(chuàng)于中國(guó)的Harbor等項(xiàng)目。

從容器的發(fā)展歷程可以看到，容器在出現(xiàn)的早期并沒(méi)有得到人們的廣泛關(guān)注，主要原因是當(dāng)時(shí)開(kāi)放的云計(jì)算環(huán)境還沒(méi)出現(xiàn)或者未成為主流。2010年之后，隨著IaaS、PaaS和SaaS等云平臺(tái)逐漸成熟，用戶對(duì)云端應(yīng)用開(kāi)發(fā)、部署和運(yùn)維的效率不斷重視，重新發(fā)掘了容器的價(jià)值，最終促成了容器技術(shù)的盛行。

容器的基本原理

本節(jié)以Linux容器為例，講解容器的實(shí)現(xiàn)原理，主要包括命名空間(Namespace)和控制組(cgroups)。

命名空間

命名空間是Linux操作系統(tǒng)內(nèi)核的一種資源隔離方式，使不同的進(jìn)程具有不同的系統(tǒng)視圖。系統(tǒng)視圖就是進(jìn)程能夠感知到的系統(tǒng)環(huán)境，如主機(jī)名、文件系統(tǒng)、網(wǎng)絡(luò)協(xié)議棧、其他用戶和進(jìn)程等。使用命名空間后，每個(gè)進(jìn)程都具備獨(dú)立的系統(tǒng)環(huán)境，進(jìn)程間彼此感覺(jué)不到對(duì)方的存在，進(jìn)程之間相互隔離。目前，Linux中的命名空間共有6種，可以嵌套使用。

• Mount：隔離了文件系統(tǒng)的掛載點(diǎn)(mount points)，處于不同“mount”命名空間中的進(jìn)程可以看到不同的文件系統(tǒng)。
• Network：隔離進(jìn)程網(wǎng)絡(luò)方面的系統(tǒng)資源，包括網(wǎng)絡(luò)設(shè)備、IPv4和IPv6的協(xié)議棧、路由表、防火墻等。
• IPC：進(jìn)程間相互通信的命名空間，不同命名空間中的進(jìn)程不能通信。
• PID：進(jìn)程號(hào)在不同的命名空間中是獨(dú)立編號(hào)的，不同的命名空間中的進(jìn)程可以有相同的編號(hào)。當(dāng)然，這些進(jìn)程在操作系統(tǒng)中的全局(命名空間外)編號(hào)是唯一的。
• UTS：系統(tǒng)標(biāo)識(shí)符命名空間，在每個(gè)命名空間中都可以有不同的主機(jī)名和NIS域名。
• User：命名空間中的用戶可以有不同于全局的用戶ID和組ID，從而具有不同的特權(quán)。

命名空間實(shí)現(xiàn)了在同一操作系統(tǒng)中隔離進(jìn)程的方法，幾乎沒(méi)有額外的系統(tǒng)開(kāi)銷，所以是非常輕量的隔離方式，進(jìn)程啟動(dòng)和運(yùn)行的過(guò)程在命名空間中和外面幾乎沒(méi)有差別。

控制組

命名空間實(shí)現(xiàn)了進(jìn)程隔離功能，但由于各個(gè)命名空間中的進(jìn)程仍然共享同樣的系統(tǒng)資源，如CPU、磁盤I/O、內(nèi)存等，所以如果某個(gè)進(jìn)程長(zhǎng)時(shí)間占用某些資源，其他命名空間里的進(jìn)程就會(huì)受到影響，這就是“吵鬧的鄰居(noisy neighbors)”現(xiàn)象。因此，命名空間并沒(méi)有完全達(dá)到進(jìn)程隔離的目的。為此，Linux內(nèi)核提供了控制組(Control Groups，cgroups)功能來(lái)處理這個(gè)問(wèn)題。

Linux把進(jìn)程分成控制組，給每組里的進(jìn)程都設(shè)定資源使用規(guī)則和限制。在發(fā)生資源競(jìng)爭(zhēng)時(shí)，系統(tǒng)會(huì)根據(jù)每個(gè)組的定義，按照比例在控制組之間分配資源。控制組可設(shè)定規(guī)則的資源包括CPU、內(nèi)存、磁盤I/O和網(wǎng)絡(luò)等。通過(guò)這種方式，就不會(huì)出現(xiàn)某些進(jìn)程無(wú)限度搶占其他進(jìn)程資源的情況。

Linux系統(tǒng)通過(guò)命名空間設(shè)置進(jìn)程的可見(jiàn)且可用資源，通過(guò)控制組規(guī)定進(jìn)程對(duì)資源的使用量，這樣隔離進(jìn)程的虛擬環(huán)境(即容器)就建立起來(lái)了。

容器運(yùn)行時(shí)

Linux 提供了命名空間和控制組兩大系統(tǒng)功能，它們是容器的基礎(chǔ)。但是，要把進(jìn)程運(yùn)行在容器中，還需要有便捷的SDK或命令來(lái)調(diào)用Linux的系統(tǒng)功能，從而創(chuàng)建出容器。容器的運(yùn)行時(shí)(runtime)就是容器進(jìn)程運(yùn)行和管理的工具。

容器運(yùn)行時(shí)分為低層運(yùn)行時(shí)和高層運(yùn)行時(shí)，功能各有側(cè)重。低層運(yùn)行時(shí)主要負(fù)責(zé)運(yùn)行容器，可在給定的容器文件系統(tǒng)上運(yùn)行容器的進(jìn)程;高層運(yùn)行時(shí)則主要為容器準(zhǔn)備必要的運(yùn)行環(huán)境，如容器鏡像下載和解壓并轉(zhuǎn)化為容器所需的文件系統(tǒng)、創(chuàng)建容器的網(wǎng)絡(luò)等，然后調(diào)用低層運(yùn)行時(shí)啟動(dòng)容器。主要的容器運(yùn)行時(shí)的關(guān)系如下圖所示。

OCI運(yùn)行時(shí)規(guī)范

成立于2015年的OCI是Linux基金會(huì)旗下的合作項(xiàng)目，以開(kāi)放治理的方式制定操作系統(tǒng)虛擬化(特別是Linux容器)的開(kāi)放工業(yè)標(biāo)準(zhǔn)，主要包括容器鏡像格式和容器運(yùn)行時(shí)(runtime)。初始成員包括Docker、亞馬遜、CoreOS、谷歌、微軟和VMware等公司。OCI成立之初，Docker公司為其捐贈(zèng)了容器鏡像格式和運(yùn)行時(shí)的草案及相應(yīng)的實(shí)現(xiàn)代碼。原來(lái)屬于Docker的libcontainer項(xiàng)目被捐贈(zèng)給OCI，成為獨(dú)立的容器運(yùn)行時(shí)項(xiàng)目runC。

OCI運(yùn)行時(shí)規(guī)范定義了容器配置、運(yùn)行時(shí)和生命周期的標(biāo)準(zhǔn)，主流的容器運(yùn)行時(shí)都遵循OCI運(yùn)行時(shí)的規(guī)范，從而提高系統(tǒng)的可移植性和互操作性，用戶可根據(jù)需要進(jìn)行選擇。

首先，容器啟動(dòng)前需要在文件系統(tǒng)中按一定格式存放所需的文件。OCI運(yùn)行時(shí)規(guī)范定義了容器文件系統(tǒng)包(filesystem bundle)的標(biāo)準(zhǔn)，在OCI運(yùn)行時(shí)的實(shí)現(xiàn)中通常由高層運(yùn)行時(shí)下載OCI鏡像，并將OCI鏡像解壓成OCI運(yùn)行時(shí)文件系統(tǒng)包，然后OCI運(yùn)行時(shí)讀取配置信息和啟動(dòng)容器里的進(jìn)程。OCI運(yùn)行時(shí)文件系統(tǒng)包主要包括以下兩部分。

• config.json：這是必需的配置文件，存放于文件系統(tǒng)包的根目錄下。OCI運(yùn)行時(shí)規(guī)范對(duì)Linux、Windows、Solaris和虛擬機(jī)4種平臺(tái)的運(yùn)行時(shí)做了相應(yīng)的配置規(guī)范。
• 容器的根文件系統(tǒng)：容器啟動(dòng)后進(jìn)程所使用的根文件系統(tǒng)，由 config.json 中的root.path屬性確定該文件系統(tǒng)的路徑，通常是“rootfs/”。

然后，在定義文件系統(tǒng)包的基礎(chǔ)上，OCI運(yùn)行時(shí)規(guī)范制定了運(yùn)行時(shí)和生命周期管理規(guī)范。生命周期定義了容器從創(chuàng)建到刪除的全過(guò)程，可用以下三條命令說(shuō)明。

• “create”命令：在調(diào)用該命令時(shí)需要用到文件系統(tǒng)包的目錄位置和容器的唯一標(biāo)識(shí)。在創(chuàng)建運(yùn)行環(huán)境時(shí)需要使用config.json里面的配置。在創(chuàng)建的過(guò)程中，用戶可加入某些事件鉤子(hook)來(lái)觸發(fā)一些定制化處理，這些事件鉤子包括prestart、createRuntime和createContainer。
• “start”命令：在調(diào)用該命令時(shí)需要運(yùn)行容器的唯一標(biāo)識(shí)。用戶可在 config.json 的process 屬性中指明運(yùn)行程序的詳細(xì)信息。“start”命令包括兩個(gè)事件鉤子：startContainer和poststart。
• “delete”命令：在調(diào)用該命令時(shí)需要運(yùn)行容器的唯一標(biāo)識(shí)。在用戶的程序終止后(包括正常和異常退出)，容器運(yùn)行時(shí)執(zhí)行“delete”命令以清除容器的運(yùn)行環(huán)境。“delete”命令有一個(gè)事件鉤子：poststop。

除了上述生命周期命令，OCI運(yùn)行時(shí)還必須支持另外兩條命令。

“state”命令：在調(diào)用該命令時(shí)需要運(yùn)行容器的唯一標(biāo)識(shí)。該命令查詢某個(gè)容器的狀態(tài)，必須包括的狀態(tài)屬性有ociVersion、id、status、pid和bundle，可選屬性有annotation。不同的運(yùn)行時(shí)實(shí)現(xiàn)可能會(huì)有一些差異。下面是一個(gè)容器狀態(tài)的例子：

{ 
    "ociVersion": "1.0.1", 
    "id": "oci-container001", 
    "status": "running", 
    "pid": 8080, 
    "bundle": "/containers/nginx", 
    "annotations": { 
        "key1": "value1" 
    } 
}  

“kill”命令：在調(diào)用該命令時(shí)需要運(yùn)行容器的唯一標(biāo)識(shí)和信號(hào)(signal)編號(hào)。該命令給容器進(jìn)程發(fā)送信號(hào)，如Linux操作系統(tǒng)的信號(hào)9表示立即終止進(jìn)程。

runC

runC是OCI運(yùn)行時(shí)規(guī)范的參考實(shí)現(xiàn)，也是最常用的容器運(yùn)行時(shí)，被其他多個(gè)項(xiàng)目使用，如containerd和CRI-O等。runC也是低層容器運(yùn)行時(shí)，開(kāi)發(fā)人員可通過(guò)runC實(shí)現(xiàn)容器的生命周期管理，避免煩瑣的操作系統(tǒng)調(diào)用。根據(jù)OCI運(yùn)行時(shí)規(guī)范，runC不包括容器鏡像的管理功能，它假定容器的文件包已經(jīng)從鏡像里解壓出來(lái)并存放于文件系統(tǒng)中。runC創(chuàng)建的容器需要手動(dòng)配置網(wǎng)絡(luò)才能與其他容器或者網(wǎng)絡(luò)節(jié)點(diǎn)連通，為此可在容器啟動(dòng)之前通過(guò)OCI定義的事件鉤子來(lái)設(shè)置網(wǎng)絡(luò)。

由于runC提供的功能比較單一，復(fù)雜的環(huán)境需要更高層的容器運(yùn)行時(shí)來(lái)生成，所以runC常常成為其他高層容器運(yùn)行時(shí)的底層實(shí)現(xiàn)基礎(chǔ)。

containerd

在OCI成立時(shí)，Docker公司把其Docker項(xiàng)目拆分為runC的低層運(yùn)行時(shí)及高層運(yùn)行時(shí)功能。2017年，Docker公司把這部分高層容器運(yùn)行時(shí)的功能集中到containerd項(xiàng)目里，捐贈(zèng)給云原生計(jì)算基金會(huì)。

containerd 已經(jīng)成為多個(gè)項(xiàng)目共同使用的高層容器運(yùn)行時(shí)，提供了容器鏡像的下載和解壓等鏡像管理功能，在運(yùn)行容器時(shí)，containerd先把鏡像解壓成OCI的文件系統(tǒng)包，然后調(diào)用runC運(yùn)行容器。containerd提供了API，其他應(yīng)用程序可以通過(guò)API與containerd交互。“ctr”是containerd的命令行工具，和“docker”命令很相像。但作為容器運(yùn)行時(shí)，containerd只注重在容器運(yùn)行等方面，因而不包含開(kāi)發(fā)者使用的鏡像構(gòu)建和鏡像上傳鏡像倉(cāng)庫(kù)等功能。

Docker

Docker引擎是最早流行也是最廣泛使用的容器運(yùn)行時(shí)之一，是一個(gè)容器管理工具，架構(gòu)如下圖所示。Docker的客戶端(命令行CLI工具)通過(guò)API調(diào)用容器引擎Docker Daemon(dockerd)的功能，完成各種容器管理任務(wù)。

Docker引擎在發(fā)布時(shí)是一個(gè)單體應(yīng)用，所有功能都集中在一個(gè)可執(zhí)行文件里，后來(lái)按功能分拆成runC和containerd兩個(gè)不同層次的運(yùn)行時(shí)，分別捐獻(xiàn)給了OCI和CNCF。上面兩節(jié)已經(jīng)分別介紹了runC和containerd的主要特點(diǎn)，剩下的dockerd就是Docker公司維護(hù)的容器運(yùn)行時(shí)。

dockerd同時(shí)提供了面向開(kāi)發(fā)者和面向運(yùn)維人員的功能。其中，面向開(kāi)發(fā)者的命令主要提供鏡像管理功能。容器鏡像一般可由Dockerfile構(gòu)建(build)而來(lái)。Dockerfile是一個(gè)文本文件，通過(guò)一組命令關(guān)鍵字定義了容器鏡像所包含的基礎(chǔ)鏡像(base image)、所需的軟件包及有關(guān)應(yīng)用程序。在Dockerfile編寫完成以后，就可以用“docker build”命令構(gòu)建鏡像了。下面是一個(gè)Dockerfile的簡(jiǎn)單例子：

FROM ubuntu:18.04 
EXPOSE 8080 
CMD ["nginx", "-g", "daemon off;"] 

容器的鏡像在構(gòu)建之后被存放在本地鏡像庫(kù)里，當(dāng)需要與其他節(jié)點(diǎn)共享鏡像時(shí)，可上傳鏡像到鏡像倉(cāng)庫(kù)(Registry)以供其他節(jié)點(diǎn)下載。

Docker還提供了容器存儲(chǔ)和網(wǎng)絡(luò)映射到宿主機(jī)的功能，大部分由containerd實(shí)現(xiàn)。應(yīng)用的數(shù)據(jù)可以被保存在容器的私有文件系統(tǒng)里面，這部分?jǐn)?shù)據(jù)會(huì)隨著容器一起被刪除。對(duì)需要數(shù)據(jù)持久化的有狀態(tài)應(yīng)用來(lái)說(shuō)，可用數(shù)據(jù)卷Volume的方式導(dǎo)入宿主機(jī)上的文件目錄到容器中，對(duì)該目錄的所有寫操作都將被保存到宿主機(jī)的文件系統(tǒng)中。Docker可以把容器內(nèi)的網(wǎng)絡(luò)映射到宿主機(jī)的網(wǎng)絡(luò)上，并且可以連接外部網(wǎng)絡(luò)。

CRI和CRI-O

Kubernetes是當(dāng)今主流的容器編排平臺(tái)，為了適應(yīng)不同場(chǎng)景的需求，Kubernetes需要有使用不同容器運(yùn)行時(shí)的能力。為此，Kubernetes從1.5版本開(kāi)始，在kubelet中增加了一個(gè)容器運(yùn)行時(shí)接口CRI(Container Runtime Interface)，需要接入Kubernetes的容器運(yùn)行時(shí)必須實(shí)現(xiàn)CRI接口。由于kubelet的任務(wù)是管理本節(jié)點(diǎn)的工作負(fù)載，需要有鏡像管理和運(yùn)行容器的能力，因此只有高層容器運(yùn)行時(shí)才適合接入CRI。CRI和容器運(yùn)行時(shí)的關(guān)系如下圖所示。

CRI和容器運(yùn)行時(shí)之間需要有個(gè)接口層，通常稱之為shim(墊片)，用以匹配相應(yīng)的容器運(yùn)行時(shí)。CRI接口由shim實(shí)現(xiàn)，定義如下，分為RuntimeService和ImageServiceManager(代碼參見(jiàn)GitHub上kubernetes/cri-api的項(xiàng)目文件“pkg/apis/services.go”)：

// RuntimeService接口必須由容器運(yùn)行時(shí)實(shí)現(xiàn) 
// 以下方法必須是線程安全的 
type RuntimeService interface { 
RuntimeVersioner 
ContainerManager 
PodSandboxManager 
ContainerStatsManager 
 
// UpdateRuntimeConfig更新運(yùn)行時(shí)配置 
UpdateRuntimeConfig(runtimeConfig *runtimeapi.RuntimeConfig) error 
 
// Status返回運(yùn)行時(shí)的狀態(tài) 
Status() (*runtimeapi.RuntimeStatus, error) 
} 
 
// ImageManagerService接口必須由容器管理器實(shí)現(xiàn) 
// 以下方法必須是線程安全的 
type ImageManagerService interface { 
// ListImages列出現(xiàn)有鏡像 
ListImages(filter *runtimeapi.ImageFilter) ([]*runtimeapi.Image, error) 
 
// ImageStatus返回鏡像狀態(tài) 
ImageStatus(image *runtimeapi.ImageSpec) (*runtimeapi.Image, error) 
 
// PullImage用認(rèn)證配置拉取鏡像 
PullImage(image *runtimeapi.ImageSpec, auth *runtimeapi.AuthConfig, podSandboxConfig *runtimeapi.PodSandboxConfig) (string, error) 
 
// RemoveImage刪除鏡像 
RemoveImage(image *runtimeapi.ImageSpec) error 
 
// ImageFsInfo返回存儲(chǔ)鏡像的文件系統(tǒng)信息 
ImageFsInfo() ([]*runtimeapi.FilesystemUsage, error) 
}  

Docker運(yùn)行時(shí)被普遍使用，它的CRI shim被稱為dockershim，內(nèi)置在Kubernetes的kubelet中，由Kubernetes項(xiàng)目組開(kāi)發(fā)和維護(hù)。其他運(yùn)行時(shí)則需要提供外置的shim。containerd從1.1版本開(kāi)始內(nèi)置了CRI plugin，不再需要外置shim來(lái)轉(zhuǎn)發(fā)請(qǐng)求，因此效率更高。在安裝Docker的最新版本時(shí)，會(huì)自動(dòng)安裝containerd，所以在一些系統(tǒng)中，Docker和Kubernetes可以同時(shí)使用containerd來(lái)運(yùn)行容器，但是二者的鏡像用了命名空間隔離，彼此是獨(dú)立的，即鏡像不可以共用。因?yàn)镈ocker和containerd常常同時(shí)存在，因此在不需要使用Docker的系統(tǒng)中只安裝containerd即可。

containerd最早是為Docker設(shè)計(jì)的代碼，包含一些用戶相關(guān)的功能。相比之下，CRI-O是替代Docker或者containerd的高效且輕量級(jí)的容器運(yùn)行時(shí)方案，是CRI的一個(gè)實(shí)現(xiàn)，能夠運(yùn)行符合OCI規(guī)范的容器，所以被稱為CRI-O。CRI-O是原生為生產(chǎn)系統(tǒng)運(yùn)行容器設(shè)計(jì)的，有個(gè)簡(jiǎn)單的命令行工具供測(cè)試用，但并不能進(jìn)行容器管理。CRI-O支持OCI的容器鏡像格式，可以從容器鏡像倉(cāng)庫(kù)中下載鏡像。CRI-O支持runC和Kata Containers這兩種低層容器運(yùn)行時(shí)。