在1.20版本之后，Kubernetes將不再支持把Docker作為容器運(yùn)行時(shí)使用。

不必驚慌，實(shí)際上沒多大影響。

[[355749]]

摘要：這里只是不建議將Docker作為底層運(yùn)行時(shí)，你仍然可以使用專為Kubernetes創(chuàng)建的容器運(yùn)行時(shí)接口(CRI)一如既往地在集群中運(yùn)行Docker鏡像。

對于Kubernetes最終用戶，此次調(diào)整同樣不會(huì)有太大影響。Docker不會(huì)就此消亡，你也仍然可以繼續(xù)將Docker作為開發(fā)工具使用。Docker會(huì)繼續(xù)構(gòu)建起不計(jì)其數(shù)的容器，而運(yùn)行docker build命令所生成的鏡像仍可在Kubernetes集群內(nèi)正常運(yùn)行。

如果你使用的是GKE或者EKS等托管Kubernetes服務(wù)，則需要確保在未來的Kubernetes版本徹底去除Docker支持之前，為你的工作節(jié)點(diǎn)引入受支持的容器運(yùn)行時(shí)。如果節(jié)點(diǎn)中包含自定義項(xiàng)，你可能需要根據(jù)當(dāng)前環(huán)境及運(yùn)行時(shí)要求做出更新。請與服務(wù)供應(yīng)商合作，確保正確完成升級測試及規(guī)劃。

如果你的集群一直在滾動(dòng)擴(kuò)展，則需要配合變量以避免服務(wù)中斷。在1.20版本中，你將收到Docker棄用警告。而在未來的Kubernets版本(計(jì)劃在2021年下半年發(fā)布的1.23版本)中，Docker運(yùn)行時(shí)將被徹底移除、不再受到支持，屆時(shí)您必須切換至其他兼容的容器運(yùn)行時(shí)，例如containerd或者CRI-O。只需要保證你所選定的運(yùn)行時(shí)，能夠支持當(dāng)前使用的Docker守護(hù)程序配置即可(例如日志記錄)。

既然問題不大，人們在慌什么?在怕什么?

這里我們需要探討兩種不同的環(huán)境，而這也是恐慌情緒的根源。首先，在Kubernetes集群內(nèi)部存在一種叫作容器運(yùn)行時(shí)的東西，負(fù)責(zé)提取并運(yùn)行容器鏡像。Docker是目前最流行的運(yùn)行時(shí)選項(xiàng)(其他常見選項(xiàng)還包括containerd與CRI-O)。但Docker在設(shè)計(jì)上并未考慮到被嵌入Kubernetes這種用法，所以可能引發(fā)問題。

很明顯，這里我們提到的“Docker”并不是同一種東西——它代表著一整套技術(shù)棧，而containerd高級容器運(yùn)行時(shí)則是Docker中的一部分。Docker很酷、實(shí)用性極強(qiáng)，提供多種用戶體驗(yàn)增強(qiáng)功能，讓我們能夠在開發(fā)過程中輕松完成協(xié)同交互。但是，用戶體驗(yàn)增強(qiáng)功能對Kubernetes來說并非必需，因?yàn)镵ubernetes并不是什么人類協(xié)作方。

結(jié)果就是，要想讓containerd這個(gè)人類友好型抽象層發(fā)揮作用，Kubernetes集群就必須引入另一款名為Dockershimi的工具。但這款工具的介入又引發(fā)了新的問題，因?yàn)槲覀儽仨氼~外加以維護(hù)，否則就可能引發(fā)安全問題。事實(shí)上，Dockershim早在Kubelet 1.23版本時(shí)就已經(jīng)被移除，或者說Kubelet很早就取消了將Docker作為容器運(yùn)行時(shí)的功能。這時(shí)候很多朋友可能要問，既然Docker棧中已經(jīng)包含containerd，Kubernetes為什么還要畫蛇添足地搞出個(gè)Dockershim?

這是因?yàn)镈ocker與CRI(即容器運(yùn)行時(shí)接口)并不相容。正是因?yàn)椴幌嗳荩晕覀儾判枰狣ockershim來緩沖一下。但這不是什么大問題，各位沒必要驚慌——這件事的本質(zhì)，就是把容器運(yùn)行時(shí)從Docker轉(zhuǎn)換為另一種受支持的選項(xiàng)。

這里需要注意的是：如果大家將底層Docker套接字(/var/run/docker.sock)設(shè)定為集群工作流中的一部分，那么轉(zhuǎn)換至其他運(yùn)行時(shí)會(huì)破壞掉當(dāng)前業(yè)務(wù)的正常運(yùn)行。這種模式在Docker中就被稱為Docker，好在我們可以使用多種選項(xiàng)解決這個(gè)特定用例，包括Kaniko、Img以及Buildah等等。

但這種變化對開發(fā)者意味著什么?我們還需要編寫Dockerfiles嗎?未來還應(yīng)不應(yīng)該繼續(xù)使用Docker?

請注意，本次變更所影響到的環(huán)境，其實(shí)跟大多數(shù)人用于進(jìn)行Docker交互的環(huán)境并不是一回事。你在開發(fā)中使用的Docker安裝，與Kubernetes集群中的Docker運(yùn)行時(shí)毫無關(guān)系。我知道，這事聽起來讓人有點(diǎn)犯迷糊。總之，對于開發(fā)人員，Docker在公布此次更改之前提供的所有方案都仍然適用。Docker生成的鏡像實(shí)際上并不特定于Docker，更準(zhǔn)確地說它應(yīng)該屬于OCI(開放容器倡議)鏡像。任何與OCI相兼容的鏡像，無論使用哪種工具構(gòu)建而成，對于Kubernetes來說都是一樣的。Containerd與CRI-O都能識別這些鏡像并正常運(yùn)行，這也是我們建立一套統(tǒng)一容器標(biāo)準(zhǔn)的意義所在。

因此，雖然變化即將到來，雖然會(huì)給部分用戶帶來麻煩，但影響并不算大。而且從長遠(yuǎn)角度看，這其實(shí)是件好事。總而言之，希望大家放下抵觸和恐慌情緒，坦然接受這個(gè)變化。