×

Red Hat OpenShift Service Mesh提供了一个平台,用于对服务网格中联网的微服务进行行为洞察和操作控制。使用Red Hat OpenShift Service Mesh,您可以在AWS环境中的Red Hat OpenShift Service上连接、保护和监控微服务。

什么是Red Hat OpenShift Service Mesh?

服务网格是在分布式微服务架构中构成应用程序的微服务网络以及这些微服务之间的交互。当服务网格的规模和复杂性增长时,理解和管理它可能会变得更加困难。

基于开源Istio项目,Red Hat OpenShift Service Mesh在现有分布式应用程序上添加了一个透明层,无需更改服务代码。通过将特殊的sidecar代理部署到网格中相关的服务来添加对Red Hat OpenShift Service Mesh的支持,该代理拦截微服务之间的所有网络通信。您可以使用服务网格控制平面功能来配置和管理服务网格。

Red Hat OpenShift Service Mesh为您提供了一种简单的方法来创建已部署服务的网络,这些服务提供

  • 服务发现

  • 负载均衡

  • 服务间身份验证

  • 故障恢复

  • 指标

  • 监控

Red Hat OpenShift Service Mesh还提供更复杂的运营功能,包括

  • A/B测试

  • 金丝雀发布

  • 访问控制

  • 端到端身份验证

服务网格架构

服务网格技术在网络通信级别运行。也就是说,服务网格组件捕获或拦截与微服务的流量,修改请求、重定向请求或创建对其他服务的请求。

Service Mesh architecture image

总的来说,Red Hat OpenShift Service Mesh由数据平面和控制平面组成。

**数据平面**是一组智能代理,运行在pod中的应用程序容器旁边,拦截和控制服务网格中微服务之间所有入站和出站的网络通信。数据平面的实现方式拦截所有入站(ingress)和出站(egress)网络流量。Istio数据平面由在pod中的应用程序容器旁边运行的Envoy容器组成。Envoy容器充当代理,控制进入和离开pod的所有网络通信。

  • **Envoy代理**是唯一与数据平面流量交互的Istio组件。服务之间所有传入(ingress)和传出(egress)的网络流量都通过代理流动。Envoy代理还收集与网格内服务流量相关的所有指标。Envoy代理作为sidecar部署,与服务在同一个pod中运行。Envoy代理也用于实现网关。

    • **Sidecar代理**管理其工作负载实例的入站和出站通信。

    • **网关**是充当负载均衡器的代理,接收传入或传出的HTTP/TCP连接。网关配置应用于运行在网格边缘的独立Envoy代理,而不是与服务工作负载一起运行的sidecar Envoy代理。您可以使用网关来管理网格的入站和出站流量,让您指定要进入或离开网格的流量。

      • **入口网关(Ingress-gateway)** - 也称为入口控制器,入口网关是一个专用Envoy代理,接收和控制进入服务网格的流量。入口网关允许将监控和路由规则应用于进入集群的流量。

      • **出口网关(Egress-gateway)** - 也称为出口控制器,出口网关是一个专用Envoy代理,管理离开服务网格的流量。出口网关允许将监控和路由规则应用于离开网格的流量。

**控制平面**管理和配置构成数据平面的代理。它是配置的权威来源,管理访问控制和使用策略,并从服务网格中的代理收集指标。

  • Istio控制平面由**Istiod**组成,它将几个以前的控制平面组件(Citadel、Galley、Pilot)合并到单个二进制文件中。Istiod提供服务发现、配置和证书管理。它将高级路由规则转换为Envoy配置,并在运行时将它们传播到sidecar。

    • Istiod可以充当证书颁发机构 (CA),生成支持数据平面中安全mTLS通信的证书。您也可以为此目的使用外部CA。

    • Istiod负责将sidecar代理容器注入部署到OpenShift集群的工作负载。

Red Hat OpenShift Service Mesh使用**istio-operator**来管理控制平面的安装。Operator是一种软件,使您能够在OpenShift集群中实现和自动化常见活动。它充当控制器,允许您设置或更改集群中对象的所需状态,在本例中为Red Hat OpenShift Service Mesh安装。

