系列文章目錄

【云原生|探索 Kubernetes-1】容器的本質是進程
【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器進程的文件系統(tǒng)

?? 關于作者

大家好，我是秋意零。

?? CSDN作者主頁

• ?? 博客主頁

?? 簡介

• ?? 普通本科生在讀
• 在校期間參與眾多計算機相關比賽，如：?? “省賽”、“國賽”，斬獲多項獎項榮譽證書
• ?? 各個平臺，秋意零 賬號創(chuàng)作者
• ?? 云社區(qū) 創(chuàng)建者

點贊、收藏+關注下次不迷路！

歡迎加入云社區(qū)

一、前言|回顧

今天介紹的主題是：Kubernetes 的本質。文章有點長，希望大家能完整閱讀完，并品味。

前面三篇文章中，我們介紹了容器的具體實現(xiàn)是怎么回事。通過前三篇文章，你應該能理解：一個 “容器”，首先是啟用 Linux Namespace（名稱空間）、配置 Linux Cgroups（限制）、使用 rootfs （根文件系統(tǒng)） 三種技術來實現(xiàn)容器進程的隔離。

二、靜態(tài)和動態(tài)視圖

1.容器基礎核心技術是由三個技術實現(xiàn)的：Linux Namespace、 Linux Cgroups、rootfs 。一個正在運行的 Linux 容器 ，我們可以 “一分為二” 看待為靜態(tài)和動態(tài)視圖：

• 靜態(tài)視圖： 一組聯(lián)合掛載目錄 /var/lib/docker/overlay2/<directory-of-running-container>/merged，這個是我們容器的 rootfs 根文件系統(tǒng)，也稱為 “容器鏡像”（Container Image），是容器的靜態(tài)視圖；
• 動態(tài)視圖： 使用 Namespace + Cgroups 技術構建的隔離環(huán)境，我們稱為 “容器運行時”（Container Runtime），是容器的動態(tài)視圖。

2.如果你是一名開發(fā)人員，我們只需要關心 “容器鏡像”，而如果你是一名運維人員，你需要關心 “容器運行時”。軟件開發(fā)流程：開發(fā)-測試-發(fā)布-運維，“容器鏡像”（這里是開發(fā)部分）承載著容器信息的傳遞，而不是 “容器運行時”（這里是運維部分）。

• 因為開發(fā)者只需要編寫代碼，代碼跑起來程序正常運行就行，是屬于 “容器鏡像”部分；
• 而運維者需要維護這個程序的生命周期，管理程序狀態(tài)的，是屬于 “容器運行時” 的部分

3.這里的價值在于：通過容器鏡像將開發(fā)者關聯(lián)起來，科技圈中 “得開發(fā)者得天下”。

• 開發(fā)者，負責將自己的程序代碼打包為容器鏡像；
• 運維者或用戶，將容器鏡像運行為容器。

這樣，容器從一個開發(fā)者當中的工具，一躍變成了云計算領域的絕對主角；

• 而這里容器還不夠有意義，更有意義的是 “容器編排”，因為單一的容器，到龐大的容器集群，從容器到容器云的飛躍，非常需要對容器進行編排管理；
• 而能夠定義容器組織和管理規(guī)范的 “容器編排” 技術，則會是容器技術領域的 “頭把交椅”。

三、爆火的容器編排工具 Kubernetes 的誕生

具有代表性的容器編排工具（這里主要介紹 Kubernetes）：

• Docker 公司的 Compose + Swarm 組合；
• Google 和 RedHat 公司主導的 Kubernetes 項目。

Kubernetes 是由 Google 開源的容器編排系統(tǒng)，最初是基于 Google 內部的 Borg 系統(tǒng)（始于 2003 年）開發(fā)的。2014 年，Google 將 Kubernetes 作為開源項目發(fā)布，并將其交給了 Cloud Native Computing Foundation（CNCF）來管理和維護，使其成為一個全球性的開源項目。Kubernetes 的誕生是為了解決容器編排的問題，使得開發(fā)人員能夠更輕松地管理和部署大規(guī)模容器化應用程序。

Google 公司的 Borg 系統(tǒng)和 Borg 論文密切相關。Borg 論文是由 Google 的工程師們在 2015 年 4 月發(fā)表的一篇論文，詳細描述了 Borg 系統(tǒng)的設計、實現(xiàn)和應用場景。這篇論文對于后來 Kubernetes 的設計和發(fā)展產生了深遠的影響。 因此，Borg 系統(tǒng)和 Borg 論文可以說是互相關聯(lián)、相輔相成的。

