還沒(méi)好好的感受，Kubernetes與Docker一起使用的時(shí)候，Kubernetes已經(jīng)棄用Docker了。有時(shí)候，我們都要相信，沒(méi)有什么會(huì)永垂不朽，即使是當(dāng)年一起緊密使用的Kubernetes和Docker，也最終是分道揚(yáng)鑣了。那么Docker為什么需要Kubernetes？在Kubernetes中又是如何使用Docker？為何最后Kubernetes又會(huì)廢棄Docker呢？如果我們想Kubernetes與Docker一起使用應(yīng)該怎么辦？我們一起來(lái)看看～

在介紹Docker為什么需要Kubernetes之前，我們先來(lái)看看為什么我們需要Docker？在Docker容器技術(shù)出現(xiàn)之前，我們開(kāi)發(fā)、測(cè)試、發(fā)布服務(wù)需要多個(gè)環(huán)境，開(kāi)發(fā)環(huán)境用于開(kāi)發(fā)人員寫(xiě)代碼、調(diào)試、自測(cè)，測(cè)試環(huán)境用于測(cè)試人員進(jìn)行功能測(cè)試、性能測(cè)試，生產(chǎn)環(huán)境用于發(fā)布正式版本，給用戶使用。在我們從開(kāi)發(fā)到上線的過(guò)程中，都在和環(huán)境打交道，在裝環(huán)境之前還得先申請(qǐng)資源，安裝操作系統(tǒng)、數(shù)據(jù)庫(kù)、應(yīng)用程序，并修改配置文件鏈接起來(lái)，這個(gè)過(guò)程是非常繁瑣的，每次修改內(nèi)容都還得重新部署一次，如果換個(gè)機(jī)器，不好意思，那就還得再來(lái)一輪。

Docker的出現(xiàn)解放了這個(gè)過(guò)程。Docker將應(yīng)用運(yùn)行的一整套環(huán)境，包括操作系統(tǒng)、數(shù)據(jù)庫(kù)、消息隊(duì)列等全都封裝成鏡像，研發(fā)人員可以在封裝的鏡像上面繼續(xù)封裝業(yè)務(wù)模塊，交付給測(cè)試和運(yùn)維人員。測(cè)試開(kāi)展測(cè)試工作時(shí)，只聚焦于業(yè)務(wù)就好，由于環(huán)境不同帶來(lái)的問(wèn)題已經(jīng)不存在了。并且Docker容器之間是進(jìn)程隔離的，在利用好服務(wù)器資源的同時(shí)，誰(shuí)也不會(huì)影響到誰(shuí)。這也是為什么阿里、頭條、美團(tuán)等互聯(lián)網(wǎng)巨頭都紛紛把基礎(chǔ)設(shè)施容器化的原因。

在微服務(wù)架構(gòu)的趨勢(shì)下，服務(wù)拆分成了微服務(wù)模式，為了保障高可用，核心微服務(wù)按照分布式進(jìn)行部署。以淘寶系統(tǒng)來(lái)說(shuō)，包含上千個(gè)微服務(wù)，一個(gè)節(jié)點(diǎn)部署一個(gè)容器，再按照分布式集群部署，整個(gè)淘寶系統(tǒng)估計(jì)得上萬(wàn)個(gè)節(jié)點(diǎn)，逢年過(guò)節(jié)，節(jié)點(diǎn)數(shù)還在不斷的增加，那就需要管理了呀，不然怎么保障節(jié)點(diǎn)之間的正常通信，問(wèn)題快速解決呢？于是Kubernetes產(chǎn)生了，它提供應(yīng)用級(jí)的集群抽象，把每個(gè)微服務(wù)抽象成service，以Pod運(yùn)行，Pod底層是Docker，對(duì)外提供能力。

在Kubernetes中包含masternode和worknode兩部分。MasterNode為控制節(jié)點(diǎn)，負(fù)責(zé)對(duì)集群資源進(jìn)行調(diào)度，用戶在KubeControllerManager中可以管控整個(gè)資源情況，比如執(zhí)行資源的創(chuàng)建與釋放；ApiServer類似Kubernetes的網(wǎng)關(guān)，對(duì)外接受客戶端的調(diào)用命令，對(duì)內(nèi)把調(diào)用請(qǐng)求傳遞給到對(duì)應(yīng)的WorkNode。WorkNode是真正干活的，真正運(yùn)行業(yè)務(wù)應(yīng)用，通過(guò)kubectl接受ApiServer的命令，使用ContainerRuntime下載鏡像和運(yùn)行容器。

問(wèn)題出現(xiàn)了，Kubernetes本身是不提供容器運(yùn)行環(huán)境的，而是使用CRI（ContainerRuntimeInterface容器運(yùn)行接口）在工作節(jié)點(diǎn)創(chuàng)建和刪除容器,因?yàn)镈ocker不符合Kubernetes的容器運(yùn)行時(shí)接口標(biāo)準(zhǔn)（CRI），所以官方必須要維護(hù)一個(gè)名為Dockershim的中間件才能夠把Docker當(dāng)作Kubernetes的容器運(yùn)行時(shí)來(lái)使用。此外Kubernetes使用的是Docker容器中的Cgroup能力，其它的模塊如網(wǎng)絡(luò)、存儲(chǔ)卷都不需要使用，然而它們卻隨Docker一起在Kubernetes中運(yùn)行，這就容易產(chǎn)生安全隱患了。綜上所述，這就是為什么Kubernetes要廢棄Docker了。

作為Kubernetes與Docker容器的用戶，不必要驚慌，使用CRI運(yùn)行時(shí)替代方案即可。CRI的實(shí)現(xiàn)方案有兩種，分別是Containerd和CRI-O。Containerd是CNCF云原生計(jì)算基金會(huì)開(kāi)源項(xiàng)目，在GitHub（https://github.com/containerd/containerd/）可直接下載使用，它是容器虛擬化技術(shù)，從Docker中剝離出來(lái)，形成開(kāi)放容器接口（OCI）的一部分，容器引擎使用它可以進(jìn)行整個(gè)容器生命周期管理（創(chuàng)建）、拉取/推送容器鏡像、存儲(chǔ)管理鏡像、管理容器網(wǎng)絡(luò)接口及網(wǎng)絡(luò)。它生于Docker，可以完成所有的運(yùn)行時(shí)工作，使用它是很好的選擇。

與Containerd相比，CRI-O就不那么友好了，它是由紅帽開(kāi)發(fā)的純CRI運(yùn)行時(shí)，對(duì)于RedHatOpenshit支持的比較好，不支持Docker，因此從Docker遷移到CRI-O是比較麻煩的。

Kubernetes官方表示Docker作為一個(gè)完整的容器技術(shù)棧，在創(chuàng)建之初就不是為了Kubernetes而設(shè)計(jì)的。Kubernetes只是在v1.20版本后不推薦將Docker作為容器運(yùn)行時(shí)使用，用戶今后依然可以使用Docker來(lái)構(gòu)建容器鏡像，而Docker生成的鏡像實(shí)際上也是一個(gè)OCI（OpenContainer Initiative）鏡像。可以說(shuō)無(wú)論使用什么工具來(lái)構(gòu)建鏡像，任何符合OCI標(biāo)準(zhǔn)的鏡像在Kubernetes看來(lái)都是一樣的。Containerd和CRI-O則可以提取這些鏡像并運(yùn)行它們。技術(shù)的升級(jí)一般來(lái)說(shuō)都是好事，它始終是為了更好的服務(wù)才做改動(dòng)。無(wú)論是開(kāi)發(fā)人員、運(yùn)維人員，我們都需要擁抱變化。