雲原生全景圖詳解

帶你瞭解雲原生技術圖譜

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

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

本章節我們將把整個全景圖拆解開來，並對整個全景圖進行綜述。在後續章節中，我們將聚焦在每一層（or 每一列），對每個類別解決的問題和原理進行更爲詳細的解讀。

雲原生全景圖的 4 層

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

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

供應層 （Provisioning）

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

供應層包括：

運行時層（Runtime）

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

在 CNCF 雲原生全景圖中，運行時保障了容器化應用程序組件的運行和通信， 包括：

編排和管理層（Orchestration and Management）

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

這一層包含：

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

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

這一層包括：

貫穿所有層的工具

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

可觀察性和分析（Observability and Analysis）

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

這這一類別你將發現：

平臺類（Platform）

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

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

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

平臺可分爲四類：

小結

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

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

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

供應層

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

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

自動化和配置

是什麼

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

解決的問題

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

如何解決問題

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

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

對應工具

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

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

從根本上講，在這一層，你需要一個或多個工具來爲 Kubernetes 集羣搭建計算環境、CPU、內存、存儲和網絡。此外，你還需要其中的一些工具來創建和管理 Kubernetes 集羣本身。

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

Container Registry

是什麼

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

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

鏡像包含執行程序（在容器內）所需的信息，並存儲在倉庫中，倉庫被分類和分組。構建、運行和管理容器的工具需要訪問（通過引用倉庫）這些鏡像。

解決的問題

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

如何解決

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

對應工具

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

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

安全和合規

是什麼

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

解決什麼問題

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

如何解決

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

對應工具

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

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

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

密鑰和身份管理

是什麼

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

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

解決的問題

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

如何解決

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

對應的工具

此類別中的工具可以分爲兩組：

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

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

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

運行時層

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

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

雲原生存儲

是什麼

存儲是存放一個應用程序持久數據的地方，也叫做持久卷（persistent volume)。輕鬆訪問持久卷對於應用程序可靠運行至關重要。通常，當我們說持久數據的時候，我們是指數據庫、消息之類的，或其他任何在應用重新啓動時不會丟失的信息。

解決的問題

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

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

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

如何解決

該類別的工具可以：

雲原生存儲意味着使用兼容雲原生環境的容器存儲接口（也就是下一個類別中的工具），並且可以自動配置，通過消除人力瓶頸從而實現了自動擴展和自我恢復。

對應工具

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

除了這一及其重要的功能，還有一些其他的工具和技術旨在解決雲原生空間中的存儲問題。Minio 是一個受歡迎的項目，它提供了兼容 S3 的 API 用於對象存儲。Velero 之類的工具可幫助簡化 Kubernetes 集羣本身以及應用程序使用的持久化數據的備份和還原過程。

容器運行時

是什麼

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

容器運行時是執行容器化（或 “隔離”）應用的軟件。如果沒有運行時，將只有容器鏡像——指定容器化應用程序外觀的文件。運行時將在容器中啓動應用程序，併爲其提供所需的資源。

解決的問題

容器鏡像（帶有應用程序規範的文件）必須以標準化、安全和隔離的方式啓動：

此外，必須爲應用程序提供 CPU、存儲、內存等資源。

如何解決

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

對應的工具

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

雲原生網絡

是什麼

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

解決什麼問題

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

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

如何解決

此類別中的項目和產品使用 CNCF 中的項目——容器網絡接口（Container Network Interface, CNI）爲容器化應用提供網絡功能。某些工具（例如 Flannel）僅爲容器提供基本連接。其他工具（如 NSX-T）提供了完整的軟件定義網絡層，可爲每個 Kubernetes 名稱空間創建一個隔離的虛擬網絡。

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

對應工具

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

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

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

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

編排和管理層

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

編排和調度

是什麼

編排和調度是指在集羣中運行和管理容器（一種打包和運送應用的新方式）。集羣是通過網絡連接的一組機器（物理機或虛擬機均可）。

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

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

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

解決的問題

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

如何解決

容器編排器自動化了容器管理的過程。這在實際操作中意味着什麼？讓我們以 Kubernetes 來回答這個問題，因爲 Kubernetes 是事實上的容器編排器。

Kubernetes 做的事情是 “期望狀態協調”：將集羣中容器的當前狀態與期望狀態匹配。工程師在文件中指定所需狀態，例如：服務 A 的 10 個實例在三個節點（即：機器）上運行，可訪問 B 數據庫，等等。該狀態需持續與實際狀態進行比較。如果預期狀態與實際狀態不匹配，Kubernetes 會通過創建或銷燬對象來進行協調（例如：如果某個容器崩潰了，Kubernetes 會啓動一個新的容器）。

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

