採用服務網格的 6 大好處？

服務網格可以做從服務發現到零信任安全、負載均衡、多雲連接、自動化和南北流量的所有事情。

即使服務網格的採用持續增長，一些組織仍在嘗試全面瞭解服務網格可以做什麼和不能做什麼。

他們可能沒有意識到服務網格不僅是一種單一用途的工具，而且可以滿足各種網絡需求。服務網格實際上可能有助於整合多個現有工具，以幫助減少管理工作和成本。

看看這兩種多雲網絡架構：

使用特定於雲供應商的網絡解決方案的多雲架構

使用與雲無關的服務網格

哪個看起來不那麼複雜？

如果您選擇的服務網格與雲無關，則可以大大簡化多雲架構。不僅如此，許多服務網格產品還包括服務發現、安全的服務到服務通信、負載均衡功能以及包含漸進式交付模式的 L7 和 L4 網絡管理功能。

其他一些服務網格產品進一步擴展以提供多雲 / 多運行時連接 [1]、網絡基礎設施自動化 [2] 和南北流量控制 [3]。讓我們看一下與雲無關的服務網格的功能，以及它在跨環境整合現有工具以減少開支方面的潛力。

服務發現

服務發現允許開發人員編目和跟蹤其網絡上所有已註冊服務的網絡位置和健康狀況。在服務不斷擴大和縮小的動態環境中，這是一項重要的能力。這通常是服務網格採用之旅的第一步 [4]。

有很多方法可以獲得服務發現能力。但 Kubernetes、Amazon EKS、Azure AKS、Google GKE 或 AWS 雲地圖和配置管理數據庫 (CMDB) 等服務發現工具中內置的常用功能通常特定於它們所運行的平臺或雲。他們可以發現的服務範圍僅限於其特定平臺或雲的邊界。然而，今天，大多數組織跨多個平臺或雲環境運行應用程序，這意味着他們需要學習、安裝和管理多個服務發現解決方案。

更好的方法是可以跨越多個運行時的與雲無關的服務網格。例如，HashiCorp Consul[5] 是一個不可知的服務網格，包括對 Kubernetes、虛擬機、Amazon ECS 和 HashiCorp Nomad 的支持，允許組織跨多個異構環境集中全局服務發現。

通過將服務發現整合到服務網格中，平臺團隊可以將服務發現作爲全局共享服務提供，與依靠單個團隊在沒有任何監督的情況下運行和管理自己的服務發現工具相比，這可以降低成本、提高合規性並簡化管理。

零信任網絡

組織不再僅僅依賴於保護網絡邊界的傳統方法，而是越來越多地尋求零信任網絡來保護他們的網絡和基礎設施。

與依賴於防禦現代雲環境中可能不存在的邊界的傳統城堡和護城河安全方法不同，零信任安全認爲任何服務（無論是在邊界內部還是外部）都不應被授予訪問權限，直到它被授權和身份驗證，所有通信都經過加密。

應用身份驗證、授權和加密的零信任網絡原則是服務網格的主要功能。服務網格通過代理（通常是 Envoy[6]）自動重定向服務之間的入口和出口流量。這允許將授權、身份驗證和加密職責轉移到代理上。

服務網格使用服務身份而不是 IP 地址作爲允許或拒絕授權的單位，極大地簡化了服務到服務通信的管理。

管理員可以配置一個單一的拒絕所有策略，該策略將由代理強制執行，以阻止所有服務到服務的通信。開發人員可以添加更精細的策略來授權特定服務根據需要進行通信。

服務網格代理還將確保所有服務到服務的通信都自動進行身份驗證和加密。在進行任何服務通信之前，代理會確保交換 TLS 證書並加密網絡上的所有流量。這導致網絡更加安全，即使在發生網絡破壞後也能防止服務之間的橫向移動。

最後，服務網格通過爲管理員和開發人員提供在開發週期早期授權、驗證和加密其網絡服務的能力，從本質上幫助組織左移 [7]，通過左移，組織可以在投入生產之前降低由於不可預見的安全漏洞而導致的最後一分鐘延誤的風險。此外，使用服務網格向左移動使網絡管理員可以專注於保護網絡邊界，而不是管理單個 IP 地址。

服務網格是網絡管理員的力量倍增器和抽象層，允許開發人員專注於他們的應用程序而不是安全邏輯，並避免管理和輪換證書和密鑰的麻煩。

負載均衡

由於服務網格上的數據流量流經代理，服務網格還可以控制流量整形等功能。一個簡單的例子是服務的多個實例之間的負載均衡。服務網格允許自定義流量模式直接在實例之間分佈，而不是通過單獨的負載均衡設備進行額外的網絡躍點。即使實例向上或向下擴展，服務網格也可以動態調整流量分佈。使用服務網格可以大大降低跨多個不同環境和雲管理多個不同負載均衡設備的成本和複雜性。

這是一個傳統的負載均衡拓撲，在服務 A 與服務 B 對話之前，負載均衡器有一個額外的網絡躍點：

傳統負載均衡

在像 Consul 這樣的服務網格中，沒有額外的躍點，因爲 sidecar 代理直接通信並且 Consul 集中管理每個代理之間的流量平衡：

Consul 負載均衡

多雲連接

