史上最全雲原生全景圖解讀攻略

帶你了解雲原生技術圖譜

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

如果把它拆開來，一次隻分析一小塊内容，你會發現整個全景圖沒有那麼複雜。事實上，該全景圖按照功能有序地組織在一起，一旦你了解了每個類别代表的内容，你就可以輕松遊走于全景圖中。​本文我們首先把整個全景圖拆解開來，并對整個全景圖進行綜述，接着聚焦在每一層（or 每一列），對每個類别解決的問題和原理進行了更為詳細的解讀。​

1. 雲原生全景圖的 4 層

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

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

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）是監控各層的工具，平台則将各層中不同的技術捆綁為一個解決方案。​

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 分發等。

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

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）。此類别中的大多數工具都提供開源和付費版本。​[外鍊圖檔轉存失敗,源站可能有防盜鍊機制,建議将圖檔儲存下來直

2. Container Registry

​

1）是什麼

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

• 容器是執行流程的一組技術限制。容器内啟動的程序會相信它們正在自己的專用計算機上運作，而不是在與其他程序（類似于虛拟機）共享的計算機上運作。簡而言之，容器可以使你在任何環境中都能控制自己的代碼運作。
• 鏡像是運作容器及其過程所需的一組存檔檔案。你可以将其視為模闆的一種形式，可以在其上建立無限數量的容器。
• 倉庫是存儲鏡像的空間。

回到 Container Registry，這是分類和存儲倉庫的專用 Web 應用程式。​鏡像包含執行程式（在容器内）所需的資訊，并存儲在倉庫中，倉庫被分類和分組。建構、運作和管理容器的工具需要通路（通過引用倉庫）這些鏡像。​

2）解決的問題

雲原生應用程式被打包後以容器的方式運作。Container Registry 負責存儲和提供這些容器鏡像。​

3）如何解決

通過在一個地方集中存儲所有容器鏡像，這些容器鏡像可以很容易地被應用程式的開發者通路。​

4）對應工具

Container Registry 要麼存儲和分發鏡像，要麼以某種方式增強現有倉庫。本質上，它是一種 Web API，允許容器引擎存儲和檢索鏡像。許多 Container Registry 提供接口，使容器掃描/簽名工具來增強所存儲鏡像的安全性。有些 Container Registry 能以特别有效的方式分發或複制圖像。任何使用容器的環境都需要使用一個或多個倉庫。​該空間中的工具可以提供內建功能，以掃描、簽名和檢查它們存儲的鏡像。在撰寫本文時，Dragonfly 和 Harbor 是該領域中的 CNCF 項目，而 Harbor 最近成為了第一個遵循 OCI 的倉庫。主要的雲提供商都提供自己的托管倉庫，其他倉庫可以獨立部署，也可以通過 Helm 之類的工具直接部署到 Kubernetes 叢集中。​

3. 安全和合規

​

1）是什麼

​雲原生應用程式的目标是快速疊代。為了定期釋出代碼，必須確定代碼和操作環境是安全的，并且隻能由獲得授權的工程師通路。這一部分的工具和項目可以用安全的方式建立和運作現代應用程式。

2）解決什麼問題

這些工具和項目可為平台和應用程式加強、監控和實施安全性。它們使你能在容器和 Kubernetes 環境中設定政策（用于合規性），深入了解存在的漏洞，捕獲錯誤配置，并加強容器和叢集。​

3）如何解決

​為了安全地運作容器，必須對其進行掃描以查找已知漏洞，并對其進行簽名以確定它們未被篡改。Kubernetes 預設的通路控制比較寬松，對于想攻擊系統的人來說， Kubernetes 叢集很容易成為目标。該空間中的工具和項目有助于增強群集，并在系統運作異常時提供工具來檢測。​

4）對應工具

​為了在動态、快速發展的環境中安全運作，我們必須将安全性視為平台和應用程式開發生命周期的一部分。這部分的工具種類繁多，可解決安全領域不同方面的問題。大多數工具屬于以下類别：​

• 審計和合規
• 生産環境強化工具的路徑
• 代碼掃描
• 漏洞掃描
• 鏡像簽名
• 政策制定和執行
• 網絡層安全

其中的一些工具和項目很少會被直接使用。例如 Trivy、Claire 和 Notary，它們會被 Registry 或其他掃描工具所利用。還有一些工具是現代應用程式平台的關鍵強化元件，例如 Falco 或 Open Policy Agent（OPA）。​該領域有許多成熟的供應商提供解決方案，也有很多創業公司的業務是把 Kubernetes 原生架構推向市場。在撰寫本文時，Falco、Notary/TUF 和 OPA 是該領域中僅有的 CNCF 項目。​

4. 密鑰和身份管理

​

1）是什麼

在進入到密鑰管理之前，我們首先定義一下密鑰。密鑰是用于加密或簽名資料的字元串。和現實中的鑰匙一樣，密鑰鎖定（加密）資料，隻有擁有正确密鑰的人才能解鎖（解密）資料。​随着應用程式和操作開始适應新的雲原生環境，安全工具也在不斷發展以滿足新的需求。此類别中的工具和項目可用于安全地存儲密碼和其他 secrets（例如 API 密鑰，加密密鑰等敏感資料）、從微服務環境中安全删除密碼和 secret 等。​

2）解決的問題

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

3）如何解決

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

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

4）對應的工具

此類别中的工具可以分為兩組：​

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

拿 Vault 來說，它是一個通用的密鑰管理工具，可管理不同類型的密鑰。而 Keycloak 則是一個身份代理工具，可用于管理不同服務的通路密鑰。​在撰寫本文時，SPIFFE/SPIRE 是該領域中唯一的 CNCF 項目。​

供應層專注于建構雲原生平台和應用程式的基礎，其中的工具涉及基礎設施供應、容器系統資料庫以及安全性。本章節詳細介紹了雲原生全景圖的最底層。​

運作時層

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

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

1. 雲原生存儲

​

1）是什麼

存儲是存放一個應用程式持久資料的地方，也叫做持久卷（persistent volume)。輕松通路持久卷對于應用程式可靠運作至關重要。通常，當我們說持久資料的時候，我們是指資料庫、消息之類的，或其他任何在應用重新啟動時不會丢失的資訊。​