Red Hat OpenShift Service Mesh还将以下Istio附加组件作为产品的一部分捆绑在一起

  • **Kiali** - Kiali是Red Hat OpenShift Service Mesh的管理控制台。它提供仪表板、可观察性和强大的配置和验证功能。它通过推断流量拓扑来显示服务网格的结构,并显示网格的健康状况。Kiali提供详细的指标、强大的验证、对Grafana的访问以及与分布式追踪平台(Jaeger)的强大集成。

  • Prometheus - Red Hat OpenShift Service Mesh 使用 Prometheus 存储来自服务的遥测信息。Kiali 依赖于 Prometheus 获取指标、健康状态和网格拓扑。

  • Jaeger - Red Hat OpenShift Service Mesh 支持分布式追踪平台 (Jaeger)。Jaeger 是一个开源的追踪服务器,它集中并显示与多个服务之间单个请求关联的追踪信息。使用分布式追踪平台 (Jaeger),您可以监控和排查基于微服务的分布式系统。

  • Elasticsearch - Elasticsearch 是一个开源的、分布式的、基于 JSON 的搜索和分析引擎。分布式追踪平台 (Jaeger) 使用 Elasticsearch 进行持久性存储。

  • Grafana - Grafana 为网格管理员提供 Istio 数据的高级查询和指标分析以及仪表板。可以选择使用 Grafana 来分析服务网格指标。

Red Hat OpenShift Service Mesh 支持以下 Istio 集成

  • 3scale - Istio 提供与 Red Hat 3scale API 管理解决方案的可选集成。对于 2.1 之前的版本,此集成是通过 3scale Istio 适配器实现的。对于 2.1 及更高版本,3scale 集成是通过 WebAssembly 模块实现的。

有关如何安装 3scale 适配器的信息,请参阅3scale Istio 适配器文档

了解 Kiali

Kiali 通过向您展示服务网格中的微服务及其连接方式来提供对服务网格的可见性。

Kiali 概述

Kiali 提供对在 AWS 上运行的 Red Hat OpenShift Service Mesh 的可观察性。Kiali 帮助您定义、验证和观察您的 Istio 服务网格。它通过推断拓扑结构来帮助您了解服务网格的结构,并提供有关服务网格健康状况的信息。

Kiali 提供命名空间的实时交互式图形视图,该视图提供对断路器、请求速率、延迟甚至流量流图等功能的可见性。Kiali 提供对不同级别组件(从应用程序到服务和工作负载)的洞察,并可以在所选图形节点或边上显示具有上下文信息和图表的用户交互。Kiali 还提供验证 Istio 配置(例如网关、目标规则、虚拟服务、网格策略等)的功能。Kiali 提供详细的指标,并提供用于高级查询的基本 Grafana 集成。通过将 Jaeger 集成到 Kiali 控制台中来提供分布式追踪。

Kiali 作为 Red Hat OpenShift Service Mesh 的一部分默认安装。

Kiali 架构

Kiali 基于开源Kiali 项目。Kiali 由两个组件组成:Kiali 应用程序和 Kiali 控制台。

  • Kiali 应用程序(后端)– 此组件在容器应用程序平台中运行,并与服务网格组件通信,检索和处理数据,并将这些数据公开给控制台。Kiali 应用程序不需要存储。将应用程序部署到集群时,配置设置在 ConfigMap 和密钥中。

  • Kiali 控制台(前端)– Kiali 控制台是一个 Web 应用程序。Kiali 应用程序服务于 Kiali 控制台,然后控制台查询后端以获取数据并将其呈现给用户。

