一文(wén)了解docker與k8s

其實 Docker 和 k8s 并非直接的競争對手兩者相互依存。 Docker 是一個容器化平台，而 k8s 是 Docker 等容器平台的協調器。

1、容器化時代

（1）虛拟化技(jì )術已經走過是三個時代，沒有容器化技(jì )術的研究就不會有Docker技(jì )術的誕生。

1）物(wù)理(lǐ)機時代： 多(duō)個應用(yòng)程序排在一台機器上。

2）虛拟機時代：一台物(wù)理(lǐ)機器安(ān)裝(zhuāng)多(duō)個虛拟機(VM),一個虛拟機跑多(duō)個程序。

3）容器化時代：一台物(wù)理(lǐ)機器安(ān)裝(zhuāng)多(duō)個容器實例(Container),一個容器跑多(duō)個程序。

（2）容器化解決了什麽問題？

用(yòng)一段話描述：

測試人員：你這個功能(néng)有問題。

開發人員：我本地是好的呀！

開發人員編寫代碼，在自己本地環境測試完成後，将代碼部署到測試或生産環境中經常會遇到各種各樣的問題。明明本地完美運行的代碼為(wèi)什麽部署後出現很(hěn)多(duō) bug，原因有很(hěn)多(duō)：不同的操作(zuò)系統、不同的依賴庫等。總結一句話：因為(wèi)本地環境和遠(yuǎn)程環境不一緻。

容器化技(jì )術正好解決了這一關鍵問題，它将軟件程序和運行的基礎環境分(fēn)開。開發人員編碼完成後将程序打包到一個容器鏡像中，鏡像中詳細列出了所依賴的環境，在不同的容器中運行标準化的鏡像，從根本上解決了環境不一緻的問題。

注：容器的概念已經出現不短的時間。但直到 2013 年開源項目 Docker 的出現才極大推廣了容器這項技(jì )術，并推動了軟件開發中容器化和微服務(wù)的趨勢，這種趨勢後來被稱為(wèi)雲原生開發。

2、容器化技(jì )術解決的核心問題

可(kě)移植性：不依賴具體(tǐ)的操作(zuò)系統或雲平台，比如在阿裏雲或騰訊雲直接随意遷移。

占地小(xiǎo)：容器隻需要其應用(yòng)程序以及它需要運行的所有容器和庫的依賴清單，不需要将所有的依賴庫都打包在一起。

共享 bin 和 lib：不同的容器可(kě)以共享 bin 和 lib，進一步節省了空間。

3、docker的出現

2010 年一位年輕小(xiǎo)夥子在美國(guó)舊金山成立了一家名叫【dotCloud】的公司， 開發了 Docker 的核心技(jì )術，從此開啓了容器技(jì )術的時代。後面 dotCloud 公司将自己的容器技(jì )術進行了簡化和标準化，取名為(wèi) Docker，就是大家熟悉的鲸魚 logo。

2013 年 dotCloud 公司宣布将 Docker 開源，随着越來越多(duō)的工程師發現了它的優點， Docker 的人氣迅速攀升，成為(wèi)當時最火爆的開源技(jì )術之一。

當前有 30％ 以上的企業在其 AWS 環境中使用(yòng) Docker，并且這個數字還在繼續增長(cháng)。

此時的 Docker，已經成為(wèi)行業裏人氣最火爆的開源技(jì )術，沒有之一。甚至像 Google、微軟、Amazon、VMware 這樣的巨頭，都對它青睐有加，表示将全力支持。

Docker 火了之後，dotCloud 公司幹脆把公司名字也改成了 Docker Inc. 。

Docker 和容器技(jì )術為(wèi)什麽會這麽火爆？說白了，就是因為(wèi)它 “輕”。在容器技(jì )術之前，業界的網紅是虛拟機。虛拟機技(jì )術的代表，是 VMWare 和 OpenStack 。

相信很(hěn)多(duō)人都用(yòng)過虛拟機。虛拟機，就是在你的操作(zuò)系統裏面，裝(zhuāng)一個軟件，然後通過這個軟件，再模拟一台甚至多(duō)台“子電(diàn)腦”出來。

在 “子電(diàn)腦” 裏，你可(kě)以和正常電(diàn)腦一樣運行程序，例如登錄 QQ。如果你願意，你可(kě)以變出好幾個 “子電(diàn)腦”，裏面都登錄上 QQ。“子電(diàn)腦” 和 “子電(diàn)腦” 之間，是相互隔離的，互不影響。

虛拟機屬于虛拟化技(jì )術。而 Docker 這樣的容器技(jì )術，也是虛拟化技(jì )術，屬于輕量級的虛拟化。

