容器的崛起

對于K8s啟用docker，作為普通開發(fā)者的體感是，k8s不就是docker的集群操作嗎？k8s棄用docker就像魚反對水一樣不可思議，那么這兩個技術(shù)究竟是什么關(guān)系，Kubernetes 是如何一步步與 Docker 解耦的，請看下文。

模塊導(dǎo)學(xué)：從微服務(wù)到云原生

什么是不可變基礎(chǔ)設(shè)施

向應(yīng)用代碼隱藏分布式架構(gòu)復(fù)雜度、讓分布式架構(gòu)得以成為一種能夠普遍推廣的普適架構(gòu)風(fēng)格的必要前提。

云原生的定義

官方定義太抽象了，我就不復(fù)制粘貼了，我選擇從我們都比較熟悉的，至少是能看得見、摸得著的容器化技術(shù)開始講起。

虛擬化的目標(biāo)與類型

容器是云計(jì)算、微服務(wù)等諸多軟件業(yè)界核心技術(shù)的共同基石。容器的首要目標(biāo)是讓軟件分發(fā)部署的過程，從傳統(tǒng)的發(fā)布安裝包、靠人工部署，轉(zhuǎn)變?yōu)橹苯影l(fā)布已經(jīng)部署好的、包含整套運(yùn)行環(huán)境的虛擬化鏡像。

操作系統(tǒng)層虛擬化

操作系統(tǒng)層虛擬化也就是容器化，僅僅是虛擬化的一個子集，它只能提供操作系統(tǒng)內(nèi)核以上的部分 ABI 兼容性與完整的環(huán)境兼容性。

引言

作為整個模塊的開篇，我們這節(jié)課的學(xué)習(xí)目的是要明確軟件運(yùn)行的“兼容性”指的是什么，以及要能理解我們經(jīng)常能聽到的“虛擬化”概念指的是什么。只有理清了這些概念、統(tǒng)一了語境，在后續(xù)的課程學(xué)習(xí)中，我們關(guān)于容器、編排、云原生等的討論，才不會產(chǎn)生太多的歧義。

Docker與K8s的相愛相殺

接下來的兩節(jié)課，我會以容器化技術(shù)的發(fā)展為線索，帶你從隔離與封裝兩個角度，去學(xué)習(xí)和了解容器技術(shù)。

今天，我們就先來學(xué)習(xí)下 Linux 系統(tǒng)中隔離技術(shù)前提準(zhǔn)備，以此為下節(jié)課理解“以容器封裝應(yīng)用”的思想打好前置基礎(chǔ)。

封裝系統(tǒng)：LXC

當(dāng)文件系統(tǒng)、訪問、資源都可以被隔離后，容器就已經(jīng)具備它降生所需要的全部前置支撐條件了，并且 Linux 的開發(fā)者們也已經(jīng)明確地看到了這一點(diǎn)。

2008 年 Linux Kernel 2.6.24 內(nèi)核在剛剛開始提供 cgroups 的同一時間，就馬上發(fā)布了名為Linux 容器（LinuX Containers，LXC）的系統(tǒng)級虛擬化功能。

如此一來，LXC 就帶著令人矚目的光環(huán)登場，它的出現(xiàn)促使“容器”從一個陽春白雪的、只流傳于開發(fā)人員口中的技術(shù)詞匯，逐漸向整個軟件業(yè)的公共概念、共同語言發(fā)展，就如同今天的“服務(wù)器”“客戶端”和“互聯(lián)網(wǎng)”一樣。

LXC 眼中的容器的定義與 OpenVZ 和 Linux-VServer 并沒有什么差別，它們都是一種封裝系統(tǒng)的輕量級虛擬機(jī)，而 Docker 眼中的容器的定義則是一種封裝應(yīng)用的技術(shù)手段。這兩種封裝理念在技術(shù)層面并沒有什么本質(zhì)區(qū)別，但在應(yīng)用效果上差異可就相當(dāng)大了。

封裝應(yīng)用：Docker

在 2013 年宣布開源的 Docker，毫無疑問是容器發(fā)展歷史上里程碑式的發(fā)明，然而 Docker 的成功似乎沒有太多技術(shù)驅(qū)動的成分。至少對于開源早期的 Docker 而言，確實(shí)沒有什么能構(gòu)成壁壘的技術(shù)。

