對於開發人員
不用過度驚慌，Docker容器和映像仍然存在。不是說世界末日來了，實際上它不會改變一切。
對於K8s管理員
仔細閱讀並開始考慮Docker替代方案
是標題黨嗎
不，這是真的發生了。Docker現在在Kubernetes中已棄用？
kubelet中的Docker支持現已棄用，並將在以後的版本中刪除。Kubelet使用一個名為「 dockershim」的模塊，該模塊實現了對Docker的CRI支持，並且在Kubernetes社區中看到了維護問題。我們鼓勵您評估在可用的容器運行時，它是CRI的完整實現（兼容v1alpha1或v1）。
簡而言之，這意味著Docker不支持稱為CRI（容器運行時接口）的Kubernetes運行時API，並且Kubernetes人們一直在使用名為「 dockershim」的橋接服務。它轉換了Docker API和CRI，但在一些次要版本中將不再從Kubernetes方面提供它。
當然，本地Docker是一個非常強大的工具，可以用來創建開發環境，但是為了了解造成這種情況的原因，您需要了解Docker在當前Kubernetes體系結構中的作用。
Kubernetes是一種基礎架構工具，可對許多不同的計算資源（例如虛擬/物理機）進行分組，使它看起來像是巨大的計算資源，可讓您的應用程式運行並與他人共享。在這種架構中，Docker（或容器運行時）僅用於通過Kubernetes控制平面進行調度，從而在實際主機中運行這些應用程式。
看一下架構圖。您可以看到每個Kubernetes節點都與控制平面通信。kubelet在每個節點上獲取元數據，並執行CRI以在該節點上運行創建/刪除容器。
但是為什麼不再使用Docker？
同樣，Kubernetes僅使用CRI進行內部通信，而與Docker通信則需要橋接服務。這就是原因一。
為了解釋下一個原因，我們必須稍微了解一下Docker架構。這是Docker的架構圖。
是的，Kubernetes實際上需要在紅色區域內運行，但是Kubernetes不使用Docker Network和Volume。
如果一個東西擁有很多用戶不用的功能，這本身可能會帶來安全隱患。您擁有的功能越少，攻擊面就越小。
因此，這是後面社區提出來考慮替代方案的地方，稱為CRI運行時。
CRI運行時
有兩種主要的CRI運行時實現。
containerd
如果您只想從Docker遷移，這是最好的選擇，因為容器實際上是在Docker內部使用的，可以完成所有「運行時」工作，如上圖所示。他們提供了CRI，這也是Docker提供的100％。
containerd是100％開放原始碼，因此您可以在GitHub上查看文檔，甚至也可以為此做出貢獻。
CRI-O
CRI-O是主要由Red Hat員工開發的CRI運行時。實際上，此運行時現在已在Red Hat OpenShift中使用。是的，他們不再依賴Docker。
有趣的是，RHEL 7也開始不正式支持Docker。相反，它們為容器環境提供Podman，Buildah和CRI-O。
我認為CRI-O的優勢在於它的極簡風格，因為它被創建為「 CRI」運行時。儘管容器化作為Docker的一部分試圖變得更加開源，但它們是純CRI運行時，因此CRI-O沒有CRI不需要的任何內容。
從Docker遷移到CRI-O可能會更具挑戰性，因為它仍然可以提供在Kubernetes上運行應用程式所需的功能。
還有一件事...
當我們談論容器運行時時，我們需要注意您在談論哪種類型的運行時。我們確實有兩種類型的運行時；CRI運行時和OCI運行時。
CRI運行時
正如我所描述的，CRI是Kubernetes提供的API，用於與容器運行時進行對話，以創建/刪除容器化的應用程式。
它們通過IPC在gRPC中作為kubelet進行通信，並且運行時在同一主機上運行，並且CRI運行時負責從kubelet獲取請求並執行OCI容器運行時以運行容器。等一下 也許我應該用一張圖表來解釋。
因此，CRI運行時將執行以下操作
從kubelet獲取gRPC請求按照規範創建OCI json配置OCI運行時
OCI運行時負責使用Linux內核系統調用（例如cgroups和命名空間）生成容器。您可能聽說過runc或gVisor。
附錄1：runC如何工作
CRI通過調用Linux系統調用執行二進位文件後，runC生成容器。這表明runC依賴Linux計算機上運行的內核。
這也意味著，如果您發現runC的漏洞獲得了主機的root特權，那麼容器化的應用程式也可以這樣做。一個厲害的黑客可能會使您的主機徹底報廢！事情肯定會變糟。這就是為什麼您也應該不斷更新Docker（或任何其他容器運行時）的原因之一，而不僅僅是容器化的應用程式。
附錄2：gVisor的工作方式
gVisor最初由Google員工創建的OCI運行時。它實際上在其基礎結構上運行，以運行其雲服務，例如Google Cloud Run，Google App Engine（第二代）和Google Cloud Functions（甚至更多！）。
這裡有趣的是gVisor具有「guest 內核」層，這意味著容器化的應用程式無法直接接觸主機內核層。即使他們認為這樣做，也只能接觸gVisor的guest內核。
gVisor的安全模型實際上非常有趣，值得閱讀官方文檔，與runC的顯著區別如下。
性能較差Linux內核層不是100％兼容的查看官方文檔的兼容性部分默認不支持總結
Docker 確被棄用，大家應該開始考慮使用 CRI 運行時，例如 containerd 與 CRI-O。containerd 與 Docker 相兼容，二者共享相同的核心組件。如果您主要使用 Kubernetes 的最低功能選項，CRI-O 可能更為適合。明確理解 CRI 運行時與 OCI 運行時之間的功能與作用範圍差異。根據您的實際工作負載與業務需求，runC 可能並不總是最好的選擇，請酌情做出考量！