2.1.1　容器發(fā)展史

2008年，最早的容器運(yùn)行時(shí)LXC（Linux Container）誕生。2013年，Docker容器引擎發(fā)布。Docker開發(fā)之初嘗試使用LXC，但由于彼時(shí)LXC隔離性相對(duì)較差，因此Docker開發(fā)Libcontainer，最終形成runC。2014年Kubernetes發(fā)布時(shí)，由于社區(qū)中Docker已經(jīng)被大量使用，因此就用Docker容器引擎。

隨著Docker越來越重，CoreOS以rkt的形式發(fā)布了一個(gè)更簡(jiǎn)單的獨(dú)立運(yùn)行時(shí)。rkt與Kubernetes具有較好的協(xié)同工作性。

隨著容器運(yùn)行時(shí)格式的增加，2015年6月OCI（Open Containers Initiative）項(xiàng)目成立。這個(gè)項(xiàng)目的目的是對(duì)容器運(yùn)行時(shí)的接口標(biāo)準(zhǔn)化，runC在第一時(shí)間通過了OCI標(biāo)準(zhǔn)的認(rèn)證。

為了實(shí)現(xiàn)Kubernetes與容器運(yùn)行時(shí)解耦，Google提出了CRI（Container Runtime Interface）標(biāo)準(zhǔn)。它是一組Kubernetes與Container Runtime進(jìn)行交互的接口，這使Kubernetes用戶可以插入除Docker之外的其他容器引擎。所以說，CRI和OCI并不沖突：Kubernetes定義的是它調(diào)用容器運(yùn)行時(shí)的標(biāo)準(zhǔn)接口，OCI定義的是容器運(yùn)行時(shí)本身的標(biāo)準(zhǔn)。

容器運(yùn)行時(shí)接口（OCI）標(biāo)準(zhǔn)提出以后，紅帽考慮到Kubernetes在企業(yè)中的應(yīng)用，專門為Kubernetes做了一個(gè)輕量級(jí)的容器運(yùn)行時(shí)，決定重用了runC等基本組件來啟動(dòng)容器，并實(shí)現(xiàn)了一個(gè)最小的CRI稱為CRI-O，CRI-O是CRI的一種標(biāo)準(zhǔn)實(shí)現(xiàn)。2017年10月，CRI-O正式發(fā)布。

當(dāng)紅帽開發(fā)CRI-O時(shí)，Docker也在研究CRI標(biāo)準(zhǔn)，這導(dǎo)致了另一個(gè)名為Containerd的運(yùn)行時(shí)的出現(xiàn)（實(shí)際上它是從Docker Engine剝離出來的）。所以從1.12版本開始，Docker會(huì)多一層Containerd組件。Kubernetes將Containerd接入CRI的標(biāo)準(zhǔn)中。即cri-containerd。

從概念上，從PaaS頂層到底層的調(diào)用關(guān)系是：

Orchestration API→Container Engine API→Kernel API

舊版本的PaaS平臺(tái)（如OpenShift 3）的調(diào)用架構(gòu)：

Kubernetes Master→Kubelet→Docker Engine→Containerd→runC→Linux Kernel

紅帽O(jiān)penShift最新的調(diào)用架構(gòu)：

Kubernetes Master→Kubelet→CRI-O→runC→Linux kernel

詳細(xì)的調(diào)用架構(gòu)如圖2-1所示。

圖2-1　Kubernetes與CRI-O調(diào)用架構(gòu)

我們看到，采用CRI-O運(yùn)行時(shí)OpenShift對(duì)底層的調(diào)用鏈路更短、效率更高、穩(wěn)定性更強(qiáng)。而很重要的一點(diǎn)是CRI-O的運(yùn)行不依賴于守護(hù)進(jìn)程，也就是說，即使OpenShift節(jié)點(diǎn)上的CRI-O的Systemd進(jìn)程終止，所有運(yùn)行的Pod也不受影響，具體的驗(yàn)證步驟可以參照“大魏分享”公眾號(hào)文章，如圖2-2所示。

圖2-2　驗(yàn)證CRI-O在故障下的表現(xiàn)

在介紹了容器發(fā)展史后，接下來我們介紹OpenShift的發(fā)展史以及與Kubernetes的關(guān)系。