事實(shí)上，它的容器化能力直接來源于 LXC，它的鏡像分層組合的文件系統(tǒng)直接來源于AUFS，在 Docker 開源后不久，就有人僅用了一百多行的 Shell 腳本，便實(shí)現(xiàn)了 Docker 的核心功能（名為Bocker，提供了 docker bulid/pull/images/ps/run/exec/logs/commit/rm/rmi 等功能）。

為什么要用 Docker 而不是 LXC？（Why would I use Docker over plain LXC？）

• 跨機(jī)器的綠色部署
• 以應(yīng)用為中心的封裝
• 自動構(gòu)建：Docker 提供了開發(fā)人員從在容器中構(gòu)建產(chǎn)品的全部支持，開發(fā)人員無需關(guān)注目標(biāo)機(jī)器的具體配置，就可以使用任意的構(gòu)建工具鏈，在容器中自動構(gòu)建出最終產(chǎn)品。
• 多版本支持：Docker 支持像 Git 一樣管理容器的連續(xù)版本，進(jìn)行檢查版本間差異、提交或者回滾等操作。從歷史記錄中，你可以查看到該容器是如何一步一步構(gòu)建成的，并且只增量上傳或下載新版本中變更的部分。
• 組件重用：Docker 允許將任何現(xiàn)有容器作為基礎(chǔ)鏡像來使用，以此構(gòu)建出更加專業(yè)的鏡像。
• 共享：Docker 擁有公共的鏡像倉庫，成千上萬的 Docker 用戶在上面上傳了自己的鏡像，同時也使用他人上傳的鏡像。
• 工具生態(tài)：Docker 開放了一套可自動化和自行擴(kuò)展的接口，在此之上用戶可以實(shí)現(xiàn)很多工具來擴(kuò)展其功能，比如容器編排、管理界面、持續(xù)集成，等等。

其實(shí)，促使 Docker 一問世就驚艷世間的，并不是什么黑科技式的秘密武器，而是它符合歷史潮流的創(chuàng)意與設(shè)計(jì)理念，還有充分開放的生態(tài)運(yùn)營。由此可見，在正確的時候，正確的人手上有一個優(yōu)秀的點(diǎn)子，確實(shí)有機(jī)會引爆一個時代。

== 和chatgpt套殼一樣，巨大的需求，最低的門檻，資源豐富的公共倉庫 ==

2014 年，Docker 開源了自己用 Golang 開發(fā)的libcontainer，這是一個越過 LXC 直接操作 namespaces 和 cgroups 的核心模塊，有了 libcontainer 以后，Docker 就能直接與系統(tǒng)內(nèi)核打交道，不必依賴 LXC 來提供容器化隔離能力了。（runC的前身，后期會講到這個）（docker開始構(gòu)建自己的技術(shù)壁壘）

到了 2015 年，在 Docker 的主導(dǎo)和倡議下，多家公司聯(lián)合制定了“開放容器交互標(biāo)準(zhǔn)”（Open Container Initiative，OCI），這是一個關(guān)于容器格式和運(yùn)行時的規(guī)范文件，其中包含了運(yùn)行時標(biāo)準(zhǔn)（runtime-spec ）、容器鏡像標(biāo)準(zhǔn)（image-spec）和鏡像分發(fā)標(biāo)準(zhǔn)（distribution-spec，分發(fā)標(biāo)準(zhǔn)還未正式發(fā)布）。

• 運(yùn)行時標(biāo)準(zhǔn)定義了應(yīng)該如何運(yùn)行一個容器、如何管理容器的狀態(tài)和生命周期、如何使用操作系統(tǒng)的底層特性（namespaces、cgroup、pivot_root 等）；
• 容器鏡像標(biāo)準(zhǔn)規(guī)定了容器鏡像的格式、配置、元數(shù)據(jù)的格式，你可以理解為對鏡像的靜態(tài)描述；
• 鏡像分發(fā)標(biāo)準(zhǔn)則規(guī)定了鏡像推送和拉取的網(wǎng)絡(luò)交互過程。

由此，為了符合 OCI 標(biāo)準(zhǔn)，Docker 推動自身的架構(gòu)繼續(xù)向前演進(jìn)。

