1.3. 了解 Service Mesh

Red Hat OpenShift Service Mesh 提供了一个平台,用于对服务网格(service mesh)中联网的微服务进行行为了解和操作控制。通过使用 Red Hat OpenShift Service Mesh,可以连接、控制并监控 OpenShift Container Platform 环境中的微服务。

1.3.1. 什么是 Red Hat OpenShift Service Mesh?

服务网格(service mesh)是一个微服务网络,它用于在一个分布式的微服务架构中构成应用程序,并提供不同微服务间的交互功能。当服务网格的规模和复杂性增大时,了解和管理它就会变得非常困难。

Red Hat OpenShift Service Mesh 基于开源 Istio 项目,它在不需要修改服务代码的情况下,为现有的分布式应用程序添加了一个透明的层。您可以在服务中添加对 Red Hat OpenShift Service Mesh 的支持,方法是将一个特殊的 sidecar 代理服务器部署到用于处理不同微服务之间的所有网络通讯的服务网格中。您可以使用 Service Mesh control plane 功能配置和管理 Service Mesh。

Red Hat OpenShift Service Mesh 可让您轻松创建部署的服务网络,该网络提供:

  • 发现
  • 负载平衡
  • 服务到服务的验证
  • 故障恢复
  • 指标
  • 监控

Red Hat OpenShift Service Mesh 还提供更复杂的操作功能,其中包括:

  • A/B 测试
  • Canary 发行版本
  • Access control
  • 端到端的验证

1.3.2. Service Mesh 架构

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

Service Mesh 架构镜像

在高级别上,Red Hat OpenShift Service Mesh 由 data plane 和一个 control plane 组成

数据平面是一组智能代理,与 pod 中的应用容器一起运行,用于拦截和控制服务网格中微服务之间的所有入站和出站网络通信。数据平面的实现方式是它会截获所有入站(ingress)和出站(egress)网络流量。Istio 数据平面由与 pod 中侧应用程序容器一起运行的 Envoy 容器组成。Envoy 容器充当代理,控制与 pod 往来的所有网络通信。

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

    • sidecar 代理 为其工作负载实例管理入站和出站通信。
    • 网关是作为接收传入或传出 HTTP/TCP 连接的负载平衡器运行的代理。网关配置适用于在网格边缘运行的独立的 Envoy 代理,而不是与您的服务负载一同运行的 sidecar Envoy 代理。您可以使用网关来管理入站和出站流量,允许您指定您要进入或离开网格的流量。

      • Ingress-gateway - 也称为入口控制器,Ingress 网关是一个专用的 Envoy 代理,用于接收和控制进入服务网格的流量。Ingress 网关允许将监控和路由规则等功能应用到进入集群的流量。
      • Egress-gateway - 另外称为出口控制器(Egress Gateway),Egress 网关是一个专用的 Envoy 代理,用于管理离开服务网格的流量。Egress 网关允许对流量退出网格应用监控和路由规则等功能。

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

  • Istio control plane 由 Istiod 组成,它会将几个之前的 control plane 组件(Citadel、Galley 和 Pilot)整合为一个二进制。Istiod 提供服务发现、配置和证书管理。它将高级别路由规则转换为 Envoy 配置,并在运行时将其传播到 sidecar。

    • Istiod 可以充当证书颁发机构 (CA),在 data plane 中生成支持安全 mTLS 通信的证书。您还可以使用外部 CA 来实现这一目的。
    • Istiod 负责将 sidecar 代理容器注入到部署到 OpenShift 集群的工作负载中。

Red Hat OpenShift Service Mesh 使用 istio-operator 来管理 control plane 的安装。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 是一个开源可追踪性服务器,可以集中并显示与多个服务间单一请求关联的 trace。利用分布式追踪平台 (Jaeger),您可以监控基于微服务的分布式系统并进行故障排除。
  • Elasticsearch - Elasticsearch 是一个开源、分布式、基于 JSON 的搜索和分析引擎。分布式追踪平台(Jaeger)使用 Elasticsearch 进行持久性存储。
  • Grafana - Grafana 为网格管理员提供用于 Istio 数据的高级查询和指标分析和仪表板。另外,Grafana 可以用来分析服务网格指标。

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

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