2）解決的問題

雲原生架構具有高度的靈活性和彈性，這使得重新開機應用時存儲持久資料變得很有挑戰性。容器化應用程式在擴容、縮容或自動恢複時，會不斷地建立或删除執行個體，并随着時間改變實體位置。是以，必須以與節點無關的方式提供雲原生存儲。但是，要存儲資料，就需要硬體（具體來說是磁盤）。磁盤和其他硬體一樣，受到基礎設施的限制。這是第一個大的挑戰。​第二個挑戰是存儲接口。該接口在資料中心之間可能會發生很大的變化（在以前，不同的基礎設施都有自己的存儲解決方案，并帶有自己的接口），這使得可移植性變得非常困難。​最後，由于雲的彈性，存儲必須以自動化方式進行配置，因為手動配置和自動擴充不相容。面臨以上這些問題，雲原生存儲就是為新的雲原生環境量身定制的。​

3）如何解決

​該類别的工具可以：​

• 為容器提供雲原生存儲選項；
• 标準化容器與存儲提供者之間的接口；
• 通過備份和還原操作提供資料保護。

雲原生存儲意味着使用相容雲原生環境的容器存儲接口（也就是下一個類别中的工具），并且可以自動配置，通過消除人力瓶頸進而實作了自動擴充和自我恢複。​

4）對應工具

容器存儲接口（CSI）在很大程度上使雲原生存儲變成了可能。CSI 允許使用标準 API 向容器提供檔案和塊存儲。該領域中有很多工具，既有開源的也有供應商提供的，都可利用 CSI 為容器提供按需存儲。​除了這一及其重要的功能，還有一些其他的工具和技術旨在解決雲原生空間中的存儲問題。Minio 是一個受歡迎的項目，它提供了相容 S3 的 API 用于對象存儲。Velero 之類的工具可幫助簡化 Kubernetes 叢集本身以及應用程式使用的持久化資料的備份和還原過程。​

2. 容器運作時

​

1）是什麼

​前面我們提到過，容器是一組用于執行應用程式的技術限制。容器化的應用程式相信自己正在專用計算機上運作，而忽略了它們其實是與其他程序（類似于虛拟機）共享資源。​容器運作時是執行容器化（或“隔離”）應用的軟體。如果沒有運作時，将隻有容器鏡像——指定容器化應用程式外觀的檔案。運作時将在容器中啟動應用程式，并為其提供所需的資源。​

