Dockershim：歷史背景

自 Kubernetes v1.24 起，Dockershim 已被移除，這對專案來說是一個積極的舉措。然而，無論是從社會角度還是在軟體開發中，上下文對於充分理解事物都至關重要，因此這值得更深入的審視。隨著 Kubernetes v1.24 中 dockershim 的移除，我們看到社群中對此決定存在一些困惑（有時甚至是恐慌級別）和不滿，這主要是由於缺乏對移除原因的上下文了解。棄用並最終從 Kubernetes 中移除 dockershim 的決定並非倉促或輕率做出的。然而，它已經醞釀了很長時間，以至於今天許多使用者都比這個決定要新，當然也比最初導致 dockershim 成為必要選擇要新得多。

那麼，dockershim 是什麼？為什麼它要被移除？

在 Kubernetes 的早期，我們只支援一種容器執行時。該執行時就是 Docker Engine。那時，市面上並沒有很多其他選擇，Docker 是使用容器的主流工具，所以這不是一個有爭議的選擇。最終，我們開始新增更多容器執行時，例如 rkt 和 hypernetes，並且很明顯 Kubernetes 使用者希望能夠選擇最適合他們的執行時。因此，Kubernetes 需要一種方式來讓叢集操作員能夠靈活地使用他們選擇的任何執行時。

容器執行時介面 (CRI) 的釋出是為了提供這種靈活性。CRI 的引入對專案和使用者都非常有利，但也帶來了一個問題：Docker Engine 作為容器執行時使用早於 CRI，而 Docker Engine 不相容 CRI。為了解決這個問題，kubelet 元件中引入了一個小型軟體 shim (dockershim)，專門用於彌補 Docker Engine 和 CRI 之間的空白，從而允許叢集操作員在很大程度上不間斷地繼續使用 Docker Engine 作為他們的容器執行時。

然而，這個小小的軟體墊片從未打算成為一個永久性解決方案。多年來，它的存在給 kubelet 本身帶來了許多不必要的複雜性。由於這個墊片，一些整合在 Docker 中的實現不一致，導致維護人員的負擔增加，而且維護特定於供應商的程式碼不符合我們的開源理念。為了減輕這種維護負擔，並朝著支援開放標準的更具協作性的社群邁進，引入了 KEP-2221，提議移除 dockershim。隨著 Kubernetes v1.20 的釋出，棄用正式生效。

我們在這方面溝通得並不好，不幸的是，棄用公告在社群內引起了一些恐慌。關於這對 Docker 公司意味著什麼，Docker 構建的容器映象是否仍能執行，以及 Docker Engine 到底是什麼的困惑，在社交媒體上引發了一場軒然大波。這是我們的錯；我們當時應該更清楚地溝通發生了什麼以及為什麼。為了解決這個問題，我們釋出了一篇部落格和配套的 FAQ，以緩解社群的擔憂，並糾正關於 Docker 是什麼以及容器如何在 Kubernetes 中工作的一些誤解。鑑於社群的擔憂，Docker 和 Mirantis 共同同意以 cri-dockerd 的形式繼續支援 dockershim 程式碼，如果需要，您可以繼續使用 Docker Engine 作為您的容器執行時。為了對希望嘗試其他執行時（如 containerd 或 cri-o）的使用者感興趣，我們編寫了遷移文件。

我們後來調查了社群，並發現仍有許多使用者存在疑問和擔憂。為此，Kubernetes 維護者和 CNCF 承諾透過擴充套件文件和其他計劃來解決這些擔憂。事實上，這篇部落格文章就是該計劃的一部分。隨著如此多的終端使用者成功遷移到其他執行時，以及改進的文件，我們相信現在每個人都有了一條通往遷移的康莊大道。

Docker 不會消失，無論是作為一個工具還是作為一家公司。它是雲原生社群和 Kubernetes 專案歷史的重要組成部分。沒有他們，我們不會有今天的成就。話雖如此，從 kubelet 中移除 dockershim 最終對社群、生態系統、專案和整個開源都有益。這是一個我們所有人齊心協力支援開放標準的機會，我們很高興能在 Docker 和社群的幫助下做到這一點。

• ←上一篇
• 下一篇→