1.2. 了解 Red Hat OpenShift Service Mesh

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

1.2.1. 了解服务网格

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

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

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

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

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

  • A/B 测试
  • Canary 发行版本
  • 速率限制
  • 访问控制
  • 端到端的验证

1.2.2. Red Hat OpenShift Service Mesh 架构

Red Hat OpenShift Service Mesh 在逻辑上被分成一个 data plane 和一个 control plane:

data plane 是一组作为 sidecar 部署的智能代理。这些代理会接收并控制服务网格内不同微服务之间的所有入站和出站网络数据。Sidecar 代理还和 Mixer(通用的策略和遥测系统) 进行沟通。

  • Envoy 代理可以截获服务网格内所有服务的入站和出站流量。Envoy 会在同一个 pod 中被部署为相关服务的 sidecar。

control plane 可以为路由流量管理和配置代理,并配置 Mixer 来强制执行策略并收集遥测数据。

  • Mixer 强制执行访问控制和使用策略(如授权、速率限制、配额、验证和请求追踪),并从 Mixer 代理服务器和其它服务收集遥测数据。
  • Pilot 在运行时配置代理。Pilot 为 Envoy sidecars 提供服务发现,智能路由的流量管理功能(例如 A/B 测试或 canary 部署),以及弹性(超时、重试和电路断路器)。
  • Citadel 用于发布并轮转证书。Citadel 通过内置的身份和凭证管理功能提供了强大的服务到服务(service-to-service)的验证功能及对最终用户的验证功能。您可以使用 Citadel 提升服务网格中未加密的网络流量的安全性。Operator 可根据服务身份而不是使用 Citadel 进行网络控制来强制实施策略。
  • Galley 用来管理服务网格配置,然后验证、处理和发布配置。Galley 用来保护其他服务网格组件,使它们与从 OpenShift Container Platform 获取的用户配置详情相隔离。

Red Hat OpenShift Service Mesh 还使用 istio-operator 来管理 control plane 的安装。Operator 是一个软件,它可让您实现和自动化 OpenShift 集群中的常见操作。它相当于一个控制器,用于设置或更改集群中对象的所需状态。

1.2.3. 了解 Kiali

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

1.2.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.2.3.2. 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 控制台会包括一个标签页来显示 Jaeger 的追踪数据。请注意:如果禁用 Istio 的分布式追踪功能,则不会提供追踪数据。同时请注意,为了查看 Jaeger 数据,用户必须可以访问安装 control plane 的命名空间。
  • Grafana - Grafana 是可选的,但作为 Red Hat OpenShift Service Mesh 安装的一部分被默认安装。如果使用了 Grafana,Kiali 的 metrics 页会包括一个链接,用户可以使用它访问 Grafana 中相同的指标数据。请注意,用户必须可以访问安装 control plane 的命名空间,以便查看到 Grafana 仪表板的链接并查看 Grafana 数据。

1.2.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.2.4. Jaeger 介绍

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

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

Jaeger 在微服务的整个堆栈中记录了独立请求的执行过程,并将其显示为 trace。trace是系统的数据/执行路径。一个端到端的 trace 由一个或者多个 span 组成。

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

1.2.4.1. Jaeger 概述

作为服务所有者,您可以使用 Jaeger 来检测您的服务,以收集与服务架构相关的信息。Jaeger 是一个开源的分布式追踪平台,可用来对现代的、云原生的基于微服务的应用程序中组件间的交互进行监控、创建网络配置集并进行故障排除。

使用 Jaeger 可让您执行以下功能:

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

Jaeger 基于厂商中立的 OpenTracing API 和工具。

1.2.4.2. Jaeger 架构

Jaeger 由几个组件组成,它们一起收集、存储和显示追踪数据。

  • Jaeger Client (Tracer、Reporter、instrumented application, client libraries)- Jaeger client 是 OpenTracing API 的具体语言实现。它们可以用来为各种现有开源框架(如 Camel (Fuse) 、Spring Boot (RHOAR) 、MicroProfile (RHOAR/Thorntail) 、Wilfly (EAP) 等提供分布式追踪工具。
  • Jaeger Agent (Server Queue, Processor Workers)- Jaeger 代理是一个网络守护进程,它会监听通过 User Datagram Protocol (UDP) 发送的 span,并发送到收集程序。这个代理应被放置在要管理的应用程序的同一主机上。这通常是通过如 Kubernetes 等容器环境中的 sidecar 来实现的。
  • Jaeger Collector (Que,Weue)- 与代理类似,该收集器可以接收 span,并将其放入内部队列以便进行处理。这允许收集器立即返回到客户端/代理,而不需要等待 span 进入存储。
  • Storage (Data Store) - 收集器需要一个持久的存储后端。Jaeger 带有一个可插入的机制用于 span 存储。请注意:在这个发行本中,唯一支持的存储是 Elasticsearch。
  • Query (Query Service) - Query 是一个从存储中检索 trace 的服务。
  • Ingester (Ingester Service) - Jaeger 可以使用 Apache Kafka 作为收集器和实际后备存储 (Elasticsearch) 之间的缓冲。Ingester 是一个从 Kafka 读取数据并写入另一个存储后端 (Elasticsearch) 的服务。
  • Jaeger Console – Jaeger 提供了一个用户界面,可让您可视觉地查看所分发的追踪数据。在搜索页面中,您可以查找 trace,并查看组成一个独立 trace 的 span 详情。

1.2.4.3. Jaeger 特性

Jaeger 追踪提供以下功能:

  • 与 Kiali 集成 – 当正确配置时,您可以从 Kiali 控制台查看 Jaeger 数据。
  • 高可伸缩性 – Jaeger 后端被设计为没有单一故障点,并可根据需要进行缩放。
  • 分布式上下文发布 – 允许您通过不同的组件连接数据以创建完整的端到端的 trace。
  • 与 Zipkin 的后向兼容性 - Jaeger 带有 API,让可以作为 Zipkin 的替代,但红帽在此发行版本中不支持 Zipkin 的兼容性。

1.2.5. 后续步骤