與Kubernetes漸行漸遠，Docker未來在哪里？
這幾天一則Kubernetes將放棄Docker的消息引起業內廣泛關注。根據Kubernetes社區給出的說明，在1.20版本之后，Kubernetes將不再支持把Docker作為容器運行時使用，據此不少人開始擔心Docker未來不能用了。實際上，這并不是說Kubernetes要完全拋棄Docker，CNCF也提醒說不要驚慌，Docker 生成的鏡像將繼續在用戶的集群中與所有運行時一起工作。但這件事還是讓人不免產生聯想，Docker還有一個怎樣的未來？很長時間以來，談到容器，Kubernetes + Docker好像是標配，現在看來并不一定。
Kubelet不再支持Docker運行時
人們對Docker未來的擔心源于Kubernetes 在1.20版本中 的 ChangeLog 提到，kubelet 中的 Docker 支持功能現已棄用，并將在之后的版本中被刪除。社區解釋說，這么做的原因是，Kubelet 之前使用的是一個名為 dockershim 的模塊，用以實現對 Docker 的 CRI 支持，但 Kubernetes 社區發現其維護存在問題，因此建議大家考慮使用包含 CRI 完整實現的可用容器運行時。
首先要說明的是，這里提到的Docker運行時并不等同于我們經常說的Docker，這可能是讓人們以為Docker被Kubernetes拋棄的一個原因。運行時（Runtime）為應用程序運行時提供保障的一個環境，通常是一些可以重用的程序/庫或者實例，這些實例可以在它們運行的時候被連接或者被任何程序調用。在Kubernetes集群內部也有一種稱為容器運行時的組件，負責提取并運行容器鏡像。Docker就是目前最流行的容器運行時，除此之外容器運行時還有Containerd與CRI-O。
與Containerd與CRI-O的定位就是一個運行時不同，Docker集成了太多功能，而很多功能作為一個運行時并非必須，比如容器創建，而且Docker最初在設計上也并未考慮到被嵌入到Kubernetes這種用法。
應該說，當初為了支持使用Docker的這個運行時，kubelet做出了妥協。如果采用Containerd與CRI-O運行時，其調用流程是：kubelet向CRI-Container插件發出調用請求，由CRI-Container再和容器運行時通信，完成請求的各種操作，但采用Docker運行時，這個流程就需要做出改變。由于Docker運行時并不兼容CRI，不得不引入一個新的插件Dockershimi作為緩沖。此時流程變成：kubelet先向Dockershimi發出請求，由Dockershimi調用Docker運行時，Docker運行時再調用其中的Containerd，由Containerd來負責完成請求的各種操作。可以看出，這個過程中Docker運行時有點尬尷，它的加入不僅在流程上多了一個環節，引入了Dockershimi，而Dockershimi的介入又引發了新的問題，必須額外加以維護，否則就可能引發安全問題。
如今，隨著Kubernetes社區的逐漸強大，當初Kubernetes向Docker做出的妥協現在不打算繼續了，這才有了kubelet不再支持Docker運行時的舉措。目前來看這件事的影響不大，正如CNCF所言，Docker不會就此消亡，Docker會繼續構建起不計其數的容器，開發人員仍然可以繼續采用Docker，繼續將Docker作為開發工具，Docker所生成的鏡像仍可在Kubernetes集群內正常運行。
如果使用的是云上的容器服務，比如GKE或者EKS等托管Kubernetes服務，則需要確保在未來的Kubernetes版本徹底去除Docker支持之前，為工作節點引入受支持的容器運行時。如果是自己負責管理的集群，則要注意更新和調整運行時以避免服務中斷。在1.20版本中，將收到Docker棄用警告。而在未來的Kubernets版本（計劃在2021年下半年發布的1.23版本）中，Docker運行時將被徹底移除、不再受到支持。
然而，長期來看呢？
Docker的未來在哪里？
毋庸置疑，容器的流行Docker功不可沒。在Docker出來之前，容器已經存在多年，但并不普及，直到Docker的出現。2013年，Docker的出現第一次把運行容器變得這么簡單，使用Docker開發人員可以輕松啟動、停止和撤銷容器，而且其低學習曲線和易用性使其成為軟件開發過程中的主流。
可以說，Docker以一己之力將容器這種相對邊緣的技術硬生生地變成了網紅。Docker的走紅帶動了Docker生態，大量圍繞著 Docker 項目的網絡、存儲、監控、CI/CD、甚至 UI 項目紛紛出臺，也涌現出了Rancher等一批在開源創業公司。與此同時，競爭的種子也就此埋下。
Docker最初從開發端發力，一家獨大，但是要Docker希望繼續做大，特別是獲取商業價值，就需要向應用部署和運營方向發力，提供部署、監控和管理等放方方面面的工具，Swarm就是其中之一。而對CoreOS、Red Hat、谷歌和微軟等這些應用程序運行平臺提供方而言，支持容器是剛需，但它們希望通過容器運行時的標準化，來盡可能降低Docker的影響。顯然，Docker并不愿意，特別是當時Docker如此火爆的背景之下。這就是雙方爭奪的焦點。
OCI規范的推出就是雙方競爭達成妥協的結果。2015 年 Docker 公司牽頭，聯合CoreOS、Google、RedHat 等公司共同宣布，Docker 將自己的容器運行時庫 Libcontainer 捐出，并改名為 RunC 項目，然后以 RunC 為依據，大家共同制定一套容器和鏡像的標準和規范，這就是 OCI（ Open Container Initiative ）。OCI 的提出目的是將在將容器運行時和鏡像的實現從 Docker 項目中完全剝離出來，為其他廠商不依賴于 Docker 項目構建各自的平臺提供可能。
OCI對Docker的影響其實不大，特別是相比于同年成立的CNCF（Cloud Native Computing Foundation），這個由Google、RedHat 等開源基礎設施領域玩家們牽頭發起的基金會，準備以 Kubernetes 項目為基礎，建立一個由開源基礎設施領域廠商主導的、按照獨立基金會方式運營的平臺級社區，來對抗以 Docker 公司為核心的容器商業生態。
與之間的較量不同，這次的較量已經離開了Docker擅長的開發領域，更多地在應用的部署和運營，也就是PaaS層面展開，這些恰恰是紅帽、Google等所擅長的。Kubernetes從最擅長的容器編排入手，把Docker作為其中一個組件，可以說從一開始就站在戰略制高點。借助Google 在Borg上積累的先進技術加上Red hat等在開源軟件方面運營的經驗，很快Kubernetes就在競爭中開始領先。
當然，剛開始時，這種競爭是很溫和，2014年Kubernetes誕生時，它使用了Docker，因為Docker是當時最流行的容器運行時。當時，除了Docker + Kubernetes，還可以選擇Docker+Mesos、Docker+Swarm。
應該說，Kubernetes與Docker并不是直接的競爭關系，直接競爭的是Docker的Swarm。Swarm是一個集群和調度工具，作用類似于Kubernetes。不過，Swarm與Kubernetes這兩者的競爭實質是對容器話語權的競爭，因此，本質上也是Docker與CNCF之間的競爭。
為了對抗Kubernetes，2016 年Docker 公司宣布放棄Swarm 項目，將容器編排和集群管理功能全部內置到 Docker 項目當中。Docker 公司意識到了 Swarm 項目目前唯一的競爭優勢，就是跟 Docker 項目的無縫集成。不過，這一招看來不靈，Docker不久就在與CNCF的較量中敗下陣來，在2017年10月的DockerCon EU 大會上，Docker官方宣布支持Kubernetes，將在自己的主打產品 Docker 企業版中內置 Kubernetes 項目，這也就是意味著，容器編排領域的爭奪已經落幕，Kubernetes得到了認可。
回頭看來，失利的Docker開始還能憑借強大的容器開發者生態發揮自己的影響力，這才有了kubelet做出的妥協，專門引入Dockershimi。然而，隨著時間的推移，Kubernetes社區的逐漸強大，Kubernetes的生態越來越完善，Docker的話語權逐漸減少，被邊緣化也在情理之中，Kubelet撤銷對Docker的特殊待遇是遲早要發生的。因此，未來的Docker更大可能是保持在開發領域發揮自己的獨特價值。
不過，無論如何，從Docker 2013年正式上市以來，以一己之力帶火了容器技術，給軟件行業帶來了顛覆性變革，推動了軟件行業乃至整個IT行業的發展和創新，從這點而言Docker是當之無愧的英雄，即使失敗也應該贏得我們的尊重。