2）解決的問題

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

• 标準化：無論它們在何處運作，都需要标準操作規則；
• 安全：通路權限應該要注意設定；
• 隔離：該應用程式不應影響其他應用程式或受到其他應用程式的影響（例如，位于同一位置的應用程式崩潰）。隔離基本上起到保護作用。

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

3）如何解決

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

4）對應的工具

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

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 網絡，這些工具可使你深入了解網絡流量，執行網絡政策，甚至将容器網絡和政策擴充到更廣泛的資料中心。​

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

• 存儲：使應用程式輕松快速通路運作所需的資料；
• 容器運作時：執行應用程式代碼；
• 網絡：確定容器化應用程式之間的通信。

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

編排和管理層

編排和管理層是 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 是另外兩個孵化項目），但它是最常用的，項目也有大量積極的維護者。​

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 中。​

3. 遠端程序調用

​

1）是什麼

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

2）解決的問題

現代應用程式由衆多單獨的服務組成，這些服務必須通過通信才能進行協作。RPC 是應用程式之間進行通信的一種方法。​

3）如何解決

​RPC 可以一種緊耦合且高度自覺的方式處理服務之間的通信。它允許帶寬高效的通信，并且許多語言支援 RPC 接口實作。RPC 不是解決此問題的唯一方法，也不是最常見的方法。​

4）對應工具

RPC 為服務之間的通信提供了高度結構化且緊密耦合的接口。gRPC 是非常流行的 RPC 實作，已被 CNCF 采用。​

4. 服務代理

1）是什麼

服務代理工具用于攔截進出某個服務的流量，對其應用一些邏輯，然後轉發該流量到另一個服務。服務代理的本質是一種“中間人”，收集網絡流量的資訊并對其應用規則。簡單如充當負載均衡器将流量轉發到單個應用程式，也可複雜如并排運作的代理網格，由單個的容器化應用程式處理所有網絡連接配接。​服務代理本身很有用，尤其是在将流量從更廣泛的網絡引到 Kubernetes 叢集時。服務代理同時也為其他系統（如 API 網關或服務網格）搭建了基礎，我們将在下文讨論。​

2）解決的問題

應用程式應以受控方式發送和接收網絡流量。為了跟蹤流量并對其進行轉換或重定向，我們需要收集資料。傳統上，開啟資料收集和網絡流量管理的代碼嵌入在每個應用程式中。服務代理可以使我們“外部化”該功能，使其無需再存在于應用程式中，而是嵌入到平台層（應用程式運作的地方）。​這是非常強大的功能，因為它使開發人員可以完全專注于編寫應用程式邏輯，而處理流量的通用任務由平台團隊管理（這是平台團隊的首要職責）。通過從單個公共位置集中配置設定和管理全局所需的服務功能（例如路由或 TLS 終止），服務之間的通信将更加可靠，安全和高效。​

3）如何解決

​代理充當使用者和服務之間或不同服務之間的守門員。通過這種獨特的定位，他們可以洞悉正在發生的通信類型。根據洞察，他們可以确定将特定請求發送到哪裡，甚至完全拒絕該請求。​代理收集關鍵資料，管理路由（在服務之間平均配置設定流量或在某些服務發生故障時重新路由），加密連接配接和緩存内容（減少資源消耗）。​

4）對應工具

​服務代理的工作原理是攔截服務之間的流量，對它們執行一些邏輯，然後可能會允許流量繼續前進。通過将一組集中控制的功能放入此代理，管理者可以完成幾件事。他們可以收集有關服務間通信的詳細名額，防止服務過載，并将其他通用标準應用于服務。服務代理是服務網格等其他工具的基礎，因為它們提供了對所有網絡流量實施更進階别政策的方法。​請注意，CNCF 将負載均衡器和 ingress provider 包括在此類别中。Envoy，Contour 和 BFE 都是 CNCF 項目。​

5. API 網關

​

1）是什麼

​人們通常通過網頁或（桌面）應用程式之類的 GUI（圖形使用者界面）與計算機程式進行互動，計算機則通過 API（應用程式程式設計接口）互相進行互動。但是，請勿将 API 與 API 網關混淆。​API 網關允許組織将關鍵功能（例如授權或限制應用程式之間的請求數量）移動到集中管理的位置。它還用作（通常是外部的）API 使用者的通用接口。​通過 API 網關，組織可以集中控制（限制或啟用）應用程式之間的互動并跟蹤它們，進而實作 拒絕請求、身份驗證之類的功能，并防止服務被過度使用（也稱為速率限制）。​

