Kubernetes vs Docker:瞭解 2021 年的容器

幾個星期前，Kubernetes 開發團隊宣佈，他們正在棄用 docker。這則新聞通過科技界和社交網路廣為流傳。Kubernetes 群集是否會中斷，如果是，我們將如何執行我們的應用程式？我們現在該怎麼辦？今天，我們將審查所有這些問題和更多。

讓我們從頭開始。如果你已經熟悉 docker 和 kubernetes，並希望直接瞭解關鍵資訊，跳到 docker 棄用對你有什麼影響？

什麼是容器？

儘管 Docker 被用作容器的同義詞，但現實情況是，它們早在 docker 成為東西之前就已經存在了。Unix 和 Linux 自 70 年代末開始引入 chroot 以來，一直有某種形式的容器。Chroot 允許系統管理員在一種但並非真正孤立的檔案系統中執行程式。後來，這個想法被提煉和增強到集裝箱引擎，如免費 BSD Jails ， OpenVZ ，或 Linux Containers（LXC）。

但是什麼是容器呢？

容器是一個邏輯分割槽，我們可以執行與系統其餘部分分離的應用程式。每個應用程式都有自己的專用網路和不與其他容器或主機共享的虛擬檔案系統。

執行容器應用程式比安裝和配置軟體方便得多。首先，容器是行動式的：我們可以在一臺伺服器中構建，並相信它將在任何伺服器中工作。另一個優點是，我們可以同時執行同一程式的多個副本，而不會發生衝突或重疊，否則確實很難做到。

然而，要使這一切發揮作用，我們需要一個容器 runtime，一個能夠執行容器的軟體。

什麼是 docker？

docker 是最受歡迎的容器 runtime-從長遠來看。這並不奇怪，因為它將容器的概念引入主流，這反過來又激發了像 Kubernetes 這樣的平臺的建立。

在 Docker 之前，執行容器確實是可能的，但這是艱苦的工作。Docker 使事情變得簡單，因為它是一個完整的技術堆疊，可以：

• 管理容器生命週期。
• 代理請求來回容器。
• 監視和記錄容器活動。
• 安裝共享目錄。
• 對容器設定資源限制。
• 生成映象。Dockerfile 是構建容器映象的格式檔案。
• 從註冊處推送和拉取影像。
• 在第一次迭代中，Docker 使用 Linux 容器（LXC）作為執行時間後端。隨著專案的發展，LXC 被容器所取代，docker 自己的實施。現代 docker 安裝分為兩個服務：containerd，負責管理容器；dockerd，處理剩餘的部分。

什麼是 kubernetes？

kubernetes 採取容器的想法，並把它一個缺口。Kubernetes 不是在單個伺服器中執行容器化應用程式，而是將其分佈在一組機器上。在 Kubernetes 中執行的應用程式的外觀和行為都像一個單元，儘管在現實中，它們可能由鬆散耦合的容器排列而成。

Kubernetes 在容器頂部新增分散式計算功能：

• 吊艙：吊艙是共享記憶體、CPU、儲存和網路等資源的邏輯容器組。
• 自動縮放：Kubernetes 可根據需要啟動和停止吊艙，從而自動適應不斷變化的工作負載。
• 自我修復：容器在故障時被監控並重新啟動。
• 負載均衡：請求分佈在健康的可用吊艙上。
• 推出：kubernetes 支援自動推出和回滾。使 Canary 和 Blue-Green 等複雜程式變得微不足道。 我們可以將 Kubernetes 的架構視為兩架飛機的組合： 控制皮膚是叢集的協調大腦。它有一個控制器，管理節點和服務，排程器分配吊艙的節點，和 API 服務，處理通訊。配置和狀態儲存在一個高度可用的資料庫稱為 etcd。 工人節點是執行容器的機器。每個工人節點執行幾個元件，如 kubelet 代理、網路代理和容器執行時。Kubernetes 版本 v1.20 的預設容器執行時是 Docker。

容器格式

在啟動容器之前，我們需要構建或下載一個容器映象，這是一個檔案系統，裡面裝滿了應用程式所需的一切：程式碼、二進位制檔案、配置檔案、庫和依賴項。

容器的普及表明需要開放的映象標準。因此，Docker 公司和 CoreOS 於 2015 年建立了開放式容器計劃（OCI），其使命是生產供應商中立格式。這一努力的結果是創造了兩項標準：

• 定義映象二進位制格式的映象規範。
• 描述如何拆開和執行容器的執行時規範。OCI 維護稱為 runc 的參考實現。容器和 CRI-O 都使用背景中的流體生成容器。OCI 標準帶來了不同容器解決方案之間的互操作性。因此，一個系統內建的影像可以在任何其他合規堆疊中執行。

OCI 標準帶來了不同容器解決方案之間的互操作性。因此，一個系統內建的映象可以在任何其他合規堆疊中執行。

Docker Vs. Kubernetes