Borg 系統(tǒng)要承擔的責任，是承載 Google 公司整個基礎設施的核心依賴。在 Google 整個基礎設施技術棧的最底層。正是由于這個地位，Borg 可以說是 Google 最不可能開源的一個項目。而幸運的是，得益于 Docker 項目和容器技術的風靡，它卻終于得以以另一種方式與開源社區(qū)見面，這個方式就是 Kubernetes 項目。

Kubernetes 項目在 Borg 體系的指導下，體現(xiàn)出了一種獨有的 “先進性” 與 “完備性”。

四、Kubernetes 要解決的問題是什么？

容器編排？容器調度？容器集群管理？

但是實際上，隨著社會和 Kubernetes 項目的不斷發(fā)展，Kubernetes 需要解決的問題是不同的，所以沒有一個標準答案，不過 Kubernetes 的誕生是為了解決容器編排的問題。

目前為止 Kubernetes 已經逐漸演進為云原生下的 ”操作系統(tǒng)”：

• 操作系統(tǒng)一般有存儲、網絡、進程調度、設備管理、安全性管理、系統(tǒng)調用 API 等功能。所以類似操作系統(tǒng)一樣 Kubernetes 也提供了的存儲、網絡、資源調度、設備管理、安全性管理、聲明式 API。
• 所以 Kubernetes 具有運維能力，比如自動化部署和擴展、高可用性和容錯、水平擴展、服務發(fā)現(xiàn)和負載均衡、網絡管理、存儲管理、自動化滾動更新等。

所以 Kubernetes 解決的問題和所在的高度對比 Compose 、Swarm 是不一樣的。

下圖是 ChatGPT 回答的 “操作系統(tǒng)” 和 “Kubernetes（操作系統(tǒng)）” 功能對比圖：

五、理解 Kubernetes 全局架構圖

Kubernetes 項目依托 Borg 項目的理論優(yōu)勢，在短短幾個月內迅速站穩(wěn)了腳跟，進而確定了Kubernetes 全局架構圖：

Kubernetes 架構是由 Master （控制節(jié)點）和 Node（計算節(jié)點） 兩種節(jié)點組成：

Master（控制節(jié)點）

Master 控制節(jié)點，主要負責管理和控制整個集群的運行。

• Master（控制節(jié)點）：由三個獨立的組件組成：kube-apiserver（提供 API 接口）、kube-apiserver（負責資源調度）、kube-controller-manager（負責容器編排控制）。整個集群的持久化數(shù)據(jù)，由 kube-apiserver 處理后交給 Etcd 鍵值對數(shù)據(jù)庫保存。

Kubernetes 沒有把 Docker 作為整個框架的核心，而是把它作為做底層容器運行時實現(xiàn)。

Kubernetes 著重要解決的問題，則來自于 Borg 的研究人員在論文中提到的一個非常重要的觀點：

• 運行在大規(guī)模集群中的各種任務之間，實際上存在著各種各樣的關系。這些關系的處理，才是作業(yè)編排和管理系統(tǒng)最困難的地方。

如：一個 Web 應用與后端數(shù)據(jù)庫之間的訪問關系，一個負載均衡器和它的后端服務之間的代理關系。

Node（計算節(jié)點）

Node（計算節(jié)點）承載容器的運行，負責運行容器的工作負載，并提供計算資源、容器運行時、容器網絡、存儲卷掛載等功能。

• Node（計算節(jié)點）：Node 節(jié)點中最核心的部分，是 kubelet 組件。

  • kubelet 主要負責和容器運行時打交道，這個交互依賴的是一個 CRI（Container Runtime Interface）容器運行時接口，這個接口是 Kubernetes 與容器運行時交互的標準接口，定義了容器運行的時候的各項核心操作，比如：容器的創(chuàng)建和銷毀、容器的啟動和停止。
    
    通過上圖 ChatGPT 介紹，CRI 和容器運行時的關系是：CRI 是 Kubernetes 針對容器運行時的標準接口規(guī)范，定義了Kubernetes主節(jié)點和容器運行時之間的通信協(xié)議。而容器運行時則是實現(xiàn)這個規(guī)范的軟件，用來啟動、停止和管理容器的進程。容器運行時需要遵守 CRI 規(guī)范來與 Kubernetes 集群進行交互。

  
  （這里需要說明的是：只要支持和 CRI 接口對接，就可以替換容器運行時和 Kubernetes 無縫集成，比如：Kubernetes 1.24.x 及以后的版本 ，Docker 項目已經不是 Kubernetes 的默認容器運行時了，而是 containerd，常見的容器運行時，可以看下圖我在官網上截取的，更多信息參考官網）
  

  • 容器運行時，通過 OCI 容器運行時規(guī)范和底層的 Linux 操作系統(tǒng)進行交互，把 CRI 請求翻譯成對 Linux 系統(tǒng)的調用，對 Linux Namespace 和 Cgroups 操作等。
    
  • kubelet 還通過 gRPC 協(xié)議與 Device Plugin 設備插件進行交互。這個插件是 Kubernetes 用來添加和管理 GPU、FPGA、網絡適配器等宿主機物理設備的主要組件，也是 Kubernetes 項目進行機器學習訓練、高性能作業(yè)支持等工作必須關注的功能，因為這些功能需要高算力的支持。提供給 Pod 使用（聲明相應的 Device Request 來獲取這些資源，并綁定到自己的容器中）。
  • kubelet 的另一個重要功能，是調用 CNI 容器網絡接口（Container Networking Interface）和 CSI 容器存儲接口（Container Storage Interface），分別為 Kubernetes 項目提供容器網絡配置和持久化存儲。
    這里目前不對 CNI 網絡插件和 CSI 存儲插件深入展開，這會是后續(xù)重要的內容。