虛拟機雖然可(kě)以隔離出很(hěn)多(duō) “子電(diàn)腦”，但占用(yòng)空間更大，啓動更慢，虛拟機軟件可(kě)能(néng)還要花(huā)錢（例如：VMWare）。

而容器技(jì )術恰好沒有這些缺點。它不需要虛拟出整個操作(zuò)系統，隻需要虛拟一個小(xiǎo)規模的環境（類似 “沙箱”）。Docker 可(kě)以輕松創建容器和基于容器的應用(yòng)程序，最初是為(wèi) Linux 構建的，現在也可(kě)以在 Windows 和 MacOS 上運行。

它啓動時間很(hěn)快，幾秒(miǎo)鍾就能(néng)完成。而且，它對資源的利用(yòng)率很(hěn)高（一台主機可(kě)以同時運行幾千個 Docker 容器）。此外，它占的空間很(hěn)小(xiǎo)，虛拟機一般要幾 GB 到幾十 GB 的空間，而容器隻需要 MB 級甚至 KB 級。

正因為(wèi)如此，容器技(jì )術受到了熱烈的歡迎和追捧，發展迅速。大家需要注意，Docker 本身并不是容器，它是創建容器的工具，是應用(yòng)容器引擎。想要搞懂 Docker，其實看它的兩句口号就行。

第一句，是 “Build, Ship and Run”。

第二句口号則是：“Build once，Run anywhere(搭建一次，到處能(néng)用(yòng))”。

Build（構建鏡像）： 鏡像就像是集裝(zhuāng)箱，包含文(wén)件以及運行環境等等資源；

Ship（運輸鏡像）：在宿主機和倉庫間進行運輸，這裏倉庫就像是超級碼頭；

Run（運行鏡像）：運行的鏡像就是一個容器，容器就是運行程序的地方。

說白了，這個 Docker 鏡像，是一個特殊的文(wén)件系統。它除了提供容器運行時所需的程序、庫、資源、配置等文(wén)件外，還包含了一些為(wèi)運行時準備的一些配置參數（例如：環境變量）。鏡像不包含任何動态數據，其内容在構建之後也不會被改變。

綜上所述，Docker 的運行過程，也就是去倉庫把鏡像拉到本地，然後用(yòng)執行命令把鏡像運行起來變成容器，這也就是為(wèi)什麽人們常常将 Docker 稱為(wèi)碼頭工人或碼頭裝(zhuāng)卸工。

負責對 Docker 鏡像進行管理(lǐ)的，是 Docker Registry 服務(wù)（類似倉庫管理(lǐ)員）。當然，不是任何人建的任何鏡像都是合法的。萬一有人構建的鏡像存在問題呢(ne)？所以，Docker Registry 服務(wù)對鏡像的管理(lǐ)是非常嚴格的。最常使用(yòng)的 Registry 公開服務(wù)，是官方的 Docker Hub，這也是默認的 Registry，并擁有大量的高質(zhì)量的官方鏡像。

4、Docker如何使用(yòng)

其實大多(duō)數人談論 Docker 時說的是 Docker Engine，這隻是一個構建和運行的容器。

在運行容器前需要編寫 Docker File，通過 dockerFile 生成鏡像，然後才能(néng)運行 Docker 容器。

Docker File 定義了運行鏡像（image）所需的所有内容，包括操作(zuò)系統和軟件安(ān)裝(zhuāng)位置。一般情況下都不需要從頭開始編寫 Docker File，在 Docker Hub 中有來自世界各地的工程師編寫好的鏡像，你可(kě)以基于此修改。

📚此外，Docker 容器提供了一種構建企業應用(yòng)程序和業務(wù)流程應用(yòng)程序的方法，這些應用(yòng)程序比傳統應用(yòng)程序更容易安(ān)裝(zhuāng)、維護和移動。

⭐Docker 容器支持隔離：Docker 容器使應用(yòng)程序不僅彼此隔離，而且與底層系統隔離。這不僅使軟件棧更幹淨，而且更容易使容器化應用(yòng)程序使用(yòng)系統資源，例如 CPU、GPU、内存、I/O、網絡等，它還可(kě)以确保數據和代碼保持獨立。

⭐Docker 容器支持可(kě)移植性：Docker 容器在支持容器運行環境的任何機器上運行。應用(yòng)程序不必綁定到主機操作(zuò)系統，因此可(kě)以保持應用(yòng)程序環境和底層操作(zuò)環境的整潔和最小(xiǎo)化。

例如，采用(yòng)容器的 MySQL 将在大多(duō)數支持容器的 Linux 系統上運行，應用(yòng)程序的所有依賴項通常都在同一個容器中提供。基于容器的應用(yòng)程序可(kě)以輕易從 on-prem 系統遷移到雲環境中，或從開發人員的筆(bǐ)記本電(diàn)腦移到服務(wù)器上，隻要目标系統支持 Docker 以及可(kě)能(néng)與之一起使用(yòng)的任何第三方工具，比如 Kubernetes。

