這幾天一則Kubernetes將放棄Docker的消息引起業(yè)內(nèi)廣泛關(guān)注。根據(jù)Kubernetes社區(qū)給出的說明，在1.20版本之后，Kubernetes將不再支持把Docker作為容器運(yùn)行時(shí)使用，據(jù)此不少人開始擔(dān)心Docker未來不能用了。實(shí)際上，這并不是說Kubernetes要完全拋棄Docker，CNCF也提醒說不要驚慌，Docker 生成的鏡像將繼續(xù)在用戶的集群中與所有運(yùn)行時(shí)一起工作。但這件事還是讓人不免產(chǎn)生聯(lián)想，Docker還有一個(gè)怎樣的未來?很長(zhǎng)時(shí)間以來，談到容器，Kubernetes + Docker好像是標(biāo)配，現(xiàn)在看來并不一定。 

Kubelet不再支持Docker運(yùn)行時(shí)

人們對(duì)Docker未來的擔(dān)心源于Kubernetes 在1.20版本中 的 ChangeLog 提到，kubelet 中的 Docker 支持功能現(xiàn)已棄用，并將在之后的版本中被刪除。社區(qū)解釋說，這么做的原因是，Kubelet 之前使用的是一個(gè)名為 dockershim 的模塊，用以實(shí)現(xiàn)對(duì) Docker 的 CRI 支持，但 Kubernetes 社區(qū)發(fā)現(xiàn)其維護(hù)存在問題，因此建議大家考慮使用包含 CRI 完整實(shí)現(xiàn)的可用容器運(yùn)行時(shí)。

首先要說明的是，這里提到的Docker運(yùn)行時(shí)并不等同于我們經(jīng)常說的Docker，這可能是讓人們以為Docker被Kubernetes拋棄的一個(gè)原因。運(yùn)行時(shí)(Runtime)為應(yīng)用程序運(yùn)行時(shí)提供保障的一個(gè)環(huán)境，通常是一些可以重用的程序/庫或者實(shí)例，這些實(shí)例可以在它們運(yùn)行的時(shí)候被連接或者被任何程序調(diào)用。在Kubernetes集群內(nèi)部也有一種稱為容器運(yùn)行時(shí)的組件，負(fù)責(zé)提取并運(yùn)行容器鏡像。Docker就是目前最流行的容器運(yùn)行時(shí)，除此之外容器運(yùn)行時(shí)還有Containerd與CRI-O。

與Containerd與CRI-O的定位就是一個(gè)運(yùn)行時(shí)不同，Docker集成了太多功能，而很多功能作為一個(gè)運(yùn)行時(shí)并非必須，比如容器創(chuàng)建，而且Docker最初在設(shè)計(jì)上也并未考慮到被嵌入到Kubernetes這種用法。

應(yīng)該說，當(dāng)初為了支持使用Docker的這個(gè)運(yùn)行時(shí)，kubelet做出了妥協(xié)。如果采用Containerd與CRI-O運(yùn)行時(shí)，其調(diào)用流程是：kubelet向CRI-Container插件發(fā)出調(diào)用請(qǐng)求，由CRI-Container再和容器運(yùn)行時(shí)通信，完成請(qǐng)求的各種操作，但采用Docker運(yùn)行時(shí)，這個(gè)流程就需要做出改變。由于Docker運(yùn)行時(shí)并不兼容CRI，不得不引入一個(gè)新的插件Dockershimi作為緩沖。此時(shí)流程變成：kubelet先向Dockershimi發(fā)出請(qǐng)求，由Dockershimi調(diào)用Docker運(yùn)行時(shí)，Docker運(yùn)行時(shí)再調(diào)用其中的Containerd，由Containerd來負(fù)責(zé)完成請(qǐng)求的各種操作。可以看出，這個(gè)過程中Docker運(yùn)行時(shí)有點(diǎn)尬尷，它的加入不僅在流程上多了一個(gè)環(huán)節(jié)，引入了Dockershimi，而Dockershimi的介入又引發(fā)了新的問題，必須額外加以維護(hù)，否則就可能引發(fā)安全問題。