Node 節(jié)點小結

Node 計算節(jié)點 kubelet 工作流程圖：

• kubelet 直接與 CRI（容器運行時接口）、Device Plugin （設備插件）、CNI（容器網絡接口）、CSI（容器存儲接口）交互：
  • CRI（容器運行時接口）： CRI 向下走，與 Container Runtime（容器運行時）交互，容器運行時負責操作容器生命周期，再下走需要與 Linux 系統(tǒng)直接交互，來操作 Linux Namespace、Linux Cgroups 等。
  • Device Plugin（設備插件）：Device Plugin 添加管理宿主機物理設備，如 GPU、FPGA（集成電路設備），下層是直接與 Linux 宿主操作系統(tǒng)交互，最終會將資源分配給容器。
  • CNI（容器網絡接口）：CNI 與 Networking 交互，Networking 負責處理容器網絡相關的功能和配置，Networking 與 Linux 系統(tǒng)交互。首先為容器創(chuàng)建一個網絡接口（包括IP地址、子網掩碼、網關等網絡參數(shù)），其次配置網絡路由（Linux 宿主機上設置，確保容器可以與其他網絡節(jié)點進行通信），最后連接網絡設備（與Linux宿主機上的網絡設備進行交互，如：虛擬網絡設備、配置VLAN）。
  • CSI（容器存儲接口）： 容器存儲管理的標準接口，與存儲提供商之間定義了一致的交互方式，這里與 Volume Plugin 卷插件交互，負責管理容器存儲卷（提供具體功能），與 Linxu 宿主機交互，提供存儲卷的掛載、卸載和管理等功能
    

六、Kubernetes 設計思想

在傳統(tǒng)虛擬機中，發(fā)現(xiàn)并不相關的應用被一股腦兒地部署在同一臺虛擬機中（粗粒度），有了容器之后就是單獨一個應用一個環(huán)境（粗粒度）。容器也是 “微服務” 思想得以落地的先決條件。

如果只做 “封裝微服務、調度單容器” 這一層次，Docker Swarm + Compose 項目就能很好實現(xiàn)，并具備了處理一些簡單依賴關系，如：一個 “Web 容器” 和它的后端數(shù)據(jù)庫 “DB 容器” 之間的訪問。

在 Compose 中，你可以使用 “l(fā)ink” 將這兩個具有依賴關系的容器聯(lián)系起來，這種 “l(fā)ink” 實際上是配置了兩個容器之間的 /etc/hosts 文件。

• 但是這種方案還是過去簡單了，沒有辦法支持未來可能出現(xiàn)的更多種類的關系。架構一般是：追求項目的普適性，就一定要從頂層開始做好設計。

Kubernetes 項目最主要的設計思想是，從更宏觀的角度，以統(tǒng)一的方式來定義任務之間的各種關系，并且為將來支持更多種類的關系留有余地。

Kubernetes 對容器間的 "訪問“ 進行了分類，比如：Pod，它是 Kubernetes 中最基本的單元，Pod 中可以包含一個或多個容器，這些容器可以通過 locahost 進行頻繁的交互和訪問，也可以通過本地磁盤目錄交換文件，因為一個 Pod 中它們的 Network Namespace 和數(shù)據(jù)卷是共享的，從而提高效率來交換信息。

需要注意的是：需要非常頻繁的交互和訪問，我們一般把這類容器放入到一個 Pod 中。