2）解決的問題

​盡管大多數容器和核心應用程式都具有 API，但 API 網關不僅僅是 API。API 網關簡化了組織管理規則和将規則應用于所有互動的方式。​API 網關允許開發人員編寫和維護較少的自定義代碼。他們還使團隊能夠檢視和控制使用者與應用程式本身之間的互動。​

3）如何解決

​API 網關位于使用者和應用程式之間。它充當中介，将來自使用者的消息（請求）轉發給适當的服務。但是在交出請求之前，它會評估使用者的請求是否被允許，并詳細記錄送出請求的人以及發出的請求數量。​簡而言之，API 網關為應用程式使用者提供了具有通用使用者界面的單入口點。它還可以将原本在應用程式中實作的任務移交給網關，進而為開發人員節省時間和金錢。

4）對應工具

像該層中的許多類别一樣，API 網關從應用程式中删除自定義代碼，并将其帶入中央系統。API 網關的工作原理是攔截對後端服務的調用，執行某種增值活動，例如驗證授權、收集名額或轉換請求，然後執行它認為适當的操作。API 網關是一組下遊應用程式的通用入口點，同時為團隊提供了可以注入業務邏輯以處理授權，速率限制和拒絕請求的地方。它們使應用開發者可以從客戶那裡提取對下遊 API 的更改，并将添加新客戶之類的任務交給網關。​

6. 服務網格

1）是什麼

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

2）解決什麼問題

在雲原生環境中，我們要處理很多服務，這些服務都需要通信。這意味着在本來不可靠且通常很慢的網絡上需要來回傳輸更多流量。為了應對這些新挑戰，工程師必須實施額外的功能。在服務網格之前，必須将該功能編碼到每個單獨的應用程式中。這些代碼通常會成為技術債，并導緻失敗或漏洞。​

3）如何解決

​服務網格在平台層的所有服務之間統一增加了可靠性，可觀察性和安全性，而無需觸及應用程式代碼。它們與任何程式設計語言相容，使開發團隊可以專注于編寫業務邏輯。​注：傳統上必須将這些服務網格功能編碼到每個服務中，是以每次釋出或更新新服務時，開發人員都必須確定這些功能也能使用，會導緻很多人為錯誤。事實上，開發人員更喜歡專注于業務邏輯（産生價值的功能），而不是建立可靠性，可觀察性和安全性功能。但對于平台所有者來說，可靠性、可觀察性和安全是核心功能，對于他們所做的一切至關重要。讓開發人員負責添加平台所有者需要的功能本身很難。服務網格和 API 網關解決了這個問題，因為它們是由平台所有者實作并普遍應用于所有服務的。​

4）對應工具

​服務網格通過服務代理将叢集上運作的所有服務綁定在一起，進而建立了服務的網格。這些是通過服務網格控制平面進行管理和控制的。服務網格允許平台所有者在不要求開發人員編寫自定義邏輯的情況下執行常見操作或在應用程式上收集資料。本質上，服務網格是通過向服務代理的網絡或網格提供指令和控制信号來管理服務間通信的基礎結構層。它的能力在于無需修改應用程式即可提供關鍵系統功能。​某些服務網格将通用服務代理（請參見上文）用于其資料平面。另外一些則使用專用代理。例如，Linkerd 使用 Linkerd2-proxy “微型代理”來獲得性能和資源消耗方面的優勢。這些代理通過邊車（sidecar) 統一地附加到每個服務上。Sidecar 是指代理在自己的容器中運作但存在于同一個 Pod 中，就像機車邊車一樣，它是一個單獨的子產品，附着在機車上。​服務網格提供了許多有用的功能，包括顯示詳細名額，加密所有流量，限制服務可授權的操作，為其他工具提供額外插件等等。​更多詳細資訊，請檢視服務網格接口規範：https://smi-spec.io/。​

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。​

2. 資料流和消息傳遞

​

1）是什麼

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

2）解決的問題