對應工具

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

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

協調和服務發現

是什麼

現代應用程序由多個單獨的服務組成，這些服務之間需要相互協作才能爲最終用戶提供價值。要進行協作，這些服務通過網絡進行通信（我們在運行時層已經討論過）。要通信，服務需要能相互定位。服務發現就是解決這個問題的。

解決的問題

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

如何解決

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

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

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

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

對應工具

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

遠程進程調用

是什麼

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

解決的問題

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

如何解決

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

對應工具

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

服務代理

是什麼

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

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

解決的問題

應用程序應以受控方式發送和接收網絡流量。爲了跟蹤流量並對其進行轉換或重定向，我們需要收集數據。傳統上，開啓數據收集和網絡流量管理的代碼嵌入在每個應用程序中。服務代理可以使我們 “外部化” 該功能，使其無需再存在於應用程序中，而是嵌入到平臺層（應用程序運行的地方）。

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

如何解決

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

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

對應工具

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

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

API 網關

是什麼

人們通常通過網頁或（桌面）應用程序之類的 GUI（圖形用戶界面）與計算機程序進行交互，計算機則通過 API（應用程序編程接口）相互進行交互。但是，請勿將 API 與 API 網關混淆。

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

通過 API 網關，組織可以集中控制（限制或啓用）應用程序之間的交互並跟蹤它們，從而實現 拒絕請求、身份驗證之類的功能，並防止服務被過度使用（也稱爲速率限制）。

解決的問題

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

API 網關允許開發人員編寫和維護較少的自定義代碼。他們還使團隊能夠查看和控制用戶與應用程序本身之間的交互。

如何解決

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

簡而言之，API 網關爲應用程序用戶提供了具有通用用戶界面的單入口點。它還可以將原本在應用程序中實現的任務移交給網關，從而爲開發人員節省時間和金錢。

對應工具

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

服務網格

是什麼

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

解決什麼問題

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

**如何解決
**

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

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

對應工具

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

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

服務網格提供了許多有用的功能，包括顯示詳細指標，加密所有流量，限制服務可授權的操作，爲其他工具提供額外插件等等。更多詳細信息，請查看服務網格接口規範：https://smi-spec.io/

小結

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

應用程序定義和開發層

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

數據庫

是什麼

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

數據庫能保障數據存儲，僅授權的用戶能訪問數據，並且允許用戶通過專門的請求來檢索數據。儘管數據庫類型繁多，但它們的總體目標都是相同的。

解決的問題

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

如何解決

數據庫提供存儲和檢索應用程序數據的通用接口。開發人員使用這些標準接口，並用一種簡單的查詢語言來存儲、查詢和檢索信息。同時，數據庫允許用戶連續備份和保存數據以及加密和管理數據訪問權限。

對應工具

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

常見的兩種數據庫類型爲：結構化查詢語言（SQL）數據庫和 NoSQL 數據庫。應用程序該使用哪種數據庫應該由其需求來驅動。

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

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

數據流和消息傳遞

是什麼

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

解決的問題

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

如何解決

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

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

對應工具

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

消息傳遞和數據流傳輸系統爲編排系統進行通信提供了一箇中心位置。消息總線提供了所有應用程序都可以訪問的公共位置，應用程序都可以通過發佈消息來告訴其服務它們在做什麼，或者通過訂閱消息來查看正在發生的事情。

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

應用程序定義和鏡像構建

是什麼

應用程序定義和鏡像構建是一個廣泛的類別，可以分爲兩個主要的子類別：

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

解決的問題

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

如何解決

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

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

對應的工具

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

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

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

持續集成和持續交付

是什麼

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

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

解決的問題

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

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

如何解決

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

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

對應工具

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

通常，該領域的項目和產品是：

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

小結

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

託管 Kubernetes 和 PaaS 解決什麼問題

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

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

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

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

Kubernetes 發行版

是什麼

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

解決的問題

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

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

如何解決

Kubernetes 發行版提供了一種安裝 Kubernetes 的可靠方式，並提供了合理的默認值以創建更好、更安全的操作環境。Kubernetes 發行版爲供應商和項目提供了所需的掌控度和可預測性，以幫助他們支持客戶部署、維護和升級 Kubernetes 集羣。

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

對應的工具

如果你已經安裝了 Kubernetes，那你可能已經使用了 kubeadm 之類的工具來啓動和運行集羣。即便如此，你可能還需要 CNI（容器網絡接口）來安裝和配置它。然後，你可能已經添加了一些存儲類，一個處理日誌消息的工具，可能還需要個 ingress controller，以及更多其他的工具。Kubernetes 發行版將自動執行部分或全部設置。它還將根據自己對最佳實踐或智能默認值的理解提供配置設置。此外，大多數發行版都將捆綁一些經過測試的擴展或附件，以確保用戶可以儘快使用新集羣。

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

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

