Kubernetes竟棄用Docker？
當Kubernetes與Docker一起使用時，Kubernetes已經被遺棄了Docker。有時，我們都必須相信什么都不會持續。即使是Kubernetes和Docker，那么最終與之使用在一起，最終與方式分開。那么為什么Docker需要Kubernetes？髕骨如何用于Kubernetes？為什么Kubernetes終于放棄了Docker？如果我們想使用與Docker的Kubernetes何時何地？讓我們一起看?介紹Docker需要Kubernetes之前，讓我們來看看為什么我們需要碼頭？在碼頭容器技術的出現之前，我們需要多種環境進行開發，測試和出版服務。開發環境用于開發人員編寫代碼，調試和自檢。測試環境用于測試儀的功能測試和性能測試，并使用生產環境用于釋放官方版以供用戶使用。在從開發啟動的過程中，我們正在處理環境。在安裝環境之前，必須首先申請資源，安裝操作系統，數據庫，應用程序和修改配置文件以鏈接。這個過程非常麻煩。每個修改都必須再次重新部署。如果你改變機器，我很抱歉，那么你必須做另一輪。碼頭的出現解放了這個過程。 Docker封裝了一組完整的環境，其中應用程序運行，包括操作系統，數據庫，消息隊列等。研發人員可以繼續封裝封裝圖像上的業務模塊，并將其提供測試和操作和維護人員。在測試和測試時，只關注業務就很好。不同環境造成的問題不再存在。和碼頭容器是孤立的過程。在充分利用服務器資源的同時，沒有人會影響任何人。這也是互聯網巨頭如Ali，Toutiao和Meituan的原因也是所有集裝箱的基礎設施。
在微服務架構的趨勢下，服務被分成了微服務模型。為了確保高可用性，以分布式方式部署核心微服務。對于淘寶系統，它包含數千個微服務，一個節點部署一個容器，然后根據分布式群集部署，整個淘寶系統估計有數萬個節點。在假期期間，節點的數量仍在增加，然后需要進行管理，否則如何保證節點之間的正常通信并快速解決問題？所以Kubernetes出生。它提供了應用程序級群集抽象，將每個MicroService摘要到服務中，運行為POD。 POD的底層是Docker，它提供外部能力。 Kubernetes，Masternode和Worknode有兩部分。 Masternode是控制節點，負責調度群集資源。用戶可以控制KubeControllermanager中的整個資源情況，例如執行資源創建和釋放; Apiserver類似于Kubernetes網關，它接受外部的客戶端調用，內部傳輸呼叫請求轉到相應的工作室。 Worknode實際上是工作，真正運行業務應用程序，通過Kubectl接受Apiserver命令，使用ContexErruntime下載圖像和運行容器。
出現問題。 Kubernetes本身并不提供容器運行時環境，但使用CRI（ContainErruntimeInterface Container Runtime接口）來創建和刪除工作者節點上的容器。由于Docker不符合Kubernetes Container運行時接口標準（CRI），因此必須維護一個名為Dockershim的中間件，以便能夠使用Docker作為Kubernetes Container運行時。此外，Kubernetes使用Docker容器中的CGROUP功能。不需要使用其他模塊，例如網絡和存儲卷，但它們在Kubernetes中運行以及Docker，這容易出現安全風險。總之，這就是為什么Kubernetes被遺棄的Docker。
作為Kubernetes和Docker容器的用戶，不需要恐慌，只需使用CRI運行時替代。 CRI有兩種實施方案，即ContainerD和CRI-O. Contantd是CNCF云本機計算基礎的開源項目。它可以直接下載并直接在github上使用（https://github.com/containerd/containerd/）。它是一個容器虛擬化技術，已從Docker剝離以形成一個開放的容器接口（OCI），集裝箱引擎可以使用它來管理整個容器生命周期（創建），拉/推容器圖像，存儲管理圖像，管理容器網絡接口和網絡。它出生于碼頭，可以做所有的運行時工作。使用它是一個不錯的選擇。
與集裝箱相比，CRI-O并不是如此友好。它是紅帽開發的純CRI運行時。它支持Redhatopenshit更好，不支持Docker。因此，從Docker遷移到CRI-O更麻煩。 Kubernetes正式表示，作為一個完整的集裝箱技術堆棧，Docker不是在創作開始時為Kubernetes設計的。 Kubernetes在V1.20之后，僅推薦使用Docker作為容器運行時。用戶仍可使用Docker將來構建容器圖像，并且Docker生成的圖像實際上是OCI（OpenContainer Initiative）圖像?？梢哉f，無論用什么工具來構建圖像，任何符合OCI標準的任何圖像都在Kubernetes中看起來也是如此。 ContainerD和CRI-O可以提取這些圖像并運行它們。技術升級通常是件好事，并且始終以更好的服務進行更改。無論是開發人員還是運營和維護人員，我們都需要接受改變。