​随着服務激增，應用程式環境變得越來越複雜，應用程式之間的通信編排也更具挑戰性。資料流或消息平台提供了一個中心位置來釋出和讀取系統中發生的所有事件，進而使應用程式可以一起工作，而不必互相了解。​

3）如何解決

​當一個服務執行其他服務應該知道的事情時，它會将事件“釋出”到資料流或消息傳遞工具。需要了解這些事件類型的服務将訂閱并監視資料流或消息傳遞工具。這就是“釋出-訂閱”的本質。​通過引入管理通信的“中間層”可以使服務彼此解耦。服務隻是監視事件、采取行動并釋出新事件，這樣能建立高度分離的體系結構。在此體系結構中，服務可以協作而無需彼此了解。這種解耦使工程師能夠添加新功能，而無需更新下遊應用程式（消費者）或發送大量查詢。系統的解耦程度越高，更改的靈活性和适應性就越高，而這正是工程師在系統中所追求的。​

4）對應工具

​資料流和消息傳遞工具早在雲原生技術成為現實之前就已經存在了。為了集中管理關鍵業務事件，組織建立了大型的企業級服務總線。但是，當我們在雲原生環境中談論資料流和消息傳遞時，通常是指 NATS、RabbitMQ、Kafka 或雲提供的消息隊列之類的工具。​消息傳遞和資料流傳輸系統為編排系統進行通信提供了一個中心位置。消息總線提供了所有應用程式都可以通路的公共位置，應用程式都可以通過釋出消息來告訴其服務它們在做什麼，或者通過訂閱消息來檢視正在發生的事情。​NATS 和 Cloudevents 項目都是這個領域的孵化項目，NATS 提供了一個成熟的消息傳遞系統，而 Cloudevents 則緻力于标準化系統之間的消息格式。Strimzi，Pravega 和 Tremor 是沙盒項目，每個項目都針對資料流和消息傳遞的獨特用例進行了量身定制。​

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 是另一個孵化項目，旨在簡化将應用程式代碼建構到容器中的過程。​

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）托管的更多項目。在此空間中尋找工具，可以幫助組織自動化生産路徑。​

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，國内的網易、火山引擎和京東，它們都可以提供出色的開源和商業工具，建議在評估發行版時仔細考慮自己的需求。​

2. 托管 Kubernetes

​

1）是什麼

​托管 Kubernetes 是由 Amazon Web Services（AWS）、DigitalOcean、Azure 或 Google 等基礎設施提供商（雲廠商）提供的服務，允許客戶按需啟動 Kubernetes 叢集。雲廠商負責管理 Kubernetes 叢集的一部分，通常稱為控制平面。托管 Kubernetes 服務與發行版相似，但由雲廠商在其基礎架構上進行管理。​

2）解決的問題

​托管 Kubernetes 使團隊隻需在雲廠商開設一個賬戶即可開始使用 Kubernetes。它解決了 Kubernetes 入門五個過程中的“五 W”問題：​

• Who：雲廠商
• What：他們托管的 Kubernetes 産品
• When：現在
• Where：雲廠商的基礎架構上
• Why：由你決定

3）如何解決

​由于 Kuberentes 托管服務提供商負責管理所有細節，是以托管的 Kubernetes 服務是開始雲原生之路的最簡單方法。使用者所需要做的就是開發自己的應用程式并将其部署在托管的 Kubernetes 服務上，這非常友善。托管産品允許使用者啟動 Kubernetes 叢集并立即開始*，同時對叢集可用性承擔一些責任。值得注意的是，這些服務的額外便利性會造成靈活性的降低：托管的 Kubernetes 服務和雲廠商綁定，且使用者無法通路 Kubernetes 控制平面，是以某些配置選項會受到限制。​注：AWS 的 EKS 略有例外，因為它還要求使用者采取一些其他步驟來準備叢集。​

4）對應的工具

​托管 Kubernetes 是由供應商（通常是基礎架構托管提供商）提供的按需使用的 Kubernetes 叢集，供應商負責配置群集和管理 Kubernetes 控制平面。再次說明，值得注意的例外是 EKS，其上的單個節點配置由用戶端決定。​托管 Kubernetes 服務使組織可以将基礎架構元件管理外包出去，這樣可以快速配置新叢集并降低營運風險。主要的權衡取舍在于可能需要為控制平面管理付費，并且使用者的管理權限有限。與自己搭建 Kubernetes 群集相比，托管服務在配置 Kubernetes 群集方面有更嚴格的限制。​在這個領域中有許多供應商和項目，在撰寫本文時，尚無 CNCF 項目。​

