Docker 大概沒想到，2020 年，它在技術圈內的兩次成為（輿論的）焦點，竟然都是因為資訊差（說是“標題黨”也不為過）。
概覽
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
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
並在同一個月的 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 捐給了 CNCF
2017 年，Docker 的網路元件 libnetwork 增加了 CNI 的支援；
同時通過使用 Docker 為 Docker Swarm 提供的 ipvs 相關的程式碼，也在 Kubernetes 中實現了基於 IPvs 的 service 負載均衡。不過在 v1.18 中開始移除了相關的依賴。
同年 11 月，Kubernetes 中新增了 containerd 的支援
2018 年
2018 年， Kubernetes 的 containerd 整合，正式 GA
之前版本的架構：
新的架構：
2019 年
2019 年，上文中提到的另一個容器執行時專案 rkt 被 CNCF 歸檔，終止使命了；
2019 年 Mirantis 收購 Docker 的企業服務。
2020 年
時間回到今年，Docker 主要被誤會的兩件事：
- Docker Inc. 修改 DockerHub 的定價和 TOS 。國內爭論較多的主要是關於合規性的問題（但是被標題黨帶歪了，免不了恐慌）；
- Kubernetes 宣佈開始進入廢棄 dockershim 支援的倒數計時，被人誤以為 Docker 不能再用了；
說明
關於 DockerHub 修改定價和 TOS 的事情，這裡就不再多說了，畢竟 DockerHub 目前大家仍然用的很歡樂，遠不像當初那些標題黨宣稱的那樣。
重點來說一下第二件事情吧。
Kubernetes 當初選擇 Docker 作為其容器執行時，本身就是因為當時它沒有其他的選擇，並且選擇 Docker 可為它帶來眾多的使用者。
所以，開始時，它便提供了內建的對 Docker 執行時的支援。
而 Docker 其實建立之初，並沒有考慮到“編排”的這個功能，當然也沒有考慮到 Kubernetes 的存在（因為當時還沒有）。
dockershim 一直都是 Kubernetes 社群為了能讓 Docker 成為其支援的容器執行時，所維護的一個相容程式。 本次所謂的廢棄，也僅僅是 Kubernetes 要放棄對現在 Kubernetes 程式碼倉庫中的 dockershim 的維護支援。 以便其可以像開始時計劃的那樣，僅負責維護其 CRI ，任何相容 CRI 的執行時，皆可作為 Kubernetes 的 runtime 。
在 Kubernetes 提出 CRI 時，有人建議在 Docker 中實現它。但是這種方式也會帶來一個問題，即使 Docker 實現了 CRI，但它仍然不是一個單純的容器執行時，它本身包含了大量的非 “純底層容器執行時” 所具備的功能。
所以後來 自 Docker 中分離出來的 containerd 專案，作為一個底層容器執行時出現了，它是 Kubernetes 容器執行時更好的選擇。
Docker 使用 containerd 作為其底層容器執行時以及眾多的雲廠商及公司在生產環境中使用 containerd 作為其 Kubernetes 的執行時，這也從側面驗證了 containerd 的穩定性。
現在 Kubernetes 和 Docker 社群都相信 containerd 已經足夠成熟可直接作為 Kubernetes 的執行時了，而無需再通過 dockershim 使用 Docker 作為 Kubernetes 的執行時了。這也標誌著 Docker 為 Kubernetes 提供一個現代化的容器執行時的承諾最終兌現了。
而本次事件中，重點的 dockershim 之後的方向如何呢？Kubernetes 程式碼倉庫中的 dockershim 將會在未來版本中移除，但是 Mirantis 公司已經和 Docker 達成合作，在未來會共同維護一份 dockershim 元件，以便支援 Docker 作為 Kubernetes 的容器執行時。
Otherwise, if you’re using the open source Docker Engine, the dockershim project will be available as an open source component, and you will be able to continue to use it with Kubernetes; it will just require a small configuration change, which we will document.
Q&A
Q：本次 Kubernetes 放棄對 dockershim 的維護，到底有什麼影響？
A：對於普通使用者而言，沒有任何影響；對於在 Kubernetes 之上進行開發的工程師，沒什麼太大影響；對於叢集管理員，需要考慮是否要在未來版本中，將容器執行時，升級為支援 CRI 的執行時，比如 containerd 。
當然，如果你並不想切換容器執行時，那也沒關係，Mirantis 公司未來會和 Docker 共同維護 dockershim , 並作為一個開源元件提供。
Q: Docker 不能用了嗎？
A：Docker 仍然是本地開發，或者單機部署最佳的容器工具，它提供了更為人性化的使用者體驗，並且也有豐富的特性。目前 Docker 已經和 AWS 達成合作，可直接通過 Docker CLI 與 AWS 整合。另外，Docker 也仍然可以作為 Kubernetes 的容器執行時，並沒有立即中止對其支援。
Q：聽說 Podman 可以藉機上位了？
A：想太多。Podman 也並不相容 CRI ，並且它也不具備作為 Kubernetes 容器執行時的條件。我個人也偶爾有在用 Podman， 並且我們在 KIND 專案中也提供了對 Podman 的支援， 但實話講，它也就是隻是一個 CLI 工具，某些情況下會有些作用，比如如果你的 Kubernetes 容器執行時使用 cri-o 的情況下，可以用來本地做下除錯。
總結
本文主要介紹了 Docker 和 Kubernetes 的發展歷程，也解釋了本次 Kubernetes 僅僅是放棄其對 dockershim 元件的支援。未來更推薦的 Kubernetes 執行時是 相容 CRI 的 containerd 之類的底層執行時。
Mirantis 公司將會和 Docker 共同維護 dockershim 並作為開源元件提供。
Docker 仍然是一款最佳的本地開發測試和部署的工具。
歡迎訂閱我的文章公眾號【MoeLove】