此外,Kiali 还依赖于容器应用程序平台和 Istio 提供的外部服务和组件。

  • Red Hat Service Mesh (Istio) - Istio 是 Kiali 的一个必要条件。Istio 是提供和控制服务网格的组件。尽管 Kiali 和 Istio 可以单独安装,但 Kiali 依赖于 Istio,如果没有 Istio,Kiali 将无法工作。Kiali 需要检索 Istio 数据和配置,这些数据和配置通过 Prometheus 和集群 API 公开。

  • Prometheus - 专用的 Prometheus 实例作为 Red Hat OpenShift Service Mesh 安装的一部分包含在内。启用 Istio 遥测时,指标数据将存储在 Prometheus 中。Kiali 使用此 Prometheus 数据来确定网格拓扑、显示指标、计算健康状况、显示可能存在的问题等等。Kiali 直接与 Prometheus 通信,并假设 Istio 遥测使用的架构。Prometheus 是 Istio 的依赖项,也是 Kiali 的硬性依赖项,许多 Kiali 的功能如果没有 Prometheus 将无法工作。

  • 集群 API - Kiali 使用 AWS 上 Red Hat OpenShift Service 的 API(集群 API)来获取和解析服务网格配置。例如,Kiali 查询集群 API 以检索命名空间、服务、部署、Pod 和其他实体的定义。Kiali 还进行查询以解析不同集群实体之间的关系。还查询集群 API 以检索 Istio 配置,例如虚拟服务、目标规则、路由规则、网关、配额等等。

  • Jaeger - Jaeger 是可选的,但作为 Red Hat OpenShift Service Mesh 安装的一部分默认安装。当您将分布式追踪平台 (Jaeger) 作为默认 Red Hat OpenShift Service Mesh 安装的一部分安装时,Kiali 控制台包含一个选项卡以显示分布式追踪数据。请注意,如果禁用 Istio 的分布式追踪功能,则追踪数据将不可用。另请注意,用户必须能够访问安装服务网格控制平面的命名空间才能查看追踪数据。

  • Grafana - Grafana 是可选的,但作为 Red Hat OpenShift Service Mesh 安装的一部分默认安装。如果可用,Kiali 的指标页面会显示链接,引导用户直接访问 Grafana 中的相同指标。请注意,用户必须能够访问安装服务网格控制平面的命名空间才能查看 Grafana 仪表板的链接并查看 Grafana 数据。

Kiali 功能

Kiali 控制台与 Red Hat Service Mesh 集成,并提供以下功能:

  • 健康状况 – 快速识别应用程序、服务或工作负载的问题。

  • 拓扑结构 – 通过 Kiali 图形可视化应用程序、服务或工作负载如何通信。

  • 指标 – 预定义的指标仪表板允许您为 Go、Node.js、Quarkus、Spring Boot、Thorntail 和 Vert.x 绘制服务网格和应用程序性能图表。您还可以创建自己的自定义仪表板。

  • 追踪 – 与 Jaeger 集成,允许您跟踪请求在构成应用程序的各种微服务中的路径。

  • 验证 – 对最常见的 Istio 对象(目标规则、服务条目、虚拟服务等)执行高级验证。

  • 配置 – 可选功能,可以使用向导或直接在 Kiali 控制台的 YAML 编辑器中创建、更新和删除 Istio 路由配置。

了解分布式追踪

每次用户在应用程序中执行操作时,架构都会执行一个请求,这可能需要几十个不同的服务参与才能生成响应。此请求的路径是一个分布式事务。分布式追踪平台 (Jaeger) 允许您执行分布式追踪,它跟踪请求在构成应用程序的各种微服务中的路径。

分布式追踪是一种用于将有关不同工作单元的信息关联在一起的技术——通常在不同的进程或主机中执行——以了解分布式事务中整个事件链。分布式追踪允许开发人员可视化大型面向服务的体系结构中的调用流程。它对于理解序列化、并行性和延迟来源非常宝贵。

分布式追踪平台 (Jaeger) 记录跨整个微服务堆栈的单个请求的执行情况,并将它们显示为追踪。追踪是系统中的数据/执行路径。端到端追踪包含一个或多个跨度。

跨度表示一个逻辑工作单元,它具有操作名称、操作的开始时间和持续时间。跨度可以嵌套和排序以对因果关系建模。

分布式追踪概述

作为服务所有者,您可以使用分布式追踪来为您的服务添加监控功能,从而收集关于服务架构的洞察信息。您可以使用 Red Hat OpenShift 分布式追踪平台来监控、网络分析和排查现代化、云原生、基于微服务的应用程序中组件之间的交互。

使用分布式追踪平台,您可以执行以下功能:

  • 监控分布式事务

  • 优化性能和延迟

  • 执行根本原因分析

Red Hat OpenShift 分布式追踪平台架构

