對於開發人員
不用過分驚慌，Docker容器和映像仍然存在。不是說世界末日來了，實際上它不會改變一切。git
可是值得一讀背後的緣由：github
https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/web
https://kubernetes.io/blog/2020/12/02/dockershim-faq/docker
對於K8s管理員
仔細閱讀並開始考慮Docker替代方案json
是標題黨嗎
不，這是真的發生了。Docker如今在Kubernetes中已棄用。安全
參考
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation微信
kubelet中的Docker支持現已棄用，並將在之後的版本中刪除。Kubelet使用一個名爲「 dockershim」的模塊，該模塊實現了對Docker的CRI支持，而且在Kubernetes社區中看到了維護問題。咱們鼓勵您評估在可用的容器運行時，它是CRI的完整實現（兼容v1alpha1或v1）。網絡
簡而言之，這意味着Docker不支持稱爲CRI（容器運行時接口）的Kubernetes運行時API，而且Kubernetes人們一直在使用名爲「 dockershim」的橋接服務。它轉換了Docker API和CRI，但在一些次要版本中將再也不從Kubernetes方面提供它。架構
固然，本地Docker是一個很是強大的工具，能夠用來建立開發環境，可是爲了瞭解形成這種狀況的緣由，您須要瞭解Docker在當前Kubernetes體系結構中的做用。app
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上查看文檔，甚至也能夠爲此作出貢獻。
https://github.com/containerd/containerd/
CRI-O
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」運行時。儘管容器化做爲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 可能並不老是最好的選擇，請酌情作出考量！
原文連接：
https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
最後，你們若是想加羣和各路大拿交流，能夠識別下面的二維碼加入：
後臺回覆「加羣」，帶你進入高手如雲交流羣
推薦閱讀：
10T 技術資源大放送！包括但不限於：雲計算、虛擬化、微服務、大數據、網絡、Linux、Docker、Kubernetes、Python、Go、C/C++、Shell、PPT 等。在公衆號內回覆「1024」，便可免費獲取！！
本文分享自微信公衆號 - Linux雲計算網絡（cloud_dev）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。