如今，隨著Kubernetes社區(qū)的逐漸強(qiáng)大，當(dāng)初Kubernetes向Docker做出的妥協(xié)現(xiàn)在不打算繼續(xù)了，這才有了kubelet不再支持Docker運(yùn)行時(shí)的舉措。目前來看這件事的影響不大，正如CNCF所言，Docker不會(huì)就此消亡，Docker會(huì)繼續(xù)構(gòu)建起不計(jì)其數(shù)的容器，開發(fā)人員仍然可以繼續(xù)采用Docker，繼續(xù)將Docker作為開發(fā)工具，Docker所生成的鏡像仍可在Kubernetes集群內(nèi)正常運(yùn)行。

如果使用的是云上的容器服務(wù)，比如GKE或者EKS等托管Kubernetes服務(wù)，則需要確保在未來的Kubernetes版本徹底去除Docker支持之前，為工作節(jié)點(diǎn)引入受支持的容器運(yùn)行時(shí)。如果是自己負(fù)責(zé)管理的集群，則要注意更新和調(diào)整運(yùn)行時(shí)以避免服務(wù)中斷。在1.20版本中，將收到Docker棄用警告。而在未來的Kubernets版本(計(jì)劃在2021年下半年發(fā)布的1.23版本)中，Docker運(yùn)行時(shí)將被徹底移除、不再受到支持。

然而，長(zhǎng)期來看呢?

Docker的未來在哪里?

毋庸置疑，容器的流行Docker功不可沒。在Docker出來之前，容器已經(jīng)存在多年，但并不普及，直到Docker的出現(xiàn)。2013年，Docker的出現(xiàn)第一次把運(yùn)行容器變得這么簡(jiǎn)單，使用Docker開發(fā)人員可以輕松啟動(dòng)、停止和撤銷容器，而且其低學(xué)習(xí)曲線和易用性使其成為軟件開發(fā)過程中的主流。

可以說，Docker以一己之力將容器這種相對(duì)邊緣的技術(shù)硬生生地變成了網(wǎng)紅。Docker的走紅帶動(dòng)了Docker生態(tài)，大量圍繞著 Docker 項(xiàng)目的網(wǎng)絡(luò)、存儲(chǔ)、監(jiān)控、CI/CD、甚至 UI 項(xiàng)目紛紛出臺(tái)，也涌現(xiàn)出了Rancher等一批在開源創(chuàng)業(yè)公司。與此同時(shí)，競(jìng)爭(zhēng)的種子也就此埋下。

Docker最初從開發(fā)端發(fā)力，一家獨(dú)大，但是要Docker希望繼續(xù)做大，特別是獲取商業(yè)價(jià)值，就需要向應(yīng)用部署和運(yùn)營(yíng)方向發(fā)力，提供部署、監(jiān)控和管理等放方方面面的工具，Swarm就是其中之一。而對(duì)CoreOS、Red Hat、谷歌和微軟等這些應(yīng)用程序運(yùn)行平臺(tái)提供方而言，支持容器是剛需，但它們希望通過容器運(yùn)行時(shí)的標(biāo)準(zhǔn)化，來盡可能降低Docker的影響。顯然，Docker并不愿意，特別是當(dāng)時(shí)Docker如此火爆的背景之下。這就是雙方爭(zhēng)奪的焦點(diǎn)。

OCI規(guī)范的推出就是雙方競(jìng)爭(zhēng)達(dá)成妥協(xié)的結(jié)果。2015 年 Docker 公司牽頭，聯(lián)合CoreOS、Google、RedHat 等公司共同宣布，Docker 將自己的容器運(yùn)行時(shí)庫 Libcontainer 捐出，并改名為 RunC 項(xiàng)目，然后以 RunC 為依據(jù)，大家共同制定一套容器和鏡像的標(biāo)準(zhǔn)和規(guī)范，這就是 OCI( Open Container Initiative )。OCI 的提出目的是將在將容器運(yùn)行時(shí)和鏡像的實(shí)現(xiàn)從 Docker 項(xiàng)目中完全剝離出來，為其他廠商不依賴于 Docker 項(xiàng)目構(gòu)建各自的平臺(tái)提供可能。

