×

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

什么是 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 中的应用程序容器一起运行,拦截并控制服务网格中微服务之间所有入站和出站的网络通信。数据平面以拦截所有入站(入口)和出站(出口)网络流量的方式实现。Istio 数据平面由与 Pod 中的应用程序容器一起运行的 Envoy 容器组成。Envoy 容器充当代理,控制进入和离开 Pod 的所有网络通信。

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

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

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

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

      • 出口网关 - 也称为出口控制器,出口网关是一个专用的 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 提供对在 OpenShift Dedicated 上运行的服务网格的可观察性。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 - Red Hat OpenShift Service Mesh安装包含一个专用的Prometheus实例。启用Istio遥测后,指标数据将存储在Prometheus中。Kiali使用此Prometheus数据来确定网格拓扑,显示指标,计算健康状况,显示可能的问题等等。Kiali直接与Prometheus通信,并假定Istio遥测使用的架构。Prometheus是Istio的依赖项,也是Kiali的硬性依赖项,许多Kiali的功能如果没有Prometheus将无法工作。

  • 集群API (Cluster API) - Kiali使用OpenShift Dedicated(集群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集成,并提供以下功能:

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

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

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

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

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

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

理解分布式跟踪

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

分布式跟踪是一种用于将不同工作单元(通常在不同的进程或主机中执行)的信息关联在一起的技术,以便了解分布式事务中整个事件链。分布式跟踪使开发人员能够可视化大型面向服务的架构中的调用流程。它对于理解序列化、并行性和延迟来源非常有价值。

分布式跟踪平台(Jaeger)记录整个微服务堆栈中各个请求的执行情况,并将它们显示为跟踪。跟踪 (trace) 是通过系统的數據/執行路徑。端到端跟踪包含一个或多个跨度。

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

分布式跟踪概述

作为服务所有者,您可以使用分布式跟踪为您的服务添加工具以收集有关您的服务架构的见解。您可以使用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 收集器 - OpenTelemetry 收集器是一种与厂商无关的方式,用于接收、处理和导出遥测数据。OpenTelemetry 收集器支持开源可观察性数据格式,例如 Jaeger 和 Prometheus,并将数据发送到一个或多个开源或商业后端。收集器是仪表库导出其遥测数据的默认位置。

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

    • 客户端 (Jaeger 客户端、Tracer、Reporter、已仪表化的应用程序、客户端库) - 分布式追踪平台 (Jaeger) 客户端是 OpenTracing API 的特定于语言的实现。它们可用于手动或使用各种现有的开源框架(例如 Camel (Fuse)、Spring Boot (RHOAR)、MicroProfile (RHOAR/Thorntail)、Wildfly (EAP) 等等,这些框架已与 OpenTracing 集成)为分布式追踪设置应用程序的仪表。

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

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

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

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

    • Ingester (Ingester 服务) - Red Hat OpenShift 分布式追踪平台可以使用 Apache Kafka 作为收集器和实际 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 兼容性。