2.1.1　容器發展史

2008年，最早的容器運行時LXC（Linux Container）誕生。2013年，Docker容器引擎發布。Docker開發之初嘗試使用LXC，但由于彼時LXC隔離性相對較差，因此Docker開發Libcontainer，最終形成runC。2014年Kubernetes發布時，由于社區中Docker已經被大量使用，因此就用Docker容器引擎。

隨著Docker越來越重，CoreOS以rkt的形式發布了一個更簡單的獨立運行時。rkt與Kubernetes具有較好的協同工作性。

隨著容器運行時格式的增加，2015年6月OCI（Open Containers Initiative）項目成立。這個項目的目的是對容器運行時的接口標準化，runC在第一時間通過了OCI標準的認證。

為了實現Kubernetes與容器運行時解耦，Google提出了CRI（Container Runtime Interface）標準。它是一組Kubernetes與Container Runtime進行交互的接口，這使Kubernetes用戶可以插入除Docker之外的其他容器引擎。所以說，CRI和OCI并不沖突：Kubernetes定義的是它調用容器運行時的標準接口，OCI定義的是容器運行時本身的標準。

容器運行時接口（OCI）標準提出以后，紅帽考慮到Kubernetes在企業中的應用，專門為Kubernetes做了一個輕量級的容器運行時，決定重用了runC等基本組件來啟動容器，并實現了一個最小的CRI稱為CRI-O，CRI-O是CRI的一種標準實現。2017年10月，CRI-O正式發布。

當紅帽開發CRI-O時，Docker也在研究CRI標準，這導致了另一個名為Containerd的運行時的出現（實際上它是從Docker Engine剝離出來的）。所以從1.12版本開始，Docker會多一層Containerd組件。Kubernetes將Containerd接入CRI的標準中。即cri-containerd。

從概念上，從PaaS頂層到底層的調用關系是：

Orchestration API→Container Engine API→Kernel API

舊版本的PaaS平臺（如OpenShift 3）的調用架構：

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

紅帽OpenShift最新的調用架構：

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

詳細的調用架構如圖2-1所示。

圖2-1　Kubernetes與CRI-O調用架構

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

圖2-2　驗證CRI-O在故障下的表現

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