有关如何安装 3scale 适配器的详情,请参考 3scale Istio 适配器文档

1.3.3. 了解 Kiali

Kiali 通过显示服务网格中的微服务服务以及连接方式,为您提供了一个可视性的服务网格概述。

1.3.3.1. Kiali 概述

Kiali 为在 OpenShift Container Platform 上运行的 Service Mesh 提供了一个观察平台。Kiali 可以帮助您定义、验证并观察 Istio 服务网格。它所提供的拓扑结构可以帮助您了解服务网格的结构,并提供服务网格的健康状况信息。

Kiali 实时提供命名空间的交互式图形视图,可让您了解诸如电路断路器、请求率、延迟甚至流量图等功能。Kiali 提供了从应用程序到服务以及负载等不同级别的组件的了解,并可显示与所选图形节点或边缘的上下文信息和图表的交互。Kiali 还提供了验证 Istio 配置(如网关、目的规则、虚拟服务、网格策略等等)的功能。Kiali 提供了详细的指标数据,并可使用基本的 Grafana 集成来进行高级查询。通过将 Jaeger 集成到 Kiali 控制台来提供分布式追踪。

默认情况下,Kiali 作为 Red Hat OpenShift Service Mesh 的一部分被安装。

1.3.3.2. Kiali 架构

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

  • Kiali 应用程序 (后端)- 该组件运行在容器应用程序平台中,并与服务网格组件进行通讯,检索和处理数据,并将这些数据提供给控制台。Kiali 应用程序不需要存储。当在集群中部署应用程序时,配置在 ConfigMaps 和 secret 中设置。
  • Kiali 控制台 (前端) – Kiali 控制台是一个 Web 应用程序。Kiali 应用程序为 Kiali 控制台提供服务,控制台会查询后端数据并把数据提供给用户。

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

  • Red Hat Service Mesh (Istio) - Kiali 需要 Istio。Istio 是提供和控制服务网格的组件。虽然 Kiali 和 Istio 可以单独安装,但是 Kiali 需要 Istio。如果没有安装 Istio,则无法工作。Kiali 需要检索 Istio 数据和配置,这些数据和配置可以通过 Prometheus 和集群 API 获得。
  • Prometheus - 一个专用的 Prometheus 实例作为 Red Hat OpenShift Service Mesh 安装的一部分被包括。启用 Istio 遥测时,指标数据存储在 Prometheus 中。Kiali 使用这个 Prometheus 数据来决定网状拓扑结构、显示指标数据、计算健康状况、显示可能的问题等等。Kiali 与 Prometheus 直接沟通,并假设 Istio Telemetry 使用的数据 schema。Istio 依赖于 Prometheus,Kiali 也依赖于 Prometheus。许多 Kiali 的功能在没有 Prometheus 的情况下将无法工作。
  • Cluster API - Kiali 使用 OpenShift Container Platform (cluster API) API 来获取和解析服务网格配置。Kiali 通过查询集群 API 获取信息,如获取命名空间、服务、部署、pod 和其他实体的定义。Kiali 还提供查询来解析不同集群实体之间的关系。另外,还可以通过查询集群 API 以获取 Istio 配置,比如虚拟服务、目的规则、路由规则、网关、配额等等。
  • Jaeger - Jaeger 是可选的,但会作为 Red Hat OpenShift Service Mesh 安装的一部分被默认安装。当您作为 Red Hat OpenShift Service Mesh 安装的一部分安装分布式追踪平台(Jaeger)时,Kiali 控制台会包括一个显示分布式追踪数据的标签页。请注意:如果禁用 Istio 的分布式追踪功能,则不会提供追踪数据。另请注意,用户必须可以访问安装 Service Mesh control plane 的命名空间,才能查看追踪数据。
  • Grafana - Grafana 是可选的,但作为 Red Hat OpenShift Service Mesh 安装的一部分被默认安装。如果使用了 Grafana,Kiali 的 metrics 页会包括一个链接,用户可以使用它访问 Grafana 中相同的指标数据。请注意,用户必须可以访问安装 Service Mesh control plane 的命名空间,以便查看到 Grafana 仪表板的链接并查看 Grafana 数据。

