標題：等等，Docker 現在在 Kubernetes 中已被棄用？我該怎麼辦？
發表：真實
描述：本文解釋了為什麼 Docker 現在在 Kubernetes 中已棄用。
標籤： Docker、 Kubernetes
封面圖：https://dev-to-uploads.s3.amazonaws.com/i/mwclzdxtfgighjrwdpfa.jpeg
太長了；博士
對於開發商
不要驚慌，Docker 容器和映像仍然存在。這並不是說它會改變一切。
還值得一讀：
https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
https://kubernetes.io/blog/2020/12/02/dockershim-faq/
對於 K8s 管理員
仔細閱讀本文並開始考慮 Docker 替代方案
這是真的嗎？
是的，它是真實的。 Docker 現已在 Kubernetes 中棄用。
參考號https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation
kubelet 中的 Docker 支援現已棄用，並將在未來版本中刪除。 kubelet 使用一個名為「dockershim」的模組，該模組實現了對 Docker 的 CRI 支持，並且在 Kubernetes 社群中發現了維護問題。我們鼓勵您在 CRI 可用時評估是否遷移到成熟的 CRI 實作（v1alpha1 或 v1 相容）。
簡而言之，這裡的意思是 Docker 不支援稱為 CRI（Container Runtime Interface）的 Kubernetes Runtime API，而 Kubernetes 人們一直在使用稱為「dockershim」的橋接服務。它轉換了 Docker API 和 CRI，但在幾個小版本中將不再從 Kubernetes 端提供。
本地 Docker 無疑是建立開發環境的一個非常強大的工具，但為了了解造成這種情況的原因，您需要了解 Docker 在目前 Kubernetes 架構中做了什麼。
Kubernetes 是一種基礎架構編排工具，它將許多不同的運算資源（例如虛擬機器/實體機）組合在一起，使其看起來像一個巨大的運算資源，供您的應用程式執行並與其他人共享。在此架構中，Docker（或容器執行時）僅用於透過 Kubernetes 控制平面調度在實際主機中執行這些應用程式。
看一下架構圖。您可以看到每個 Kubernetes 節點都與控制平面進行通訊。每個節點上的kubelet取得元資料，並執行 CRI 在節點上執行建立/刪除容器。
但為什麼 Docker 被棄用了呢？
同樣，Kubernetes 只在 CRI 中進行通信，而與 Docker 通信需要橋接服務。這就是原因1。
為了解釋下一個原因，我們必須稍微了解 Docker 架構。這是圖表。
所以是的，Kubernetes 實際上需要在紅色區域內。 Kubernetes 中不使用 Docker Network 和 Volume。
擁有更多功能但您從未使用過，這本身就可能存在安全風險。擁有的功能越少，攻擊面就越小。
所以這就是你開始考慮替代方案的地方。它稱為 CRI 執行時。
CRI 執行時
有兩種主要的 CRI 執行時實作。
容器d
如果您只想從 Docker 遷移，這是最好的選擇，因為容器實際上在 Docker 內部使用來完成所有「執行時間」作業，如上圖所示。他們提供 CRI，而且 Docker 也提供 100% 的服務。
containerd 是 100% 開源的，因此您可以在 GitHub 上查看文件，甚至也可以為其做出貢獻。
https://github.com/containerd/containerd/
哭吧
CRI-O 是主要由 Red Hat 人員開發的 CRI 執行時。事實上，這個執行時現在已經在 Red Hat OpenShift 中使用。是的，他們不再依賴 Docker。
有趣的是，RHEL 7 也不正式支援 Docker。相反，他們為容器環境提供了 Podman、Buildah 和 CRI-O。
https://github.com/cri-o/cri-o
在我看來，CRI-O 的優勢在於其極簡主義，因為它被建立為「CRI」執行時。雖然 containerd 最初是作為 Docker 的一部分嘗試變得更加開源，但它們是純 CRI 執行時，因此 CRI-O 沒有 CRI 不需要的任何內容。
從 Docker 遷移到 CRI-O 可能更具挑戰性，因為它仍然提供在 Kubernetes 上執行應用程式所需的功能。
還有一件事...
當我們談論容器執行時，我們需要小心您談論的是哪種類型的執行時。我們確實有兩種類型的執行時； CRI 執行時和 OCI 執行時。
CRI 執行時
正如我所描述的，CRI 是 Kubernetes 提供的 API，用於與容器執行時通信，以便建立/刪除容器化應用程式。
它們透過 IPC 作為 kubelet 在 gRPC 中進行通信，執行時執行在同一主機上，CRI 執行時負責從 kubelet 獲取請求並執行 OCI 容器執行時來執行容器。等等，什麼？也許我應該用一張圖表來解釋這一點。
那麼 CRI 運作時的作用如下
-
從 kubelet 取得 gRPC 請求
-
依照規格建立 OCI json 配置
OCI 運作時
OCI 執行時負責使用 Linux 核心系統呼叫（例如 cgroup 和命名空間）產生容器。您可能聽過runc或gVisor 。他們就是這樣。
附錄1：runC如何運作
在 CRI 透過呼叫 Linux 系統呼叫執行二進位檔案後，runC 產生容器。這表明 runC依賴Linux 電腦上執行的核心。
它還意味著，如果您發現 runC 的漏洞使您獲得主機的 root 權限，那麼容器化應用程式也可以這樣做。一個糟糕的黑客可能會奪走您主機的根並繁榮！事情肯定會變得很糟。這就是為什麼您也應該不斷更新 Docker（或任何其他容器執行時）而不僅僅是容器化應用程式的原因之一。
附錄2：gVisor如何運作
gVisor 是 OCI 執行時，最初由 Google 人員建立。它實際上在他們的基礎設施上執行來執行他們的雲端服務，例如 Google Cloud Run、Google App Engine（第二代）和 Google Cloud Functions（甚至更多！）
有趣的是，gVisor 有一個「來賓核心」層，這意味著容器化應用程式無法直接接觸主機核心層。即使他們認為他們這樣做了，他們也只觸及 gVisor 的客戶核心。
gVisor的安全模型其實非常有趣，值得閱讀官方文件。
與 runC 的顯著差異如下。
-
性能更差
-
Linux 核心層並非 100% 相容
-
預設不支援
結論
1. Docker 肯定已被棄用，但僅限於 Kubernetes，因此，如果您是 K8s 管理員，您應該開始考慮採用 CRI 執行時，例如 containerd 和 CRI-O。
A。 Containerd 與 Docker 相容，核心元件相同。
b.如果您希望 Kubernetes 擁有更多最小功能，CRI-O 可能是個強大的選擇
2.了解CRI和OCI運作時職責和範圍的差異
根據您的工作負載，runC 可能並不總是最好的選擇！
原文出處：https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式