組織數位轉型期間向 Kubernetes 和 Linux 基礎設施的過渡導致應用程式越來越多地開始基於微服務架構構建,因此經常需要複雜的方案來在服務之間路由請求。
借助紅帽 OpenShift Service Mesh,我們超越了傳統路由,並提供元件來追蹤和視覺化這些請求,從而使服務互動更簡單、更可靠。 引入特殊的邏輯控制級別,即所謂的服務網格
Red Hat OpenShift Service Mesh 作為特殊的 Kubernetes Operator 提供,其功能可以在 Red Hat OpenShift 4 中進行測試
改進應用程式和服務等級的通訊追蹤、路由和最佳化
僅使用硬體負載平衡器、專用網路設備和其他已成為現代IT 環境中常態的類似解決方案,在出現的服務到服務等級上一致且統一地調節和管理通訊是非常困難的,有時甚至是不可能的應用程式及其服務之間。 透過增加額外的服務網格管理層,容器化應用程式可以更好地監控、路由和優化與平台核心 Kubernetes 的通訊。 服務網格有助於簡化跨多個位置的混合工作負載的管理,並提供對資料位置的更精細的控制。 隨著 OpenShift Service Mesh 的發布,我們希望微服務技術堆疊的這個重要元件能夠幫助組織實施多雲和混合策略。
OpenShift Service Mesh 建構在 Istio、Kiali 和 Jaeger 等多個開源專案之上,提供了在微服務應用程式架構中對通訊邏輯進行程式設計的能力。 因此,開發團隊可以完全專注於開發解決業務問題的應用程式和服務。
讓開發者的生活更輕鬆
可視化所有服務之間的連接並查看互動拓撲的能力也有助於更好地理解服務間關係的複雜情況。 透過將這些強大的功能整合到 OpenShift Service Mesh 中,紅帽為開發人員提供了成功開發和部署雲端原生微服務所需的一組擴充工具。
為了簡化服務網格的創建,我們的解決方案可讓您使用適當的 Kubernetes 運算子在現有 OpenShift 執行個體中輕鬆實現此層級的管理。 該操作員負責所有必需元件的安裝、網路整合和操作管理,讓您可以立即開始使用新建立的服務網格來部署實際應用程式。
降低實施和管理服務網格的勞動力成本使您能夠快速建立和測試應用程式概念,並且不會在開發過程中失去對情況的控制。 為什麼要等到管理服務間通訊成為一個真正的問題? OpenShift Service Mesh 可以在您實際需要之前輕鬆提供您所需的可擴充性。
OpenShift Service Mesh 為 OpenShift 使用者提供的優點包括:
- 追蹤和監控(Jaeger)。 啟動服務網格以提高可管理性可能伴隨一定的效能下降,因此 OpenShift Service Mesh 可以測量效能的基線水平,然後使用該資料進行後續最佳化。
- 可視化(Kiali)。 服務網格的視覺化表示有助於理解服務網格的拓撲以及服務如何互動的整體情況。
- Kubernetes 服務網格運營商。 透過自動執行安裝、維護和服務生命週期管理等常見任務,最大限度地減少管理應用程式時的管理需求。 透過添加業務邏輯,您可以進一步簡化管理並加快生產中新功能的引入。 OpenShift Service Mesh 營運商部署 Istio、Kiali 和 Jaeger 套件,並提供一次性實現所有所需功能的設定邏輯。
- 支援多個網路介面 (multus)。 OpenShift Service Mesh 消除了手動步驟,使開發人員能夠使用 SCC(安全上下文約束)在增強安全模式下執行程式碼。 特別是,它提供了叢集中工作負載的額外隔離,例如,命名空間可以指定哪些工作負載可以作為 root 運行,哪些不能。 因此,可以將備受開發人員追捧的 Istio 優勢與叢集管理員所需的精心編寫的安全措施結合。
- 與紅帽 3scale API 管理整合。 對於需要提高服務 API 存取安全性的開發人員或 IT 營運商,OpenShift Service Mesh 提供了原生 Red Hat 3scale Istio Mixer Adapter 元件,與服務網格不同,它允許您在 API 層級控制服務間通訊。
對於Service Mesh技術的進一步發展,今年年初紅帽宣布參與該行業項目
嘗試 OpenShift
服務網格技術有助於大幅簡化混合雲中微服務堆疊的使用。 因此,我們鼓勵每一個積極使用 Kubernetes 和容器的人
來源: www.habr.com