託管 Kubernetes

是什麼

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

解決的問題

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

如何解決

由於 Kuberentes 託管服務提供商負責管理所有細節，因此託管的 Kubernetes 服務是開始雲原生之路的最簡單方法。用戶所需要做的就是開發自己的應用程序並將其部署在託管的 Kubernetes 服務上，這非常方便。託管產品允許用戶啓動 Kubernetes 集羣並立即開始 *，同時對集羣可用性承擔一些責任。值得注意的是，這些服務的額外便利性會造成靈活性的降低：託管的 Kubernetes 服務和雲廠商綁定，且用戶無法訪問 Kubernetes 控制平面，因此某些配置選項會受到限制。

AWS 的 EKS 略有例外，因爲它還要求用戶採取一些其他步驟來準備集羣。

對應的工具

託管 Kubernetes 是由供應商（通常是基礎架構託管提供商）提供的按需使用的 Kubernetes 集羣，供應商負責配置羣集和管理 Kubernetes 控制平面。再次說明，值得注意的例外是 EKS，其上的單個節點配置由客戶端決定。

託管 Kubernetes 服務使組織可以將基礎架構組件管理外包出去，這樣可以快速配置新集羣並降低運營風險。主要的權衡取捨在於可能需要爲控制平面管理付費，並且用戶的管理權限有限。與自己搭建 Kubernetes 羣集相比，託管服務在配置 Kubernetes 羣集方面有更嚴格的限制。

在這個領域中有許多供應商和項目，在撰寫本文時，尚無 CNCF 項目。

Kubernetes 安裝程序

是什麼

Kubernetes 安裝程序可幫助你在機器上安裝 Kubernetes，它們可自動化 Kubernetes 的安裝和配置過程，甚至可以幫助升級。Kubernetes 安裝程序通常與 Kubernetes 發行版或託管 Kubernetes 產品結合使用或由它們使用。

解決的問題

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

如何解決

Kubernetes 安裝程序簡化了 Kubernetes 的安裝過程。像發行版一樣，它們爲源代碼和版本提供經過審覈的源。它們還經常自帶 Kubernetes 環境配置。像 kind （Docker 中的 Kubernetes）這樣的 Kubernetes 安裝程序允許通過單個命令獲得 Kubernetes 集羣。

對應的工具

無論是在 Docker 上本地安裝 Kubernetes，啓動和配置新的虛擬機，還是準備新的物理服務器，都需要一個工具來處理各種 Kubernetes 組件的準備工作。

Kubernetes 安裝程序可簡化該過程。有些處理節點啓動，還有一些僅配置已供應的節點。它們都提供不同程度的自動化，並且適合不同的用例。開始使用 Kubernetes 安裝程序時，應先了解自己的需求，然後選擇可以滿足這些需求的安裝程序。在撰寫本文時，kubeadm 是 Kubernetes 生態系統中至關重要的工具，已包含在 CKA 測試中。Minikube、kind、kops 和 kubespray 都是 CNCF 中的 Kubernetes 安裝程序項目。

PaaS / 容器服務

是什麼

PaaS（平臺即服務）是一種環境，允許用戶運行應用程序而不必瞭解底層計算資源。此類別中的 PaaS 和容器服務是一種機制，可爲開發人員託管 PaaS 或託管他們可以使用的服務。

解決的問題

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

如何解決

PaaS 爲組合運行應用程序所需的開源和閉源工具提供了選擇。許多 PaaS 產品包含處理 PaaS 安裝和升級的工具，以及將應用程序代碼轉換爲正在運行的應用程序的機制。此外，PaaS 可以處理應用程序實例的運行時需求，包括按需擴展單個組件以及可視化單個應用程序的性能和日誌消息。

對應的工具

組織正在採用雲原生技術來實現特定的業務或目標。與構建自定義應用程序平臺相比，PaaS 可快速讓組織實現價值。Heroku 或 Cloud Foundry Application Runtime 之類的工具可幫助組織快速啓動並運行新的應用程序，它們可提供運行雲原生應用程序所需的工具。任何 PaaS 都有自身的限制。大多數只支持一種語言或一部分應用程序類型，其自帶的一些工具選項可能並不適合你的需求。無狀態應用程序通常在 PaaS 中表現出色，而數據庫等有狀態應用程序通常不太適合 PaaS。目前在這個領域沒有 CNCF 項目，但是大多數產品都是開源的。

