一、背景
由於最近知道了 K8s 新版本（v1.20）確定棄用 Docker 的消息，為了明確是否會對現有系統架構產生響，所以對涉及到的相關技術進行了一定的梳理（索性的是對現有的系統架構基本無影響：>）。
二、K8s（版本 < 1.20） 與 Docker 的關系
首先，通過一張圖片來說明 K8s（版本<1.20）與 Docker 之間的關系。為了能夠更好的理解下邊的圖片，要先交代下 K8s 的一個限制條件：
那就是 K8s 只能與 CRI 運行時通信
對於啥是 CRI 運行時？我們暫可以簡單的將 Ta 理解為與 Docker 同等的存在（另外一個容器容器運行時）。Ok，下面我們來看圖說話吧：
通過上邊的圖片我們可以看到，K8s 是通過 docker-shim 作為橋接服務，將 CRI 轉換為 Docker API，然后與 Dokcer 進行通信的。
三、CRI 是啥？
CRI（Container Runtime Interface）是 K8s 定義的一組與容器運行時進行交互的接口，用於將 K8s 平台與特定的容器實現解耦。在 K8s 早期的版本中，對於容器環境的支持是通過 hard code 方式直接調用 Docker API 的，后來為了支持更多的容器運行時和更精簡的容器運行時，K8s 提出了CRI。
CRI 運行時有兩個實現方案：
containerd
containerd 是 Docker 的一部分，提供的 CRI 都是由 Docker 提供的。
CRI-O：
CRI-O 在本質上屬於純 CRI 運行時，因此不包含除 CRI 之外的任何其他內容。
四、OCI 是啥？
當我們談論「容器運行時」時，請注意我們到底是在談論哪種類型的運行時，這里運行時分為兩種：
CRI 運行時
OCI 運行時
OCI（Open Container Initiative），可以看做是「容器運行時」的一個標准，Ta 使用 Linux 內核系統調用（例如：cgroups 與命名空間）生成容器，按此標准實現的「容器運行時」有 runC 和 gVisor。
四、CRI、OCI 之間的關系？
還是通過圖片來說明下吧：
通過上邊的圖片，我們可以得出如下結論：
實際對容器的操作最終還是要交給 OCI，CRI 也只是個中轉