KubernetesvsDocker：2021年容器有哪些變化

KubernetesvsDocker：2021

年容器有哪些變化前言幾個(gè)星期前，Kubernetes開(kāi)發(fā)團(tuán)隊(duì)宣布，他們正在棄用docker。這則新聞通過(guò)科技界和社交網(wǎng)絡(luò)廣為流傳。Kubernetes群集是否會(huì)中斷，如果是，我們將如何運(yùn)行我們的應(yīng)用程序？我們現(xiàn)在該怎么辦？今天，我們將審查所有這些問(wèn)題和更多。讓我們從頭開(kāi)始。如果你已經(jīng)熟悉docker和kubernetes，并希望直接了解關(guān)鍵信息，跳到docker棄用對(duì)你有什么影響？什么是容器？盡管Docker被用作容器的同義詞，但現(xiàn)實(shí)情況是，它們?cè)缭赿ocker成為東西之前就已經(jīng)存在了。Unix和Linux自70年代末開(kāi)始引入chroot以來(lái)，一直有某種形式的容器。Chroot允許系統(tǒng)管理員在一種但并非真正孤立的文件系統(tǒng)中運(yùn)行程序。后來(lái)，這個(gè)想法被提煉和增強(qiáng)到集裝箱引擎，如免費(fèi)BSDJails，OpenVZ，或LinuxContainers（LXC）。但是什么是容器呢？容器是一個(gè)邏輯分區(qū)，我們可以運(yùn)行與系統(tǒng)其余部分分離的應(yīng)用程序。每個(gè)應(yīng)用程序都有自己的專用網(wǎng)絡(luò)和不與其他容器或主機(jī)共享的虛擬文件系統(tǒng)。

ContainerRuntimeContainerContainerContainerContainerHostOperatingSystemContainerRuntimeContainerContainerContainerContainerHostOperatingSystem運(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-從長(zhǎng)遠(yuǎn)來(lái)看。這并不奇怪，因?yàn)樗鼘⑷萜鞯母拍钜胫髁?，這反過(guò)來(lái)又激發(fā)了像Kubernetes這樣的平臺(tái)的創(chuàng)建。在Docker之前，運(yùn)行容器確實(shí)是可能的，但這是艱苦的工作。Docker使事情變得簡(jiǎn)單，因?yàn)樗且粋€(gè)完整的技術(shù)堆棧，可以：管理容器生命周期。代理請(qǐng)求來(lái)回容器。監(jiān)視和記錄容器活動(dòng)。安裝共享目錄。對(duì)容器設(shè)置資源限制。生成鏡像。Dockerfile是構(gòu)建容器鏡像的格式文件。從注冊(cè)處推送和拉取圖像。在第一次迭代中，Docker使用Linux容器（LXC）作為運(yùn)行時(shí)間后端。隨著項(xiàng)目的發(fā)展，LXC被容器所取代，docker自己的實(shí)施?，F(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ù)載均衡：請(qǐng)求分布在健康的可用吊艙上。推出：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ù)庫(kù)稱為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。

ContainerCC&ntain&rB容器格式ControlPlaneContainerRuntimeWorkerNodeWorkerNodeControllerSchedulerkubeletproxyAPIserverkubeletproxyContainerRuntimeContain"APodContainerCC&ntain&rB容器格式ControlPlaneContainerRuntimeWorkerNodeWorkerNodeControllerSchedulerkubeletproxyAPIserverkubeletproxyContainerRuntimeContain"APod1在啟動(dòng)容器之前，我們需要構(gòu)建或下載一個(gè)容器鏡像，這是一個(gè)文件系統(tǒng)，里面裝滿了應(yīng)用程序所需的一切：代碼、二進(jìn)制文件、配置文件、庫(kù)和依賴項(xiàng)。容器的普及表明需要開(kāi)放的鏡像標(biāo)準(zhǔn)。因此，Docker公司和CoreOS于2015年建立了開(kāi)放式容器計(jì)劃（OCI），其使命是生產(chǎn)供應(yīng)商中立格式。這一努力的結(jié)果是創(chuàng)造了兩項(xiàng)標(biāo)準(zhǔn)：定義鏡像二進(jìn)制格式的鏡像規(guī)范。描述如何拆開(kāi)和運(yùn)行容器的運(yùn)行時(shí)規(guī)范。OCI維護(hù)稱為runc的參考實(shí)現(xiàn)。容器和cri-o都使用背景中的流體生成容器。OCI標(biāo)準(zhǔn)帶來(lái)了不同容器解決方案之間的互操作性。因此，一個(gè)系統(tǒng)內(nèi)置的圖像可以在任何其他合規(guī)堆棧中運(yùn)行。OCI標(biāo)準(zhǔn)帶來(lái)了不同容器解決方案之間的互操作性。因此，一個(gè)系統(tǒng)內(nèi)置的鏡像可以在任何其他合規(guī)堆棧中運(yùn)行。DockervsKubernetes這里是事情變得更加技術(shù)性的地方。我說(shuō)每個(gè)Kubernetes工人節(jié)點(diǎn)都需要一個(gè)容器運(yùn)行時(shí)。在其第一個(gè)原始設(shè)計(jì)，Docker是離不開(kāi)Kubernetes，因?yàn)樗俏ㄒ坏倪\(yùn)行時(shí)支持。然而，Docker從未被設(shè)計(jì)成在Kubernetes內(nèi)運(yùn)行。意識(shí)到這個(gè)問(wèn)題，Kubernetes開(kāi)發(fā)人員最終實(shí)現(xiàn)了一個(gè)名為容器運(yùn)行時(shí)間接口(CRI)的API。此界面允許我們?cè)诓煌娜萜鬟\(yùn)行時(shí)之間進(jìn)行選擇，使平臺(tái)更加靈活，對(duì)Docker的依賴性更小。