**首先，它是將 libcontainer 獨(dú)立出來，封裝重構(gòu)成runC 項(xiàng)目，并捐獻(xiàn)給了 Linux 基金會管理。**runC 是 OCI Runtime 的首個參考實(shí)現(xiàn)，它提出了“讓標(biāo)準(zhǔn)容器無所不在”（Make Standard Containers Available Everywhere）的口號。

而為了能夠兼容所有符合標(biāo)準(zhǔn)的 OCI Runtime 實(shí)現(xiàn)，Docker 進(jìn)一步重構(gòu)了 Docker Daemon 子系統(tǒng)，把其中與運(yùn)行時交互的部分抽象為了containerd 項(xiàng)目。

**這是一個負(fù)責(zé)管理容器執(zhí)行、分發(fā)、監(jiān)控、網(wǎng)絡(luò)、構(gòu)建、日志等功能的核心模塊，其內(nèi)部會為每個容器運(yùn)行時創(chuàng)建一個 containerd-shim 適配進(jìn)程，**默認(rèn)與 runC 搭配工作，但也可以切換到其他 OCI Runtime 實(shí)現(xiàn)上（然而實(shí)際并沒做到，最后 containerd 仍是緊密綁定于 runC）。

后來到了 2016 年，Docker 把 containerd 捐獻(xiàn)給了 CNCF 管理。

可以說，runC 與 containerd 兩個項(xiàng)目的捐贈托管，既帶有 Docker 對開源信念的追求，也帶有 Docker 在眾多云計(jì)算大廠夾擊下自救的無奈，這兩個項(xiàng)目也將會成為未來 Docker 消亡和存續(xù)的伏筆（到這節(jié)課的末尾你就能理解這句矛盾的話了）。

封裝集群：

Kubernetes如果說以 Docker 為代表的容器引擎，是把軟件的發(fā)布流程從分發(fā)二進(jìn)制安裝包，轉(zhuǎn)變?yōu)榱酥苯臃职l(fā)虛擬化后的整個運(yùn)行環(huán)境，讓應(yīng)用得以實(shí)現(xiàn)跨機(jī)器的綠色部署；那以 Kubernetes 為代表的容器編排框架，就是把大型軟件系統(tǒng)運(yùn)行所依賴的集群環(huán)境也進(jìn)行了虛擬化，讓集群得以實(shí)現(xiàn)跨數(shù)據(jù)中心的綠色部署，并能夠根據(jù)實(shí)際情況自動擴(kuò)縮。

盡管早在 2013 年，Pivotal（持有著 Spring Framework 和 Cloud Foundry 的公司）就提出了“云原生”的概念，但是要實(shí)現(xiàn)服務(wù)化、具備韌性（Resilience）、彈性（Elasticity）、可觀測性（Observability）的軟件系統(tǒng)依舊十分困難，在當(dāng)時基本只能依靠架構(gòu)師和程序員高超的個人能力，云計(jì)算本身還幫不上什么忙。

而在云的時代，不能充分利用云的強(qiáng)大能力，這讓云計(jì)算廠商無比遺憾，也無比焦慮。

所以可以說，直到 Kubernetes 橫空出世，大家才終于等到了破局的希望，認(rèn)準(zhǔn)了這就是云原生時代的操作系統(tǒng)，是讓復(fù)雜軟件在云計(jì)算下獲得韌性、彈性、可觀測性的最佳路徑，也是為廠商們推動云計(jì)算時代加速到來的關(guān)鍵引擎之一。

Docker 靠的是優(yōu)秀的理念，它是以一個“好點(diǎn)子”引爆了一個時代。我相信就算沒有 Docker，也會有 Cocker 或者 Eocker 的出現(xiàn)，但由成立僅三年的 DotCloud 公司（三年后又倒閉）做成了這樣的產(chǎn)品，確實(shí)有一定的偶然性。

而 Kubernetes 的成功，不僅有 Google 深厚的技術(shù)功底作支撐、有領(lǐng)先時代的設(shè)計(jì)理念，更加關(guān)鍵的是 Kubernetes 的出現(xiàn)，符合所有云計(jì)算大廠的切身利益，有著業(yè)界巨頭不遺余力地廣泛支持，所以它的成功便是一種必然。

Kubernetes 與 Docker 兩者的關(guān)系十分微妙，因此我們把握住兩者關(guān)系的變化過程，是理解 Kubernetes 架構(gòu)演變與 CRI、OCI 規(guī)范的良好線索。

Kubernetes 是如何一步步與 Docker 解耦的？

