[導讀]-???前言??-幾個星期前，Kubernetes開發(fā)團隊宣布，他們正在棄用docker。這則新聞通過科技界和社交網絡廣為流傳。Kubernetes群集是否會中斷，如果是，我們將如何運行我們的應用程序？我們現在該怎么辦？今天，我們將審查所有這些問題和更多。讓我們從頭開始。如果你已...
-? ? ?前言? ? -
幾個星期前，Kubernetes開發(fā)團隊宣布，他們正在棄用docker。這則新聞通過科技界和社交網絡廣為流傳。Kubernetes 群集是否會中斷，如果是，我們將如何運行我們的應用程序？我們現在該怎么辦？今天，我們將審查所有這些問題和更多。
讓我們從頭開始。如果你已經熟悉docker和kubernetes，并希望直接了解關鍵信息，跳到docker棄用對你有什么影響？
-? ? ?什么是容器？? ? -
盡管Docker被用作容器的同義詞，但現實情況是，它們早在docker成為東西之前就已經存在了。Unix 和 Linux 自 70 年代末開始引入 chroot 以來，一直有某種形式的容器。Chroot 允許系統管理員在一種但并非真正孤立的文件系統中運行程序。后來，這個想法被提煉和增強到集裝箱引擎，如免費 BSD Jails ， OpenVZ ，或Linux Containers（LXC）?。
但是什么是容器呢？
容器是一個邏輯分區(qū)，我們可以運行與系統其余部分分離的應用程序。每個應用程序都有自己的專用網絡和不與其他容器或主機共享的虛擬文件系統。
運行容器應用程序比安裝和配置軟件方便得多。首先，容器是便攜式的：我們可以在一臺服務器中構建，并相信它將在任何服務器中工作。另一個優(yōu)點是，我們可以同時運行同一程序的多個副本，而不會發(fā)生沖突或重疊，否則確實很難做到。
然而，要使這一切發(fā)揮作用，我們需要一個容器runtime，一個能夠運行容器的軟件。
-? ? ?什么是 Docker？? ? -
什么是docker？
docker是最受歡迎的容器runtime-從長遠來看。這并不奇怪，因為它將容器的概念引入主流，這反過來又激發(fā)了像Kubernetes這樣的平臺的創(chuàng)建。
在Docker之前，運行容器確實是可能的，但這是艱苦的工作。Docker 使事情變得簡單，因為它是一個完整的技術堆棧，可以：
- 管理容器生命周期。
- 代理請求來回容器。
- 監(jiān)視和記錄容器活動。
- 安裝共享目錄。
- 對容器設置資源限制。
- 生成鏡像。Dockerfile是構建容器鏡像的格式文件。
- 從注冊處推送和拉取圖像。
- 在第一次迭代中，Docker 使用 Linux 容器 （LXC） 作為運行時間后端。隨著項目的發(fā)展，LXC被容器所取代，docker自己的實施?，F代docker安裝分為兩個服務：containerd，負責管理容器；dockerd，處理剩余的部分。
-? ? ?什么是 Kubernetes？? ? -
kubernetes采取容器的想法，并把它一個缺口。Kubernetes 不是在單個服務器中運行容器化應用程序，而是將其分布在一組機器上。在 Kubernetes 中運行的應用程序的外觀和行為都像一個單元，盡管在現實中，它們可能由松散耦合的容器排列而成。
Kubernetes在容器頂部添加分布式計算功能：
- 吊艙：吊艙是共享內存、CPU、存儲和網絡等資源的邏輯容器組。
- 自動縮放：Kubernetes 可根據需要啟動和停止吊艙，從而自動適應不斷變化的工作負載。
- 自我修復：容器在故障時被監(jiān)控并重新啟動。
- 負載均衡：請求分布在健康的可用吊艙上。
- 推出：kubernetes支持自動推出和回滾。使 Canary 和 Blue-Green 等復雜程序變得微不足道。我們可以將Kubernetes的架構視為兩架飛機的組合：
控制面板是集群的協調大腦。它有一個控制器，管理節(jié)點和服務，調度器分配吊艙的節(jié)點，和API服務，處理通信。配置和狀態(tài)存儲在一個高度可用的數據庫稱為etcd。工人節(jié)點是運行容器的機器。每個工人節(jié)點運行幾個組件，如kubelet代理、網絡代理和容器運行時。Kubernetes版本 v1.20 的默認容器運行時是 Docker。
-? ? ?容器格式? ? -
在啟動容器之前，我們需要構建或下載一個容器鏡像，這是一個文件系統，里面裝滿了應用程序所需的一切：代碼、二進制文件、配置文件、庫和依賴項。
容器的普及表明需要開放的鏡像標準。因此，Docker 公司和 CoreOS 于 2015 年建立了開放式容器計劃（OCI）?，其使命是生產供應商中立格式。這一努力的結果是創(chuàng)造了兩項標準：
- 定義鏡像二進制格式的鏡像規(guī)范。
- 描述如何拆開和運行容器的運行時規(guī)范。OCI 維護稱為runc的參考實現。容器和 CRI-O 都使用背景中的流體生成容器。OCI 標準帶來了不同容器解決方案之間的互操作性。因此，一個系統內置的圖像可以在任何其他合規(guī)堆棧中運行。
OCI 標準帶來了不同容器解決方案之間的互操作性。因此，一個系統內置的鏡像可以在任何其他合規(guī)堆棧中運行。
-? ? ?Docker VS Kubernetes? ? -
這里是事情變得更加技術性的地方。我說每個Kubernetes工人節(jié)點都需要一個容器運行時。在其第一個原始設計?，Docker是離不開Kubernetes，因為它是唯一的運行時支持。
然而，Docker從未被設計成在Kubernetes內運行。意識到這個問題，Kubernetes開發(fā)人員最終實現了一個名為容器運行時間接口（CRI） 的 API。此界面允許我們在不同的容器運行時之間進行選擇，使平臺更加靈活，對 Docker 的依賴性更小。?
這一變化給Kubernetes團隊帶來了新的困難， 因為Docker不知道CRI或支持CRI 。因此，在引入 API 的同時，他們不得不編寫一個名為Dockershim的適配器，以便將 CRI 消息轉換為 Docker 特定命令。
-? ? ?棄用 Dockershim? ? -
雖然Docker是一段時間以來第一個也是唯一支持的引擎，但是它從來不在長期計劃內。Kubernetes V 1.20棄用了dockershim ， 拉開了離開docker的過渡的序幕。
一旦過渡完成，堆棧就會變小得多。它從這個：?
?變?yōu)椋?結果是每個工人節(jié)點所需的膨脹更少，依賴性也更少。
-? ? ?那么，為什么要改變呢？? ? -
簡單地說，Docker很重。我們得到更好的性能與輕量級集裝箱運行時，如容器或CRI-O 。最近的例子是，谷歌的基準顯示，容器消耗的內存和CPU更少，而吊艙的啟動時間也比Docker少。
此外，在某些方面，Docker本身可以被認為是技術債務。事實上，Kubernetes需要的是容器運行時：容器。其余的，至少就Kubernetes而言，是額外的開銷。
Kubernetes棄用Docker對你有什么影響？
事情并不像聽起來那么戲劇化。讓我們在整節(jié)的開頭說，在v1.20中唯一改變的是，你會得到一個棄用警告，只有當你運行Docker。就這樣。
我還能使用Docker進行開發(fā)嗎？
是的，你絕對可以，現在和在可預見的未來。你看，Docker不運行Docker特定的鏡像：它運行符合OCI標準的容器。只要Docker繼續(xù)使用這種格式，Kubernetes將繼續(xù)接受它們。
我仍然可以用Docker打包我的生產應用程序嗎？
是的，原因與上一個問題相同。與Docker打包的應用程序將繼續(xù)運行-那里沒有變化。因此，您仍然可以使用您了解和喜愛的工具構建和測試容器。您不需要更改CI/CD 管道或切換到其他鏡像注冊，Docker 制作的鏡像將繼續(xù)像始終一樣在群集中工作。
-? ? ?我需要改變什么？? ? -
現在什么都沒有如果您的群集使用 Docker 作為運行時，則升級到 v1.20 后將獲得棄用警告。但這一變化是Kubernetes社區(qū)發(fā)出的一個明確信號，表明他們想采取的方向。是時候開始規(guī)劃未來了。
變革何時發(fā)生？
該計劃是在2021年底將所有Docker依賴關系完全刪除v1.23。
當Kubernetes離開時，會發(fā)生什么？
屆時，Kubernetes 集群管理員將被迫切換到符合 CRI 標準的容器運行時。
如果你是一個最終用戶，沒有很多變化給你。除非你運行某種節(jié)點自定義，否則你可能不必做任何特別的事情。僅測試您的應用程序與新的容器運行時配合使用。
這些是升級到 v1.23 后會導致問題或中斷的一些事情：
- 使用Docker特定的日志記錄和監(jiān)視。即，從日志中解析 Docker 消息或投票 Docker API。
- 使用Docker優(yōu)化。
- 運行依賴docker CLI 的腳本。
- 運行docker命令在特權吊艙。例如：構建鏡像。有關替代解決方案，請參閱卡尼科等項目。docker build
- 使用docker工人設置。
- 運行窗口容器。容器確實在 Windows 中工作， 但它的支持水平還沒有達到 Docker 的。目標是通過集裝箱版本 1.20為 Windows 提供穩(wěn)定的容器釋放。
- 如果您在 AWS EKS、Google GKE 或 Azure AKS 等云提供商上使用托管集群，請在 Docker 支持消失之前檢查您的集群是否使用了支持的運行時。有些云供應商落后幾個版本，因此您可能有更多的時間來計劃。因此，請咨詢您的提供商。舉個例子，谷歌云宣布，他們正在改變默認運行時從Docker到容器的所有新創(chuàng)建的工人節(jié)點，但你仍然可以選擇Docker。
如果您運行自己的集群：除了檢查上述要點外，您還需要評估移動到與 CRI 完全兼容的另一個容器運行時。Kubernetes文檔詳細解釋了這些步驟：
- 切換到容器
- 切換到CRI-O 或者，如果你想繼續(xù)使用Docker過去的版本1.23，按照cri-dockerd項目，它計劃保持Docker作為一個可行的運行時選擇。
結論 Kubernetes正在成長，但這種變化并不需要是一次創(chuàng)傷性的經歷。大多數用戶不必采取任何行動。對于那些這樣做的人，還有時間測試和計劃。
下載文檔