這裡是事情變得更加技術性的地方。我說每個 Kubernetes 工人節點都需要一個容器執行時。在其第一個原始設計 ，Docker 是離不開 Kubernetes，因為它是唯一的執行時支援。

然而，Docker 從未被設計成在 Kubernetes 內執行。意識到這個問題，Kubernetes 開發人員最終實現了一個名為容器執行時間介面（CRI）的 API。此介面允許我們在不同的容器執行時之間進行選擇，使平臺更加靈活，對 Docker 的依賴性更小。

這一變化給 Kubernetes 團隊帶來了新的困難， 因為 Docker 不知道 CRI 或支援 CRI 。因此，在引入 API 的同時，他們不得不編寫一個名為 Dockershim 的介面卡，以便將 CRI 訊息轉換為 Docker 特定命令。

棄用 Dockershim

雖然 Docker 是一段時間以來第一個也是唯一支援的引擎，但是它從來不在長期計劃內。Kubernetes V 1.20 棄用了 dockershim ， 拉開了離開 docker 的過渡的序幕。

一旦過渡完成，堆疊就會變小得多。它從這個：

變為：

結果是每個工人節點所需的膨脹更少，依賴性也更少。

那麼，為什麼要改變呢？

簡單地說，Docker 很重。我們得到更好的效能與輕量級集裝箱執行時，如容器或 CRI-O 。最近的例子是，谷歌的基準顯示，容器消耗的記憶體和 CPU 更少，而吊艙的啟動時間也比 Docker 少。

此外，在某些方面，Docker 本身可以被認為是技術債務。事實上，Kubernetes 需要的是容器執行時：容器。其餘的，至少就 Kubernetes 而言，是額外的開銷。

Kubernetes 棄用 Docker 對你有什麼影響？

事情並不像聽起來那麼戲劇化。讓我們在整節的開頭說，在 v1.20 中唯一改變的是，你會得到一個棄用警告，只有當你執行 Docker。就這樣。

我還能使用 Docker 進行開發嗎？

是的，你絕對可以，現在和在可預見的未來。你看，Docker 不執行 Docker 特定的映象：它執行符合 OCI 標準的容器。只要 Docker 繼續使用這種格式，Kubernetes 將繼續接受它們。

我仍然可以用 Docker 打包我的生產應用程式嗎？

是的，原因與上一個問題相同。與 Docker 打包的應用程式將繼續執行 - 那裡沒有變化。因此，您仍然可以使用您瞭解和喜愛的工具構建和測試容器。您不需要更改 CI/CD 管道或切換到其他映象註冊，Docker 製作的映象將繼續像始終一樣在群集中工作。

我需要改變什麼？

現在什麼都沒有如果您的群集使用 Docker 作為執行時，則升級到 v1.20 後將獲得棄用警告。但這一變化是 Kubernetes 社群發出的一個明確訊號，表明他們想採取的方向。是時候開始規劃未來了。

變革何時發生？

該計劃是在 2021 年底將所有 Docker 依賴關係完全刪除 v1.23。

當 Kubernetes 離開時，會發生什麼？

屆時，Kubernetes 叢集管理員將被迫切換到符合 CRI 標準的容器執行時。

如果你是一個終端使用者，沒有很多變化給你。除非你執行某種節點自定義，否則你可能不必做任何特別的事情。僅測試您的應用程式與新的容器執行時配合使用。

這些是升級到 v1.23 後會導致問題或中斷的一些事情：

• 使用 Docker 特定的日誌記錄和監視。即，從日誌中解析 Docker 訊息或投票 Docker API。
• 使用 Docker 優化。
• 執行依賴 docker CLI 的指令碼。
• 執行 docker 命令在特權吊艙。例如：構建映象。有關替代解決方案，請參閱卡尼科等專案。docker build
• 使用 docker 工人設定。
• 執行視窗容器。容器確實在 Windows 中工作， 但它的支援水平還沒有達到 Docker 的。目標是通過集裝箱版本 1.20 為 Windows 提供穩定的容器釋放。
• 如果您在 AWS EKS、Google GKE 或 Azure AKS 等雲提供商上使用託管叢集，請在 Docker 支援消失之前檢查您的叢集是否使用了支援的執行時。有些雲供應商落後幾個版本，因此您可能有更多的時間來計劃。因此，請諮詢您的提供商。舉個例子，谷歌雲宣佈，他們正在改變預設執行時從 Docker 到容器的所有新建立的工人節點，但你仍然可以選擇 Docker。

如果您執行自己的叢集：除了檢查上述要點外，您還需要評估移動到與 CRI 完全相容的另一個容器執行時。Kubernetes 文件詳細解釋了這些步驟：

• 切換到容器
• 切換到 CRI-O 或者，如果你想繼續使用 Docker 過去的版本 1.23，按照 cri-dockerd 專案，它計劃保持 Docker 作為一個可行的執行時選擇。

結論 Kubernetes 正在成長，但這種變化並不需要是一次創傷性的經歷。大多數使用者不必採取任何行動。對於那些這樣做的人，還有時間測試和計劃