Kubernetes為什么要棄用docker？

作者：Draveness 2021-06-04 05:21:19

云計(jì)算 Kubernetes 是今天容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，而 Docker 從誕生之日到今天都在容器中扮演著舉足輕重的地位，也都是 Kubernetes 中的默認(rèn)容器引擎。

公司主營業(yè)務(wù)：網(wǎng)站建設(shè)、網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出吳堡免費(fèi)做網(wǎng)站回饋大家。

圖片來自 Pexels

然而在 2020 年 12 月，Kubernetes 社區(qū)決定著手移除倉庫中 Dockershim 相關(guān)代碼，這對于 Kubernetes 和 Docker 兩個社區(qū)來說都意義重大。

圖 1：Dockershim

相信大多數(shù)的開發(fā)者都聽說過 Kubernetes 和 Docker，也知道我們可以使用 Kubernetes 管理 Docker 容器，但是可能沒有聽說過 Dockershim，即 Docker 墊片。

如上圖所示，Kubernetes 中的節(jié)點(diǎn)代理 Kubelet 為了訪問 Docker 提供的服務(wù)需要先經(jīng)過社區(qū)維護(hù)的 Dockershim，Dockershim 會將請求轉(zhuǎn)發(fā)給管理容器的 Docker 服務(wù)。

其實(shí)從上面的架構(gòu)圖中，我們就能猜測出 Kubernetes 社區(qū)從代碼倉庫移除 Dockershim 的原因：

• Kubernetes 引入容器運(yùn)行時接口(Container Runtime Interface、CRI)隔離不同容器運(yùn)行時的實(shí)現(xiàn)機(jī)制，容器編排系統(tǒng)不應(yīng)該依賴于某個具體的運(yùn)行時實(shí)現(xiàn)。
• Docker 沒有支持也不打算支持 Kubernetes 的 CRI 接口，需要 Kubernetes 社區(qū)在倉庫中維護(hù) Dockershim。

可擴(kuò)展性

Kubernetes 通過引入新的容器運(yùn)行時接口將容器管理與具體的運(yùn)行時解耦，不再依賴于某個具體的運(yùn)行時實(shí)現(xiàn)。

很多開源項(xiàng)目在早期為了降低用戶的使用成本，都會提供開箱即用的體驗(yàn)，而隨著用戶群體的擴(kuò)大，為了滿足更多定制化的需求、提供更強(qiáng)的可擴(kuò)展性，會引入更多的接口。

Kubernetes 通過下面的一系列接口為不同模塊提供了擴(kuò)展性：

圖 2：Kubernetes 接口和可擴(kuò)展性

Kubernetes 在較早期的版本中就引入了 CRD、CNI、CRI 和 CSI 等接口，只有用于擴(kuò)展調(diào)度器的調(diào)度框架是 Kubernetes 中比較新的特性。

我們在這里就不展開分析其他的接口和擴(kuò)展了，簡單介紹一下容器運(yùn)行時接口。

Kubernetes 早在 1.3 就在代碼倉庫中同時支持了 rkt 和 Docker 兩種運(yùn)行時。

但是這些代碼為 Kubelet 組件的維護(hù)帶來了很大的困難，不僅需要維護(hù)不同的運(yùn)行時，接入新的運(yùn)行時也很困難。

容器運(yùn)行時接口(Container Runtime Interface、CRI)是 Kubernetes 在 1.5 中引入的新接口，Kubelet 可以通過這個新接口使用各種各樣的容器運(yùn)行時。

其實(shí) CRI 的發(fā)布就意味著 Kubernetes 一定會將 Dockershim 的代碼從倉庫中移除。

CRI 是一系列用于管理容器運(yùn)行時和鏡像的 gRPC 接口，我們能在它的定義中找到 RuntimeService 和 ImageService 兩個服務(wù)。

它們的名字很好地解釋了各自的作用：

  
 
 
 

   
  
  
  
service RuntimeService { 
   
  
  
  
    rpc Version(VersionRequest) returns (VersionResponse) {} 
   
  
  
  
 
   
  
  
  
    rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {} 
   
  
  
  
    rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {} 
   
  
  
  
    rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {} 
   
  
  
  
    rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {} 
   
  
  
  
    rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {} 
   
  
  
  
 
   
  
  
  
    rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {} 
   
  
  
  
    rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {} 
   
  
  
  
    rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {} 
   
  
  
  
    rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {} 
   
  
  
  
    rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {} 
   
  
  
  
    rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {} 
   
  
  
  
    rpc UpdateContainerResources(UpdateContainerResourcesRequest) returns (UpdateContainerResourcesResponse) {} 
   
  
  
  
    rpc ReopenContainerLog(ReopenContainerLogRequest) returns (ReopenContainerLogResponse) {} 
   
  
  
  
 
   
  
  
  
    ... 
   
  
  
  
} 
   
  
  
  
 
   
  
  
  
service ImageService { 
   
  
  
  
    rpc ListImages(ListImagesRequest) returns (ListImagesResponse) {} 
   
  
  
  
    rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResponse) {} 
   
  
  
  
    rpc PullImage(PullImageRequest) returns (PullImageResponse) {} 
   
  
  
  
    rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse) {} 
   
  
  
  
    rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResponse) {} 
   
  
  
  
} 
  
 
 
 

