Kubernetes竟棄用Docker？
當(dāng)Kubernetes與Docker一起使用時，Kubernetes已經(jīng)被遺棄了Docker。有時，我們都必須相信什么都不會持續(xù)。即使是Kubernetes和Docker，那么最終與之使用在一起，最終與方式分開。那么為什么Docker需要Kubernetes？髕骨如何用于Kubernetes？為什么Kubernetes終于放棄了Docker？如果我們想使用與Docker的Kubernetes何時何地？讓我們一起看?介紹Docker需要Kubernetes之前，讓我們來看看為什么我們需要碼頭？在碼頭容器技術(shù)的出現(xiàn)之前，我們需要多種環(huán)境進(jìn)行開發(fā)，測試和出版服務(wù)。開發(fā)環(huán)境用于開發(fā)人員編寫代碼，調(diào)試和自檢。測試環(huán)境用于測試儀的功能測試和性能測試，并使用生產(chǎn)環(huán)境用于釋放官方版以供用戶使用。在從開發(fā)啟動的過程中，我們正在處理環(huán)境。在安裝環(huán)境之前，必須首先申請資源，安裝操作系統(tǒng)，數(shù)據(jù)庫，應(yīng)用程序和修改配置文件以鏈接。這個過程非常麻煩。每個修改都必須再次重新部署。如果你改變機(jī)器，我很抱歉，那么你必須做另一輪。碼頭的出現(xiàn)解放了這個過程。 Docker封裝了一組完整的環(huán)境，其中應(yīng)用程序運(yùn)行，包括操作系統(tǒng)，數(shù)據(jù)庫，消息隊列等。研發(fā)人員可以繼續(xù)封裝封裝圖像上的業(yè)務(wù)模塊，并將其提供測試和操作和維護(hù)人員。在測試和測試時，只關(guān)注業(yè)務(wù)就很好。不同環(huán)境造成的問題不再存在。和碼頭容器是孤立的過程。在充分利用服務(wù)器資源的同時，沒有人會影響任何人。這也是互聯(lián)網(wǎng)巨頭如Ali，Toutiao和Meituan的原因也是所有集裝箱的基礎(chǔ)設(shè)施。
在微服務(wù)架構(gòu)的趨勢下，服務(wù)被分成了微服務(wù)模型。為了確保高可用性，以分布式方式部署核心微服務(wù)。對于淘寶系統(tǒng)，它包含數(shù)千個微服務(wù)，一個節(jié)點(diǎn)部署一個容器，然后根據(jù)分布式群集部署，整個淘寶系統(tǒng)估計有數(shù)萬個節(jié)點(diǎn)。在假期期間，節(jié)點(diǎn)的數(shù)量仍在增加，然后需要進(jìn)行管理，否則如何保證節(jié)點(diǎn)之間的正常通信并快速解決問題？所以Kubernetes出生。它提供了應(yīng)用程序級群集抽象，將每個MicroService摘要到服務(wù)中，運(yùn)行為POD。 POD的底層是Docker，它提供外部能力。 Kubernetes，Masternode和Worknode有兩部分。 Masternode是控制節(jié)點(diǎn)，負(fù)責(zé)調(diào)度群集資源。用戶可以控制KubeControllermanager中的整個資源情況，例如執(zhí)行資源創(chuàng)建和釋放; Apiserver類似于Kubernetes網(wǎng)關(guān)，它接受外部的客戶端調(diào)用，內(nèi)部傳輸呼叫請求轉(zhuǎn)到相應(yīng)的工作室。 Worknode實(shí)際上是工作，真正運(yùn)行業(yè)務(wù)應(yīng)用程序，通過Kubectl接受Apiserver命令，使用ContexErruntime下載圖像和運(yùn)行容器。
出現(xiàn)問題。 Kubernetes本身并不提供容器運(yùn)行時環(huán)境，但使用CRI（ContainErruntimeInterface Container Runtime接口）來創(chuàng)建和刪除工作者節(jié)點(diǎn)上的容器。由于Docker不符合Kubernetes Container運(yùn)行時接口標(biāo)準(zhǔn)（CRI），因此必須維護(hù)一個名為Dockershim的中間件，以便能夠使用Docker作為Kubernetes Container運(yùn)行時。此外，Kubernetes使用Docker容器中的CGROUP功能。不需要使用其他模塊，例如網(wǎng)絡(luò)和存儲卷，但它們在Kubernetes中運(yùn)行以及Docker，這容易出現(xiàn)安全風(fēng)險。總之，這就是為什么Kubernetes被遺棄的Docker。
作為Kubernetes和Docker容器的用戶，不需要恐慌，只需使用CRI運(yùn)行時替代。 CRI有兩種實(shí)施方案，即ContainerD和CRI-O. Contantd是CNCF云本機(jī)計算基礎(chǔ)的開源項目。它可以直接下載并直接在github上使用（https://github.com/containerd/containerd/）。它是一個容器虛擬化技術(shù)，已從Docker剝離以形成一個開放的容器接口（OCI），集裝箱引擎可以使用它來管理整個容器生命周期（創(chuàng)建），拉/推容器圖像，存儲管理圖像，管理容器網(wǎng)絡(luò)接口和網(wǎng)絡(luò)。它出生于碼頭，可以做所有的運(yùn)行時工作。使用它是一個不錯的選擇。
與集裝箱相比，CRI-O并不是如此友好。它是紅帽開發(fā)的純CRI運(yùn)行時。它支持Redhatopenshit更好，不支持Docker。因此，從Docker遷移到CRI-O更麻煩。 Kubernetes正式表示，作為一個完整的集裝箱技術(shù)堆棧，Docker不是在創(chuàng)作開始時為Kubernetes設(shè)計的。 Kubernetes在V1.20之后，僅推薦使用Docker作為容器運(yùn)行時。用戶仍可使用Docker將來構(gòu)建容器圖像，并且Docker生成的圖像實(shí)際上是OCI（OpenContainer Initiative）圖像。可以說，無論用什么工具來構(gòu)建圖像，任何符合OCI標(biāo)準(zhǔn)的任何圖像都在Kubernetes中看起來也是如此。 ContainerD和CRI-O可以提取這些圖像并運(yùn)行它們。技術(shù)升級通常是件好事，并且始終以更好的服務(wù)進(jìn)行更改。無論是開發(fā)人員還是運(yùn)營和維護(hù)人員，我們都需要接受改變。