3. Kubernetes 安裝程式

​

1）是什麼

Kubernetes 安裝程式可幫助你在機器上安裝 Kubernetes，它們可自動化 Kubernetes 的安裝和配置過程，甚至可以幫助更新。Kubernetes 安裝程式通常與 Kubernetes 發行版或托管 Kubernetes 産品結合使用或由它們使用。​

2）解決的問題

與 Kubernetes 發行版相似，Kubernetes 安裝程式可簡化 Kubernetes 的上手過程。開源的 Kubernetes 依賴于 kubeadm 之類的安裝程式。截至本文撰寫之時，kubeadm 可用于啟動和運作 Kubernetes 叢集，是 CKA（Kubernetes 管理者認證） 測試的一部分。​

3）如何解決

Kubernetes 安裝程式簡化了 Kubernetes 的安裝過程。像發行版一樣，它們為源代碼和版本提供經過稽核的源。它們還經常自帶 Kubernetes 環境配置。像 kind （Docker 中的 Kubernetes）這樣的 Kubernetes 安裝程式允許通過單個指令獲得 Kubernetes 叢集。​

4）對應的工具

無論是在 Docker 上本地安裝 Kubernetes，啟動和配置新的虛拟機，還是準備新的實體伺服器，都需要一個工具來處理各種 Kubernetes 元件的準備工作。​Kubernetes 安裝程式可簡化該過程。有些處理節點啟動，還有一些僅配置已供應的節點。它們都提供不同程度的自動化，并且适合不同的用例。開始使用 Kubernetes 安裝程式時，應先了解自己的需求，然後選擇可以滿足這些需求的安裝程式。在撰寫本文時，kubeadm 是 Kubernetes 生态系統中至關重要的工具，已包含在 CKA 測試中。Minikube、kind、kops 和 kubespray 都是 CNCF 中的 Kubernetes 安裝程式項目。​

4. PaaS / 容器服務

​

1）是什麼

​PaaS（平台即服務）是一種環境，允許使用者運作應用程式而不必了解底層計算資源。此類别中的 PaaS 和容器服務是一種機制，可為開發人員托管 PaaS 或托管他們可以使用的服務。​

2）解決的問題

​在本篇文章中，我們讨論了有關“雲原生”的工具和技術。PaaS 連接配接了此領域中的許多技術，可為開發人員提供直接價值。它回答了以下問題：​

• 我如何在各種環境中運作應用程式？
• 一旦應用程式運作起來，我的團隊和使用者将如何與它們互動？

3）如何解決

PaaS 為組合運作應用程式所需的開源和閉源工具提供了選擇。許多 PaaS 産品包含處理 PaaS 安裝和更新的工具，以及将應用程式代碼轉換為正在運作的應用程式的機制。此外，PaaS 可以處理應用程式執行個體的運作時需求，包括按需擴充單個元件以及可視化單個應用程式的性能和日志消息。​

4）對應的工具

組織正在采用雲原生技術來實作特定的業務或目标。與建構自定義應用程式平台相比，PaaS 可快速讓組織實作價值。Heroku 或 Cloud Foundry Application Runtime 之類的工具可幫助組織快速啟動并運作新的應用程式，它們可提供運作雲原生應用程式所需的工具。任何 PaaS 都有自身的限制。大多數隻支援一種語言或一部分應用程式類型，其自帶的一些工具選項可能并不适合你的需求。無狀态應用程式通常在 PaaS 中表現出色，而資料庫等有狀态應用程式通常不太适合 PaaS。目前在這個領域沒有 CNCF 項目，但是大多數産品都是開源的。​

5. 小結

​如文中所介紹，有多種工具可幫助簡化 Kubernetes 的采用。Kubernetes 發行版、托管 Kubernetes 服務、Kubernetes 安裝程式以及 PaaS 都承擔了一些安裝和配置的工作，可進行預打包。每個解決方案都有其自己的特點。​在采用上述任何一種方法之前，需要進行一些研究，以确定适合自己需求的最佳解決方案。你可能需要考慮：​