1.3.3.3. Kiali 的功能

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

  • 健康 – 快速识别应用程序、服务或者工作负载的问题。
  • 拓扑 – 以图形的形式显示应用程序、服务或工作负载如何通过 Kiali 进行通信。
  • 指标 – 预定义的 metrics dashboard 可为您生成 Go、Node.js、Quarkus 、Spring Boot 、Thonttail 和 Vert.x 的服务网格和应用程序性能图表。。您还可以创建您自己的自定义仪表板。
  • 追踪 – 通过与 Jaeger 集成,可以在组成一个应用程序的多个微服务间追踪请求的路径。
  • 验证 – 对最常见 Istio 对象(Destination Rules 、Service Entries 、Virtual Services 等等)进行高级验证。
  • 配置 – 使用向导创建、更新和删除 Istio 路由配置的可选功能,或者直接在 Kiali Console 的 YAML 编辑器中创建、更新和删除 Istio 路由配置。

1.3.4. 了解分布式追踪

每次用户在某个应用程序中执行一项操作时,一个请求都会在所在的系统上执行,而这个系统可能需要几十个不同服务的共同参与才可以做出相应的响应。这个请求的路径是一个分布式的事务。分布式追踪平台 (Jaeger) 可让您执行分布式追踪,在组成一个应用的多个微服务间追踪请求的路径。

分布式追踪是用来将不同工作单元的信息关联起来的技术,通常是在不同进程或主机中执行的,以便理解分布式事务中的整个事件链。分布式追踪可让开发人员在大型服务架构中视觉化调用流程。它对理解序列化、平行和延迟来源会很有价值。

分布式追踪平台 (Jaeger) 记录了在微服务的整个堆栈间执行单个请求,并将其显示为 trace。trace是系统的数据/执行路径。端到端追踪包含一个或多个范围。

span 代表具有操作名称、操作的开始时间和持续时间的逻辑工作单元。span 可能会被嵌套并排序以模拟因果关系。

1.3.4.1. 分布式追踪概述

作为服务所有者,您可以使用分布式追踪来检测您的服务,以收集与服务架构相关的信息。您可以使用 Red Hat OpenShift distributed tracing 平台来监控、网络性能分析,并对现代、云原生的微服务应用程序中组件间的交互进行故障排除。

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

  • 监控分布式事务
  • 优化性能和延迟时间
  • 执行根原因分析

分布式追踪平台由三个组件组成:

  • Red Hat OpenShift distributed tracing Platform (Tempo),它基于开源 Grafana Tempo 项目
  • 红帽构建的 OpenTelemetry,它基于开源 OpenTelemetry 项目
  • Red Hat OpenShift distributed tracing Platform (Jaeger),它基于开源 Jaeger 项目

    重要

    Jaeger 不使用经 FIPS 验证的加密模块。

1.3.4.2. Red Hat OpenShift distributed tracing Platform 架构