許多組織擁有分散在給定雲的不同網絡和區域中的不同團隊和服務。許多還跨多個雲環境部署服務。跨不同雲網絡安全地連接這些服務是一項非常理想的功能，通常需要網絡團隊付出大量努力。此外，要求子網之間不重疊的無類域間路由 (CIDR) 範圍的限制可能會阻止虛擬私有云 (VPC) 和虛擬網絡 (VNET) 之間的網絡連接。服務網格產品可以安全地連接在不同雲網絡上運行的服務，而無需付出同樣的努力。

例如，HashiCorp Consul 支持多數據中心拓撲，該拓撲使用網狀網關在跨雲的不同網絡中運行的多個 Consul 部署之間建立安全連接。團隊 A 可以在 EKS 上部署 Consul 集羣。團隊 B 可以在 AKS 上部署一個獨立的 Consul 集羣。團隊 C 可以在私有的內部數據中心的虛擬機上部署 Consul 集羣。可以在三個 Consul 集羣之間建立多數據中心配置，允許在 EKS、AKS 和虛擬機之間運行的服務進行安全連接，而無需額外的網絡配置 (如 vpn、Direct Connects 或 ExpressRoutes)。Consul 網狀網關允許將多個 Consul 部署集羣化，即使 IP 範圍在網絡中重疊。

自動化

自動化在動態環境中尤其有利。波動的需求要求運營商擴展服務實例的數量，這是一項相當微不足道的任務。但是，可能需要更新網絡防火牆、負載均衡器或其他網絡基礎設施，才能訪問新實例。類似地，新的應用程序服務可能需要更新網絡設備，然後客戶端才能訪問它們。

由於大多數組織都有獨立的網絡和安全團隊，因此這些工作流程通常涉及網絡設備更新的手動工單請求，這可能需要數小時甚至數天才能完成。縮減或停用服務可能會導致額外的問題。這是因爲網絡團隊從網絡設備中刪除 IP 地址的請求很容易被忽視，從而導致潛在的安全漏洞。

爲了應對這些挑戰，一些服務網格與 HashiCorp Terraform 等基礎設施供應工具建立了獨特的集成。Consul 與 Terraform 具有獨特的集成，可以自動觸發網絡設備更新和重新配置。運營商可以配置 Consul-Terraform-Sync (CTS)[8] 以根據 Consul 目錄中服務的更改自動更新防火牆和負載均衡器等設備。自動化這些任務減少了對手動票務系統的依賴，提高了工作流程效率，並加強了組織的安全狀況。

南北交通管制

除了在組織網絡內的服務之間調整和路由流量外，還需要從外部客戶端提供對這些服務的訪問。AWS API Gateway、Azure API Management 和 Google Cloud API Gateway 等雲原生選項對於不打算擴展到單一雲的組織來說可能是不錯的選擇。然而，對於在多個雲上運行的組織而言，在單個通用平臺上進行標準化是有價值的。

一些不可知的服務網格，包括 Consul，有一個內置的 API 網關 [9]，可以提供與雲原生選項類似的功能。這使組織可以使用一個一致的管理平面來管理服務網格流量（東西向）以及來自外部客戶端（南北向）的流量，從而無需在不同環境中部署多個不同的 API 網關。

誰從服務網格的工具整合中受益？

如果服務網格可以幫助整合不同運行時之間的許多不同工具，那麼每個組織都應該將服務網格整合到他們的基礎設施中嗎？這取決於：

對於 81% 已經使用或計劃使用多雲的組織而言 [10]，服務網格絕對可以幫助遏制工具的蔓延。

即使是致力於單一雲提供商的組織也可能要處理由不同開發團隊選擇的不同運行時。對服務網格進行標準化以提供全局服務發現、零信任網絡和負載均衡也可以幫助這些組織減少工具蔓延。像 Consul 這樣的服務網格可以通過內置特性提供進一步的工具整合，以連接雲之間的服務、自動化網絡設備更新以及控制外部客戶端對服務的訪問。

雖然一些較小的組織可能看不到工具的顯着整合，但至少他們仍然可以通過採用服務網格來改善他們的整體安全狀況，而不會給開發人員、平臺工程師或網絡工程師帶來額外的負擔。

譯自：https://u.kubeinfo.cn/5Gmmsk

譯者：# 公衆號：進擊雲原生

參考資料

[1]

多雲 / 多運行時連接: https://www.hashicorp.com/blog/consul-1-13-introduces-cluster-peering

[2]

網絡基礎設施自動化: https://www.consul.io/docs/nia

[3]

南北流量控制: https://www.consul.io/docs/api-gateway

[4]

第一步: https://thenewstack.io/service-mesh-is-just-the-tip-of-the-iceberg/

[5]

HashiCorp Consul: https://www.consul.io/

[6]

Envoy: https://www.envoyproxy.io/

[7]

左移: https://www.aquasec.com/cloud-native-academy/devsecops/shift-left-devops

[8]

Consul-Terraform-Sync (CTS): https://github.com/hashicorp/consul-terraform-sync

[9]

API 網關: https://www.consul.io/docs/api-gateway

[10]

81% 已經使用或計劃使用多雲的組織而言: https://www.hashicorp.com/state-of-the-cloud#81percent-choose-multi-cloud

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