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

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

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

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

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

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

Docker 與 OpenShift

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

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

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

平臺(tái)之爭(zhēng)

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

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

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

Kubernetes 宣布棄用 Docker

近日 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 需要通過一個(gè)名為 Dockershim 的模塊連接到 Docker，然后由Docker 連接到 Containerd 來創(chuàng)建容器。從技術(shù)上來看，實(shí)際的容器運(yùn)行時(shí)是 Containerd，而不是 Docker。Docker 的作用只不過是在 Containerd 上創(chuàng)建容器而已。作為人類用戶，只需運(yùn)行一個(gè) Docker run 就可以創(chuàng)建一個(gè)容器，這一點(diǎn)非常方便；然而在方便的同時(shí)，Docker 也帶來了許多無用的操作和技術(shù)債務(wù)，對(duì)于 Kubernetes 而言，這就是負(fù)擔(dān)。Kubernetes 完全可以繞過Docker，自己在 Containerd 上創(chuàng)建容器，從而獲得同樣的效果。而Kubernetes 1.20 中就采用了這種做法。

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

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

Docker的替代品

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

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

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

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

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