Red Hat OpenShift 分布式追踪平台由多个组件组成,这些组件协同工作以收集、存储和显示追踪数据。

  • Red Hat OpenShift 分布式追踪平台 (Tempo) - 此组件基于开源 Grafana Tempo 项目

    • 网关 (Gateway) – 网关处理身份验证、授权并将请求转发到分发器或查询前端服务。

    • 分发器 (Distributor) – 分发器接受多种格式的跨度数据,包括 Jaeger、OpenTelemetry 和 Zipkin。它通过对traceID进行哈希并使用分布式一致哈希环将跨度路由到 Ingester。

    • Ingester – Ingester 将追踪批量处理成块,创建布隆过滤器和索引,然后将所有数据刷新到后端。

    • 查询前端 (Query Frontend) – 查询前端负责为传入的查询划分搜索空间。然后将搜索查询发送到查询器。查询前端部署通过 Tempo 查询 sidecar 公开 Jaeger UI。

    • 查询器 (Querier) - 查询器负责在 Ingester 或后端存储中查找请求的 trace ID。根据参数,它可以查询 Ingester 并从后端拉取布隆索引以搜索对象存储中的块。

    • 压实器 (Compactor) – 压实器在后端存储之间传输数据块以减少数据块的总数。

  • Red Hat 版本的 OpenTelemetry - 此组件基于开源 OpenTelemetry 项目

    • OpenTelemetry Collector - OpenTelemetry Collector 是一种与供应商无关的方式来接收、处理和导出遥测数据。OpenTelemetry Collector 支持开源可观测性数据格式,例如 Jaeger 和 Prometheus,并将数据发送到一个或多个开源或商业后端。Collector 是仪表库导出其遥测数据的默认位置。

  • Red Hat OpenShift 分布式追踪平台 (Jaeger) - 此组件基于开源 Jaeger 项目

    • 客户端 (Client) (Jaeger 客户端、Tracer、Reporter、已 instrumentation 的应用程序、客户端库) - 分布式追踪平台 (Jaeger) 客户端是 OpenTracing API 的特定于语言的实现。它们可用于手动或使用各种现有的开源框架(例如 Camel (Fuse)、Spring Boot (RHOAR)、MicroProfile (RHOAR/Thorntail)、Wildfly (EAP) 以及许多其他已与 OpenTracing 集成的框架)为分布式追踪 instrumentation 应用程序。

    • Agent (Jaeger agent、服务器队列、处理器工作器) - 分布式追踪平台 (Jaeger) agent 是一个网络守护进程,它侦听通过用户数据报协议 (UDP) 发送的跨度数据,并将这些数据批量发送到 Collector。agent 旨在与已 instrumentation 的应用程序放在同一主机上。这通常通过在 Kubernetes 等容器环境中使用 sidecar 来实现。

    • Jaeger Collector (Collector、队列、工作器) - 与 Jaeger agent 类似,Jaeger Collector 接收跨度数据并将它们放入内部队列以进行处理。这允许 Jaeger Collector 立即返回到客户端/agent,而无需等待跨度数据进入存储。

    • 存储 (Storage) (数据存储) - Collector 需要持久性存储后端。Red Hat OpenShift 分布式追踪平台 (Jaeger) 具有用于跨度存储的可插拔机制。Red Hat OpenShift 分布式追踪平台 (Jaeger) 支持 Elasticsearch 存储。

    • 查询 (Query) (查询服务) - 查询是一个从存储中检索追踪数据的服务。

    • Ingester (Ingester 服务) - Red Hat OpenShift 分布式追踪平台可以使用 Apache Kafka 作为 Collector 和实际 Elasticsearch 后端存储之间的缓冲区。Ingester 是一个从 Kafka 读取数据并写入 Elasticsearch 后端存储的服务。

    • Jaeger 控制台 – 使用 Red Hat OpenShift 分布式追踪平台 (Jaeger) 用户界面,您可以可视化您的分布式追踪数据。在搜索页面上,您可以查找追踪并浏览构成单个追踪的跨度的详细信息。

Red Hat OpenShift 分布式追踪平台功能

Red Hat OpenShift 分布式追踪平台提供以下功能:

  • 与 Kiali 集成 – 正确配置后,您可以从 Kiali 控制台查看分布式追踪平台数据。

  • 高可扩展性 – 分布式追踪平台后端设计为没有单点故障,并且可以根据业务需求进行扩展。

  • 分布式上下文传播 – 使您能够将来自不同组件的数据连接在一起以创建完整的端到端追踪。

  • 向后兼容 Zipkin – Red Hat OpenShift 分布式追踪平台具有 API,使其可以作为 Zipkin 的直接替代品,但 Red Hat 在此版本中不支持 Zipkin 兼容性。

后续步骤