主持人 > 博客 > 管理 > 服務網格資料平面與控制平面

服務網格資料平面與控制平面

嘿哈布爾！ 我提請您注意這篇文章的翻譯 “服務網格資料平面與控制平面” 阿夫托拉 馬特·克萊恩.

服務網格資料平面與控制平面

這次，我「想要並翻譯」了服務網格元件、資料平面和控制平面的描述。 在我看來，這個描述是最容易理解和最有趣的，最重要的是，它讓我理解了“有必要嗎？”

隨著「服務網格」的想法在過去兩年中變得越來越流行（原文發佈於10 年2017 月XNUMX 日），並且該領域的參與者數量不斷增加，我發現整個行業的混亂程度也相應增加。技術社區關於如何比較和對比不同的解決方案。

我在 XNUMX 月寫的以下一系列推文最好地概括了這種情況：

服務網格混亂#1：Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy。 它們都無法與 Istio 匹敵。 Istio 是完全不同的東西。 1 /

第一個只是資料平面。 他們自己什麼都不做。 他們一定有心情做更多事。 2/

Istio 是將各個部分連接在一起的控制平面的範例。 這是另一層。 /結尾

先前的推文提到了幾個不同的項目（Linkerd、NGINX、HAProxy、Envoy 和 Istio），但更重要的是介紹了資料平面、服務網格和控制平面的一般概念。 在這篇文章中，我將退後一步，在非常高的層面上討論「資料平面」和「控制平面」這兩個術語的含義，然後討論這些術語如何應用於推文中提到的項目。

服務網格到底是什麼？

服務網格資料平面與控制平面
圖 1：服務網格概述

圖1 說明了服務網格最基本的概念。 有四個服務集群（AD）。 每個服務實例都與本機代理伺服器關聯。 來自單一應用程式實例的所有網路流量（HTTP、REST、gRPC、Redis 等）都透過本機代理傳遞到對應的外部服務叢集。 這樣，應用程式實例不知道整個網絡，只知道其本地代理。 實際上，分散式系統網路已從服務中刪除。

數據平面

在服務網格中，位於應用程式本地的代理伺服器執行下列任務：

  • 服務發現。 您的應用程式可以使用哪些服務/應用程式？
  • 健康檢查。 服務發現傳回的服務執行個體是否健康並準備好接受網路流量？ 這可以包括主動（例如回應/健康檢查）和被動（例如使用3個連續的5xx錯誤作為不健康服務狀態的指示）健康檢查。
  • 路由。 當從 REST 服務接收到對「/foo」的請求時，該請求應該發送到哪個服務群集？
  • 負載平衡。 一旦在路由過程中選擇了服務集群，請求應該發送到哪個服務實例？ 超時時間是多少？ 用什麼斷路設定？ 如果請求失敗，是否應該重試？
  • 認證與授權。 對於傳入請求，可以使用 mTLS 或其他機制對呼叫服務進行加密識別/授權嗎？ 如果它被識別/授權，是否允許在服務上呼叫請求的操作（端點），或者是否應該返回未經身份驗證的回應？
  • 可觀察性。 應為每個請求產生詳細的統計數據、日誌/日誌和分散式追蹤數據，以便操作員能夠了解分散式流量並在出現問題時進行偵錯。

資料平面負責服務網格中的所有先前點。 事實上，服務本地的代理（sidecar）就是資料平面。 換句話說，資料平面負責有條件地廣播、轉送和監視發送到服務或從服務發送的每個網路資料包。

控制平面

本地代理在資料平面中提供的網路抽像是神奇的（？）。 然而，代理實際上如何知道到服務 B 的「/foo」路由呢？ 如何使用代理請求填充的服務發現資料？ 負載平衡、逾時、斷路等參數如何配置？ 如何使用藍/綠方法或優雅的流量轉換方法來部署應用程式？ 誰配置係統範圍的身份驗證和授權設定？

上述所有項目都在服務網格的控制平面的控制之下。 控制平面採用一組隔離的無狀態代理並將它們轉變為分散式系統.

我認為許多技術人員發現資料平面和控制平面的獨立概念令人困惑的原因是，對於大多數人來說，資料平面是熟悉的，而控制平面是陌生的/不理解的。 我們長期以來一直致力於實體網路路由器和交換器的研究。 我們知道資料包/請求需要從 A 點發送到 B 點，我們可以使用硬體和軟體來完成此操作。 新一代軟體代理只是我們長期以來使用的工具的奇特版本。

服務網格資料平面與控制平面
圖 2：人類控制平面

然而，我們已經使用控制平面很長時間了，儘管大多數網路營運商可能不會將系統的這一部分與任何技術組件相關聯。 原因很簡單：
現今使用的大多數控制平面是......我們.

上 圖2 顯示了我所說的“人類控制平面”。 在這種類型的部署中（仍然很常見），可能是脾氣暴躁的操作員創建靜態配置（可能透過腳本），並透過一些特殊流程將它們部署到所有代理程式。 然後，代理開始使用此配置並開始使用更新的設定處理資料平面。

