Kubernetes 團隊近日宣布將在最新版本中棄用 Docker 支持的功能，后續(xù)版本會陸續(xù)刪除這些功能。

近日，Kubernetes 團隊發(fā)布了最新的 1.20 版本，新版本更新了許多內(nèi)容：

存儲卷快照功能趨于穩(wěn)定；Kubectl Debug 進入 Beta；Beta：API 優(yōu)先級和公平性；IPV4/IPV6 Alpha 功能更新；GA：限制進程 PID；Dockershim 棄用；Exec 探針超時處理等等（詳情可查看：https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/ ）

其 中，有一項更新對于開發(fā)者社區(qū)來說無疑是一枚重磅炸彈： 正式宣布棄用 Docker 支持的功能。 那么，究竟 Kubernetes 為什么要這么做，以及這么做會有什么影響呢？

Docker 是一種以容器化的方式打包、分發(fā)和部署應(yīng)用程序的方式。自 2013 年 3 月 13 日初始版本發(fā)布以來，Docker 已成為容器業(yè)界的事實標(biāo)準(zhǔn)。而Kubernetes 是一款由 Google 開發(fā)的開源容器編排系統(tǒng)。

Kubernetes 架構(gòu)示意圖，來自維基百科

在 2015 年的峰會上，紅帽發(fā)布了 OpenShift V3.0，該新版本 OpenShift 底層采用 Docker 容器，同時開始使用 Kubernetes 來編排鏡像。然而，在 2016 年的紅帽峰會期間，Docker 對紅帽的 OpenShift 展開了鋒芒畢露的攻擊。他們不僅發(fā)表了以下推文，還給與會者發(fā)放帶有“我們不接受模仿”字樣的T恤衫：

顯然左邊的仿制鯨魚就是在嘲諷紅帽的 OpenShift。當(dāng)時，OpenShift 采用了基于 Docker 的容器。紅帽發(fā)布的 Docker 一般會比原版落后一點點，而且為了提供所謂的“企業(yè)支持”，紅帽采取了給舊版本 Docker 打補丁的行為。但相比之下，Docker 總是在發(fā)布最新版。

當(dāng)然，對于維護企業(yè)應(yīng)用應(yīng)該采用升級還是采用移植補丁的方式，到現(xiàn)在依然眾說紛紜，所以對于這一點在此不做評論，但 Docker 在紅帽自己的峰會上的這種行為確實有點出乎意料。不得不承認，在此之前 Docker 是一項偉大的技術(shù)，畢竟它是 RedShift 的重要組成部分，但從那天起，事情就開始變味了。

早期的 PaaS 平臺主要是 OpenShift，以及兩家競爭對手 Docker 和Pivotal 。Docker 人所共知就不用多說了，Pivotal 是 EMC 和 VMware 于2013 年創(chuàng)建的公司，專注于開源 PaaS 的解決方案。他們的企業(yè)解決方案非常成功，原因非常簡單：用戶體驗非常好，尤其是結(jié)合 Pivotal Labs 使用的時候。

而 Docker 是企業(yè)解決方案的后起之秀，他們的優(yōu)勢就是開發(fā)者們早已熟知Docker 引擎了。而當(dāng)時 Kubernetes 還不知道在哪兒。然而，Docker 對OpenShift 的攻擊行為，使紅帽不得不將資源投入到了 Kubernetes 上。后來的結(jié)果大家都看到了，Kubernetes 大獲成功，并且獲得了整個行業(yè)的擁護。

此時 Docker 為了挽回敗局而推出了 Docker Swarm，但為時已晚。2016 年后半年，Kubernetes 超過了 Docker Swarm，成了行業(yè)事實上的標(biāo)準(zhǔn)。最終，Docker Swarm 并沒有給 Kubernetes 帶來任何沖擊。可以認為這是Docker 的第一次死亡，從此以后，Docker 不再是企業(yè)級的 PaaS 解決方案，只能作為云原生系統(tǒng)中的一部分存在，好在它一直是 Kubernetes 中的一個重要組成部分。

近日 Kubernetes 宣布棄用 Docker。

（官網(wǎng)博客鏈接：https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/）：

這無疑是第二次宣布了 Docker 的死亡。按照 Kubernetes 自己的說法，Docker 已不再是必須的技術(shù)，而是變成了技術(shù)債務(wù)。1.19 版以前的Kubernetes 需要通過一個名為 Dockershim 的模塊連接到 Docker，然后由Docker 連接到 Containerd 來創(chuàng)建容器。從技術(shù)上來看，實際的容器運行時是 Containerd，而不是 Docker。Docker 的作用只不過是在 Containerd 上創(chuàng)建容器而已。作為人類用戶，只需運行一個 Docker run 就可以創(chuàng)建一個容器，這一點非常方便；然而在方便的同時，Docker 也帶來了許多無用的操作和技術(shù)債務(wù)，對于 Kubernetes 而言，這就是負擔(dān)。Kubernetes 完全可以繞過Docker，自己在 Containerd 上創(chuàng)建容器，從而獲得同樣的效果。而Kubernetes 1.20 中就采用了這種做法。

盡管 Docker 公司的商業(yè)模式失敗了，但我們必須承認 Docker 為整個行業(yè)做出的巨大貢獻。Docker 公司帶來的技術(shù)是業(yè)內(nèi)最好的。時至今日，我們的CI/CD 系統(tǒng)還極其依賴 Docker。沒有 Docker，也不可能有 Kubernetes 的成功，而且 Kubernetes 依然有 Docker 的影子。

不過也不用擔(dān)心，Kubernetes 團隊已經(jīng)做了大量的努力，盡可能使升級過程平穩(wěn)。即使你升級到 1.20，也只會收到一個關(guān)于 Docker 已被棄用的警告。目前Kubernetes 的計劃是在 2021 年末期發(fā)布的 1.22 中徹底移除 Docker 支持，所以開發(fā)者必須在那之前切換到其他的容器運行時，比如 Containerd 或 CRI-O 等。

棄用 Docker 之后，開發(fā)者們對其替代品的討論逐漸熱烈，其中 Containerd 和 Podman 倍受期待。

Containerd 是一個工業(yè)級標(biāo)準(zhǔn)的容器運行時，它強調(diào)簡單性、健壯性和可移植性。它可以管理容器的生命周期，可以被 Kubernets CRI 等項目使用，并為廣泛的行業(yè)合作打下基礎(chǔ)等。

Podman 原來是 CRI-O 項目的一部分，后來被分離成一個單獨的項目叫 libpod。Podman 的使用體驗和 Docker 類似，不同的是 Podman 沒有 daemon。直接通過 OCI runtime（默認也是 runc）來啟動容器，所以容器的進程是 Podman 的子進程。這比較像 Linux 的 fork/exec 模型，而 Docker 采用的是 C/S（客戶端/服務(wù)器）模型。

雖然目前容器市場 Docker 還是占用很大的比例，但被棄用的結(jié)局已定，在這個過渡期中，不妨去擁抱 Containerd 和 Podman 吧！

到此這篇關(guān)于被棄用的 Docker 會被 Podman 取代嗎？的文章就介紹到這了,更多相關(guān)Docker替代Podman內(nèi)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！