![](https://img-blog.csdnimg.cn/20210705150951760.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
來源 ｜ [爾達 Erda 公眾號](https://mp.weixin.qq.com/s/29sZTo5cCWavvwAHGnmfBA)

# 帶你瞭解雲原生技術圖譜

如果你研究過雲原生應用程式和相關技術，大機率你遇到過 CNCF 的雲原生全景圖。這張全景圖技術之多、規模之大無疑會讓人感到震驚，那麼我們該如何去理解這張圖呢？

如果把它拆開來，一次只分析一小塊內容，你會發現整個全景圖沒有那麼複雜。事實上，該全景圖按照功能有序地組織在一起，一旦你瞭解了每個類別代表的內容，你就可以輕鬆遊走於全景圖中。

本文我們首先把整個全景圖拆解開來，並對整個全景圖進行綜述，接著聚焦在每一層（or 每一列），對每個類別解決的問題和原理進行了更為詳細的解讀。

![](https://img-blog.csdnimg.cn/20210705151014202.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 1. 雲原生全景圖的 4 層

首先，我們剝離掉所有單個的技術，僅檢視類別（如下圖）。圖中有不同的“行”，像建築的不同層，每層都有自己的子類別。最底層提供了構建雲原生基礎設施的工具。往上，你可以開始新增執行和管理應用程式所需的工具，比如執行時和排程層。在最上層，有定義和開發應用程式的工具，比如資料庫、映象構建和 CI/CD 工具（我們將在後文討論）。

![](https://img-blog.csdnimg.cn/20210705151026488.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

好了，現在你應該記住了雲原生全景圖始於基礎設施，往上的每一層都更接近實際的應用程式。這就是每層代表的意思（後面我們會討論上圖右邊的兩“列”）。下面我們就從最底層開始，逐層進行解析。

### 1）供應層 （Provisioning）

供應指的是為雲原生應用準備標準基礎環境所涉及的工具。它包含了基礎設施的建立、管理、配置流程的自動化，以及容器映象的掃描、簽名和儲存等。供應層透過提供設定和實施策略，在應用程式和平臺中構建身份驗證和授權，以及處理金鑰分發等等的工具，也擴充到了安全領域。

供應層包括：

- 自動化和部署工具：幫助工程師在無需人工干預情況下即可構建計算環境；
- 容器登錄檔：儲存應用程式的可執行檔案；
- 不同安全領域的安全和合規框架；金鑰管理解決方案：透過加密確保只有授權的使用者才能訪問特定的應用程式。
- 這些工具使工程師可以編寫基礎設施引數，使系統可以按需搭建新環境，確保了一致性和安全性。

### 2）執行時層（Runtime）

接下來是執行時層。這個詞可能會讓你感到迷惑。像很多 IT 術語一樣，執行時沒有嚴格的定義，且可以根據語境有不同的用法。狹義上講，執行時是特定機器上準備執行應用程式的沙盒——也就是保障應用程式正常執行所需的最低配置。廣義上講，執行時是執行一個應用程式所需的所有工具。

在 CNCF 雲原生全景圖中，執行時保障了容器化應用程式元件的執行和通訊， 包括：

- 雲原生儲存：為容器化應用提供虛擬磁碟或持久化儲存；
- 容器執行時：為容器提供隔離、資源和安全；
- 雲網路：分散式系統的節點（機器或程式）透過其連線和通訊。

### 3）編排和管理層（Orchestration and Management）

一旦按照安全和合規性標準（供應層）自動化基礎設施供應，並安裝了應用程式執行所需的工具（執行時層），工程師就需要弄清楚如何編排和管理應用程式。編排和管理層將所有容器化服務（應用程式元件）作為一個群組管理。這些容器化服務需要相互識別和通訊，並需要進行協調。這一層可為雲原生應用提供自動化和彈效能力，使雲原生應用天然具有可擴充套件性。

這一層包含：

- 編排和排程：部署和管理容器叢集，確保它們具有彈性伸縮能力，相互之間低耦合，並且可擴充套件。事實上，編排工具（絕大多數情況下就是 Kubernetes）透過管理容器和操作環境構成了叢集；
- 協調和服務發現：使得服務（應用程式元件）之間可以相互定位和通訊；
- 遠端程式呼叫（RPC）：使跨節點服務間通訊的技術；
- 服務代理：服務間通訊的中介。服務代理的唯一目的就是對服務之間的通訊進行更多控制，而不會對通訊本身新增任何內容。服務代理對下面將提到的服務網格（Service Mesh）至關重要。
- API 閘道器：一個抽象層，外部應用可透過 API 閘道器進行通訊；
- Service Mesh：某種程度上類似於 API 閘道器，它是應用程式進行通訊的專用基礎架構層，提供基於策略的內部服務間通訊。此外，它還可能包含流量加密、服務發現、應用程式監控等內容。

### 4）應用定義和開發層 （Application Definition and Developement)

現在，我們來到了最頂層。應用定義和開發層，顧名思義，聚集了讓工程師構建和執行應用程式的工具。上述所有內容都是關於構建可靠、安全的環境，以及提供全部所需的應用程式依賴。

這一層包括：

- 資料庫：使應用程式能以有序的方式收集資料；
- 流和訊息傳遞：使應用程式能傳送和接收訊息（事件和流）。它不是網路層，而是讓訊息成為佇列並處理訊息的工具；
- 應用程式定義和映象構建：用於配置、維護和執行容器映象（應用程式的可執行檔案）的服務；
- 持續整合和持續交付（CI/CD）：使開發者可自動測試程式碼是否與程式碼庫（應用程式的其餘部分）相容。如果團隊足夠成熟，甚至可以自動部署程式碼到生產環境。

## 2. 貫穿所有層的工具

接下來我們將進入到雲原生全景圖右側貫穿所有層的兩列。可觀察性和分析（Observability&analysis）是監控各層的工具，平臺則將各層中不同的技術捆綁為一個解決方案。

![](https://img-blog.csdnimg.cn/20210705151125189.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
### 1）可觀察性和分析（Observability and Analysis）

為了限制服務中斷並降低解決問題的平均時間（MRRT），你需要監控和分析應用層序的方方面面，以便在出現異常時可立即發現並糾正。複雜環境中容易出現故障，這些工具可快速識別並解決故障，從而降低故障帶來的影響。由於這一類別貫穿並監控各層，因此它在側面，而不是嵌入到某一層中。

這一類別你將發現：

- 日誌工具：收集事件日誌（有關程式的資訊）；
- 監控方案：收集指標（以數字表示的系統引數，例如 RAM 可用性）；
- 追蹤工具：追蹤比監控更進了一步，它們監控使用者請求的傳播，與服務網格相關。
- 混沌工程（Chaos Engineering）：在生產環境中測試軟體的工具，可識別缺陷並進行修復，減少其對服務交付的影響。

### 2）平臺類（Platform）

可以看到，圖中每一個模組解決一個特定的問題。但我們知道，僅有儲存並不能提供應用程式所需的全部功能。你還需要編排工具、容器執行時、服務發現、網路和 API 閘道器等等。平臺覆蓋多層，將不同的工具組合在一起，以解決更大的問題。

配置和微調不同的模組使其安全可靠，並確保它利用的技術都能及時更新、所有漏洞都打了補丁，這並不是一件容易的事情。使用平臺時，使用者不用額外擔心這些細節問題。

你可能會注意到，所有的類別都圍繞著 Kubernetes 展開。這是因為 Kubernetes 雖然只是雲原生景觀圖這張拼圖中的一塊，但它卻是雲原生技術棧的核心。順便說一下，CNCF 剛建立時，Kubernetes 就是其中的第一個種子專案，後來才有了其他專案。

平臺可分為四類：

- K8s 發行版：採用未經修改的開放原始碼（儘管有人對其進行了修改），並根據市場需要增加了其他功能。
- 託管的 K8s：類似於 Kubernetes 發行版，但是由提供商託管。
- K8s 安裝程式：自動執行 Kubernetes 的安裝和配置過程。
- PaaS / 容器服務：類似於託管的 Kubernetes，但是包含了一套更廣泛的應用部署工具（通常是來自雲原生景觀圖）。

## 3. 小結

在每個類別中，針對相同或相似的問題，都有不同的工具可選擇。有一些是適用於新現實的預雲原生技術，還有一些則是全新的。區別在於它們的實現和設計方法。沒有完美的技術符合你的所有需求。大多數情況下，技術受設計和架構選擇的限制——始終需要權衡取捨。

在選擇技術棧時，工程師必須仔細考慮每種能力和需要權衡取捨的地方，以確定最合適的選項。雖然這樣會讓情況變得更復雜，但在選擇應用程式所需的最適合的資料儲存、基礎設施管理、訊息系統等方案時，這樣做是最可行的辦法。現在，構建一個系統比雲原生之前的時代容易多了。如果構建恰當，雲原生技術將提供更強大的靈活性。在現如今快速變化的技術生態中，這可能是最重要的能力之一。

下面我們來詳細介紹雲原生全景圖的每一層。

# 供應層

雲原生全景圖的最底層是供應層（provisioning）。這一層包含構建雲原生基礎設施的工具，如基礎設施的建立、管理、配置流程的自動化，以及容器映象的掃描、簽名和儲存等。供應層也跟安全相關，該層中的一些工具可用於設定和實施策略，將身份驗證和授權內建到應用程式和平臺中，以及處理 secret 分發等。

![](https://img-blog.csdnimg.cn/20210705151210234.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

接下來讓我們看一下供應層的每個類別，它所扮演的角色以及這些技術如何幫助應用程式適應新的雲原生環境。

## 1. 自動化和配置

### 1）是什麼

自動化和配置工具可加快計算資源（虛擬機器、網路、防火牆規則、負載均衡器等）的建立和配置過程。這些工具可以處理基礎設施構建過程中不同部分的內容，大多數工具都可與該空間中其他專案和產品整合。

### 2）解決的問題

傳統上，IT 流程依賴高強度的手動釋出過程，週期冗長，通常可達 3-6 個月。這些週期伴隨著許多人工流程和管控，讓生產環境的變更非常緩慢。這種緩慢的釋出週期和靜態的環境與雲原生開發不匹配。為了縮短開發週期，必須動態配置基礎設施且無需人工干預。

### 3）如何解決問題

供應層的這些工具使工程師無需人工干預即可構建計算環境。透過程式碼化環境設定，只需點選按鈕即可實現環境配置。手動設定容易出錯，但是一旦進行了編碼，環境建立就會與所需的確切狀態相匹配，這是一個巨大的優勢。

儘管不同工具實現的方法不同，但它們都是透過自動化來簡化配置資源過程中的人工操作。

### 4）對應工具

當我們從老式的人工驅動構建方式過渡到雲環境所需的按需擴充套件模式時，會發現以前的模式和工具已經無法滿足需求，組織也無法維持一個需要建立、配置和管理伺服器的 7×24 員工隊伍。Terraform 之類的自動化工具減少了擴充套件數伺服器和相關網路以及防火牆規則所需的工作量。Puppet、Chef 和 Ansible 之類的工具可以在伺服器和應用程式啟動時以程式設計方式配置它們，並允許開發人員使用它們。

一些工具直接與 AWS 或 vSphere 等平臺提供的基礎設施 API 進行互動，還有一些工具則側重於配置單個計算機以使其成為 Kubernetes 叢集的一部分。Chef 和 Terraform 這類的工具可以進行互操作以配置環境。OpenStack 這類工具可提供 IaaS 環境讓其他工具使用。

從根本上講，在這一層，你需要一個或多個工具來為 Kubernetes 叢集搭建計算環境、CPU、記憶體、儲存和網路。此外，你還需要其中的一些工具來建立和管理 Kubernetes 叢集本身。

在撰寫本文時，該領域中有三個 CNCF 專案：KubeEdge（一個沙盒專案）以及 Kubespray 和 Kops（後兩個是 Kubernetes 子專案，雖然未在全景圖中列出，但它們也屬於 CNCF）。此類別中的大多數工具都提供開源和付費版本。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直![](https://img-blog.csdnimg.cn/20210705151403813.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

![](https://img-blog.csdnimg.cn/202107051514146.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 2. Container Registry

### 1）是什麼

在定義 Container Registry 之前，我們首先討論三個緊密相關的概念：

- 容器是執行流程的一組技術約束。容器內啟動的程式會相信它們正在自己的專用計算機上執行，而不是在與其他程式（類似於虛擬機器）共享的計算機上執行。簡而言之，容器可以使你在任何環境中都能控制自己的程式碼執行。
- 映象是執行容器及其過程所需的一組存檔檔案。你可以將其視為模板的一種形式，可以在其上建立無限數量的容器。
- 倉庫是儲存映象的空間。

回到 Container Registry，這是分類和儲存倉庫的專用 Web 應用程式。

映象包含執行程式（在容器內）所需的資訊，並儲存在倉庫中，倉庫被分類和分組。構建、執行和管理容器的工具需要訪問（透過引用倉庫）這些映象。

![](https://img-blog.csdnimg.cn/20210705151433867.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

### 2）解決的問題
雲原生應用程式被打包後以容器的方式執行。Container Registry 負責儲存和提供這些容器映象。

### 3）如何解決
透過在一個地方集中儲存所有容器映象，這些容器映象可以很容易地被應用程式的開發者訪問。

### 4）對應工具
Container Registry 要麼儲存和分發映象，要麼以某種方式增強現有倉庫。本質上，它是一種 Web API，允許容器引擎儲存和檢索映象。許多 Container Registry 提供介面，使容器掃描/簽名工具來增強所儲存映象的安全性。有些 Container Registry 能以特別有效的方式分發或複製影像。任何使用容器的環境都需要使用一個或多個倉庫。

該空間中的工具可以提供整合功能，以掃描、簽名和檢查它們儲存的映象。在撰寫本文時，Dragonfly 和 Harbor 是該領域中的 CNCF 專案，而 Harbor 最近成為了第一個遵循 OCI 的倉庫。主要的雲提供商都提供自己的託管倉庫，其他倉庫可以獨立部署，也可以透過 Helm 之類的工具直接部署到 Kubernetes 叢集中。

![](https://img-blog.csdnimg.cn/20210705151456633.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

![](https://img-blog.csdnimg.cn/2021070515150896.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 3. 安全和合規

### 1）是什麼

雲原生應用程式的目標是快速迭代。為了定期釋出程式碼，必須確保程式碼和操作環境是安全的，並且只能由獲得授權的工程師訪問。這一部分的工具和專案可以用安全的方式建立和執行現代應用程式。

### 2）解決什麼問題

這些工具和專案可為平臺和應用程式加強、監控和實施安全性。它們使你能在容器和 Kubernetes 環境中設定策略（用於合規性），深入瞭解存在的漏洞，捕獲錯誤配置，並加固容器和叢集。

### 3）如何解決

為了安全地執行容器，必須對其進行掃描以查詢已知漏洞，並對其進行簽名以確保它們未被篡改。Kubernetes 預設的訪問控制比較寬鬆，對於想攻擊系統的人來說， Kubernetes 叢集很容易成為目標。該空間中的工具和專案有助於增強群集，並在系統執行異常時提供工具來檢測。

### 4）對應工具

為了在動態、快速發展的環境中安全執行，我們必須將安全性視為平臺和應用程式開發生命週期的一部分。這部分的工具種類繁多，可解決安全領域不同方面的問題。大多數工具屬於以下類別：

- 審計和合規
- 生產環境強化工具的路徑
   - 程式碼掃描
   - 漏洞掃描
   - 映象簽名
- 策略制定和執行
- 網路層安全

其中的一些工具和專案很少會被直接使用。例如 Trivy、Claire 和 Notary，它們會被 Registry 或其他掃描工具所利用。還有一些工具是現代應用程式平臺的關鍵強化元件，例如 Falco 或 Open Policy Agent（OPA）。

該領域有許多成熟的供應商提供解決方案，也有很多創業公司的業務是把 Kubernetes 原生框架推向市場。在撰寫本文時，Falco、Notary/TUF 和 OPA 是該領域中僅有的 CNCF 專案。

![](https://img-blog.csdnimg.cn/20210705151549487.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705151600135.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 4. 金鑰和身份管理

### 1）是什麼

在進入到金鑰管理之前，我們首先定義一下金鑰。金鑰是用於加密或簽名資料的字串。和現實中的鑰匙一樣，金鑰鎖定（加密）資料，只有擁有正確金鑰的人才能解鎖（解密）資料。

隨著應用程式和操作開始適應新的雲原生環境，安全工具也在不斷髮展以滿足新的需求。此類別中的工具和專案可用於安全地儲存密碼和其他 secrets（例如 API 金鑰，加密金鑰等敏感資料）、從微服務環境中安全刪除密碼和 secret 等。

### 2）解決的問題
雲原生環境是高度動態的，需要完全程式設計（無人參與）和自動化的按需 secret 分發。應用程式還必須知道給定的請求是否來自有效來源（身份驗證），以及該請求是否有權執行操作（授權）。通常將其稱為 AuthN 和 AuthZ。

### 3）如何解決

每個工具或專案實施的方法不同，但他們都提供：

- 安全分發 secret 或金鑰的方法。
- 身份認證或（和）授權的服務或規範。

### 4）對應的工具
此類別中的工具可以分為兩組：

- 一些工具專注於金鑰生成、儲存、管理和輪轉。
- 另一些專注於單點登入和身份管理。

拿 Vault 來說，它是一個通用的金鑰管理工具，可管理不同型別的金鑰。而 Keycloak 則是一個身份代理工具，可用於管理不同服務的訪問金鑰。

在撰寫本文時，SPIFFE/SPIRE 是該領域中唯一的 CNCF 專案。

![](https://img-blog.csdnimg.cn/20210705151641594.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705151709615.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

供應層專注於構建雲原生平臺和應用程式的基礎，其中的工具涉及基礎設施供應、容器登錄檔以及安全性。本章節詳細介紹了雲原生全景圖的最底層。

# 執行時層

本章節我們將一起了解執行時層（runtime），這一層包含了容器在雲原生環境中執行所需的一切。即：啟動容器的程式碼，也叫執行時引擎；使容器獲得持久化儲存的工具；以及管理容器環境網路的工具。

但是注意，不要將這一層的資源與基礎設施和供應層的網路和儲存弄混淆，後者的工作是讓容器平臺執行起來。容器直接使用執行時層的工具來啟動或停止，儲存資料，以及相互通訊。

![](https://img-blog.csdnimg.cn/20210705151727918.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 1. 雲原生儲存

### 1）是什麼
儲存是存放一個應用程式持久資料的地方，也叫做持久卷（persistent volume)。輕鬆訪問持久卷對於應用程式可靠執行至關重要。通常，當我們說持久資料的時候，我們是指資料庫、訊息之類的，或其他任何在應用重新啟動時不會丟失的資訊。

### 2）解決的問題
雲原生架構具有高度的靈活性和彈性，這使得重啟應用時儲存持久資料變得很有挑戰性。容器化應用程式在擴容、縮容或自動恢復時，會不斷地建立或刪除例項，並隨著時間改變物理位置。因此，必須以與節點無關的方式提供雲原生儲存。但是，要儲存資料，就需要硬體（具體來說是磁碟）。磁碟和其他硬體一樣，受到基礎設施的限制。這是第一個大的挑戰。

第二個挑戰是儲存介面。該介面在資料中心之間可能會發生很大的變化（在以前，不同的基礎設施都有自己的儲存解決方案，並帶有自己的介面），這使得可移植性變得非常困難。

最後，由於雲的彈性，儲存必須以自動化方式進行配置，因為手動配置和自動擴充套件不相容。面臨以上這些問題，雲原生儲存就是為新的雲原生環境量身定製的。

### 3）如何解決

該類別的工具可以：

- 為容器提供雲原生儲存選項；
- 標準化容器與儲存提供者之間的介面；
- 透過備份和還原操作提供資料保護。

雲原生儲存意味著使用相容雲原生環境的容器儲存介面（也就是下一個類別中的工具），並且可以自動配置，透過消除人力瓶頸從而實現了自動擴充套件和自我恢復。

### 4）對應工具
容器儲存介面（CSI）在很大程度上使雲原生儲存變成了可能。CSI 允許使用標準 API 向容器提供檔案和塊儲存。該領域中有很多工具，既有開源的也有供應商提供的，都可利用 CSI 為容器提供按需儲存。

除了這一及其重要的功能，還有一些其他的工具和技術旨在解決雲原生空間中的儲存問題。Minio 是一個受歡迎的專案，它提供了相容 S3 的 API 用於物件儲存。Velero 之類的工具可幫助簡化 Kubernetes 叢集本身以及應用程式使用的持久化資料的備份和還原過程。

![](https://img-blog.csdnimg.cn/20210705151808590.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705151819694.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 2. 容器執行時

### 1）是什麼

前面我們提到過，容器是一組用於執行應用程式的技術約束。容器化的應用程式相信自己正在專用計算機上執行，而忽略了它們其實是與其他程式（類似於虛擬機器）共享資源。

容器執行時是執行容器化（或“隔離”）應用的軟體。如果沒有執行時，將只有容器映象——指定容器化應用程式外觀的檔案。執行時將在容器中啟動應用程式，併為其提供所需的資源。

### 2）解決的問題

容器映象（帶有應用程式規範的檔案）必須以標準化、安全和隔離的方式啟動：

- 標準化：無論它們在何處執行，都需要標準操作規則；
- 安全：訪問許可權應該要注意設定；
- 隔離：該應用程式不應影響其他應用程式或受到其他應用程式的影響（例如，位於同一位置的應用程式崩潰）。隔離基本上起到保護作用。

此外，必須為應用程式提供 CPU、儲存、記憶體等資源。

### 3）如何解決

容器執行時可以完成所有這些工作。它以標準化方式在所有環境中啟動應用程式，並設定安全邊界。安全邊界是執行時和其他工具不同的地方，CRI-O 或 gVisor 等執行時強化了它們的安全性邊界。執行時還為容器設定資源限制。沒有資源限制，應用程式可能會根據需要消耗資源，這樣就有可能佔用其他應用程式的資源。因此設定資源限制是很必要的。

### 4）對應的工具

不是所有此類別中的工具都一樣。Containerd（Docker 產品的一部分）和 CRI-O 是標準的容器執行時實現。有一些工具可以將容器的使用擴充套件到其他技術，例如 Kata，它允許將容器作為 VM 執行。其他工具旨在解決與容器相關的特定問題，例如 gVisor，它在容器和 OS 之間提供了額外的安全層。

![](https://img-blog.csdnimg.cn/20210705151852647.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

![](https://img-blog.csdnimg.cn/20210705151902345.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 3. 雲原生網路

### 1）是什麼

容器透過雲原生網路實現相互之間及和基礎設施層之間的通訊。分散式應用程式具有多個元件，這些元件將網路用於不同目的。此類別中的工具將虛擬網路覆蓋在現有網路之上，專門用於應用程式進行通訊，稱為覆蓋網路（overlay network)。

### 2）解決什麼問題

通常我們將在容器中執行的程式碼稱為應用程式，但實際上，大多數容器中僅包含大型應用程式的一小部分特定功能。諸如 Netflix 或 Gmail 之類的現代應用程式實際上由許多較小的元件組成，每個元件都在自己的容器中執行。為了使所有這些獨立的部分正常執行組成一個完整的應用，容器之間需要相互通訊。此類別的工具就提供該專用通訊網路。

此外，這些容器之間交換的訊息可能是私密的、敏感的或者非常重要的。這導致了其他要求：例如為各種元件提供隔離，檢查流量以識別網路問題的能力。在某些情況下，可能還需要擴充這些網路及網路策略（如防火牆和訪問規則），以便應用程式可以連線到容器網路外部執行的 VM 或服務。

### 3）如何解決
此類別中的專案和產品使用 CNCF 中的專案——容器網路介面（Container Network Interface, CNI）為容器化應用提供網路功能。某些工具（例如 Flannel）僅為容器提供基本連線。其他工具（如 NSX-T）提供了完整的軟體定義網路層，可為每個 Kubernetes 名稱空間建立一個隔離的虛擬網路。

容器網路至少應該能為 Pod（Kubernetes 中執行容器化應用的地方）分配 IP 地址，以允許其他程式訪問。

### 4）對應工具

CNI 標準化了網路層為 Pod 提供功能的方式，這在很大程度上實現了該領域的多樣性和創新性。為 Kubernetes 環境選擇網路非常關鍵，有許多工具可選。Weave Net，Antrea，Calico 和 Flannel 均提供有效的開源網路層，它們的功能各不相同，應根據特定需求進行選擇。

此外，許多供應商已準備好使用軟體定義網路（SDN）工具來支援和擴充套件 Kubernetes 網路，這些工具可使你深入瞭解網路流量，執行網路策略，甚至將容器網路和策略擴充套件到更廣泛的資料中心。

![](https://img-blog.csdnimg.cn/20210705151938163.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705151948849.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

本文是對執行時層的概述，該層提供了容器在雲原生環境中執行所需的工具，包括：

- 儲存：使應用程式輕鬆快速訪問執行所需的資料；
- 容器執行時：執行應用程式程式碼；
- 網路：確保容器化應用程式之間的通訊。

在下一章節中，我們將探索編排和管理層，該層處理的是如何將所有容器化應用程式作為一個組進行管理。

# 編排和管理層
編排和管理層是 CNCF 雲原生全景圖的第三層。在使用這一層的工具之前，工程師大概已經按照安全合規標準自動配置了基礎設施，併為應用程式設定了執行時（執行時層）。現在，他們必須弄清楚如何將所有應用程式元件作為整體來編排和管理。這些元件必須相互識別以進行通訊，並透過協調實現共同的目標。編排和管理層的工具可實現自動化和彈性伸縮，基於此雲原生應用程式天然具有可擴充套件性。

## 1. 編排和排程
### 1）是什麼

編排和排程是指在叢集中執行和管理容器（一種打包和運送應用的新方式）。叢集是透過網路連線的一組機器（物理機或虛擬機器均可）。

容器編排器（和排程器）與電腦上管理所有應用程式（如微軟 360、Zoom、Slack 等）的作業系統類似。作業系統執行你想使用的應用程式，並規劃哪個應用程式該在何時使用電腦的 CPU 和其他硬體資源。

雖然在一臺機器上執行所有東西很棒，但如今大多數應用程式的大小遠非一臺機器所能處理，大多數現代的應用程式都是分散式的，這就需要一種軟體能夠管理在不同機器上執行的元件。簡單來說，你需要一個“叢集作業系統”。這就是編排工具。

你可能已經注意到了，在本系列的前幾篇文章中，容器頻繁出現。容器可以讓應用程式執行在不同的環境中，這種能力是關鍵。容器編排器（大多數情況下是指 Kubernetes）也是如此。容器和 Kubernetes 是雲原生架構的核心，所以我們總是聽到別人提起它們。

### 2）解決的問題
在雲原生架構中，應用程式被分解成很多小的元件或服務，每個元件或服務都放在一個容器裡。你可能已經聽說過微服務，指的就是這種情況。現在，你擁有的不再是一個大型的應用程式，而是多個小型的服務，每個服務都需要資源、要被監控，在出現問題的時候也需要修復。對單個服務來說手動執行這些操作是可行的，但當你有上百個容器時，你就需要自動化的流程。

### 3）如何解決
容器編排器自動化了容器管理的過程。這在實際操作中意味著什麼？讓我們以 Kubernetes 來回答這個問題，因為 Kubernetes 是事實上的容器編排器。

Kubernetes 做的事情是“期望狀態協調”：將叢集中容器的當前狀態與期望狀態匹配。工程師在檔案中指定所需狀態，例如：服務 A 的 10 個例項在三個節點（即：機器）上執行，可訪問 B 資料庫，等等。該狀態需持續與實際狀態進行比較。如果預期狀態與實際狀態不匹配，Kubernetes 會透過建立或銷燬物件來進行協調（例如：如果某個容器崩潰了，Kubernetes 會啟動一個新的容器）。

簡而言之，Kubernetes 允許你將叢集視為一臺計算機。它僅關注環境併為你處理實現細節。

### 4）對應工具

Kubernetes 與其他容器編排器（Docker Swarm，Mesos 等）都是編排排程工具，其基本目的是允許將多個不同的計算機作為一個資源池進行管理，並以宣告式的方式管理它們，即不必告訴 Kubernetes 如何做，而是提供要完成的工作的定義。這樣可以在一個或多個 YAML 檔案中維護所需的狀態，並將其應用於其他 Kubernetes 叢集。然後，編排器本身會建立缺失的內容或刪除無需存在的東西。

雖然 Kubernetes 不是 CNCF 託管的唯一編排器（Crossplane 和 Volcano 是另外兩個孵化專案），但它是最常用的，專案也有大量積極的維護者。

![](https://img-blog.csdnimg.cn/20210705152035822.png#pic_center)
![](https://img-blog.csdnimg.cn/20210705152045994.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 2. 協調和服務發現

### 1）是什麼
現代應用程式由多個單獨的服務組成，這些服務之間需要相互協作才能為終端使用者提供價值。要進行協作，這些服務透過網路進行通訊（我們在執行時層已經討論過）。要通訊，服務需要能相互定位。服務發現就是解決這個問題的。

### 2）解決的問題

雲原生架構是動態的，總是在不斷變化。當一個節點上的某個容器崩潰時，一個新的容器會在另一個節點上啟動來替代它。或者，當一個應用程式擴充套件時，它的副本會散佈在整個網路中。沒有一個地方可以提供特定服務，一切的位置在不斷變化。此類別的工具跟蹤網路中的服務，以便服務在需要時可以相互查詢。

### 3）如何解決

服務發現工具可提供一個公共的位置來查詢和識別單個的服務。該類別中有兩種工具：

- 服務發現引擎：類似資料庫的工具，儲存的資訊包括：存在什麼哪些服務以及如何定位它們；
- 名稱解析工具（如 CoreDNS）：接收服務位置請求並返回網路地址資訊。

注：在 Kubernetes 中，為了使 Pod 可達，引入了一個稱為“Service”的新抽象層。Service 為動態變化的 Pod 組提供了單一穩定的地址。

請注意，“Service” 在不同的語境中有不同的含義，可能會造成混淆。“services” 通常指位於容器/Pod 中的服務，是實際應用程式中具有特定功能的應用元件或微服務（例如：iPhone 的面部識別演算法）。

而 Kubernetes 的 Service 是一種抽象，可幫助 Pod 相互查詢和定位。它是服務（功能上的）作為程式或 Pod 的入口點。在 Kubernetes 中，當你建立了一個 Service （抽象），你就建立了一組 Pod，這些 Pod 一起透過單一 endpoint （入口）提供一個服務（功能）。

### 4）對應工具

隨著分散式系統變得越來越普遍，傳統的 DNS 流程和負載均衡器已經無法跟上不斷變化的 Endpoint 資訊，因此有了服務發現工具。它們可用來處理快速對自身進行註冊和登出的各個應用程式例項。一些服務發現工具（例如 etcd 和 CoreDNS）是 Kubernetes 原生的，其他一些工具有自定義的庫或工具讓服務有效執行。CoreDNS 和 etcd 是 CNCF 專案，並且內建在 Kubernetes 中。

![](https://img-blog.csdnimg.cn/20210705152119706.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705152129606.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 3. 遠端程式呼叫

### 1）是什麼

遠端程式呼叫（RPC，Remote Procedure Call）是一種使應用程式相互通訊的特殊技術。它代表了應用程式相互之間構建通訊的一種方法。

### 2）解決的問題
現代應用程式由眾多單獨的服務組成，這些服務必須透過通訊才能進行協作。RPC 是應用程式之間進行通訊的一種方法。

### 3）如何解決

RPC 可以一種緊耦合且高度自覺的方式處理服務之間的通訊。它允許頻寬高效的通訊，並且許多語言支援 RPC 介面實現。RPC 不是解決此問題的唯一方法，也不是最常見的方法。

### 4）對應工具
RPC 為服務之間的通訊提供了高度結構化且緊密耦合的介面。gRPC 是非常流行的 RPC 實現，已被 CNCF 採用。

![](https://img-blog.csdnimg.cn/20210705152203553.png#pic_center)
![](https://img-blog.csdnimg.cn/20210705152211783.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 4. 服務代理

### 1）是什麼
服務代理工具用於攔截進出某個服務的流量，對其應用一些邏輯，然後轉發該流量到另一個服務。服務代理的本質是一種“中間人”，收集網路流量的資訊並對其應用規則。簡單如充當負載均衡器將流量轉發到單個應用程式，也可複雜如並排執行的代理網格，由單個的容器化應用程式處理所有網路連線。

服務代理本身很有用，尤其是在將流量從更廣泛的網路引到 Kubernetes 叢集時。服務代理同時也為其他系統（如 API 閘道器或服務網格）搭建了基礎，我們將在下文討論。

### 2）解決的問題
應用程式應以受控方式傳送和接收網路流量。為了跟蹤流量並對其進行轉換或重定向，我們需要收集資料。傳統上，開啟資料收集和網路流量管理的程式碼嵌入在每個應用程式中。服務代理可以使我們“外部化”該功能，使其無需再存在於應用程式中，而是嵌入到平臺層（應用程式執行的地方）。

這是非常強大的功能，因為它使開發人員可以完全專注於編寫應用程式邏輯，而處理流量的通用任務由平臺團隊管理（這是平臺團隊的首要職責）。透過從單個公共位置集中分配和管理全域性所需的服務功能（例如路由或 TLS 終止），服務之間的通訊將更加可靠，安全和高效。

### 3）如何解決

代理充當使用者和服務之間或不同服務之間的守門員。透過這種獨特的定位，他們可以洞悉正在發生的通訊型別。根據洞察，他們可以確定將特定請求傳送到哪裡，甚至完全拒絕該請求。

代理收集關鍵資料，管理路由（在服務之間平均分配流量或在某些服務發生故障時重新路由），加密連線和快取內容（減少資源消耗）。

### 4）對應工具

服務代理的工作原理是攔截服務之間的流量，對它們執行一些邏輯，然後可能會允許流量繼續前進。透過將一組集中控制的功能放入此代理，管理員可以完成幾件事。他們可以收集有關服務間通訊的詳細指標，防止服務過載，並將其他通用標準應用於服務。服務代理是服務網格等其他工具的基礎，因為它們提供了對所有網路流量實施更高階別策略的方法。

請注意，CNCF 將負載均衡器和 ingress provider 包括在此類別中。Envoy，Contour 和 BFE 都是 CNCF 專案。

![](https://img-blog.csdnimg.cn/20210705152346775.png#pic_center)
![](https://img-blog.csdnimg.cn/20210705152405518.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 5. API 閘道器

### 1）是什麼

人們通常透過網頁或（桌面）應用程式之類的 GUI（圖形使用者介面）與計算機程式進行互動，計算機則透過 API（應用程式程式設計介面）相互進行互動。但是，請勿將 API 與 API 閘道器混淆。

API 閘道器允許組織將關鍵功能（例如授權或限制應用程式之間的請求數量）移動到集中管理的位置。它還用作（通常是外部的）API 使用者的通用介面。

透過 API 閘道器，組織可以集中控制（限制或啟用）應用程式之間的互動並跟蹤它們，從而實現 拒絕請求、身份驗證之類的功能，並防止服務被過度使用（也稱為速率限制）。

### 2）解決的問題

儘管大多數容器和核心應用程式都具有 API，但 API 閘道器不僅僅是 API。API 閘道器簡化了組織管理規則和將規則應用於所有互動的方式。

API 閘道器允許開發人員編寫和維護較少的自定義程式碼。他們還使團隊能夠檢視和控制使用者與應用程式本身之間的互動。

### 3）如何解決

API 閘道器位於使用者和應用程式之間。它充當中介，將來自使用者的訊息（請求）轉發給適當的服務。但是在交出請求之前，它會評估使用者的請求是否被允許，並詳細記錄發出請求的人以及發出的請求數量。

簡而言之，API 閘道器為應用程式使用者提供了具有通用使用者介面的單入口點。它還可以將原本在應用程式中實現的任務移交給閘道器，從而為開發人員節省時間和金錢。

### 4）對應工具
像該層中的許多類別一樣，API 閘道器從應用程式中刪除自定義程式碼，並將其帶入中央系統。API 閘道器的工作原理是攔截對後端服務的呼叫，執行某種增值活動，例如驗證授權、收集指標或轉換請求，然後執行它認為適當的操作。API 閘道器是一組下游應用程式的通用入口點，同時為團隊提供了可以注入業務邏輯以處理授權，速率限制和拒絕請求的地方。它們使應用開發者可以從客戶那裡提取對下游 API 的更改，並將新增新客戶之類的任務交給閘道器。

![](https://img-blog.csdnimg.cn/2021070515244478.png#pic_center)
![](https://img-blog.csdnimg.cn/20210705152454699.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 6. 服務網格
### 1）是什麼

如果你已經瞭解了一些雲原生相關的知識，則“服務網格”這個術語可能已經聽說過。最近服務網格引起了很多關注。TNS 的長期貢獻者 Janakiram MSV 表示，“在 Kubernetes 之後，服務網格技術已成為雲原生技術棧中最關鍵的部分。” 服務網格管理服務之間的流量（即通訊）。它們使平臺團隊能夠無需更改任何程式碼即可在叢集內執行的所有服務之間統一新增可靠性，可觀察性和安全性功能。

### 2）解決什麼問題
在雲原生環境中，我們要處理很多服務，這些服務都需要通訊。這意味著在本來不可靠且通常很慢的網路上需要來回傳輸更多流量。為了應對這些新挑戰，工程師必須實施額外的功能。在服務網格之前，必須將該功能編碼到每個單獨的應用程式中。這些程式碼通常會成為技術債，並導致失敗或漏洞。

### 3）如何解決

服務網格在平臺層的所有服務之間統一增加了可靠性，可觀察性和安全性，而無需觸及應用程式程式碼。它們與任何程式語言相容，使開發團隊可以專注於編寫業務邏輯。

注：傳統上必須將這些服務網格功能編碼到每個服務中，因此每次釋出或更新新服務時，開發人員都必須確保這些功能也能使用，會導致很多人為錯誤。事實上，開發人員更喜歡專注於業務邏輯（產生價值的功能），而不是建立可靠性，可觀察性和安全性功能。但對於平臺所有者來說，可靠性、可觀察性和安全是核心功能，對於他們所做的一切至關重要。讓開發人員負責新增平臺所有者需要的功能本身很難。服務網格和 API 閘道器解決了這個問題，因為它們是由平臺所有者實現並普遍應用於所有服務的。

### 4）對應工具

服務網格透過服務代理將叢集上執行的所有服務繫結在一起，從而建立了服務的網格。這些是透過服務網格控制平面進行管理和控制的。服務網格允許平臺所有者在不要求開發人員編寫自定義邏輯的情況下執行常見操作或在應用程式上收集資料。本質上，服務網格是透過向服務代理的網路或網格提供命令和控制訊號來管理服務間通訊的基礎結構層。它的能力在於無需修改應用程式即可提供關鍵系統功能。

某些服務網格將通用服務代理（請參見上文）用於其資料平面。另外一些則使用專用代理。例如，Linkerd 使用 Linkerd2-proxy “微型代理”來獲得效能和資源消耗方面的優勢。這些代理透過邊車（sidecar) 統一地附加到每個服務上。Sidecar 是指代理在自己的容器中執行但存在於同一個 Pod 中，就像摩托車邊車一樣，它是一個單獨的模組，附著在摩托車上。

服務網格提供了許多有用的功能，包括顯示詳細指標，加密所有流量，限制服務可授權的操作，為其他工具提供額外外掛等等。

更多詳細資訊，請檢視服務網格介面規範：https://smi-spec.io/。

![](https://img-blog.csdnimg.cn/20210705152530988.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705152540804.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

## 7. 小結

編排和管理層的工具旨在將獨立的容器化應用作為一個組進行管理。編排和排程工具可以看作是叢集作業系統，用於管理整個叢集中的容器化應用程式。協調和服務發現，服務代理和服務網格確保服務可以找到彼此並進行有效通訊，彼此協作以成為一個流暢的應用程式。API 閘道器是一個附加層，可對服務通訊加以更多控制，尤其是對外部應用程式之間的通訊。在下一章節中，我們將討論應用程式定義和開發層——CNCF 全景圖的最後一層。它涵蓋資料庫、資料流和訊息傳遞、應用程式定義和映象構建，以及持續整合和交付。

# 應用程式定義和開發層

現在我們來到了雲原生全景圖的最上層。應用程式定義和開發層，顧名思義，聚焦在幫助工程師構建應用程式並使其執行的工具上。本文前面的內容都是關於構建可靠安全的環境以及提供所有必需的應用程式依賴，應用程式定義和開發層則是關於構建軟體。

## 1. 資料庫

### 1）是什麼

資料庫管理系統是一個應用程式，可幫助其他應用程式高效地儲存和檢索資料。

資料庫能保障資料儲存，僅授權的使用者能訪問資料，並且允許使用者透過專門的請求來檢索資料。儘管資料庫型別繁多，但它們的總體目標都是相同的。

### 2）解決的問題

大多數應用程式都需要有效的方式來儲存和檢索資料，並且保證資料安全。資料庫使用成熟的技術以結構化的方式進行此操作。

### 3）如何解決

資料庫提供儲存和檢索應用程式資料的通用介面。開發人員使用這些標準介面，並用一種簡單的查詢語言來儲存、查詢和檢索資訊。同時，資料庫允許使用者連續備份和儲存資料以及加密和管理資料訪問許可權。

### 4）對應工具

我們已經瞭解了資料庫管理系統是一種用於儲存和檢索資料的應用程式。它使用一種通用的語言和介面，並且可以被多種語言和框架輕鬆使用。

常見的兩種資料庫型別為：結構化查詢語言（SQL）資料庫和 NoSQL 資料庫。應用程式該使用哪種資料庫應該由其需求來驅動。

Kubernetes 支援有狀態的應用程式，近年來使用 Kubernetes 的使用越來越廣泛，我們已經看到了利用容器化技術的新一代資料庫。這些新的雲原生資料庫旨在將 Kubernetes 的擴充套件性和可用性優勢引入資料庫。YugaByte 和 Couchbase 之類的工具是典型的雲原生資料庫，Vitess 和 TiKV 是該領域的 CNCF 專案。

注意：檢視此類別時會發現以 DB 結尾的多個名稱（例如 MongoDB、CockroachDB、FaunaDB），你可能會猜測它們代表資料庫。還有以 SQL 結尾的各種名稱（例如 MySQL 或 MemSQL）。一些是已經適應了雲原生環境的“老派”資料庫，還有一些是相容 SQL 的 NoSQL 資料庫，例如 YugaByte 和 Vitess。

![](https://img-blog.csdnimg.cn/20210705152622223.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705152634308.png#pic_center)

## 2. 資料流和訊息傳遞

### 1）是什麼

資料流和訊息傳遞工具透過在系統之間傳輸訊息（即事件）來實現服務到服務的通訊。單個服務連線到訊息傳遞服務以釋出事件和（或）從其他服務讀取訊息。這種動態變化創造了一個環境，在這個環境中單個應用要麼是釋出者，即可編寫事件；要麼是訂閱事件的訂閱者，或者更可能是兩者兼而有之。

### 2）解決的問題

隨著服務激增，應用程式環境變得越來越複雜，應用程式之間的通訊編排也更具挑戰性。資料流或訊息平臺提供了一箇中心位置來發布和讀取系統中發生的所有事件，從而使應用程式可以一起工作，而不必相互瞭解。

### 3）如何解決

當一個服務執行其他服務應該知道的事情時，它會將事件“釋出”到資料流或訊息傳遞工具。需要了解這些事件型別的服務將訂閱並監視資料流或訊息傳遞工具。這就是“釋出-訂閱”的本質。

透過引入管理通訊的“中間層”可以使服務彼此解耦。服務只是監視事件、採取行動併發布新事件，這樣能建立高度分離的體系結構。在此體系結構中，服務可以協作而無需彼此瞭解。這種解耦使工程師能夠新增新功能，而無需更新下游應用程式（消費者）或傳送大量查詢。系統的解耦程度越高，更改的靈活性和適應性就越高，而這正是工程師在系統中所追求的。

### 4）對應工具

資料流和訊息傳遞工具早在雲原生技術成為現實之前就已經存在了。為了集中管理關鍵業務事件，組織建立了大型的企業級服務匯流排。但是，當我們在雲原生環境中談論資料流和訊息傳遞時，通常是指 NATS、RabbitMQ、Kafka 或雲提供的訊息佇列之類的工具。

訊息傳遞和資料流傳輸系統為編排系統進行通訊提供了一箇中心位置。訊息匯流排提供了所有應用程式都可以訪問的公共位置，應用程式都可以透過釋出訊息來告訴其服務它們在做什麼，或者透過訂閱訊息來檢視正在發生的事情。

NATS 和 Cloudevents 專案都是這個領域的孵化專案，NATS 提供了一個成熟的訊息傳遞系統，而 Cloudevents 則致力於標準化系統之間的訊息格式。Strimzi，Pravega 和 Tremor 是沙盒專案，每個專案都針對資料流和訊息傳遞的獨特用例進行了量身定製。

![](https://img-blog.csdnimg.cn/20210705152702188.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

![](https://img-blog.csdnimg.cn/20210705152713386.png#pic_center)
## 3. 應用程式定義和映象構建

### 1）是什麼

應用程式定義和映象構建是一個廣泛的類別，可以分為兩個主要的子類別：

- 聚焦於開發的工具：可幫助將應用程式程式碼構建到容器和 Kubernetes 中。
- 聚焦於運維的工具：以標準化的方式部署應用。

無論是加快或簡化開發環境，提供標準化的方式來部署第三方應用程式，還是簡化編寫新的 Kubernetes 擴充套件的過程，此類別的工具都可以最佳化 Kubernetes 開發和運維人員的體驗。

### 2）解決的問題

Kubernetes（或者容器化環境）非常靈活且功能強大。這種靈活性也帶來了複雜性，主要體現在對於各種新用例有眾多配置選項。開發人員必須將程式碼容器化，並在類生產環境中進行開發。在快速的釋出計劃週期下，運維人員需要以一種標準化的方法來將應用程式部署到容器環境中。

### 3）如何解決

該領域的工具旨在解決開發或運維人員面臨的一些挑戰。對於開發者，有一些工具可以簡化擴充套件 Kubernetes 的過程以構建、部署和連線應用程式。許多專案和產品可以儲存或部署預打包的應用程式，使運維人員可以快速部署 Kafka 之類的流服務或安裝 Linkerd 之類的服務網格。

開發雲原生應用程式帶來了一系列全新的挑戰，因此需要大量多樣化的工具來簡化應用程式的構建和部署。當你需要解決環境中的開發和運維問題時，可以看看此類別中的工具。

### 4）對應的工具
應用程式定義和構建工具涵蓋了廣泛的功能，比如使用 KubeVirt 將 Kubernetes 擴充套件到虛擬機器，或使用 Telepresence 之類的工具將開發環境移植到 Kubernetes 中來加速應用程式開發等。從整體上講，該領域中的工具可以解決開發人員面臨的正確編寫、打包、測試或執行自定義應用程式的問題，也可以解決運維人員面臨的部署和管理應用程式的問題。

Helm 是該類別中唯一一個畢業的專案，為許多應用程式部署模式奠定了基礎。Helm 允許 Kubernetes 使用者部署和自定義一些流行的第三方應用程式，Artifact Hub（CNCF 沙箱專案）和 Bitnami 等專案已採用 Helm 來提供精選的應用程式目錄。Helm 也足夠靈活，允許使用者自定義自己的應用程式部署。

Operator Framework 是一個孵化專案，旨在簡化構建和部署 Operator 的過程。Operator 不在本文討論範圍之內，但請注意，它類似於 Helm，有助於部署和管理應用程式。Cloud Native Buildpacks 是另一個孵化專案，旨在簡化將應用程式程式碼構建到容器中的過程。

![](https://img-blog.csdnimg.cn/20210705152745219.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705152754925.png#pic_center)

## 4. 持續整合和持續交付

### 1）是什麼

持續整合（CI）和持續交付（CD）工具可透過嵌入式質量保證實現快速高效的開發過程。CI 透過立即構建和測試程式碼來自動化程式碼變更，確保生成可部署的製品。CD 則更進一步，推動該製品進入部署階段。

成熟的 CI/CD 系統會監視原始碼中的變更，自動構建和測試程式碼，然後將其從開發階段轉移到生產階段。在此過程中，CI/CD 系統必須透過各種測試或驗證來決定該過程是繼續還是失敗。

### 2）解決的問題

構建和部署應用程式是一個困難重重且容易出錯的過程，特別是當過程中涉及很多人為干預和手動步驟時。如果不將程式碼整合到程式碼庫中，開發人員在軟體上花的時間越長，識別錯誤所花費的時間就越長，問題修復也就越困難。透過定期整合程式碼，可以及早發現錯誤並更輕鬆地排除故障。畢竟，在幾行程式碼中查詢錯誤比在幾百行程式碼中查詢錯誤要容易得多。

儘管 Kubernetes 之類的工具為執行和管理應用程式提供了極大的靈活性，它們也為 CI/CD 工具帶來了新的挑戰和機遇。雲原生 CI/CD 系統能夠利用 Kubernetes 本身來構建、執行和管理 CI/CD 流程（通常稱為流水線）。Kubernetes 還提供應用程式執行狀況的資訊，從而使雲原生 CI/CD 工具能夠更輕鬆地確定給定的變更是否成功，是否需要回滾。

### 3）如何解決

CI 工具可確保開發人員引入的任何程式碼更改或更新都能自動、連續地與其他更改進行構建、驗證並整合。開發人員每次新增更新時都會觸發自動測試，確保只有良好的程式碼才能將其匯入系統。CD 擴充套件了 CI，能將 CI 流程的結果推送到類生產和生產環境中。

假設開發人員更改了 Web 應用的程式碼。CI 系統會看到程式碼更改，然後構建並測試該 Web 應用的新版本。CD 系統獲取該新版本，並將其部署到開發、測試、預生產以及最終生產環境中。在流程的每個步驟之後測試已部署的應用程式時，它會執行此操作。這些系統一起構成了該 Web 應用的 CI/CD 管道。

### 4）對應工具

隨著時間的流逝，市面上已經有了許多工具來幫助將程式碼從儲存庫移至執行最終應用程式的生產環境。像大多數其他計算領域一樣，雲原生開發的到來改變了 CI/CD 系統。類似 Jenkins（可能是市場上使用最廣泛的 CI 工具）的傳統工具已經透過完善迭代，以更好地適應 Kubernetes 生態系統。Flux 和 Argo 等公司率先開發了一種稱為 GitOps 的持續交付的新方法。

通常，該領域的專案和產品是：

- CI 系統；
- CD 系統；
- 幫助 CD 系統確定程式碼是否準備好投入生產的工具；
- 前三者的合集（Spinnaker 和 Argo 就是如此）。

Argo 和 Brigade 是該領域中僅有的 CNCF 專案，但是你可以找到由持續交付基金會（Continuous Delivery Foundation）託管的更多專案。在此空間中尋找工具，可以幫助組織自動化生產路徑。

![](https://img-blog.csdnimg.cn/20210705152828932.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
![](https://img-blog.csdnimg.cn/20210705152838186.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)
## 5. 小結

應用程式定義和開發層中的工具使工程師能夠構建雲原生應用程式。該層的工具包括：

- 資料庫：儲存和檢索資料。
- 資料流和訊息傳遞工具：實現相互分離、精心設計的架構。
- 應用程式定義和映象構建工具：包含可改善開發人員和操作員體驗的多種技術。
- CI/CD 工具：確保程式碼處於可部署狀態，並幫助工程師及早發現錯誤，從而確保程式碼質量。

# 託管 K8s 和 PaaS 解決的問題

在上面的內容中，我們討論了 CNCF 雲原生全景圖的各層：供應層、執行時層、編排管理層以及應用定義和開發層。本章節我們將聚焦在平臺層。

正如我們在本文中看到的那樣，每個類別都解決了特定的問題。僅僅儲存並不能提供管理應用程式所需的全部功能，你還需要編排管理、容器執行時、服務發現、網路、API 閘道器等工具。平臺將來自不同層的工具捆綁在一起，以解決更大的問題。

平臺裡其實沒有新的工具。你當然可以構建自己的平臺，事實上，許多組織都這樣做。但是，可靠、安全地配置和微調不同的模組，同時確保始終更新所有技術並修補漏洞，這不是一件容易的事。你需要一支專門的團隊來構建和維護它。如果沒有所需的專業知識，那麼使用平臺可能會更好。對於某些組織，尤其是工程團隊規模較小的組織，平臺是採用雲原生技術的唯一方法。

你可能已經注意到了，所有的平臺都是圍繞 Kubernetes 來演化的，因為 Kubernetes 是雲原生技術棧的核心。

## 1. Kubernetes 發行版
### 1）是什麼

發行版是指供應商以 Kubernetes 為核心（採用未經修改的開原始碼，儘管有些人對其進行了修改），並將其打包以進行重新發行。通常這個過程需要查詢和驗證 Kubernetes 軟體，並提供叢集安裝和升級的機制。許多 Kubernetes 發行版都包含其他閉源或開源的應用程式。

### 2）解決的問題

開源 Kubernetes 並未指定特定的安裝工具，而是將許多設定配置選項提供給使用者。此外，有限的社群資源（包括社群論壇、StackOverflow、Slack 或 Discord 等）已經不能解決所有的問題。

隨著 Kubernetes 的普及，Kubernetes 的使用變得越來越容易，但是查詢和使用開源安裝程式可能會面臨挑戰。使用者需要了解使用哪個版本，在何處獲取，以及特定元件是否能相容。此外，還需要決定叢集上部署什麼軟體，要使用哪些設定來確保平臺的安全性、穩定性和高效能。所有這些都需要豐富的 Kubernetes 專業知識，而這些知識可能並不容易獲得。

### 3）如何解決

Kubernetes 發行版提供了一種安裝 Kubernetes 的可靠方式，並提供了合理的預設值以建立更好、更安全的操作環境。

Kubernetes 發行版為供應商和專案提供了所需的掌控度和可預測性，以幫助他們支援客戶部署、維護和升級 Kubernetes 叢集。

這種可預測性使發行版提供商在客戶遇到生產問題時可為其提供支援。發行版常常提供經過測試和受支援的升級路徑，使使用者的 Kubernetes 叢集保持最新的版本。此外，發行版通常提供可在 Kubernetes 上部署的軟體，從而使其更易於使用。

### 4）對應的工具

如果你已經安裝了 Kubernetes，那你可能已經使用了 kubeadm 之類的工具來啟動和執行叢集。即便如此，你可能還需要 CNI（容器網路介面）來安裝和配置它。然後，你可能已經新增了一些儲存類，一個處理日誌訊息的工具，可能還需要個 ingress controller，以及更多其他的工具。Kubernetes 發行版將自動執行部分或全部設定。它還將根據自己對最佳實踐或智慧預設值的理解提供配置設定。此外，大多數發行版都將捆綁一些經過測試的擴充套件或附件，以確保使用者可以儘快使用新叢集。

我們以 Kublr 為例。它以 Kubernetes 為核心，主要捆綁了來自供應層、執行時層、編排管理層的工具。所有模組都預先配置了一些選項並且開箱即用。不同的平臺聚焦不同的功能。就 Kublr 而言，重點是在運維方面，而其他平臺則可能聚焦在開發工具上。

此類別中有很多工具選項。如下圖所示，企業可以選擇和供應商達成技術合作，比如國外的 Canonical、VMware、Mirantis、SUSE，國內的網易、火山引擎和京東，它們都可以提供出色的開源和商業工具，建議在評估發行版時仔細

必看！史上最全雲原生全景圖解讀攻略來啦

相關文章