由于Kubernetes已成為當前云原生基礎設施的事實標準，Kubernetes在1.20版本后棄用Docker作為容器運行時引發了開發人員的關注，針對此事，網易數帆資深架構師、網易輕舟容器編排技術負責人王新勇給出了自己的見解，他認為，Kubernetes移除dockershim的代碼確實有其合理之處，同時此事對絕大多數開發者沒有多大的影響，

• 從Kubernetes運行時提供統一的介面抽象這個角度來說，移除dockershim的代碼確實有其合理之處，畢竟之前dockershim是由于歷史原因，屬于特例的，
• Kubernetes編排是事實標準，容器的鏡像格式遵守OCI，所有之前的交付的構件，無論容器運行時怎樣變化，都不會有影響，
• 容器平臺提供商需要做一些適配、整合、測驗等，需要提供kubernetes支持的容器運行時，也可以通過額外維護和引入一個新的不屬于kubernetes專案的“dockershim”中間層來繼續支持docker作為運行時，不過無論怎么做，絕大部分開發人員都是感知不到的，

插播：12月16-17日，2020 Cloud Native Day，網易PingCAP阿里VMware大咖云集，詳見文末，歡迎報名

Kubernetes和Docker的關系

• Docker最初只是一個容器引擎，應該是很多人進入容器領域時最早接觸的東西，Docker為普及Linux的容器技術做出了很大的貢獻（雖然Linux容器上，LXC更早，而且早期版本的Docker就是基于LXC實作的，但是Docker的最大創新就是提出了鏡像的概念），

• 在2015年，我們探索容器技術做蜂巢產品的時候，那時候很多人的理解里面，容器基本就是Docker，Docker就是容器，直到現在應該好多開發者還是這個認知，

• Kubernetes是做容器編排的，本身跟最初Docker解決的問題領域是不沖突的，而且很多人都是從Docker入手才開始接觸Kubernetes的，不過后來Docker也想做容器編排的事情，推出了Docker Swarm，Docker Swarm跟Kubernetes就構成了競爭的關系了，Docker從此以后就不僅僅是運行時了，而是一整套容器技術堆疊了，現在Docker公司又推出了企業服務Mirantis Kubernetes Engine，同時支持了Kubernetes和Swarm兩種編排技術，

• 總結來看： 1. Docker作為一定意義上早期容器技術的代名詞，對于Linux容器，對于kubernetes的普及都起到了重要的作用，如果僅僅把docker當作一個容器運行時、鏡像構建管理、本地開發測驗容器工具套件的使用功能上來說（而且實際上，絕大部分開發者目前也就是這么干的），跟kubernetes做編排在功能上是相輔相成的，Docker負責制作相關的軟體構建并將其運行起來，Kubernetes用來控制如何運行這些容器， 2. 如果說有競爭關系，其實隨著Docker自己的編排引擎Swarm的影響力越來越弱，已經基本上喪失了競爭能力了，但是Docker公司推出的企業服務Mirantis Kubernetetes Engine確實是會跟Google的一些服務形成競爭關系，

Kubernetes和Docker的場景與用戶

• kubernetes是一個大而全的容器編排引擎，不僅僅是運行容器，還有存盤、網路，還提供了配置管理、服務發現等功能，而且還提供了非常靈活的擴展性，

• 而且現在基于Kubernetes，已經構成了一整套生態，各種基于Kubernetes的解決方案很多，像微服務、Operator化的中間件服務，service mesh，serverless等，這些技術的引入可以達到提高運維自動化能力，提升開發效率等，因此，如果業務規模足夠大，對于這些功能的需求比較迫切，是應該考慮使用Kubernetes的，例如網易數帆構建云OS支撐集團多元化業務，解決集群生命周期自動化管理、簡化運行時環境運維、提升資源利用率等問題，Kubernetes因其對云基礎設施抽象、融合及生態的優勢，成為我們的首選技術，

• 當然，強大的功能，靈活的可定制性自然而然就帶來了使用上的復雜性，概念很多，配置引數很多，運維復雜，因此使用kubernetes相比較來說比較重，一般DIY一個kubernetes集群會比較復雜，所以大家實際在使用Kubernetes的時候，一般不會自己去DIY Kubernetes，公有云上一般都是會去買托管的K8S服務，像GKE，EKS這種，對于on-premise情況下，在自己的IDC中，一般都會去購買像輕舟容器云這樣的成熟的容器服務，這類服務提供了比較友好的使用方式，而且又將運維部署的復雜性對客戶進行了屏蔽，可以讓客戶更好的使用Kubernetes，

• 如果用戶的業務部署比較簡單，規模也較小，僅僅是為了使用容器做應用交付的便利，也沒有其他的功能需求的話，僅僅通過docker run/docker-compose這種方式也能管得好的話，實際上是沒必要非得引入Kubernetes這樣非常重的編排組件的，反而直接僅僅使用docker會更輕量，也更好運維，比如toB的軟體交付的情況，如果要部署的軟體的部署架構比較簡單的話，僅僅涉及少量幾臺機器，服務行程也不多的情況下，也有不少是直接使用docker，而不引入Kubernetes的，比較輕量、簡單，（當然我這里沒有專門提Docker Swarm，因為實際上我們使用Docker Swarm幾乎沒有，也不太有啥場景非Docker Swarm不可的，除非是早期遺留）