• 我會遇到一些需要掌控控制平面的場景嗎？如果有，托管解決方案可能不是一個很好的選擇。
• 我有沒有一個小型團隊來管理“标準”工作負載，并需要分流盡可能多的操作任務？如果有，托管解決方案可能非常合适你。
• 便攜性對我來說重要嗎？
• 生産就緒情況如何？

還有更多問題需要考慮。沒有一個“最佳工具”，但是對于你的特定需求，肯定可以選擇一個有效工具。希望本文能幫助你将搜尋範圍縮小到正确的區域。​

可觀察性和分析

終于我們來到了雲原生全景圖詳解的最後一章節。本章節将向大家介紹雲原生全景圖中的可觀察性和分析這一“列”。

首先我們定義一下可觀察性和分析（Observability & analysis)。可觀察性是一種系統特性，描述了通過外部輸出可以了解系統的程度。通過衡量 CPU 時間、記憶體、磁盤空間、延遲、error 等名額，可以或多或少地觀察到計算機系統的狀态。分析則是嘗試了解這些可用于觀察的資料。​為了確定服務不會中斷，我們需要觀察和分析應用程式的各個方面，以便立即發現并修複異常情況。這就是可觀察性和分析這個類别要做的事情。它貫穿并觀察所有層，是以在整個全景圖的側面而不是嵌在某一層。​此類别中的工具包括日志記錄 (logging)、監控 (monitoring)、追蹤（tracing) 和混沌工程（chaos engineering)。雖然混沌工程在這裡列出，但它更多的是一種可靠性工具，而不是可觀察性或分析工具。​

1. 日志記錄

​

1）是什麼

​應用程式會輸出穩定的日志消息流，以描述自身在何時做了什麼。這些日志消息會捕獲系統中發生的各種事件，例如失敗或成功的操作、審計資訊或運作狀況。日志記錄工具将收集、存儲和分析這些消息，以追溯錯誤報告和相關資料。日志記錄（loging）、度量（metrics)、追蹤（tracing) 是可觀察性的三大支柱。​

2）解決的問題

​收集、存儲和分析日志是建構現代平台的關鍵部分，日志記錄可幫助執行這其中的某一項或全部任務。一些工具可處理從收集到分析全方位的工作，還有一些工具則專注于單個任務（例如收集）。所有日志記錄工具都旨在幫助組織更好地控制日志消息。​

3）如何解決

​在收集、存儲和分析應用程式的日志消息時，我們将了解應用程式在任何給定時間的通信内容。但請注意，日志代表應用程式有意輸出的消息，它們不一定能查明給定問題的根本原因。盡管如此，随時收集和保留日志消息是一項非常強大的功能，它将幫助團隊診斷問題并滿足合規性要求。​

4）常用工具

​盡管收集、存儲和處理日志消息不是什麼新鮮事，但雲原生模式和 Kubernetes 的出現極大地改變了我們處理日志的方式。适用于虛拟機和實體機的傳統日志記錄方法（例如将日志寫入檔案）不适用于容器化的應用程式，因為在這些容器化應用程式中，檔案系統的生命周期可能并不會比應用程式持久。在雲原生環境中，諸如 Fluentd 之類的日志收集工具與應用程式容器一起運作，并直接從應用程式收集消息，然後将消息轉發到中央日志存儲以進行彙總和分析。​CNCF 中的日志記錄工具隻有 Fluentd。​

2. 監控

1）是什麼

監控是指對應用程式進行檢測，收集、聚合和分析日志和名額，以增進我們對應用程式行為的了解。日志描述了特定的事件，而名額則是在給定時間點對系統的度量。日志和 metrics 是兩種不同的事物，但是要全面了解系統的運作狀況，二者都是必需的。監控的内容包括觀察磁盤空間、CPU 使用率、單個節點上的記憶體消耗，以及執行詳細的綜合事務以檢視系統或應用程式是否正确且及時地進行了響應等。有許多不同的方法可用來監控系統和應用程式。​

2）解決的問題

​在運作應用程式或平台時，我們希望它完成既定的任務，并確定隻有被授權的使用者才能通路。通過監控，我們可以知道應用程式/平台是否在正常、安全且高效地運作，是否僅有被授權的使用者可以通路。​

3）如何解決

​良好的監控方法使運維人員能夠在發生事故時迅速做出響應，甚至可以自動響應。監控可以讓我們洞察系統目前運作的狀況，監測到問題進行修複。它能跟蹤應用程式運作狀況、使用者行為等内容，是有效運作應用程式的重要組成部分。​

