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

在介紹Docker為什麼需要Kubernetes之前，我們先來看看為什麼我們需要Docker？在Docker容器技術出現之前，我們開發、測試、釋出服務需要多個環境，開發環境用於開發人員寫程式碼、除錯、自測，測試環境用於測試人員進行功能測試、效能測試，生產環境用於釋出正式版本，給使用者使用。在我們從開發到上線的過程中，都在和環境打交道，在裝環境之前還得先申請資源，安裝作業系統、資料庫、應用程式，並修改配置檔案連結起來，這個過程是非常繁瑣的，每次修改內容都還得重新部署一次，如果換個機器，不好意思，那就還得再來一輪。

在微服務架構的趨勢下，服務拆分成了微服務模式，為了保障高可用，核心微服務按照分散式進行部署。以淘寶系統來說，包含上千個微服務，一個節點部署一個容器，再按照分散式叢集部署，整個淘寶系統估計得上萬個節點，逢年過節，節點數還在不斷的增加，那就需要管理了呀，不然怎麼保障節點之間的正常通訊，問題快速解決呢？於是Kubernetes產生了，它提供應用級的叢集抽象，把每個微服務抽象成service，以Pod執行，Pod底層是Docker，對外提供能力。

在Kubernetes中包含masternode和worknode兩部分。MasterNode為控制節點，負責對叢集資源進行排程，使用者在KubeControllerManager中可以管控整個資源情況，比如執行資源的建立與釋放；ApiServer類似Kubernetes的閘道器，對外接受客戶端的呼叫命令，對內把呼叫請求傳遞給到對應的WorkNode。WorkNode是真正幹活的，真正執行業務應用，透過kubectl接受ApiServer的命令，使用ContainerRuntime下載映象和執行容器。

問題出現了，Kubernetes本身是不提供容器執行環境的，而是使用CRI（ContainerRuntimeInterface容器執行介面）在工作節點建立和刪除容器,因為Docker不符合Kubernetes的容器執行時介面標準（CRI），所以官方必須要維護一個名為Dockershim的中介軟體才能夠把Docker當作Kubernetes的容器執行時來使用。此外Kubernetes使用的是Docker容器中的Cgroup能力，其它的模組如網路、儲存卷都不需要使用，然而它們卻隨Docker一起在Kubernetes中執行，這就容易產生安全隱患了。綜上所述，這就是為什麼Kubernetes要廢棄Docker了。

作為Kubernetes與Docker容器的使用者，不必要驚慌，使用CRI執行時替代方案即可。CRI的實現方案有兩種，分別是Containerd和CRI-O。Containerd是CNCF雲原生計算基金會開源專案，在GitHub（https://github.com/containerd/containerd/）可直接下載使用，它是容器虛擬化技術，從Docker中剝離出來，形成開放容器介面（OCI）的一部分，容器引擎使用它可以進行整個容器生命週期管理（建立）、拉取/推送容器映象、儲存管理映象、管理容器網路介面及網路。它生於Docker，可以完成所有的執行時工作，使用它是很好的選擇。

與Containerd相比，CRI-O就不那麼友好了，它是由紅帽開發的純CRI執行時，對於RedHatOpenshit支援的比較好，不支援Docker，因此從Docker遷移到CRI-O是比較麻煩的。

Kubernetes官方表示Docker作為一個完整的容器技術棧，在建立之初就不是為了Kubernetes而設計的。Kubernetes只是在v1.20版本後不推薦將Docker作為容器執行時使用，使用者今後依然可以使用Docker來構建容器映象，而Docker生成的映象實際上也是一個OCI（OpenContainer Initiative）映象。可以說無論使用什麼工具來構建映象，任何符合OCI標準的映象在Kubernetes看來都是一樣的。Containerd和CRI-O則可以提取這些映象並執行它們。技術的升級一般來說都是好事，它始終是為了更好的服務才做改動。無論是開發人員、運維人員，我們都需要擁抱變化