服務網格資料平面與控制平面
圖 3：高階服務網格控制平面

上 圖3 顯示服務網格的「擴展」控制平面。 它由以下部分組成：

  • 人類：仍然有一個人（希望不要那麼生氣）對整個系統做出高層決策。
  • 控制平面使用者介面：人與某種類型的使用者介面互動來控制系統。 這可以是 Web 入口網站、命令列應用程式 (CLI) 或其他一些介面。 使用使用者介面，操作員可以存取全域系統配置參數，例如：
    • 部署控制、藍/綠和/或漸進式流量過渡
    • 身份驗證和授權選項
    • 路由表規範，例如當應用程式 A 請求有關「/foo」的資訊時會發生什麼
    • 負載平衡器設置，例如逾時、重試、熔斷設定等。
  • 工作負載調度程序：服務透過某種類型的調度/編排系統（例如 Kubernetes 或 Nomad）在基礎設施上運作。 調度程序負責載入服務及其本機代理。
  • 服務發現。 當調度程序啟動和停止服務實例時，它會向服務發現系統報告健康狀態。
  • Sidecar代理程式配置API ：本地代理使用最終一致的模型從各種系統組件動態提取狀態，無需操作員幹預。 整個系統由所有目前運行的服務實例和本地代理伺服器組成，最終匯聚成一個生態系統。 Envoy 的通用資料平面 API 是其在實務上如何運作的一個範例。

本質上，控制平面的目的是設定最終被資料平面接受的策略。 更先進的控制平面將從操作員手中移除一些系統的更多部件，並且需要更少的手動操作，只要它們正常工作！...

資料平面和控制平面。 資料平面與控制平面總結

  • 服務網格資料平面：影響系統中的每個資料包/請求。 負責應用程式/服務發現、健康檢查、路由、負載平衡、身份驗證/授權和可觀察性。
  • 服務網格控制平面：為業務網路內所有運作的資料平面提供策略和配置。 不觸及系統上的任何包/請求。 控制平面將所有資料平面變成一個分散式系統。

目前的項目景觀

了解了上面的解釋後，我們來看看 Service Mesh 專案的目前狀態。

  • 數據平面：Linkerd、NGINX、HAProxy、Envoy、Traefik
  • 控制平面：Istio、Nelson、SmartStack

我不會深入分析上述每個解決方案，而是會簡要討論一些我認為目前在生態系統中造成混亂的問題。

Linkerd 是 2016 年初首批用於服務網格的資料平面代理伺服器之一，在提高人們對服務網格設計模型的認識和關注方面做得非常出色。 大約 6 個月後，Envoy 加入 Linkerd（儘管他自 2015 年底以來一直在 Lyft）。 Linkerd 和 Envoy 是討論服務網格時最常提到的兩個項目。

Istio 於 2017 年 XNUMX 月發布。 Istio 專案的目標與中所示的擴展控制平面非常相似 圖3。 Istio 的 Envoy 是預設代理。 因此，Istio 是控制平面，Envoy 是資料平面。 在很短的時間內，Istio 引起了極大的關注，其他資料平面開始整合以取代 Envoy（Linkerd 和 NGINX 都展示了與 Istio 的整合）。 事實上，不同的資料平面可以在同一控制平面內使用，這意味著控制平面和資料平面不一定是緊密耦合的。 Envoy 的通用資料平面 API 等 API 可以在系統的兩個部分之間形成橋樑。

Nelson 和 SmartStack 有助於進一步說明控制平面和資料平面的分離。 Nelson 使用 Envoy 作為代理，並基於 HashiCorp 堆疊為服務網格建立可靠的控制平面，即游牧者等SmartStack 或許是新一波服務網格中的第一個。 SmartStack 圍繞 HAProxy 或 NGINX 來建立控制平面，展示了將控制平面與服務網格和資料平面解耦的能力。

具有服務網格的微服務架構正在獲得越來越多的關注（這是正確的！），越來越多的專案和供應商開始朝這個方向努力。 在接下來的幾年中，我們將看到資料平面和控制平面方面的大量創新，以及不同組件的進一步混合。 最終，微服務架構對於營運商來說應該變得更加透明和神奇（？）。
希望越來越少生氣。

重點

  • 服務網格由兩個不同的部分組成：資料平面和控制平面。 這兩個組件都是必需的，沒有它們系統將無法運作。
  • 控制平面大家都很熟悉了，此時，控制平面可能就是你了！
  • 所有資料平面都在功能、效能、可配置性和可擴展性方面相互競爭。
  • 所有控制平面在功能、可配置性、可擴展性和易用性方面都相互競爭。
  • 一個控制平面可以包含正確的抽象和 API，以便可以使用多個資料平面。

來源： www.habr.com

添加評論