這一變化給Kubernetes團(tuán)隊(duì)帶來(lái)了新的困難，因?yàn)镈ocker不知道CRI或支持CRI。因此，在引入API的同時(shí)，他們不得不編寫一個(gè)名為Dockershim的適配器，以便將CRI消息轉(zhuǎn)換為Docker特定命令。棄用Dockershim雖然Docker是一段時(shí)間以來(lái)第一個(gè)也是唯一支持的引擎，但是它從來(lái)不在長(zhǎng)期計(jì)劃內(nèi)。160皿0土0$V1.20棄用了dockershim,拉開(kāi)了離開(kāi)docker的過(guò)渡的序幕。一旦過(guò)渡完成，堆棧就會(huì)變小得多。它從這個(gè)：廠(contaLi-r1] cri , -、kubelet *containerd-<iContainer1)L[C-ntaineri]結(jié)果是每個(gè)工人節(jié)點(diǎn)所需的膨脹更少，依賴性也更少。那么，為什么要改變呢？簡(jiǎn)單地說(shuō)，Docker很重。我們得到更好的性能與輕量級(jí)集裝箱運(yùn)行時(shí)，如容器或CRbO。最近的例子是，谷歌的基準(zhǔn)顯示，容器消耗的內(nèi)存和CPU更少，而吊艙的啟動(dòng)時(shí)間也比Docker少。止匕外，在某些方面，Docker本身可以被認(rèn)為是技術(shù)債務(wù)。事實(shí)上，Kubernetes需要的是容器運(yùn)行時(shí)：容器。其余的，至少就Kubernetes而言，是額外的開(kāi)銷。Kubernetes棄用Docker對(duì)你有什么影響？事情并不像聽(tīng)起來(lái)那么戲劇化。讓我們?cè)谡?jié)的開(kāi)頭說(shuō)，在v1.20中唯一改變的是，你會(huì)得到一個(gè)棄用警告，只有當(dāng)你運(yùn)行Docker。就這樣。我還能使用Docker進(jìn)行開(kāi)發(fā)嗎？是的，你絕對(duì)可以，現(xiàn)在和在可預(yù)見(jiàn)的未來(lái)。你看，Docker不運(yùn)行Docker特定的鏡像：它運(yùn)行符合OCI標(biāo)準(zhǔn)的容器。只要Docker繼續(xù)使用這種格式，Kubernetes將繼續(xù)接受它們。我仍然可以用Docker打包我的生產(chǎn)應(yīng)用程序嗎？是的，原因與上一個(gè)問(wèn)題相同。與Docker打包的應(yīng)用程序?qū)⒗^續(xù)運(yùn)行-那里沒(méi)有變化。因此，您仍然可以使用您了解和喜愛(ài)的工具構(gòu)建和測(cè)試容器。您不需要更改CI/CD管道或切換到其他鏡像注冊(cè)，Docker制作的鏡像將繼續(xù)像始終一樣在群集中工作。我需要改變什么？現(xiàn)在什么都沒(méi)有如果您的群集使用Docker作為運(yùn)行時(shí)，則升級(jí)到v1.20后將獲得棄用警告。但這一變化是Kubernetes社區(qū)發(fā)出的一個(gè)明確信號(hào)，表明他們想采取的方向。是時(shí)候開(kāi)始規(guī)劃未來(lái)了。變革何時(shí)發(fā)生？該計(jì)劃是在2021年底將所有Docker依賴關(guān)系完全刪除v1.23。當(dāng)Kubernetes離開(kāi)時(shí)，會(huì)發(fā)生什么？屆時(shí)，Kubernetes集群管理員將被迫切換到符合CRI標(biāo)準(zhǔn)的容器運(yùn)行時(shí)。如果你是一個(gè)最終用戶，沒(méi)有很多變化給你。除非你運(yùn)行某種節(jié)點(diǎn)自定義，否則你可能不必做任何特別的事情。僅測(cè)試您的應(yīng)用程序與新的容器運(yùn)行時(shí)配合使用。這些是升級(jí)到v1.23后會(huì)導(dǎo)致問(wèn)題或中斷的一些事情：使用Docker特定的日志記錄和監(jiān)視。即，從日志中解析Docker消息或投票DockerAPI。使用Docker優(yōu)化。運(yùn)行依賴dockerCLI的腳本。運(yùn)行docker命令在特權(quán)吊艙。例如：構(gòu)建鏡像。有關(guān)替代解決方案，請(qǐng)參閱卡尼科等項(xiàng)目。dockerbuild使用docker工人設(shè)置。運(yùn)行窗口容器。容器確實(shí)在Windows中工作，但它的支持水平還沒(méi)有達(dá)到Docker的。目標(biāo)是通過(guò)集裝箱版本1.20為Windows提供穩(wěn)定的容器釋放。如果您在AWSEKS、GoogleGKE或AzureAKS等云提供商上使用托管集群，請(qǐng)?jiān)贒ocker支持消失之前檢查您的集群是否使用了支持的運(yùn)行時(shí)。有些云供應(yīng)商落后幾個(gè)版本，因此您可能有更多的時(shí)間來(lái)計(jì)劃。因此，請(qǐng)咨詢您的提供商。舉個(gè)例子，谷歌云宣布，他們正在改變默認(rèn)運(yùn)行時(shí)從Docker到容器的所有新創(chuàng)建的工人節(jié)點(diǎn)，但你仍然可以選擇Dockero如果您運(yùn)