Docker容器化和Kubernetes容器編排，作爲微服務和雲原生的核心依賴，這幾年已是大紅大紫全民皆知。然而近日Kubernetes官方發佈公告，宣佈自 v1.20 起放棄對 Docker 的支持，驚呆了一衆開發者。在這背後，究竟是人性的扭曲，還是道德的淪喪，下面來爲大家一一分析解讀。
官方聲明地址：https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
Docker容器化
容器技術，打破了原來用虛擬機部署軟件對硬件環境和條件的限制，讓軟件的邏輯邊界獲得了更大程度的擴展。只要是一臺能夠安裝Linux的個人PC機、服務器、甚至是小巧玲瓏的樹莓派，都可以非常輕鬆的安裝容器，實現了硬件資源的最大化利用。這也讓微服務技術得以更好的落地，更加便捷、高效的實現企業生產效率的提升。
目前大型互聯網公司有騰訊、京東、美團、新浪、大衆點評等都在使用。比如說騰訊的蓋亞，基於docker部署管理，據說已經有萬臺規模，用於大數據處理。美團主要是用於持續集成，自動構建方面，另外新浪也做了實踐。容器化是一個大趨勢，以後這方面的公司會越來越多。
Kubernetes容器編排
就在Docker容器技術被炒得熱火朝天之時，大家發現，如果想要將Docker應用於具體的業務實現，在編排、管理和調度等各個方面，都不容易。於是，我們迫切需要一套管理系統，對 Docker 及容器進行更高級更靈活的管理，於是kubernetes應運而生。
Kubernetes 能在實體機或虛擬機集羣上調度和運行程序容器，避免人肉運維屏蔽底層細節，當下已經被譽爲“雲時代的操作系統”，核心地位可見一斑！
Docker+Kubernetes已然成爲微服務和雲計算的主流，然而突然爆出Kubernetes放棄對Docker的支持，屆時用戶將收到 Docker 棄用警告，並需要改用其他容器運行時。但 Docker 作爲容器鏡像構建工具的作用將不受影響，用其構建的容器鏡像將一如既往地在集羣中與所有容器運行時正常運轉。這又發生了什麼？
官方說明
官方解釋稱，Docker 作爲一個完整的容器技術堆棧，在其創建之初就不是爲了將其嵌入 Kubernetes 而設計的。除了其作爲容器運行時本身的作用以外，Docker 還包含了一系列方便用戶交互的 UX 更改，而這些額外的功能對於 Kubernetes 來說過於臃腫。
事實上，Docker 並不符合 Kubernetes 的容器運行時接口標準（CRI），官方必須要維護一個名爲 Dockershim 的中間件才能夠把 Docker 當作 Kubernetes 的容器運行時來使用。因此，官方建議用戶使用符合 CRI 的 containerd 或 CRI-O 作爲取代 Docker 的容器運行時，並表示最早將於 v1.23 版本把 Dockershim 從 Kubelet 中移除。
不過，Kubernetes 官方表示用戶今後依然可以使用 Docker 來構建容器鏡像，而 Docker 生成的鏡像實際上也是一個 OCI（Open Container Initiative）鏡像。無論使用什麼工具來構建鏡像，任何符合 OCI 標準的鏡像在 Kubernetes 看來都是一樣的。containerd 和 CRI-O 則可以提取這些鏡像並運行它們。
劃重點：Docker+Kubernetes這套東西開發者還是可以繼續玩的，沒問題。但將來會推薦別的容器技術來代替docker的。
畫外音：以前Kubernetes支持Docker是沒辦法，現在準備拋棄換新人了，官方如此多解釋無非欲蓋彌彰，Docker在容器編排工具競爭的失敗，註定了未來的命運。
例行分享
又到了資源分享時刻，這裏整理了50+頭部互聯網公司的架構師內部分享資料，關注容器、關注Kubernetes、關注雲原生的小夥伴兒，趕緊掃碼領取吧！本內容若有侵權可聯繫刪除。
掃碼領取即可領取
添加微信zhaoxiNet007也可