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