• 還有一個就是，使用kubernetes做編排引擎的情況下，實際開發者在日常的開發中，也會比較多地使用Docker，

影響到哪些開發者和企業

• 對于一般的應用開發者來說，他們一般不會直接去面對Kubernetes的，因此，對于他們來說，可能壓根就是無感知的 ，應用開發者甚至都不用知道他們的業務是用容器運行的，以輕舟容器云產品為例，我們提供了自動從代碼編譯構建，到運行上線的一條龍服務，應用開發者可以完全不知道容器，僅僅寫好代碼、提交代碼，剩下的作業就交給輕舟容器云平臺來進行了，容器云平臺會按照預先定義的動作模板，完成接下來的所有作業，

• 對于整個基于Kubernetes生態的各個解決方案提供商來說，由于當前基于Kubernetes的編排是事實標準，容器的鏡像格式又是都遵守OCI的，因此可以說所有的之前的交付的構件，無論容器運行時怎樣變化，實際上都不會有啥影響，

• 對于容器平臺提供商來說，可能需要一些適配和準備動作，就拿輕舟容器平臺來說，我們是有比較好的準備的，實際上Kubernetes棄用docker從很早就開始討論了，我們也一直有關注相關的資訊，很早我們就開始關注和使用Containerd作為我們的容器運行時的一個選項了，目前也在網易內部的部分服務中進行了比較長時間的運行，后續也會在輕舟容器云平臺中，提供相關的運行時多個選項 ，并逐步過渡到使用containerd作為運行時，

• 當然，即使按照當前的計劃，到kubernetes v1.22版本，從kubernetes中洗掉了dockershim的支持，我們還可以通過將dockershim從kubernetes中摳出來，獨立運行，作為kubernetes的cri到docker api的配接器，實作kubernetes繼續支持docker，從而保持之前的使用習慣，

遷移到containerd、CRI-O復雜度如何

參見上個問題，不同的開發人員感知上可能是不一樣的，

對于一般應用開發，可能自己從來都不會去寫一個Dockerfile，那么對于他們來說是沒有復雜度的，

對于之前可能需要跟Docker打交道的，往往也就是在開發除錯階段打交道，主要就是制作容器鏡像和本地除錯的，這種情況也是不需要進行遷移的，因為使用Docker制作的鏡像，在其他運行時下同樣能夠正常跑，所有的作業流程都可以保持不變，沒有遷移復雜度，

對于容器平臺提供商來說，需要做的動作會大一點，需要做一些適配、整合、測驗等，需要提供kubernetes支持的容器運行時，當然也可以通過額外維護和引入一個新的不屬于kubernetes專案的“dockershim”中間層來繼續支持docker作為運行時，不過無論怎么做，這個也是絕大部分開發人員都感知不到的，

當然，如果開發人員有興趣的話，去學習一下crictl的操作也是可以的，有了使用docker的基礎，上手還是很快的，

主要目的分析

docker的API比較早，跟CRI不兼容，因此kubernetes中實作了docker到CRI的適配層dockershim，根據KEP，CRI已經是容器運行時標準介面了，而docker作為容器運行時也不應該享受特權，同時去除掉dockershim支持，還能實作kubernetes與docker的解耦，減少kubernetes社區的負擔，也能夠使得kubernetes的運行時支持上可以有更好的演進和發展，

其實類似的事情，之前在kubernetes中已經發生過，那就是把很多廠商的in-tree的Volume相關的代碼移除，而改為統一的基于CSI的實作，而kubernetes就專注于CSI就行了，不用再跟很多廠商的代碼耦合了，

從kubernetes運行時提供統一的介面抽象這個角度來說，移除dockershim的代碼確實有其合理之處，畢竟之前dockershim是由于歷史原因，屬于特例的，但是畢竟Docker是容器技術的“前輩”，昨天還是“小甜甜”，今天就成“牛夫人”了，還是有點唏噓的，

Docker會逐漸消亡嗎

還是將docker專案和docker公司分開來看吧，

docker專案的未來，我認為不會消亡，會使用docker命令可能會成為一個開發人員的必備技能，畢竟技術的慣性是很強大的，太多的開發人員直到現在可能還是認為容器就是docker，docker就是容器，日常開發程序中，docker命令有比較好用，用得又比較熟，沒有必要換，

docker公司的處境和未來，我自己不懂公司經營，沒法給出分析，不過就算docker公司處境不樂觀，還是有強大的開源社區的，應該是不影響 docker專案的，

對云原生技術的影響

可能只是一個小插曲，

云原生技術分享預告

2020年12月16-17日，來自CNCF、VMware、PingCAP、網易數帆、阿里云等17位重磅演講嘉賓，帶來2天主題分享，立體化決議云原生前沿技術與實踐，活動詳情如圖，名額有限，歡迎點擊這里，或識別下圖二維碼報名，