Kubernetes 團隊近日宣布將在最新版本中棄用 Docker 支持的功能，后續版本會陸續刪除這些功能。
近日，Kubernetes 團隊發布了最新的 1.20 版本，新版本更新了許多內容：
存儲卷快照功能趨于穩定；Kubectl Debug 進入 Beta；Beta：API 優先級和公平性；IPV4/IPV6 Alpha 功能更新；GA：限制進程 PID；Dockershim 棄用；Exec 探針超時處理等等（詳情可查看：https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/ ）
其 中，有一項更新對于開發者社區來說無疑是一枚重磅炸彈： 正式宣布棄用 Docker 支持的功能。 那么，究竟 Kubernetes 為什么要這么做，以及這么做會有什么影響呢？
Docker 是一種以容器化的方式打包、分發和部署應用程序的方式。自 2013 年 3 月 13 日初始版本發布以來，Docker 已成為容器業界的事實標準。而Kubernetes 是一款由 Google 開發的開源容器編排系統。
Kubernetes 架構示意圖，來自維基百科
Docker 與 OpenShift
在 2015 年的峰會上，紅帽發布了 OpenShift V3.0，該新版本 OpenShift 底層采用 Docker 容器，同時開始使用 Kubernetes 來編排鏡像。然而，在 2016 年的紅帽峰會期間，Docker 對紅帽的 OpenShift 展開了鋒芒畢露的攻擊。他們不僅發表了以下推文，還給與會者發放帶有“我們不接受模仿”字樣的T恤衫：
顯然左邊的仿制鯨魚就是在嘲諷紅帽的 OpenShift。當時，OpenShift 采用了基于 Docker 的容器。紅帽發布的 Docker 一般會比原版落后一點點，而且為了提供所謂的“企業支持”，紅帽采取了給舊版本 Docker 打補丁的行為。但相比之下，Docker 總是在發布最新版。
當然，對于維護企業應用應該采用升級還是采用移植補丁的方式，到現在依然眾說紛紜，所以對于這一點在此不做評論，但 Docker 在紅帽自己的峰會上的這種行為確實有點出乎意料。不得不承認，在此之前 Docker 是一項偉大的技術，畢竟它是 RedShift 的重要組成部分，但從那天起，事情就開始變味了。
平臺之爭
早期的 PaaS 平臺主要是 OpenShift，以及兩家競爭對手 Docker 和Pivotal 。Docker 人所共知就不用多說了，Pivotal 是 EMC 和 VMware 于2013 年創建的公司，專注于開源 PaaS 的解決方案。他們的企業解決方案非常成功，原因非常簡單：用戶體驗非常好，尤其是結合 Pivotal Labs 使用的時候。
而 Docker 是企業解決方案的后起之秀，他們的優勢就是開發者們早已熟知Docker 引擎了。而當時 Kubernetes 還不知道在哪兒。然而，Docker 對OpenShift 的攻擊行為，使紅帽不得不將資源投入到了 Kubernetes 上。后來的結果大家都看到了，Kubernetes 大獲成功，并且獲得了整個行業的擁護。
此時 Docker 為了挽回敗局而推出了 Docker Swarm，但為時已晚。2016 年后半年，Kubernetes 超過了 Docker Swarm，成了行業事實上的標準。最終，Docker Swarm 并沒有給 Kubernetes 帶來任何沖擊。可以認為這是Docker 的第一次死亡，從此以后，Docker 不再是企業級的 PaaS 解決方案，只能作為云原生系統中的一部分存在，好在它一直是 Kubernetes 中的一個重要組成部分。
Kubernetes 宣布棄用 Docker
近日 Kubernetes 宣布棄用 Docker。
（官網博客鏈接：https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/）：
這無疑是第二次宣布了 Docker 的死亡。按照 Kubernetes 自己的說法，Docker 已不再是必須的技術，而是變成了技術債務。1.19 版以前的Kubernetes 需要通過一個名為 Dockershim 的模塊連接到 Docker，然后由Docker 連接到 Containerd 來創建容器。從技術上來看，實際的容器運行時是 Containerd，而不是 Docker。Docker 的作用只不過是在 Containerd 上創建容器而已。作為人類用戶，只需運行一個 Docker run 就可以創建一個容器，這一點非常方便；然而在方便的同時，Docker 也帶來了許多無用的操作和技術債務，對于 Kubernetes 而言，這就是負擔。Kubernetes 完全可以繞過Docker，自己在 Containerd 上創建容器，從而獲得同樣的效果。而Kubernetes 1.20 中就采用了這種做法。
盡管 Docker 公司的商業模式失敗了，但我們必須承認 Docker 為整個行業做出的巨大貢獻。Docker 公司帶來的技術是業內最好的。時至今日，我們的CI/CD 系統還極其依賴 Docker。沒有 Docker，也不可能有 Kubernetes 的成功，而且 Kubernetes 依然有 Docker 的影子。
不過也不用擔心，Kubernetes 團隊已經做了大量的努力，盡可能使升級過程平穩。即使你升級到 1.20，也只會收到一個關于 Docker 已被棄用的警告。目前Kubernetes 的計劃是在 2021 年末期發布的 1.22 中徹底移除 Docker 支持，所以開發者必須在那之前切換到其他的容器運行時，比如 Containerd 或 CRI-O 等。
Docker的替代品
棄用 Docker 之后，開發者們對其替代品的討論逐漸熱烈，其中 Containerd 和 Podman 倍受期待。
Containerd 是一個工業級標準的容器運行時，它強調簡單性、健壯性和可移植性。它可以管理容器的生命周期，可以被 Kubernets CRI 等項目使用，并為廣泛的行業合作打下基礎等。
Podman 原來是 CRI-O 項目的一部分，后來被分離成一個單獨的項目叫 libpod。Podman 的使用體驗和 Docker 類似，不同的是 Podman 沒有 daemon。直接通過 OCI runtime（默認也是 runc）來啟動容器，所以容器的進程是 Podman 的子進程。這比較像 Linux 的 fork/exec 模型，而 Docker 采用的是 C/S（客戶端/服務器）模型。
雖然目前容器市場 Docker 還是占用很大的比例，但被棄用的結局已定，在這個過渡期中，不妨去擁抱 Containerd 和 Podman 吧！
到此這篇關于被棄用的 Docker 會被 Podman 取代嗎？的文章就介紹到這了,更多相關Docker替代Podman內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！
