Kubernetes竟棄用Docker？

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

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

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

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

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

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

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

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

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