4）常用工具

​雲原生環境中的監控和傳統應用程式的監控類似。我們需要跟蹤名額、日志和事件以了解應用程式的運作狀況。主要差別在于雲原生環境中的某些托管對象是臨時的，它們可能不會持久，是以将監控系統與自動生成的資源名稱聯系在一起并不是一個好政策。CNCF 中有許多監控工具，最主要的是 Prometheus（已經從 CNCF 畢業）。​

3. 追蹤

​

1）是什麼

​在微服務架構中，服務之間不斷通過網絡互相通信。追蹤是日志記錄的一種專門用法，可以跟蹤請求在分布式系統中移動的路徑。​

2）解決的問題

了解微服務應用程式在某個時間點的行為是一項極具挑戰的任務。盡管有許多工具可以提供服務行為相關的洞察，但我們可能難以通過單個服務的行為來了解整個應用程式的運作情況。​

3）如何解決

​追蹤對應用程式發送的消息添加唯一辨別符，可解決上述問題。該唯一辨別符可以跟随/追蹤各個事務在系統中移動的路徑，可以通過追蹤的資訊了解應用程式的運作狀況，以及調試有問題的微服務或行為。​

4）常用工具

​追蹤是一種功能強大的調試工具，可以對分布式應用程式的行為進行故障排除和 fine-tune。要實作追蹤也需要一些成本，比如需要修改應用程式代碼以發出跟蹤資料，并且所有 Span 都需要由應用程式資料路徑中的基礎架構元件傳播。CNCF 中的追蹤工具有 Jaeger 和 Open Tracing。​

4. 混沌工程

​

1）是什麼

​混沌工程（chaos engineering）是指有意将故障引入系統以建立更具彈性的應用程式和工程團隊的實踐。混亂工程工具以一種可控的方式在系統中引入故障，并針對應用程式的特定執行個體運作特定的實驗。​

2）解決的問題

​複雜的系統會出現故障。故障的原因有多種，給分布式系統帶來的後果也很難預測。一些組織已經接受了這一點，他們願意采用混沌工程技術，不去試圖防止故障的發生，而是設法練習從故障中恢複。這被稱為優化平均修複時間（MTTR）。​

3）如何解決

​在雲原生環境中，應用程式必須動态适應故障——這是一個相對較新的概念。這意味着當出現故障時，系統不會完全崩潰，而是可以優雅地降級或恢複。混沌工程工具可以在生産環境的系統上進行實驗，以確定在發生真正的故障時系統也能應對。​簡言之，對一個系統進行混沌工程實驗，是為了確定該系統可以承受意外情況。使用混沌工程工具，不必等待故障發生後再進行應對，而是可以在可控條件下為系統注入故障，以發現漏洞并在變更覆寫這些漏洞之前加以修複。​

4）常用工具

​混沌工程工具和實踐對于應用程式的高可用至關重要。分布式系統通常過于複雜，而且任何變更過程都無法完全确定其對環境的影響。通過有意引入混沌工程實踐，團隊可以練習從故障中恢複，并将這個過程自動化。CNCF 中的混沌工程工具有 Chaos Mesh 和 Litmus Chaos。還有一些其他的開源和閉源的混沌工程工具。

​

5. 小結

​可觀察性和分析這一列的工具可用于了解系統的運作狀況，并確定系統即使在惡劣的條件下也能正常運作。日志記錄工具可捕獲應用程式發出的事件消息，監控工具可監測日志和名額，追蹤工具可跟蹤單個請求的路徑。結合使用這些工具，理想情況下可以 360 度全方位檢視系統中正在發生的事情。混沌工程提供了一種安全的方法來保證系統可以承受意外事件，基本上可以確定系統的健康運作。​文章來源：K8sMeetup 社群，點選檢視原文。

一站式雲原生 PaaS 平台

Erda 作為開源的一站式雲原生 PaaS 平台，具備 DevOps、微服務觀測治理、多雲管理以及快資料治理等平台級能力。點選下方連結即可參與開源，和衆多開發者一起探讨、交流，共建開源社群。歡迎大家關注、貢獻代碼和 Star！​

• Erda Github 位址：https://github.com/erda-project/erda
• Erda Cloud 官網：https://www.erda.cloud/