小結

如文中所介紹，有多種工具可幫助簡化 Kubernetes 的採用。Kubernetes 發行版、託管 Kubernetes 服務、Kubernetes 安裝程序以及 PaaS 都承擔了一些安裝和配置的工作，可進行預打包。每個解決方案都有其自己的特點。

在採用上述任何一種方法之前，需要進行一些研究，以確定適合自己需求的最佳解決方案。你可能需要考慮：

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

可觀察性是什麼，有哪些相關工具

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

首先我們定義一下可觀察性和分析（Observability & analysis)。可觀察性是一種系統特性，描述了通過外部輸出可以理解系統的程度。通過衡量 CPU 時間、內存、磁盤空間、延遲、error 等指標，可以或多或少地觀察到計算機系統的狀態。分析則是嘗試理解這些可用於觀察的數據。

爲了確保服務不會中斷，我們需要觀察和分析應用程序的各個方面，以便立即發現並修復異常情況。這就是可觀察性和分析這個類別要做的事情。它貫穿並觀察所有層，因此在整個全景圖的側面而不是嵌在某一層。

此類別中的工具包括日誌記錄 (logging)、監控 (monitoring)、追蹤（tracing) 和混沌工程（chaos engineering)。雖然混沌工程在這裏列出，但它更多的是一種可靠性工具，而不是可觀察性或分析工具。

日誌記錄

是什麼

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

解決的問題

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

如何解決

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

常用工具

儘管收集、存儲和處理日誌消息不是什麼新鮮事，但云原生模式和 Kubernetes 的出現極大地改變了我們處理日誌的方式。適用於虛擬機和物理機的傳統日誌記錄方法（例如將日誌寫入文件）不適用於容器化的應用程序，因爲在這些容器化應用程序中，文件系統的生命週期可能並不會比應用程序持久。在雲原生環境中，諸如 Fluentd 之類的日誌收集工具與應用程序容器一起運行，並直接從應用程序收集消息，然後將消息轉發到中央日誌存儲以進行彙總和分析。

CNCF 中的日誌記錄工具只有 Fluentd。

監控

是什麼

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

解決的問題

在運行應用程序或平臺時，我們希望它完成既定的任務，並確保只有被授權的用戶才能訪問。通過監控，我們可以知道應用程序 / 平臺是否在正常、安全且高效地運行，是否僅有被授權的用戶可以訪問。

如何解決

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

常用工具

雲原生環境中的監控和傳統應用程序的監控類似。我們需要跟蹤指標、日誌和事件以瞭解應用程序的運行狀況。主要區別在於雲原生環境中的某些託管對象是臨時的，它們可能不會持久，因此將監控系統與自動生成的資源名稱聯繫在一起並不是一個好策略。CNCF 中有許多監控工具，最主要的是 Prometheus（已經從 CNCF 畢業）。

追蹤

是什麼

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

解決的問題

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

如何解決

追蹤對應用程序發送的消息添加唯一標識符，可解決上述問題。該唯一標識符可以跟隨 / 追蹤各個事務在系統中移動的路徑，可以通過追蹤的信息瞭解應用程序的運行狀況，以及調試有問題的微服務或行爲。

常用工具

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

混沌工程

是什麼

混沌工程（chaos engineering）是指有意將故障引入系統以創建更具彈性的應用程序和工程團隊的實踐。混亂工程工具以一種可控的方式在系統中引入故障，並針對應用程序的特定實例運行特定的實驗。

解決的問題

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

如何解決

在雲原生環境中，應用程序必須動態適應故障——這是一個相對較新的概念。這意味着當出現故障時，系統不會完全崩潰，而是可以優雅地降級或恢復。混沌工程工具可以在生產環境的系統上進行實驗，以確保在發生真正的故障時系統也能應對。

簡言之，對一個系統進行混沌工程實驗，是爲了確保該系統可以承受意外情況。使用混沌工程工具，不必等待故障發生後再進行應對，而是可以在可控條件下爲系統注入故障，以發現漏洞並在變更覆蓋這些漏洞之前加以修復。

常用工具

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

小結

可觀察性和分析這一列的工具可用於瞭解系統的運行狀況，並確保系統即使在惡劣的條件下也能正常運行。日誌記錄工具可捕獲應用程序發出的事件消息，監控工具可監測日誌和指標，追蹤工具可跟蹤單個請求的路徑。結合使用這些工具，理想情況下可以 360 度全方位查看系統中正在發生的事情。混沌工程提供了一種安全的方法來保證系統可以承受意外事件，基本上可以確保系統的健康運行。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/cgkkflioTiepIUyEwVbxkg

猜你喜歡