在一般使用者的體感中，k8s，就是作為管理和編排眾多docker容器的工具，后來聽說k8s要棄用docker，感覺就像魚反對水一樣不可思議，但是k8s隨著版本更迭慢慢解耦docker，可以看做是云原生發(fā)展的歷史，對理解現(xiàn)在k8s架構(gòu)有重大意義。于我而言，在這里多費(fèi)筆墨的原因是，這個過程和企業(yè)級架構(gòu)中用于替換或者升級某一個應(yīng)用或者組件也如出一轍，在替換過程中的抽象和重構(gòu)，亦是大型應(yīng)用的常態(tài)。

在 Kubernetes 開源的早期，它是完全依賴且綁定 Docker 的，并沒有過多地考慮日后有使用其他容器引擎的可能性。直到 Kubernetes 1.5 之前，Kubernetes 管理容器的方式都是通過內(nèi)部的 DockerManager，向 Docker Engine 以 HTTP 方式發(fā)送指令，通過 Docker 來操作鏡像的增刪改查的，如上圖最右邊線路的箭頭所示（圖中的 kubelet 是集群節(jié)點(diǎn)中的代理程序，負(fù)責(zé)與管理集群的 Master 通信，其他節(jié)點(diǎn)的含義在下面介紹時都會有解釋）。

現(xiàn)在，我們可以把這個階段的 Kubernetes 與容器引擎的調(diào)用關(guān)系捋直，并結(jié)合前面提到的 Docker 捐獻(xiàn) containerd 與 runC 后重構(gòu)的調(diào)用，一起來梳理下這個完整的調(diào)用鏈條：

• Kubernetes Master → kubelet → DockerManager → Docker Engine → containerd → runC

然后到了 2016 年，Kubernetes 1.5 版本開始引入“容器運(yùn)行時接口”（Container Runtime Interface，CRI），這是一個定義容器運(yùn)行時應(yīng)該如何接入到 kubelet 的規(guī)范標(biāo)準(zhǔn)，從此 Kubernetes 內(nèi)部的 DockerManager，就被更為通用的 KubeGenericRuntimeManager 所替代了（實(shí)際上在 1.6.6 之前都仍然可以看到 DockerManager），kubelet 與 KubeGenericRuntimeManager 之間通過 gRPC 協(xié)議通信。

不過，由于 CRI 是在 Docker 之后才發(fā)布的規(guī)范，Docker 是肯定不支持 CRI 的，所以 Kubernetes 又提供了 DockerShim 服務(wù)作為 Docker 與 CRI 的適配層，由它與 Docker Engine 以 HTTP 形式通信，從而實(shí)現(xiàn)了原來 DockerManager 的全部功能。

此時，Docker 對 Kubernetes 來說就只是一項(xiàng)默認(rèn)依賴，而非之前的不可或缺了，現(xiàn)在它們的調(diào)用鏈為：

• Kubernetes Master → kubelet → KubeGenericRuntimeManager → DockerShim → Docker Engine → containerd → runC

接著再到 2017 年，由 Google、RedHat、Intel、SUSE、IBM 聯(lián)合發(fā)起的CRI-O（Container Runtime Interface Orchestrator）項(xiàng)目發(fā)布了首個正式版本。

一方面，我們從名字上就可以看出來，它肯定是完全遵循 CRI 規(guī)范來實(shí)現(xiàn)的；另一方面，它可以支持所有符合 OCI 運(yùn)行時標(biāo)準(zhǔn)的容器引擎，默認(rèn)仍然是與 runC 搭配工作的，如果要換成Clear Containers、Kata Containers等其他 OCI 運(yùn)行時，也完全沒有問題。（前面提過的運(yùn)行時交互的部分抽象為了containerd 項(xiàng)目，負(fù)責(zé)管理容器執(zhí)行、分發(fā)、監(jiān)控、網(wǎng)絡(luò)、構(gòu)建、日志等功能的核心模塊，其內(nèi)部會為每個容器運(yùn)行時創(chuàng)建一個 containerd-shim 適配進(jìn)程）

不過到這里，開源版的 Kubernetes 雖然完全支持用戶去自由選擇（根據(jù)用戶宿主機(jī)的環(huán)境選擇）是使用 CRI-O、cri-containerd，還是 DockerShim 來作為 CRI 實(shí)現(xiàn)，但在 RedHat 自己擴(kuò)展定制的 Kubernetes 企業(yè)版，即OpenShift 4中，調(diào)用鏈已經(jīng)沒有了 Docker Engine 的身影：