對 Kubernetes 稍有了解的人都能從上面的定義中找到一些熟悉的方法，它們都是容器運(yùn)行時需要暴露給 Kubelet 的接口。

Kubernetes 將 CRI 墊片實(shí)現(xiàn)成 gRPC 服務(wù)器與 Kubelet 中的客戶端通信，所有的請求都會被轉(zhuǎn)發(fā)給容器運(yùn)行時處理。

圖 3：Kubernetes 和 CRI

Kubernetes 中的聲明式接口非常常見，作為聲明式接口的擁躉，CRI 沒有使用聲明式的接口是一件聽起來『非常怪異』的事情。

不過 Kubernetes 社區(qū)考慮過讓容器運(yùn)行時重用 Pod 資源，這樣容器運(yùn)行時可以實(shí)現(xiàn)不同的控制邏輯來管理容器，能夠極大地簡化 Kubelet 和容器運(yùn)行時之間的接口。

但是社區(qū)出于以下兩點(diǎn)考慮，最終沒有選擇聲明式的接口：

• 所有的運(yùn)行時都需要重新實(shí)現(xiàn)相同的邏輯支持很多 Pod 級別的功能和機(jī)制。
• Pod 的定義在 CRI 設(shè)計(jì)時演進(jìn)地非?？欤跏蓟萜鞯裙δ芏夹枰\(yùn)行時的配合。

雖然社區(qū)最終為 CRI 選擇了命令式的接口，但是 Kubelet 仍然會保證 Pod 的狀態(tài)會不斷地向期望狀態(tài)遷移。

不兼容接口

與容器運(yùn)行時相比，Docker 更像是一個復(fù)雜的開發(fā)者工具，它提供了從構(gòu)建到運(yùn)行的全套功能。

開發(fā)者可以很快地上手 Docker 并在本地運(yùn)行并管理一些 Docker 容器，然而在集群中運(yùn)行的容器運(yùn)行時往往不需要這么復(fù)雜的功能，Kubernetes 需要的只是 CRI 中定義的那些接口。

圖 4：Docker & CRI

Docker 的官方文檔加起來可能有一本書的厚度，相信沒有任何開發(fā)者可以熟練運(yùn)用 Docker 提供的全部功能。

而作為開發(fā)者工具，雖然 Docker 中包含 CRI 需要的所有功能，但是都需要實(shí)現(xiàn)一層包裝以兼容 CRI。

除此之外，社區(qū)提出的很多新功能都沒有辦法在 Dockershim 中實(shí)現(xiàn)，例如 cgroups v2 以及用戶命名空間。

Kubernetes 作為比較松散的開源社區(qū)，每個成員尤其是各個 SIG 的成員都只會在開源社區(qū)上花費(fèi)有限的時間。

而維護(hù) Kubelet 的 sig-node 又尤其繁忙，很多新的功能都因?yàn)榫S護(hù)者沒有足夠的精力而被擱置。

所以既然 Docker 社區(qū)看起來沒有打算支持 Kubernetes 的 CRI 接口，維護(hù) Dockershim 又需要花費(fèi)很多精力，那么我們就能理解為什么 Kubernetes 會移除 Dockershim 了。

總結(jié)

今天的 Kubernetes 已經(jīng)是非常成熟的項(xiàng)目，它的關(guān)注點(diǎn)也逐漸從提供更完善的功能轉(zhuǎn)變到提供更好的擴(kuò)展性，這樣才能滿足不同場景和不同公司定制化的業(yè)務(wù)需求。

Kubernetes 在過去因?yàn)?Docker 的熱門而選擇 Docker，而在今天又因?yàn)楦甙旱木S護(hù)成本而放棄 Docker，我們能夠從這個過程中體會到容器領(lǐng)域的發(fā)展和進(jìn)步。

移除 Docker 的種子其實(shí)從 CRI 發(fā)布時就種下了，Dockershim 一直都是 Kubernetes 為了兼容 Docker 獲得市場采取的臨時決定。

對于今天已經(jīng)統(tǒng)治市場的 Kubernetes 來說，Docker 的支持顯得非常雞肋，移除代碼也就順理成章了。

我們在這里重新回顧一下 Kubernetes 在倉庫中移除 Docker 支持的兩個原因：

Kubernetes 在早期版本中引入 CRI 擺脫依賴某個具體的容器運(yùn)行時依賴，屏蔽底層的諸多實(shí)現(xiàn)細(xì)節(jié)，讓 Kubernetes 能夠更關(guān)注容器的編排。

Docker 本身不兼容 CRI 接口，而且官方并沒有實(shí)現(xiàn) CRI 的打算，同時也不支持容器的一些新需求，所以 Dockershim 的維護(hù)成為了社區(qū)的想要擺脫負(fù)擔(dān)。

到最后，我們還是來看一些比較開放的相關(guān)問題，有興趣的讀者可以仔細(xì)思考一下下面的問題：

Kubernetes 中還有哪些模塊提供良好的擴(kuò)展性?

除了文中提到的 CRI-O、Containerd，還有哪些支持 CRI 的容器運(yùn)行時?

作者：Draveness

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號真沒什么邏輯(ID：draveness)

當(dāng)前名稱：Kubernetes為什么要棄用Docker？
本文鏈接：http://m.5511xx.com/article/coioeph.html