Docker 大概沒想到，2020 年，它在技術圈內的兩次成為（輿論的）焦點，竟然都是因為信息差（說是「標題黨」也不為過）。
近幾年，Kubernetes 已經成為自有機房、雲上廣泛使用的容器編排方案，最廣泛的使用方式是 Kubernetes+Docker。從 DevOps 人員的角度，一面用 kubctl 命令、k8s API 來操作集群，一面在單機用 Docker 命令來管理鏡像、運行鏡像。
單獨用 Docker 的情況，在一些公司的場景裡面也是有的。一種場景是「只分不合」，把一臺機器用 Docker 做資源隔離，但是不需要將多容器「編排」。單獨用 Kubernetes，下層不是 Docker 的情況，並不算很多。
Kubernetes 和 Docker 的關係，簡單來說，有互補，也有競爭。在一般的認知中，Kubernetes 和 Docker 是互補關係：
Dockers屬於下層——容器引擎；
Kubernetes屬於上層——編排調度層。
Docker 源於 Linux Container，可以將一臺機器的資源分成 N 份容器，做到資源的隔離，並將可運行的程序定義為標準的 docker image；Kubernetes 則可以把不同機器的每份容器進行編排、調度，組成分布式系統。
2013 年
Docker 是在 2013 年的 PyCon 上首次正式對外公布的。它帶來了一種先進的軟體交付方式，即，通過容器鏡像進行軟體的交付。工程師們只需要簡單的 docker build 命令即可製作出自己的鏡像，並通過 docker push 將其發布至 DockerHub 上。通過簡單的 docker run命令即可快速的使用指定鏡像啟動自己的服務。
通過這種辦法，可以有效的解決軟體運行時環境差異帶來的問題，達到其 Build once, Run anywhere 的目標。
從此 Docker 也基本成為了容器的代名詞，並成為容器時代的引領者。
2014 年
2014 年 Google 推出 Kubernetes 用於解決大規模場景下 Docker 容器編排的問題。
這是一個邏輯選擇，在當時 Docker 是最流行也是唯一的運行時。Kubernetes 通過對 Docker 容器運行時的支持，迎來了大量的用戶。
同時，Google 及 Kubernetes 社區與 Docker 也在進行著密切的合作，在其官方博客上有如下內容：
We』ll continue to build out the feature set, while collaborating with the Docker community to incorporate the best ideas from Kubernetes into Docker.
An update on container support on Google Cloud Platform[1]
Kubernetes is an open source manager for Docker containers, based on Google’s years of experience using containers at Internet scale. Docker is delivering the full container stack that Kubernetes schedules into, and is looking to move critical capabilities upstream and align the Kubernetes framework with Libswarm.
Welcome Microsoft, RedHat, IBM, Docker and more to the Kubernetes community[2]
並在同一個月的 DockerCon 上發布演講，介紹了 Kubernetes 並受到了廣泛的關注。
此時 Docker Inc. 也發布了其容器編排工具， libswarm （也就是後來的 swarmkit） 。
2015 年
2015 年 OCI （Open Container Initiative）由 Docker 和其他容器行業領導者共同成立（它也是 Linux 基金會旗下項目）
OCI 主要包含兩個規範：
運行時規範（runtime-spec）：容器運行時，如何運行指定的 文件系統上的包
容器鏡像規範（image-spec）：如何創建一個 OCI 運行時可運行的文件系統上的包
Docker 把它自己的容器鏡像格式和 runtime ( 現在的 runc ) 都捐給了 OCI 作為初始工作。
2016 年
2016 年 6 月，Docker v1.12 發布，帶來了 Docker 在多主機多容器的編排解決方案，Docker Swarm 。 這裡也需要注意的是，Docker v1.12 的設計原則：
Simple Yet Powerful （簡單而強大）
Resilient（彈性）
Secure（安全）
Optional Features and Backward Compatibility（可選功能及向後兼容）
所以你可以通過配置自行選擇是否需要使用 Docker Swarm ，而無需擔心有什麼副作用。
2016 年 12 月， Kubernetes 發布 CRI （Container Runtime Interface） ，這當中一部分原因是由於 Kubernetes 嘗試支持另一個由 CoreOS 領導的容器運行時項目 rkt ，但是需要寫很多兼容的代碼之類的，為了避免後續兼容其他運行時帶來的維護工作，所以發布了統一的 CRI 接口，凡是支持 CRI 的運行時，皆可直接作為 Kubernetes 的底層運行時；
當然， Kubernetes 也是在 2016 年逐步取得那場容器編排戰爭的勝利的。
2017 年
2017 年， Docker 將自身從 v1.11 起開始引入的容器運行時 containerd[3] 捐給了 CNCF[4]
2017 年，Docker 的網絡組件 libnetwork 增加了 CNI 的支持；同時通過使用 Docker 為 Docker Swarm 提供的 ipvs 相關的代碼[5]，也在 Kubernetes 中實現了基於 IPvs 的 service 負載均衡。不過在 v1.18 中開始移除了相關的依賴。
同年 11 月，Kubernetes 中新增了 containerd 的支持[6]
cri-containerd
2018 年
2018 年， Kubernetes 的 containerd 集成，正式 GA[7]
containerd 1.0 cri-containerd
containerd 1.1 cri-containerd
2019 年
2019 年，上文中提到的另一個容器運行時項目 rkt 被 CNCF 歸檔，終止使命了；2019 年 Mirantis 收購 Docker 的企業服務。
2020 年
時間回到今年，Docker 主要被誤會的兩件事：
Docker Inc. 修改 DockerHub 的定價和 TOS 。國內爭論較多的主要是關於合規性的問題（但是被標題黨帶歪了，免不了恐慌）；
Kubernetes 宣布開始進入廢棄 dockershim 支持的倒計時，被人誤以為 Docker 不能再用了；
一切都如此悄悄地開始。作為廣受歡迎的容器集群管理工具，在即將發行的Kubernetes 1.20版本說明文件中，Kubernetes（k8s）宣布："kubelet放棄對Docker的支持，並會在將來的版本中移除。"
是的，實現了對Docker兼容支持其kubelet容器運行時Container Runtime Interface（CRI）標準的dockershim中間件將很快成為歷史。所以呢？這沒什麼大不了的。
谷歌雲開發人員助理及著名的Kubernetes導師凱爾西·海託華（Kelsey Hightower）在推特上說："Docker不等於容器。Docker可以構建容器映像，Docker可以從容器倉庫中push和pull，Docker是容器運行時其中一員，Docker可以創建容器進程，但Linux仍然是老大。"
正如著名的"不必恐慌：Kubernetes和Docker"博客文章中所解釋的那樣，Kubernetes只是在v1.20版本後不推薦將Docker作為容器運行時使用。人們仍然可以使用Docker構建容器，繼續在倉庫中進行push和pull操作等。實際上是因為Docker並不符合Kubernetes的容器運行時接口標準(CRI)而不被推薦使用，Docker生成的鏡像依然可以一如既往地在集群中工作。
簡而言之，這就是我們想說的，這沒什麼大不了的，不必恐慌。
就像Dockershim Deprecation FAQ所說："在1.20中唯一改變的是，如果使用Docker作為容器運行時，則在kubelet啟動時會列印一條警告信息。"
Dockershim中間件會一直保留到2021年末，直到發布Kubernetes 1.23版本為止。Kubernetes團隊將與所有人緊密合作，直到所有人都準備好了相關變更，才會將dockershim放飛牧場。
總結
本文主要介紹了 Docker 和 Kubernetes 的發展歷程，也解釋了本次 Kubernetes 僅僅是放棄其對 dockershim 組件的支持。未來更推薦的 Kubernetes 運行時是 兼容 CRI 的 containerd 之類的底層運行時。
Mirantis 公司將會和 Docker 共同維護 dockershim 並作為開源組件提供。
Docker 仍然是一款最佳的本地開發測試和部署的工具。