• Kubernetes Master → kubelet → KubeGenericRuntimeManager → CRI-O→ runC

當(dāng)然，因?yàn)榇藭r Docker 在容器引擎中的市場份額仍然占有絕對優(yōu)勢，對于普通用戶來說，如果沒有明確的收益，也并沒有什么動力要把 Docker 換成別的引擎。所以 CRI-O 即使擺出了直接挖掉 Docker 根基的兇悍姿勢，實(shí)際上也并沒有給 Docker 帶來太多即時可見的影響。不過，我們能夠想像此時 Docker 心中肯定充斥了難以言喻的危機(jī)感。

時間繼續(xù)來到了 2018 年，由 Docker 捐獻(xiàn)給 CNCF 的 containerd，在 CNCF 的精心孵化下發(fā)布了 1.1 版，1.1 版與 1.0 版的最大區(qū)別是此時它已經(jīng)完美地支持了 CRI 標(biāo)準(zhǔn)，這意味著原本用作 CRI 適配器的 cri-containerd 從此不再被需要。

此時，我們再觀察 Kubernetes 到容器運(yùn)行時的調(diào)用鏈，就會發(fā)現(xiàn)調(diào)用步驟會比通過 DockerShim、Docker Engine 與 containerd 交互的步驟要減少兩步，這又意味著用戶只要愿意拋棄掉 Docker 情懷的話，在容器編排上就可以至少省略一次 HTTP 調(diào)用，獲得性能上的收益。而且根據(jù) Kubernetes 官方給出的測試數(shù)據(jù)，這些免費(fèi)的收益還相當(dāng)?shù)乜捎^。

如此，Kubernetes 從 1.10 版本宣布開始支持 containerd 1.1，在調(diào)用鏈中就已經(jīng)能夠完全抹去 Docker Engine 的存在了：

Kubernetes Master → kubelet → KubeGenericRuntimeManager → containerd → runC

而到了今天，要使用哪一種容器運(yùn)行時，就取決于你安裝 Kubernetes 時宿主機(jī)上的容器運(yùn)行時環(huán)境，但對于云計(jì)算廠商來說，比如國內(nèi)的阿里云 ACK、騰訊云 TKE等直接提供的 Kubernetes 容器環(huán)境，采用的容器運(yùn)行時普遍都已經(jīng)是 containerd 了，畢竟運(yùn)行性能對它們來說就是核心生產(chǎn)力和競爭力。

畫時間線圖描述，結(jié)合調(diào)用圖就清楚了。

小結(jié)

學(xué)完這節(jié)課，我們可以試著來做一個判斷：在未來，隨著 Kubernetes 的持續(xù)發(fā)展壯大，Docker Engine 經(jīng)歷從不可或缺、默認(rèn)依賴、可選擇、直到淘汰，會是大概率的事件。從表面上看，這件事情是 Google、RedHat 等云計(jì)算大廠聯(lián)手所為，可實(shí)際淘汰它的還是技術(shù)發(fā)展的潮流趨勢。這就如同 Docker 誕生時依賴 LXC，到最后用 libcontainer 取代掉 LXC 一樣。

同時，我們也該看到事情的另一面：現(xiàn)在連 LXC 都還沒有掛掉，反倒還發(fā)展出了更加專注于跟 OpenVZ 等系統(tǒng)級虛擬化競爭的LXD，就可以相信 Docker 本身也是很難徹底消亡的，已經(jīng)養(yǎng)成習(xí)慣的 CLI 界面，已經(jīng)形成成熟生態(tài)的鏡像倉庫等，都應(yīng)該會長期存在，只是在容器編排領(lǐng)域，未來的 Docker 很可能只會以 runC 和 containerd 的形式存續(xù)下去，畢竟它們最初都源于 Docker 的血脈。

一課一思

在 2021 年 1 月初，Kubernetes 宣布將會在 v1.23 版本中，把 Dockershim 從 Kubelet 中移除，那么你會如何看待容器化日后的發(fā)展呢？文章來源地址http://www.zghlxwxcb.cn/news/detail-400563.html

到了這里，關(guān)于容器的崛起——Docker與K8s的相愛相殺的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！