OCI對(duì)Docker的影響其實(shí)不大，特別是相比于同年成立的CNCF(Cloud Native Computing Foundation)，這個(gè)由Google、RedHat 等開源基礎(chǔ)設(shè)施領(lǐng)域玩家們牽頭發(fā)起的基金會(huì)，準(zhǔn)備以 Kubernetes 項(xiàng)目為基礎(chǔ)，建立一個(gè)由開源基礎(chǔ)設(shè)施領(lǐng)域廠商主導(dǎo)的、按照獨(dú)立基金會(huì)方式運(yùn)營(yíng)的平臺(tái)級(jí)社區(qū)，來對(duì)抗以 Docker 公司為核心的容器商業(yè)生態(tài)。

與之間的較量不同，這次的較量已經(jīng)離開了Docker擅長(zhǎng)的開發(fā)領(lǐng)域，更多地在應(yīng)用的部署和運(yùn)營(yíng)，也就是PaaS層面展開，這些恰恰是紅帽、Google等所擅長(zhǎng)的。Kubernetes從最擅長(zhǎng)的容器編排入手，把Docker作為其中一個(gè)組件，可以說從一開始就站在戰(zhàn)略制高點(diǎn)。借助Google 在Borg上積累的先進(jìn)技術(shù)加上Red hat等在開源軟件方面運(yùn)營(yíng)的經(jīng)驗(yàn)，很快Kubernetes就在競(jìng)爭(zhēng)中開始領(lǐng)先。

當(dāng)然，剛開始時(shí)，這種競(jìng)爭(zhēng)是很溫和，2014年Kubernetes誕生時(shí)，它使用了Docker，因?yàn)镈ocker是當(dāng)時(shí)最流行的容器運(yùn)行時(shí)。當(dāng)時(shí)，除了Docker + Kubernetes，還可以選擇Docker+Mesos、Docker+Swarm。

應(yīng)該說，Kubernetes與Docker并不是直接的競(jìng)爭(zhēng)關(guān)系，直接競(jìng)爭(zhēng)的是Docker的Swarm。Swarm是一個(gè)集群和調(diào)度工具，作用類似于Kubernetes。不過，Swarm與Kubernetes這兩者的競(jìng)爭(zhēng)實(shí)質(zhì)是對(duì)容器話語權(quán)的競(jìng)爭(zhēng)，因此，本質(zhì)上也是Docker與CNCF之間的競(jìng)爭(zhēng)。

為了對(duì)抗Kubernetes，2016 年Docker 公司宣布放棄Swarm 項(xiàng)目，將容器編排和集群管理功能全部?jī)?nèi)置到 Docker 項(xiàng)目當(dāng)中。Docker 公司意識(shí)到了 Swarm 項(xiàng)目目前唯一的競(jìng)爭(zhēng)優(yōu)勢(shì)，就是跟 Docker 項(xiàng)目的無縫集成。不過，這一招看來不靈，Docker不久就在與CNCF的較量中敗下陣來，在2017年10月的DockerCon EU 大會(huì)上，Docker官方宣布支持Kubernetes，將在自己的主打產(chǎn)品 Docker 企業(yè)版中內(nèi)置 Kubernetes 項(xiàng)目，這也就是意味著，容器編排領(lǐng)域的爭(zhēng)奪已經(jīng)落幕，Kubernetes得到了認(rèn)可。

回頭看來，失利的Docker開始還能憑借強(qiáng)大的容器開發(fā)者生態(tài)發(fā)揮自己的影響力，這才有了kubelet做出的妥協(xié)，專門引入Dockershimi。然而，隨著時(shí)間的推移，Kubernetes社區(qū)的逐漸強(qiáng)大，Kubernetes的生態(tài)越來越完善，Docker的話語權(quán)逐漸減少，被邊緣化也在情理之中，Kubelet撤銷對(duì)Docker的特殊待遇是遲早要發(fā)生的。因此，未來的Docker更大可能是保持在開發(fā)領(lǐng)域發(fā)揮自己的獨(dú)特價(jià)值。

不過，無論如何，從Docker 2013年正式上市以來，以一己之力帶火了容器技術(shù)，給軟件行業(yè)帶來了顛覆性變革，推動(dòng)了軟件行業(yè)乃至整個(gè)IT行業(yè)的發(fā)展和創(chuàng)新，從這點(diǎn)而言Docker是當(dāng)之無愧的英雄，即使失敗也應(yīng)該贏得我們的尊重。