OpenShift 文档正在迁移，不久后将仅在docs.redhat.com（所有 Red Hat 产品文档的所在地）提供。立即体验新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

理解服务网格

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

什么是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代理。您可以使用网关来管理网格的入站和出站流量，从而指定您希望进入或离开网格的流量。

      • 入口网关 - 也称为入口控制器，入口网关是一个专用的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 Container Platform 上运行的服务网格的可观察性。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 的硬依赖项，如果没有 Prometheus，Kiali 的许多功能将无法工作。

  • 集群 API - Kiali 使用 OpenShift Container Platform 的 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 项目。

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

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

    • Ingester – Ingester 将追踪批量处理成块，创建布隆过滤器和索引，然后将其全部刷新到后端。

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

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

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

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

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

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

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

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

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

    • 存储（数据存储） - 收集器需要一个持久性存储后端。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 分布式追踪平台具有允许将其用作 Zipkin 的直接替代品的 API，但 Red Hat 在此版本中不支持 Zipkin 兼容性。

后续步骤