來源 |?K8sMeetup社區

作者 |?Catherine Paganini

翻譯 |?Sarah（K8sMeetup）

校對 |?木子（才云）

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

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

本文是這一系列的第一篇文章，我們將把整個全景圖拆解開來，并對整個全景圖進行綜述。在后續文章中，我們將聚焦在每一層（or 每一列），對每個類別解決的問題和原理進行更為詳細的解讀。

云原生全景圖的 4 層

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

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

供應層 （Provisioning）

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

供應層包括：

• 自動化和部署工具：幫助工程師在無需人工干預情況下即可構建計算環境；

• 容器注冊表：存儲應用程序的可執行文件；

• 不同安全領域的安全和合規框架；

• 密鑰管理解決方案：通過加密確保只有授權的用戶才能訪問特定的應用程序。

這些工具使工程師可以編寫基礎設施參數，使系統可以按需搭建新環境，確保了一致性和安全性。

運行時層（Runtime）

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

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

• 云原生存儲：為容器化應用提供虛擬磁盤或持久化存儲；

• 容器運行時：為容器提供隔離、資源和安全；

• 云網絡：分布式系統的節點（機器或進程）通過其連接和通信。

編排和管理層（Orchestration and Management）

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

這一層包含：

• 編排和調度：部署和管理容器集群，確保它們具有彈性伸縮能力，相互之間低耦合，并且可擴展。事實上，編排工具（絕大多數情況下就是 Kubernetes）通過管理容器和操作環境構成了集群；

• 協調和服務發現：使得服務（應用程序組件）之間可以相互定位和通信；

• 遠程進程調用（RPC）：使跨節點服務間通信的技術；

• 服務代理：服務間通信的中介。服務代理的唯一目的就是對服務之間的通信進行更多控制，而不會對通信本身添加任何內容。服務代理對下面將提到的服務網格（service mesh）至關重要。

• API 網關：一個抽象層，外部應用可通過 API 網關進行通信；

• Service Mesh：某種程度上類似于 API 網關，它是應用程序進行通信的專用基礎架構層，提供基于策略的內部服務間通信。此外，它還可能包含流量加密、服務發現、應用程序監控等內容。

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

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

這一層包括：

• 數據庫：使應用程序能以有序的方式收集數據；

• 流和消息傳遞：使應用程序能發送和接收消息（事件和流）。它不是網絡層，而是讓消息成為隊列并處理消息的工具；

• 應用程序定義和鏡像構建：用于配置、維護和運行容器鏡像（應用程序的可執行文件）的服務；

• 持續集成和持續交付（CI/CD）：使開發者可自動測試代碼是否與代碼庫（應用程序的其余部分）兼容。如果團隊足夠成熟，甚至可以自動部署代碼到生產環境。

貫穿所有層的工具

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

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

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

這這一類別你將發現：

• 日志工具：收集事件日志（有關進程的信息）；

• 監控方案：收集指標（以數字表示的系統參數，例如 RAM 可用性）；

• 追蹤工具：追蹤比監控更進了一步，它們監控用戶請求的傳播，與服務網格相關。

• 混沌工程（Chaos Engineering）：在生產環境中測試軟件的工具，可識別缺陷并進行修復，減少其對服務交付的影響。

平臺類（Platform）

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

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

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

平臺可分為四類：

• Kubernetes 發行版：采用未經修改的開放源代碼（盡管有人對其進行了修改），并根據市場需要增加了其他功能；

• 托管的 Kubernetes：類似于 Kubernetes 發行版，但是由提供商托管；

• Kubernetes 安裝程序：自動執行 Kubernetes 的安裝和配置過程；

• PaaS/容器服務：類似于托管的 Kubernetes，但是包含了一套更廣泛的應用部署工具（通常是來自云原生景觀圖）。

  總結

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

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

更多閱讀推薦

• SRE 是如何保障穩定性的
  

• 新春聊一下：技術架構與架構師角色的諸多思考

• 如何寫出讓 CPU 跑得更快的代

• 備戰春招：阿里一面，給了幾條SQL，問需要執行幾次樹搜索操作？

總結

以上是生活随笔為你收集整理的都在说云原生，它的技术图谱你真的了解吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。