⭐通常，Docker 容器鏡像必須為(wèi)特定的平台構建。例如 Windows 容器不能(néng)在 Linux 上運行，反之亦然；以前，繞過此限制的一種方法是啓動運行所需操作(zuò)系統實例的虛拟機，并在虛拟機中運行容器。

然而 Docker 團隊後來設計了一個更優雅的解決方案，稱為(wèi) manifest，它允許多(duō)個操作(zuò)系統的鏡像并行打包。盡管 manifest 還處于試驗階段，但這暗示了容器可(kě)能(néng)成為(wèi)跨平台應用(yòng)程序解決方案和跨環境應用(yòng)程序解決方案。

⭐Docker 容器支持可(kě)組合性：大多(duō)數業務(wù)應用(yòng)程序由幾個獨立的組件組成，web 服務(wù)器、數據庫和 cache 緩存。Docker 容器可(kě)以将這些部件組合成一個容易更換的功能(néng)單元。每個部分(fēn)由不同的容器提供，可(kě)以獨立于其他(tā)容器進行維護、更新(xīn)、交換和修改。

🔥 這本質(zhì)上是應用(yòng)程序設計的微服務(wù)模型。通過将應用(yòng)程序功能(néng)劃分(fēn)為(wèi)獨立的、自包含的服務(wù)，微服務(wù)模型為(wèi)過程緩慢的傳統開發和單一僵化的應用(yòng)程序提供了一種解決方案，輕量級和便攜式容器使構建和維護基于微服務(wù)的應用(yòng)程序變得更加容易。

5、編排系統的需求催生了k8s

盡管 Docker 為(wèi)容器化的應用(yòng)程序提供了開放标準，但随着容器越來越多(duō)出現了一系列新(xīn)問題：

如何協調、調度和管理(lǐ)這些容器？

如何在升級應用(yòng)程序時不中斷服務(wù)？

如何監視應用(yòng)程序的運行狀況？

如何批量重新(xīn)啓動容器裏的程序？

解決這些問題需要容器編排技(jì )術，可(kě)以将衆多(duō)機器抽象，對外呈現出一台超大機器。現在業界比較流行的有：k8s、Mesos、Docker Swarm。

在業務(wù)發展初期隻有幾個微服務(wù)，這時用(yòng) Docker 就足夠了，但随着業務(wù)規模逐漸擴大，容器越來越多(duō)，運維人員的工作(zuò)越來越複雜，這個時候就需要編排系統解救 opers。

一個成熟的容器編排系統需要具備以下能(néng)力：

處理(lǐ)大量的容器和用(yòng)戶

負載均衡

鑒權和安(ān)全性

管理(lǐ)服務(wù)通信

多(duō)平台部署

其中，K8S，就是基于容器的集群管理(lǐ)平台，它的全稱，是 kubernetes。

和 Docker 不同，K8S 的創造者，是衆人皆知的行業巨頭——Google。

然而，K8S 并不是一件全新(xīn)的發明。它的前身，是 Google 自己搗鼓了十多(duō)年的 Borg 系統。K8S 是 Google 研發的容器協調器，已捐贈給 CNCF，現已開源。

Google 利用(yòng)在容器管理(lǐ)多(duō)年的經驗和專業知識推出了 k8s，主要用(yòng)于自動化部署應用(yòng)程序容器，可(kě)以支持衆多(duō)容器化工具包括現在非常流行的 Docker。

目前 k8s 是容器編排市場的領導者，開源并公布了一系列标準化方法，主流的公有雲平台都宣布支持。

一流的廠商都在搶占标準的制高點，一堆小(xiǎo)廠商跟着一起玩，這就叫生态了。

6、k8s架構和組件

k8s 由衆多(duō)組件組成，組件間通過 API 互相通信，歸納起來主要分(fēn)為(wèi)三個部分(fēn)：

controller manager

nodes

pods

Controller Manager，即控制器管理(lǐ)器，用(yòng)于調度程序以及節點狀态檢測(是k8s的大腦)。

Nodes，構成了 Kubernetes 集群的集體(tǐ)計算能(néng)力，實際部署容器運行的地方。

Pods，Kubernetes 集群中資源的最小(xiǎo)單位。

下圖是 Kubernetes 集成 Jenkins 實現 CICD（一圖勝千言，需要對其有一個大緻的認識）：

而下圖則是 GitLab + Jenkins Pipeline + Doker + k8s + Helm 自動化部署：

7、k8s與Docker Swarm江湖(hú)恩怨