Red Hat OpenShift distributed tracing 平台由多个组件组成,它们一起收集、存储和显示追踪数据。

  • Red Hat OpenShift distributed tracing Platform (Tempo) - 此组件基于开源 Grafana Tempo 项目

    • 网关 - 网关处理身份验证、授权和将请求转发到分布式或查询前端服务。
    • Distributor - Distributor 接受多种格式(包括 Jaeger、OpenTelemetry 和 Zipkin)的 span。它通过哈希 traceID 并将分布式一致的哈希环路由到 Ingester。
    • Ingester - Ingester 将 trace 批处理到块中,创建 bloom 过滤器和索引,然后将其全部刷新到后端。
    • Query Frontend - Query Frontend 负责为传入的查询对搜索空间进行分片。然后,搜索查询会发送到 Queriers。Query Frontend 部署通过 Tempo Query sidecar 公开 Jaeger UI。
    • Querier - Querier 负责在 Ingester 或后端存储中查找请求的 trace ID。根据参数,它可以查询 Ingesters,并从后端拉取 Bloom 索引,以便在对象存储中搜索块。
    • compactor - Compactors 流块到后端存储中,以减少块总数。
  • 红帽构建的 OpenTelemetry - 此组件基于开源 OpenTelemetry 项目

    • OpenTelemetry Collector - OpenTelemetry Collector 是一个与厂商无关的方式来接收、处理和导出遥测数据。OpenTelemetry Collector 支持开源可观察数据格式,如 Jaeger 和 Prometheus,发送到一个或多个开源或商业后端。Collector 是默认位置检测库来导出其遥测数据。
  • Red Hat OpenShift distributed tracing Platform (Jaeger) - 此组件基于开源 Jaeger 项目

    • 客户端 (Jaeger 客户端、跟踪器、报告程序、客户端库)- 分布式追踪平台 (Jaeger) 客户端是 OpenTracing API 的特定语言实施。它们可以用来为各种现有开源框架(如 Camel (Fuse) 、Spring Boot (RHOAR) 、MicroProfile (RHOAR/Thorntail) 、Wilfly (EAP) 等提供分布式追踪工具。
    • 代理 (Jaeger 代理,Server Queue, Processor Workers)- 分布式追踪平台 (Jaeger) 代理是一个网络守护进程,侦听通过用户数据报协议(UDP)发送并发送到 Collector。这个代理应被放置在要管理的应用程序的同一主机上。这通常是通过容器环境(如 Kubernetes)中的 sidecar 来实现。
    • Jaeger Collector (Collector, Queue, Workers)- 与 Jaeger 代理类似,Jaeger Collector 接收 span,并将它们放置在内部队列中进行处理。这允许 Jaeger Collector 立即返回到客户端/代理,而不是等待 span 变为存储。
    • Storage (Data Store) - 收集器需要一个持久的存储后端。Red Hat OpenShift distributed tracing Platform (Jaeger) 提供了用于 span 存储的可插拔机制。Red Hat OpenShift distributed tracing Platform (Jaeger)支持 Elasticsearch 存储。
    • Query (Query Service) - Query 是一个从存储中检索 trace 的服务。
    • Ingester (Ingester Service)- Red Hat OpenShift distributed tracing 平台可以使用 Apache Kafka 作为 Collector 和实际的 Elasticsearch 后端存储之间的缓冲。Ingester 是一个从 Kafka 读取数据并写入 Elasticsearch 存储后端的服务。
    • Jaeger 控制台 - 使用 Red Hat OpenShift distributed tracing 平台 (Jaeger) 用户界面,您可以视觉化您的分布式追踪数据。在搜索页面中,您可以查找 trace,并查看组成一个独立 trace 的 span 详情。

1.3.4.3. Red Hat OpenShift distributed tracing Platform 功能

Red Hat OpenShift distributed tracing 平台提供以下功能:

  • 与 Kiali 集成 - 当正确配置时,您可以从 Kiali 控制台查看分布式追踪平台数据。
  • 高可伸缩性 - 分布式追踪平台后端设计具有单一故障点,而且能够按照业务需求进行扩展。
  • 分布式上下文发布 – 允许您通过不同的组件连接数据以创建完整的端到端的 trace。
  • 与 Zipkin 的后向兼容性 - Red Hat OpenShift distributed tracing platform 有 API,它能将其用作 Zipkin 的简易替代品,但红帽在此发行版本中不支持 Zipkin 的兼容性。

1.3.5. 后续步骤