對于另外一種更為常見的需求，比如： Web 應用與數(shù)據(jù)庫之間的訪問關系，它們之間一般不會部署到一個 Pod 中或者說一臺機器上，這樣即使 Web 端 down 機了，數(shù)據(jù)庫也不會受到影響，對于容器來說把當前運行的容器刪除了，或者后端數(shù)據(jù)庫做了高可用（前端也可以）IP地址會變化或后端 IP 地址很多，這種時候 Web 怎么和數(shù)據(jù)庫連接呢？

• Kubernetes 為這種情況提供了一個叫 ”Service“ 的服務。目前你可以把 Service 看作一個做負載均衡和服務發(fā)現(xiàn)的一個服務。Service 為我們提供了一個虛擬 VIP，我們訪問這個與后端數(shù)據(jù)庫關聯(lián)的 VIP 地址，它就會為我們代理到后端的數(shù)據(jù)庫上，并且支持負責均衡和服務發(fā)現(xiàn)（外部可以訪問）。

七、Kubernetes 全景圖

從 Servcie 服務可以看到，我們都是圍繞著 Pod 去擴展和去提供服務的，我們可以看下圖 Kubernetes 項目核心功能的“全景圖”：
從這副圖中，我們可以看到 Pod 的地位是在最中心，所有的服務都是為 Pod 提供服務或者管理 Pod。

從容器這個最基礎的概念出發(fā)，首先遇到了容器間 “緊密協(xié)作” 關系的難題，于是就有了 Pod；有了 Pod 之后，我們希望能一次啟動或收縮多個應用的實例，這樣就需要 Deployment 這個 Pod 的控制器；有了這樣的控制器之后（一組相同的 Pod），就需要一個 VIP 來負載均衡和暴露服務訪問它，這個時候就有了 Service。

這個時候還有一些問題，比如：Web 訪問數(shù)據(jù)庫時肯定時需要密碼的，這個時候我們怎么安全的定義密碼而不會以明文的方式暴露在外呢？

• Kubernetes 提供了一個加 Secret 服務，它把鍵值對的數(shù)據(jù)保存在 Etcd 中，我們使用這個密碼信息時，就要用到 Secret 里的數(shù)據(jù)以 Volume 的方式掛載到容器里。

Kubernetes 項目并沒有像其他項目那樣，為每一個管理功能創(chuàng)建一個指令，然后在項目中實現(xiàn)其中的邏輯。

• 相比之下，在 Kubernetes 項目中，我們所推崇的使用方法是：
  • 首先，通過一個“編排對象”，比如 Pod、Job、CronJob、Deployment 等，來描述你試圖管理的應用；
  • 然后，再為它定義一些“服務對象”，比如 Service、Secret、Horizontal Pod Autoscaler（自動水平擴展器）等。這些對象，會負責具體的平臺級功能。

這種使用方法，就是所謂的 “聲明式 API”。這種 API 對應的 “編排對象” 和 “服務對象”，都是 Kubernetes 項目中的 API 對象（API Object）。

總結

首先我們簡單的回顧了一下前面章節(jié)的知識，理解靜態(tài)視圖和動態(tài)視圖，了解開發(fā)和運維在容器中所承擔的角色。

接著我們介紹了 Kubernetes 它和 borg 系統(tǒng)和論文之間的關系，這里也說明了 Kubernetes 誕生的基礎，闡述了 Kubernetes 是為解決什么問題而誕生的。然后我們重點介紹了 Kubernetes 的全局架構圖，從 Master 控制節(jié)點和 Node 計算節(jié)點展開。

最后我們說明了設計思想所站在的高度和其他項目有什么不同，同時闡述了 Kubernetes 之間的對象服務關系，分清楚 “編排對象” 和 “服務對象”，理解 Kubernetes 是管理 Pod 以及為 Pod 提供服務的。通過 Pod 我們應該能明白 Kubernetes 是可以想象成操作系統(tǒng)的，為 Pod 提供網絡、存儲、安全、等服務，而 Pod 則是我們這個系統(tǒng)中的應用程序。

? 最后

?? 我是秋意零，歡迎大家一鍵三連、加入云社區(qū)

?? 我們下期再見(⊙o⊙)?。。?mark hidden color="red">文章來源：http://www.zghlxwxcb.cn/news/detail-480335.html

參考

參考《深入剖析Kubernetes》作者 張磊文章來源地址http://www.zghlxwxcb.cn/news/detail-480335.html

到了這里，關于【探索 Kubernetes|容器基礎進階篇 系列 4】理解現(xiàn)代云原生時代的引擎的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！