Docker Swarm 與 k8s 同為(wèi)容器編排技(jì )術。

如果非要拿(ná)Docker和k8s進行比較，其實更應該拿(ná)Docker Swarm和k8s比較。

Docker Swarm是Docker自駕針對集群化部署管理(lǐ)的解決方案。優點很(hěn)明顯，可(kě)以更緊密集成到Docker生态系統中。雖說Swarm和Docker血緣更近，但是由于商業、生态等原因依舊沒有k8s流行。

8、Docker與k8s難舍難分(fēn)

Docker和k8s在業界非常流行，已經是事實上的标準了。

Docker是用(yòng)于構建、分(fēn)發、運行()容器的平台和工具。

而k8s實際上是一個使用(yòng)Docker容器進行編排的系統，主要圍繞pods進行工作(zuò)。Pods是k8s生态中最小(xiǎo)的調度單位，可(kě)以包含一個或多(duō)個容器。

Docker和k8s分(fēn)别做不通的事情，兩者是協同關系。

9、開發實踐

（1）不用(yòng)k8s可(kě)以使用(yòng)docker嗎？

可(kě)以。對于一些小(xiǎo)型公司、業務(wù)不太複雜的情況下都是可(kě)以直接使用(yòng)docker的。盡管k8s有很(hěn)多(duō)好處，但是衆所周知它非常複雜，簡單業務(wù)完全可(kě)以放棄使用(yòng)k8s。但是當業務(wù)達到一定規模後可(kě)能(néng)還是要借助k8s才行。

（2）沒有Docker可(kě)以使用(yòng)k8s嗎？

k8s展示一個容器編排器，沒有容器拿(ná)什麽編排？？

k8s經常與Docker進行搭配使用(yòng)，但是也可(kě)以使用(yòng)其他(tā)容器，如RunC、Containerted等。

（3）Docker Swarm和k8s怎麽選？

選k8s。2019 年底 Docker Enterprise 已經出售給 Mirantis，Mirantis 聲明要逐步淘汰 Docker Swarm，後續會将 k8s 作(zuò)為(wèi)默認編排工具。

10、k8s棄用(yòng)docker？

k8s 1.20版本的changelog原文(wén)如下：

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community

原文(wén)說的是kubelet是通過一個叫做dockershim的模塊實現對docker的支持，然後以後版本會移除這個dockershim模塊。

典型的k8s runtime架構(dockershim)

關于dockershim是什麽還要從k8s發布之初和docker的關系說起。k8s在發布之初，docker在容器實現方面占據壟斷地位。為(wèi)了迎合主流，kubernetes官網也率先使用(yòng)docker作(zuò)為(wèi)底層容器的實現。

注： shim 顧名思義就是 “墊片”的意思。

2016年12月k8s發布CRI(Container Runtime Interface)，很(hěn)重要的一個考量就是為(wèi)了避免後續兼容其他(tā)運行時帶來的維護工作(zuò)，所以發布了統一的CRI接口。這樣凡是支持CRI的運行時，皆可(kě)以直接作(zuò)為(wèi)k8s的底層運行時。

所以之前的架構是：

Kubelet 通過CRI接口調用(yòng)dockershim請求創建容器；

dockershim把創建容器的請求轉換成docker daemon的請求往docker創建一個容器；

這時候把容器創建請求請求到使用(yòng)CRI實現的containerd；

containerd通過OCI調用(yòng)containerd-shim然後進而使用(yòng)操作(zuò)系統底層實現容器的創建 ；

看到這兒，相信大家就知道官網為(wèi)什麽要移除dockershim了！！！

因為(wèi)這個調用(yòng)合着需要經過兩個劃水的dockershim和docker daemon。kubelet直接調用(yòng)containerd就完事了。于是就有了如下新(xīn)架構：

        總結來說，k8s啓用(yòng)的其實是dockershim，選擇直接對接CRI接口；并且默認支持的是containerd(就是docker自帶的組件)，所以完全可(kě)以和docker本身做到100%兼容。k8s去除dockershim是自身發展考慮，為(wèi)的是支持更通用(yòng)的CRI标準，更高抽象化意味着更好的兼容性。

        順便說下，即便啓用(yòng)docker也不代表docker就要涼了。docker帶給我們的是更新(xīn)的工作(zuò)流和開發方式，一種容器化的思維。在我們的日常開發中，docker在臨時搭建一些環境時還是可(kě)以發揮巨大作(zuò)用(yòng)的。

————————————————

                            版權聲明：本文(wén)為(wèi)博主原創文(wén)章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文(wén)出處鏈接和本聲明。

原文(wén)鏈接：https://blog.csdn.net/mijichui2153/article/details/136327686