Service Mesh

OpenShift Container Platform 4.11

Service Mesh 的安装、使用和发行注记信息

Red Hat OpenShift Documentation Team

摘要

本文档提供了有关如何在 OpenShift Container Platform 中使用 Service Mesh 的信息.

第 1 章 Service Mesh 2.x

1.1. 关于 OpenShift Service Mesh

注意

因为 Red Hat OpenShift Service Mesh 的发行节奏与 OpenShift Container Platform 不同,且 Red Hat OpenShift Service Mesh Operator 支持部署多个版本的 ServiceMeshControlPlane,所以 Service Mesh 没有为产品的次版本维护单独的文档。当前文档集适用于 Service Mesh 的最新版本,除非在特定主题或特定功能中明确指定了特定于版本的限制。

如需有关 Red Hat OpenShift Service Mesh 生命周期和支持的平台的更多信息,请参阅平台生命周期政策

1.1.1. Red Hat OpenShift Service Mesh 简介

Red Hat OpenShift Service Mesh 通过在应用程序中创建集中控制点来解决微服务架构中的各种问题。它在现有分布式应用上添加一个透明层,而无需对应用代码进行任何更改。

微服务架构将企业应用的工作分成模块化服务,从而简化扩展和维护。但是,随着微服务架构上构建的企业应用的规模和复杂性不断增长,理解和管理变得困难。Service Mesh 可以通过捕获或截获服务间的流量来解决这些架构问题,并可修改、重定向或创建新请求到其他服务。

Service Mesh 基于开源 Istio 项目,为创建部署的服务提供发现、负载均衡、服务对服务身份验证、故障恢复、指标和监控的服务网络提供了便捷的方法。服务网格还提供更复杂的操作功能,其中包括 A/B 测试、canary 发行版本、访问控制以及端到端验证。

1.1.2. 核心功能

Red Hat OpenShift Service Mesh 在服务网络间提供了实现关键功能的统一方式:

  • 流量管理 - 控制服务间的流量和 API 调用,提高调用的可靠性,并使网络在条件不好的情况保持稳定。
  • 服务标识和安全性 - 在网格中提供可验证身份的服务,并提供保护服务流量的能力,以便可以通过信任度不同的网络进行传输。
  • 策略强制 - 对服务间的交互应用机构策略,确保实施访问策略,并在用户间分配资源。通过配置网格就可以对策略进行更改,而不需要修改应用程序代码。
  • 遥测 - 了解服务间的依赖关系以及服务间的网络数据流,从而可以快速发现问题。

1.2. Service Mesh 发行注记

1.2.1. 使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息

1.2.2. 新功能及功能增强

此版本对以下方面进行了改进。

1.2.2.1. Red Hat OpenShift Service Mesh 版本 2.4.5 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.11 及更新的版本的支持。

1.2.2.1.1. Red Hat OpenShift Service Mesh 2.4.5 版中包含的组件版本
组件版本

Istio

1.16.7

Envoy Proxy

1.24.12

Jaeger

1.47.0

Kiali

1.65.11

1.2.2.2. Red Hat OpenShift Service Mesh 版本 2.4.4 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.11 及更新的版本的支持。

1.2.2.2.1. Red Hat OpenShift Service Mesh 2.4.4 版中包含的组件版本
组件版本

Istio

1.16.7

Envoy Proxy

1.24.12

Jaeger

1.47.0

Kiali

1.65.10

1.2.2.3. Red Hat OpenShift Service Mesh 版本 2.4.3 的新功能

  • Red Hat OpenShift Service Mesh Operator 现在在基于 ARM 的集群上作为技术预览功能提供。
  • 添加了 envoyExtAuthzGrpc 字段,该字段用于使用 gRPC API 配置外部授权提供程序。
  • 解决了常见的漏洞和风险(CVE)。
  • 此发行版本在 OpenShift Container Platform 4.10 及更新的版本中被支持。
1.2.2.3.1. Red Hat OpenShift Service Mesh 2.4.3 版中包含的组件版本
组件版本

Istio

1.16.7

Envoy Proxy

1.24.10

Jaeger

1.42.0

Kiali

1.65.8

1.2.2.3.2. Red Hat OpenShift Service Mesh operator 到基于 ARM 的集群
重要

Red Hat OpenShift Service Mesh operator 到 ARM 的集群只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

此发行版本使 Red Hat OpenShift Service Mesh Operator 在基于 ARM 的集群上作为技术预览功能提供。提供了 Istio, Envoy, Prometheus, Kiali, 和 Grafana 镜像。没有 Jaeger 镜像,因此 Jaeger 必须作为 Service Mesh 附加组件禁用。

1.2.2.3.3. 远程过程调用(gRPC) API 支持外部授权配置

此功能增强添加了 envoyExtAuthzGrpc 字段,以使用 gRPC API 配置外部授权供应商。

1.2.2.4. Red Hat OpenShift Service Mesh 版本 2.4.2 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.4.1. Red Hat OpenShift Service Mesh 2.4.2 版中包含的组件版本
组件版本

Istio

1.16.7

Envoy Proxy

1.24.10

Jaeger

1.42.0

Kiali

1.65.7

1.2.2.5. Red Hat OpenShift Service Mesh 版本 2.4.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.5.1. Red Hat OpenShift Service Mesh 2.4.1 版中包含的组件版本
组件版本

Istio

1.16.5

Envoy Proxy

1.24.8

Jaeger

1.42.0

Kiali

1.65.7

1.2.2.6. Red Hat OpenShift Service Mesh 版本 2.4 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.6.1. Red Hat OpenShift Service Mesh 2.4 版中包含的组件版本
组件版本

Istio

1.16.5

Envoy Proxy

1.24.8

Jaeger

1.42.0

Kiali

1.65.6

1.2.2.6.2. 集群范围的部署

此功能增强引入了集群范围的部署的通用版本。集群范围的部署包含一个服务网格 control plane,用于监控整个集群的资源。control plane 在所有命名空间中使用单个查询来监控影响网格配置的每个 Istio 或 Kubernetes 资源。减少集群范围的部署中 control plane 执行的查询数量可提高性能。

1.2.2.6.3. 支持发现选择器

此功能增强引入了一个通用的 meshConfig.discoverySelectors 字段版本,该字段可用于集群范围的部署来限制服务网格 control plane 可以发现的服务。

spec:
  meshConfig
    discoverySelectors:
    - matchLabels:
        env: prod
        region: us-east1
    - matchExpressions:
      - key: app
        operator: In
        values:
          - cassandra
          - spark
1.2.2.6.4. 与 cert-manager istio-csr 集成

在这个版本中,Red Hat OpenShift Service Mesh 与 cert-manager 控制器和 istio-csr 代理集成。cert-manager 在 Kubernetes 集群中将证书和证书签发者添加为资源类型,并简化了获取、续订和使用这些证书的过程。cert-manager 为 Istio 提供并轮转中间 CA 证书。与 istio-csr 集成可让用户将 Istio 代理的签名证书请求委派给 cert-managerServiceMeshControlPlane v2.4 接受 cert-manager 提供的 CA 证书作为 cacerts secret。

注意

IBM Power、IBM Z 和 IBM® LinuxONE 不支持与 cert-manageristio-csr 集成。

1.2.2.6.5. 与外部授权系统集成

此功能增强引入了一种通用可用的方法,使用 AuthorizationPolicy 资源的 action: CUSTOM 字段将 Red Hat OpenShift Service Mesh 与外部授权系统集成。使用 envoyExtAuthzHttp 字段将访问控制委派给外部授权系统。

1.2.2.6.6. 与外部 Prometheus 安装集成

此功能增强引入了 Prometheus 扩展供应商的通用版本。您可以通过在 spec.meshConfig 规格中将 extensionProviders 字段的值设置为 prometheus,将指标公开给 OpenShift Container Platform 监控堆栈或自定义 Prometheus 安装。Telemetry 对象配置 Istio 代理来收集流量指标。Service Mesh 只支持 Prometheus 指标的 Telemetry API。

spec:
  meshConfig:
    extensionProviders:
    - name: prometheus
      prometheus: {}
---
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-prometheus-metrics
spec:
  metrics:
  - providers:
    - name: prometheus
1.2.2.6.7. 单堆栈 IPv6 支持

此功能增强引进了对单堆栈 IPv6 集群的常用支持,提供对更广泛的 IP 地址的访问。不支持双堆栈 IPv4 或 IPv6 集群。

注意

IBM Power、IBM Z 和 IBM® LinuxONE 上不支持单一堆栈 IPv6。

1.2.2.6.8. OpenShift Container Platform Gateway API 支持
重要

OpenShift Container Platform Gateway API 支持只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

此功能增强引入了 OpenShift Container Platform Gateway API 的更新技术预览版本。默认情况下禁用 OpenShift Container Platform 网关 API。

1.2.2.6.8.1. 启用 OpenShift Container Platform 网关 API

要启用 OpenShift Container Platform Gateway API,在 ServiceMeshControlPlane 资源的 techPreview.gatewayAPI 规格中将 enabled 字段的值设置为 true

spec:
  techPreview:
    gatewayAPI:
      enabled: true

在以前的版本中,环境变量用于启用网关 API。

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: "true"
            PILOT_ENABLE_GATEWAY_API_STATUS: "true"
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"
1.2.2.6.9. 在基础架构节点上部署 control plane

Service Mesh control plane 部署现在在 OpenShift 基础架构节点上被支持并记录。如需更多信息,请参阅以下文档:

  • 配置所有 Service Mesh control plane 组件以便在基础架构节点上运行
  • 配置单个 Service Mesh control plane 组件以便在基础架构节点上运行
1.2.2.6.10. Istio 1.16 支持

Service Mesh 2.4 基于 Istio 1.16,它引入了新功能和产品改进。虽然很多 Istio 1.16 功能被支持,但请注意以下例外:

  • 对于 sidecar 的 HBONE 协议是一个实验性功能,它不被支持。
  • 不支持 ARM64 架构上的 Service Mesh。
  • OpenTelemetry API 仍是一个技术预览功能。

1.2.2.7. Red Hat OpenShift Service Mesh 2.3.9 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.11 及更新的版本的支持。

1.2.2.7.1. Red Hat OpenShift Service Mesh 2.3.9 版中包含的组件版本
组件版本

Istio

1.14.5

Envoy Proxy

1.22.11

Jaeger

1.47.0

Kiali

1.57.14

1.2.2.8. Red Hat OpenShift Service Mesh 版本 2.3.8 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.11 及更新的版本的支持。

1.2.2.8.1. Red Hat OpenShift Service Mesh 2.3.8 版中包含的组件版本
组件版本

Istio

1.14.5

Envoy Proxy

1.22.11

Jaeger

1.47.0

Kiali

1.57.13

1.2.2.9. Red Hat OpenShift Service Mesh 版本 2.3.7 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.9.1. Red Hat OpenShift Service Mesh 2.3.7 版中包含的组件版本
组件版本

Istio

1.14.6

Envoy Proxy

1.22.11

Jaeger

1.42.0

Kiali

1.57.11

1.2.2.10. Red Hat OpenShift Service Mesh 版本 2.3.6 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.10.1. Red Hat OpenShift Service Mesh 2.3.6 版中包含的组件版本
组件版本

Istio

1.14.5

Envoy Proxy

1.22.11

Jaeger

1.42.0

Kiali

1.57.10

1.2.2.11. Red Hat OpenShift Service Mesh 2.3.5 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.11.1. Red Hat OpenShift Service Mesh 2.3.5 版中包含的组件版本
组件版本

Istio

1.14.5

Envoy Proxy

1.22.9

Jaeger

1.42.0

Kiali

1.57.10

1.2.2.12. Red Hat OpenShift Service Mesh 版本 2.3.4 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.12.1. Red Hat OpenShift Service Mesh 2.3.4 版中包含的组件版本
组件版本

Istio

1.14.6

Envoy Proxy

1.22.9

Jaeger

1.42.0

Kiali

1.57.9

1.2.2.13. Red Hat OpenShift Service Mesh 版本 2.3.3 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.13.1. Red Hat OpenShift Service Mesh 2.3.3 版中包含的组件版本
组件版本

Istio

1.14.5

Envoy Proxy

1.22.9

Jaeger

1.42.0

Kiali

1.57.7

1.2.2.14. Red Hat OpenShift Service Mesh 版本 2.3.2 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.14.1. Red Hat OpenShift Service Mesh 2.3.2 版中包含的组件版本
组件版本

Istio

1.14.5

Envoy Proxy

1.22.7

Jaeger

1.39

Kiali

1.57.6

1.2.2.15. Red Hat OpenShift Service Mesh 版本 2.3.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本引入了新功能,解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.15.1. Red Hat OpenShift Service Mesh 2.3.1 版中包含的组件版本
组件版本

Istio

1.14.5

Envoy Proxy

1.22.4

Jaeger

1.39

Kiali

1.57.5

1.2.2.16. Red Hat OpenShift Service Mesh 版本 2.3 的新功能

此 Red Hat OpenShift Service Mesh 发行版本引入了新功能,解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.16.1. Red Hat OpenShift Service Mesh 2.3 版中包含的组件版本
组件版本

Istio

1.14.3

Envoy Proxy

1.22.4

Jaeger

1.38

Kiali

1.57.3

1.2.2.16.2. 新的 Container Network Interface (CNI) DaemonSet 容器和 ConfigMap

openshift-operators 命名空间包括一个新的 istio CNI DaemonSet istio-cni-node-v2-3 和一个新的 ConfigMap 资源 istio-cni-config-v2-3

当升级到 Service Mesh Control Plane 2.3 时,现有的 istio-cni-node DaemonSet 不会改变,并创建新的 istio-cni-node-v2-3 DaemonSet。

此名称更改不会影响之前的版本或任何使用上一发行版本的 Service Mesh Control Plane 关联的 istio-cni-node CNI DaemonSet。

1.2.2.16.3. 网关注入支持

此发行版本引入了对网关注入的通用支持。网关配置适用于在网格边缘运行的独立的 Envoy 代理,而不是与您的服务负载一同运行的 sidecar Envoy 代理。这可让自定义网关选项。在使用网关注入时,您必须在要运行网关代理的命名空间中创建以下资源:ServiceDeploymentRoleRoleBinding

1.2.2.16.4. Istio 1.14 支持

Service Mesh 2.3 基于 Istio 1.14,它引入了新功能和产品改进。虽然很多 Istio 1.14 功能被支持,但请注意以下例外:

  • 除 image 字段外,支持 proxyConfig API。
  • Telemetry API 是一个技术预览功能。
  • SPIRE 运行时不受支持。
1.2.2.16.5. OpenShift Service Mesh 控制台
重要

OpenShift Service Mesh 控制台只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

此发行版本引入了 OpenShift Container Platform Service Mesh 控制台的一个技术预览版本,它将 Kiali 界面直接集成到 OpenShift web 控制台中。如需更多信息,请参阅 引入 OpenShift Service Mesh 控制台(技术预览)

1.2.2.16.6. 集群范围的部署
重要

集群范围的部署只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

此发行版本引入了集群范围的部署,作为技术预览功能。集群范围的部署包含一个 Service Mesh Control Plane,它监控整个集群的资源。control plane 对所有命名空间使用一个查询来监控影响网格配置的每个 Istio 或 Kubernetes 资源类型。相反,多租户方法为每个命名空间使用每个命名空间的查询。减少集群范围的部署中 control plane 执行的查询数量可提高性能。

注意

此集群范围的部署文档仅适用于使用 SMCP v2.3 创建的 SMCP v2.3 集群范围的部署,与使用 SMCP v2.4 创建的集群范围的部署不兼容。

1.2.2.16.6.1. 配置集群范围的部署

以下示例 ServiceMeshControlPlane 对象配置集群范围的部署。

要为集群范围的部署创建 SMCP,用户必须属于 cluster-admin ClusterRole。如果为集群范围的部署配置了 SMCP,它必须是集群中的唯一 SMCP。您无法将 control plane 模式从多租户改为集群范围的(或从集群范围到多租户)。如果多租户 control plane 已存在,请删除它并创建新 control plane。

本例为集群范围的部署配置 SMCP。

  apiVersion: maistra.io/v2
  kind: ServiceMeshControlPlane
  metadata:
    name: cluster-wide
    namespace: istio-system
  spec:
    version: v2.3
    techPreview:
      controlPlaneMode: ClusterScoped 1
1
启用 Istiod 监控集群级别的资源,而不是监控每个命名空间。

另外,还必须为集群范围的部署配置 SMMR。本例为集群范围的部署配置 SMMR。

  apiVersion: maistra.io/v1
  kind: ServiceMeshMemberRoll
  metadata:
    name: default
  spec:
    members:
    - '*' 1
1
将所有命名空间添加到网格中,包括您随后创建的任何命名空间。以下命名空间不是网格的一部分:kube、openshift、kube-* 和 openshift-*。

1.2.2.17. Red Hat OpenShift Service Mesh 版本 2.2.12 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.11 及更新的版本的支持。

1.2.2.17.1. Red Hat OpenShift Service Mesh 2.2.12 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.47.0

Kiali

1.48.11

1.2.2.18. Red Hat OpenShift Service Mesh 版本 2.2.11 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.11 及更新的版本的支持。

1.2.2.18.1. Red Hat OpenShift Service Mesh 2.2.11 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.47.0

Kiali

1.48.10

1.2.2.19. Red Hat OpenShift Service Mesh 版本 2.2.10 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.19.1. Red Hat OpenShift Service Mesh 2.2.10 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.42.0

Kiali

1.48.8

1.2.2.20. Red Hat OpenShift Service Mesh 版本 2.2.9 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.20.1. Red Hat OpenShift Service Mesh 2.2.9 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.42.0

Kiali

1.48.7

1.2.2.21. Red Hat OpenShift Service Mesh 版本 2.2.8 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.21.1. Red Hat OpenShift Service Mesh 2.2.8 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.42.0

Kiali

1.48.7

1.2.2.22. Red Hat OpenShift Service Mesh 版本 2.2.7 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.10 及更新的版本的支持。

1.2.2.22.1. Red Hat OpenShift Service Mesh 2.2.7 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.42.0

Kiali

1.48.6

1.2.2.23. Red Hat OpenShift Service Mesh 版本 2.2.6 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.23.1. Red Hat OpenShift Service Mesh 2.2.6 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.39

Kiali

1.48.5

1.2.2.24. Red Hat OpenShift Service Mesh 版本 2.2.5 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.24.1. Red Hat OpenShift Service Mesh 2.2.5 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.39

Kiali

1.48.3

1.2.2.25. New features Red Hat OpenShift Service Mesh version 2.2.4

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.25.1. Red Hat OpenShift Service Mesh 2.2.4 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.36.14

Kiali

1.48.3

1.2.2.26. Red Hat OpenShift Service Mesh 版本 2.2.3 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.26.1. Red Hat OpenShift Service Mesh 2.2.3 版中包含的组件版本
组件版本

Istio

1.12.9

Envoy Proxy

1.20.8

Jaeger

1.36

Kiali

1.48.3

1.2.2.27. Red Hat OpenShift Service Mesh 版本 2.2.2 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.27.1. Red Hat OpenShift Service Mesh 2.2.2 版中包含的组件版本
组件版本

Istio

1.12.7

Envoy Proxy

1.20.6

Jaeger

1.36

Kiali

1.48.2-1

1.2.2.27.2. 复制路由标签

在这个版本中,除了复制注解外,您还可以为 OpenShift 路由复制特定的标签。Red Hat OpenShift Service Mesh 将 Istio 网关资源中存在的所有标签和注解(从 kubectl.kubernetes.io 开始的注解除外)复制到受管 OpenShift Route 资源中。

1.2.2.28. Red Hat OpenShift Service Mesh 版本 2.2.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.28.1. Red Hat OpenShift Service Mesh 2.2.1 版中包含的组件版本
组件版本

Istio

1.12.7

Envoy Proxy

1.20.6

Jaeger

1.34.1

Kiali

1.48.2-1

1.2.2.29. Red Hat OpenShift Service Mesh 2.2 的新功能

此 Red Hat OpenShift Service Mesh 发行版本添加了新的功能和改进,并被 OpenShift Container Platform 4.9 和更新版本支持。

1.2.2.29.1. Red Hat OpenShift Service Mesh 2.2 版中包含的组件版本
组件版本

Istio

1.12.7

Envoy Proxy

1.20.4

Jaeger

1.34.1

Kiali

1.48.0.16

1.2.2.29.2. WasmPlugin API

此发行版本添加了对 WasmPlugin API 的支持,并弃用了 ServiceMeshExtension API。

1.2.2.29.3. ROSA 支持

此发行版本引进了对 AWS(ROSA)上的 Red Hat OpenShift 的服务网格支持,包括多集群联邦。

1.2.2.29.4. istio-node DaemonSet 重命名

在此发行版本中,istio-node DaemonSet 被重命名为 istio-cni-node,以匹配上游 Istio 中的名称。

1.2.2.29.5. Envoy sidecar 网络更改

Istio 1.10 更新了 Envoy,默认使用 eth0 而不是 lo 将流量发送到应用程序容器。

1.2.2.29.6. Service Mesh Control Plane 1.1

对于所有平台,此发行版本结束了对基于 Service Mesh 1.1 的 Service Mesh Control Planes 的支持。

1.2.2.29.7. Istio 1.12 支持

Service Mesh 2.2 基于 Istio 1.12,它带来新功能和产品改进。虽然仍然会支持许多 Istio 1.12 功能,但请注意以下不被支持的功能:

  • AuthPolicy Dry Run 是一个技术预览功能。
  • gRPC Proxyless Service Mesh 是一个技术预览功能。
  • Telemetry API 是一个技术预览功能。
  • 发现选择器功能不受支持。
  • 外部 control plane 不受支持。
  • 网关注入不受支持。
1.2.2.29.8. Kubernetes Gateway API
重要

Kubernetes Gateway API 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

Kubernetes Gateway API 是一个技术预览功能,默认为禁用。如果 Kubernetes API 部署控制器被禁用,您必须手动部署并将入口网关链接到创建的网关对象。

如果启用了 Kubernetes API 部署控制器,则在创建网关对象时,入口网关会自动部署。

1.2.2.29.8.1. 安装 Gateway API CRD

默认情况下,网关 API CRD 不会在 OpenShift 集群中预安装。在 SMCP 中启用网关 API 支持前安装 CRD。

$ kubectl get crd gateways.gateway.networking.k8s.io || { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.0" | kubectl apply -f -; }
1.2.2.29.8.2. 启用 Kubernetes 网关 API

要启用这个功能,请在 ServiceMeshControlPlane 中为 Istiod 容器设置以下环境变量:

spec:
  runtime:
    components:
      pilot:
        container:
          env:
            PILOT_ENABLE_GATEWAY_API: "true"
            PILOT_ENABLE_GATEWAY_API_STATUS: "true"
            # and optionally, for the deployment controller
            PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"

使用 SameNamespaceAll 设置在 Gateway API 监听器上限制路由附加功能可能。Istio 会忽略 listeners.allowedRoutes.namespaces 中标签选择器的使用,并恢复到默认行为 (SameNamespace)。

1.2.2.29.8.3. 手动将现有网关链接到网关资源

如果 Kubernetes API 部署控制器被禁用,您必须手动部署,然后将入口网关链接到创建的网关资源。

  apiVersion: gateway.networking.k8s.io/v1alpha2
  kind: Gateway
  metadata:
    name: gateway
  spec:
    addresses:
    - value: ingress.istio-gateways.svc.cluster.local
      type: Hostname

1.2.2.30. New features Red Hat OpenShift Service Mesh 2.1.6

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.30.1. Red Hat OpenShift Service Mesh 2.1.6 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.5

Jaeger

1.36

Kiali

1.36.16

1.2.2.31. New features Red Hat OpenShift Service Mesh 2.1.5.2

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.31.1. Red Hat OpenShift Service Mesh 2.1.5.2 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.5

Jaeger

1.36

Kiali

1.24.17

1.2.2.32. New features Red Hat OpenShift Service Mesh 2.1.5.1

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.32.1. Red Hat OpenShift Service Mesh 2.1.5.1 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.5

Jaeger

1.36

Kiali

1.36.13

1.2.2.33. Red Hat OpenShift Service Mesh 2.1.5 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题 (CVE),包含程序错误修复,并受 OpenShift Container Platform 4.9 及更新的版本的支持。

1.2.2.33.1. Red Hat OpenShift Service Mesh 2.1.5 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.1

Jaeger

1.36

Kiali

1.36.12-1

1.2.2.34. Red Hat OpenShift Service Mesh 2.1.4 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.34.1. Red Hat OpenShift Service Mesh 2.1.4 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.1

Jaeger

1.30.2

Kiali

1.36.12-1

1.2.2.35. Red Hat OpenShift Service Mesh 2.1.3 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.35.1. Red Hat OpenShift Service Mesh 2.1.3 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.1

Jaeger

1.30.2

Kiali

1.36.10-2

1.2.2.36. Red Hat OpenShift Service Mesh 2.1.2.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.36.1. Red Hat OpenShift Service Mesh 2.1.2.1 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.1

Jaeger

1.30.2

Kiali

1.36.9

1.2.2.37. Red Hat OpenShift Service Mesh 2.1.2 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

在这个版本中,Red Hat OpenShift distributed tracing platform (Jaeger) Operator 被默认安装到 openshift-distributed-tracing 命名空间。在以前的版本中,默认安装已在 openshift-operator 命名空间中。

1.2.2.37.1. Red Hat OpenShift Service Mesh 2.1.2 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.1

Jaeger

1.30.1

Kiali

1.36.8

1.2.2.38. Red Hat OpenShift Service Mesh 2.1.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

此发行版本还添加了禁用自动创建网络策略的功能。

1.2.2.38.1. Red Hat OpenShift Service Mesh 2.1.1 版中包含的组件版本
组件版本

Istio

1.9.9

Envoy Proxy

1.17.1

Jaeger

1.24.1

Kiali

1.36.7

1.2.2.38.2. 禁用网络策略

Red Hat OpenShift Service Mesh 自动在 Service Mesh control plane 和应用程序命名空间中创建和管理多个 NetworkPolicies 资源。这是为了确保应用程序和 control plane 可以相互通信。

如果要禁用自动创建和管理 NetworkPolicies 资源,例如为了强制执行公司安全策略,您可以编辑 ServiceMeshControlPlane,将 spec.security.manageNetworkPolicy 设置设置为 false

注意

当您禁用了 spec.security.manageNetworkPolicy,Red Hat OpenShift Service Mesh 不会创建 任何 NetworkPolicy 对象。系统管理员负责管理网络并修复可能导致的任何问题。

流程

  1. 在 OpenShift Container Platform web 控制台中,点击 OperatorsInstalled Operators
  2. 从 Project 菜单中选择安装 Service Mesh control plane 的项目,如 istio-system
  3. 点 Red Hat OpenShift Service Mesh Operator。在 Istio Service Mesh Control Plane 栏中,点 ServiceMeshControlPlane 的名称,如 basic-install
  4. Create ServiceMeshControlPlane Details 页中,点 YAML 修改您的配置。
  5. ServiceMeshControlPlane 字段 spec.security.manageNetworkPolicy 设置为 false,如下例所示。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
          trust:
          manageNetworkPolicy: false
  6. Save

1.2.2.39. Red Hat OpenShift Service Mesh 2.1 的新功能和增强

此 Red Hat OpenShift Service Mesh 发行版本添加了对 Istio 1.9.8, Envoy Proxy 1.17.1, Jaeger 1.24.1, and Kiali 1.36.5 on OpenShift Container Platform 4.6 EUS, 4.7, 4.8, 4.9 的支持,以及新的功能和增强功能。

1.2.2.39.1. Red Hat OpenShift Service Mesh 2.1 版中包含的组件版本
组件版本

Istio

1.9.6

Envoy Proxy

1.17.1

Jaeger

1.24.1

Kiali

1.36.5

1.2.2.39.2. Service Mesh Federation

添加了新的自定义资源定义(CRD)以支持联邦服务网格(federating service mesh)。服务网格可以整合到同一集群中或跨不同的 OpenShift 集群。这些新资源包括:

  • ServiceMeshPeer - 使用单独的服务网格定义联邦,包括网关配置、root 信任证书配置和状态字段。在一对联邦网格中,每个网格将定义自己的独立 ServiceMeshPeer 资源。
  • ExportedServiceMeshSet - 定义给定 ServiceMeshPeshPeer 的服务可用于导入的对等网格。
  • ImportedServiceSet - 定义给定 ServiceMeshPeer 的服务是从 peer 网格中导入的。这些服务还必须由 peer 的 ExportedServiceMeshSet 资源提供。

在 AWS(ROSA)、Azure Red Hat OpenShift(ARO)或 OpenShift Dedicated(OSD)上的 Red Hat OpenShift Service 上的集群间不支持 Service Mesh Federation。

1.2.2.39.3. OVN-Kubernetes Container Network Interface(CNI)正式发布

OVN-Kubernetes Container Network Interface(CNI)以前在 Red Hat OpenShift Service Mesh 2.0.1 中作为技术预览功能引进,现在包括在 Red Hat OpenShift Service Mesh 2.1 和 2.0.x 中,用于 OpenShift Container Platform 4.7.32、OpenShift Container Platform 4.8.12 和 OpenShift Container Platform 4.9。

1.2.2.39.4. Service Mesh WebAssembly(WASM)扩展

ServiceMeshExtensions 自定义资源定义(CRD)现已正式发布,它首次作为技术预览功能在版本 2.0 中推出。您可以使用 CRD 构建自己的插件,但红帽并不支持您创建的插件。

在 Service Mesh 2.1 中已完全删除 Mixer。如果启用了 Mixer,则会阻止从 Service Mesh 2.0.x 升级到 2.1。混合器插件需要移植到 WebAssembly 扩展。

1.2.2.39.5. 3scale WebAssembly Adapter(WASM)

Mixer 现已正式删除,OpenShift Service Mesh 2.1 不支持 3scale 混合器适配器。在升级到 Service Mesh 2.1 之前,删除基于 Mixer 的 3scale 适配器和任何其他 Mixer 插件。然后,使用 Service MeshExtension 资源手动安装和配置使用 Service Mesh 2.1+ 的新 3scale WebAssembly 适配器。

3scale 2.11 引入了基于 WebAssembly 的更新 Service Mesh 集成。

1.2.2.39.6. Istio 1.9 支持

Service Mesh 2.1 基于 Istio 1.9,它带来了大量新功能和产品增强。虽然大多数 Istio 1.9 功能被支持,但请注意以下例外:

  • 虚拟机集成尚不受支持
  • 尚不支持 Kubernetes 网关 API
  • 尚不支持远程获取和加载 WebAssembly HTTP 过滤器
  • 尚不支持使用 Kubernetes CSR API 的自定义 CA 集成
  • 监控流量的请求分类是一个技术预览功能
  • 通过授权策略的 CUSTOM 操作与外部授权系统集成是一项技术预览功能
1.2.2.39.7. 改进了 Service Mesh operator 性能

Red Hat OpenShift Service Mesh 在每个 ServiceMeshControlPlane 协调结束时用于修剪旧资源的时间已经减少。这会更快地进行 ServiceMeshControlPlane 部署,并允许应用到现有 SMCP 的更改更快地生效。

1.2.2.39.8. Kiali 更新

Kiali 1.36 包括以下功能和增强:

  • Service Mesh 故障排除功能

    • control plane 和网关监控
    • 代理同步状态
    • Envoy 配置视图
    • 显示 Envoy 代理和应用程序日志处于交集的统一视图
  • 支持联邦服务网格视图的命名空间和集群选择
  • 新的验证、向导和分布式追踪增强

1.2.2.40. New features Red Hat OpenShift Service Mesh 2.0.11.1

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题(CVE)、程序错误修正,并受 OpenShift Container Platform 4.9 和更高版本的支持。

1.2.2.40.1. Red Hat OpenShift Service Mesh 2.0.11.1 版中包含的组件版本
组件版本

Istio

1.6.14

Envoy Proxy

1.14.5

Jaeger

1.36

Kiali

1.24.17

1.2.2.41. Red Hat OpenShift Service Mesh 2.0.11 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题(CVE)、程序错误修正,并受 OpenShift Container Platform 4.9 和更高版本的支持。

1.2.2.41.1. Red Hat OpenShift Service Mesh 2.0.11 版中包含的组件版本
组件版本

Istio

1.6.14

Envoy Proxy

1.14.5

Jaeger

1.36

Kiali

1.24.16-1

1.2.2.42. Red Hat OpenShift Service Mesh 2.0.10 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.42.1. Red Hat OpenShift Service Mesh 2.0.10 版中包含的组件版本
组件版本

Istio

1.6.14

Envoy Proxy

1.14.5

Jaeger

1.28.0

Kiali

1.24.16-1

1.2.2.43. Red Hat OpenShift Service Mesh 2.0.9 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.43.1. Red Hat OpenShift Service Mesh 2.0.9 版中包含的组件版本
组件版本

Istio

1.6.14

Envoy Proxy

1.14.5

Jaeger

1.24.1

Kiali

1.24.11

1.2.2.44. Red Hat OpenShift Service Mesh 2.0.8 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了程序错误修正。

1.2.2.45. Red Hat OpenShift Service Mesh 2.0.7.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题。

1.2.2.45.1. Red Hat OpenShift Service Mesh 处理 URI 片段的方式改变

Red Hat OpenShift Service Mesh 包含一个可远程利用的漏洞 CVE-2021-39156,其中 HTTP 请求带有片段(以 # 字符开头的 URI 末尾的一个部分),您可以绕过 Istio URI 基于路径的授权策略。例如,Istio 授权策略拒绝发送到 URI 路径 /user/profile 的请求。在存在安全漏洞的版本中,带有 URI 路径 /user/profile#section1 的请求绕过拒绝策略并路由到后端(通过规范的 URI path /user/profile%23section1),可能会导致安全事件。

如果您使用带有 DENY 操作和 operation.paths 的授权策略,或者 ALLOW 操作和 operation.notPaths,则会受到此漏洞的影响。

在这个版本中,在授权和路由前会删除请求的 URI 片段部分。这可以防止其 URI 中带有片段的请求绕过基于 URI 且没有片段部分的授权策略。

要从缓解措施中的新行为中选择,将保留 URI 的片段部分。您可以将 ServiceMeshControlPlane 配置为保留 URI 片段。

警告

如前文所述,禁用新行为将对路径进行规范化,并被视为不安全。在选择保留 URI 片段之前,确保您已将这些内容放入任何安全策略中。

ServiceMeshControlPlane 修改示例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  techPreview:
    meshConfig:
      defaultConfig:
        proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"

1.2.2.45.2. 授权策略所需的更新

Istio 为主机名本身和所有匹配端口生成主机名。例如,用于 "httpbin.foo" 主机的虚拟服务或网关会生成匹配 "httpbin.foo 和 httpbin.foo:*" 的配置。但是,完全匹配授权策略仅与为 hostsnotHosts 字段给出的确切字符串匹配。

如果您使用精确字符串比较的 AuthorizationPolicy 来确定 主机或非主机,则会影响您的集群。

您必须更新授权策略 规则,以使用前缀匹配而不是完全匹配。例如,在第一个 AuthorizationPolicy 示例中,将 hosts: ["httpbin.com"] 替换为 hosts: ["httpbin.com:*"]

第一个 AuthorizationPolicy 示例使用前缀匹配

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["dev"]
    to:
    - operation:
        hosts: [“httpbin.com”,"httpbin.com:*"]

第二个 AuthorizationPolicy 示例使用前缀匹配

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: default
spec:
  action: DENY
  rules:
  - to:
    - operation:
        hosts: ["httpbin.example.com:*"]

1.2.2.46. Red Hat OpenShift Service Mesh 2.0.7 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.47. Red Hat OpenShift Dedicated 和 Microsoft Azure Red Hat OpenShift 上的 Red Hat OpenShift Service Mesh

Red Hat OpenShift Service Mesh 现在通过 Red Hat OpenShift Dedicated 和 Microsoft Azure Red Hat OpenShift 支持。

1.2.2.48. Red Hat OpenShift Service Mesh 2.0.6 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.49. Red Hat OpenShift Service Mesh 2.0.5 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.50. Red Hat OpenShift Service Mesh 2.0.4 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

重要

要解决 CVE-2021-29492 和 CVE-2021-31920 的问题,则必须完成手动步骤。

1.2.2.50.1. CVE-2021-29492 和 CVE-2021-31920 所需的手动更新

Istio 包含一个可被远程利用的漏洞,当使用基于路径的授权规则时,带有多个斜杠或转义的斜杠字符(%2F%5C)的 HTTP 请求路径可能会绕过 Istio 授权策略。

例如,假设 Istio 集群管理员定义了一个授权 DENY 策略,以便在路径 /admin 上拒绝请求。发送到 URL 路径 //admin 的请求不会被授权策略拒绝。

根据 RFC 3986,带有多个斜杠的路径 //admin 在技术上应被视为与 /admin 不同的路径。但是,一些后端服务选择通过将多个斜杠合并成单斜杠来规范 URL 路径。这可能导致绕过授权策略(//admin 不匹配 /admin),用户可以在后端的路径 /admin 上访问资源,这可能会产生安全问题。

如果您使用 ALLOW action + notPaths 字段或者 DENY action + paths 字段特征,您的集群会受到这个漏洞的影响。这些模式可能会被意外的策略绕过。

在以下情况下,集群不会受到此漏洞的影响:

  • 您没有授权策略。
  • 您的授权策略没有定义 pathsnotPaths 字段。
  • 您的授权策略使用 ALLOW action + paths 字段或 DENY action + notPaths 字段特征。这些模式只会导致意外的拒绝,而不是绕过策略。对于以上情况,升级是可选的。
注意

路径规范化的 Red Hat OpenShift Service Mesh 配置位置与 Istio 配置不同。

1.2.2.50.2. 更新路径规范化配置

Istio 授权策略可能基于 HTTP 请求中的 URL 路径。路径规范化 (也称为 URI 规范化)、修改和标准化传入请求的路径,以便能够以标准的方式处理规范化路径。在路径规范化后,同步不同路径可能是等同的。

Istio 在根据授权策略和路由请求前,支持请求路径中的以下规范化方案:

表 1.1. 规范化方案

OptionDescriptionExample备注

NONE

没有进行规范化。Envoy 接收的任何内容都会完全按原样转发到任何后端服务。

../%2Fa../b 由授权策略评估并发送到您的服务。

此设置会受到 CVE-2021-31920 的影响。

BASE

这是目前 Istio 默认安装中使用的选项。这在 Envoy 代理上应用 normalize_path 选项,该选项在 RFC 3986 之后使用额外的规范化来转换反斜杠来正斜杠。

/a/../b 被规范化为 /b\da 被规范化为 /da

此设置会受到 CVE-2021-31920 的影响。

MERGE_SLASHES

斜杠会在 BASE 规范化后合并。

/a//b 被规范化为 /a/b

更新此设置以缓解 CVE-2021-31920 的问题。

DECODE_AND_MERGE_SLASHES

默认允许所有流量时的最严格设置。建议使用此设置,请注意您必须对您的授权策略路由进行彻底测试。Percent 编码的 斜杠和反斜杠字符(%2F%2f%5C%5c)被解码为 /\,在 MERGE_SLASHES 规范化前。

/a%2fb 规范化为 /a/b

更新此设置以缓解 CVE-2021-31920 的问题。这个设置更为安全,但可能会破坏应用程序。在部署到生产环境中前测试您的应用程序。

规范化算法按以下顺序进行:

  1. 解码百分比 %2F%2f%5C%5c
  2. RFC 3986 和其他在 Envoy 中的 normalize_path 选项实现的规范化。
  3. 合并斜杠。
警告

虽然这些规范化选项代表来自 HTTP 标准和常见行业实践的建议,但应用程序可能会以它选择的任何方式解释 URL。在使用拒绝策略时,请确保您了解应用程序的行为方式。

1.2.2.50.3. 路径规范配置示例

确保 Envoy 规范化请求路径以匹配后端服务的预期,对您的系统安全至关重要。以下示例可用作配置系统的参考。规范化 URL 路径,如果选择 NONE,则原始 URL 路径为:

  1. 用于检查授权策略。
  2. 转发到后端应用程序。

表 1.2. 配置示例

如果您的应用程序…​选择…​

依赖于代理进行规范化

BASEMERGE_SLASHESDECODE_AND_MERGE_SLASHES

根据 RFC 3986 规范化请求路径,且不合并斜杠。

BASE

根据 RFC 3986 和合并斜杠规范化请求路径,但不解码使用百分比编码的斜杠。

MERGE_SLASHES

根据 RFC 3986 规范化请求路径,解码 百分比编码的斜杠以及合并斜杠。

DECODE_AND_MERGE_SLASHES

以与 RFC 3986 不兼容的方式处理请求路径。

NONE

1.2.2.50.4. 为路径规范化配置 SMCP

要为 Red Hat OpenShift Service Mesh 配置路径规范化,请在 ServiceMeshControlPlane 中指定以下内容。使用配置示例来帮助确定您的系统设置。

SMCP v2 路径规范化

spec:
  techPreview:
    global:
      pathNormalization: <option>

1.2.2.50.5. 配置大小写规范化

在某些环境中,在授权策略中对路径进行比较时不区分大小写可能很有用。例如,把 https://myurl/get 视为与 https://myurl/GeT 一样。在这些情况下,您可以使用如下所示的 EnvoyFilter。此过滤器将更改用于比较的路径以及应用程序显示的路径。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

EnvoyFilter 保存到文件中并运行以下命令:

$ oc create -f <myEnvoyFilterFile>
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingress-case-insensitive
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.lua
        typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local path = request_handle:headers():get(":path")
                request_handle:headers():replace(":path", string.lower(path))
              end

1.2.2.51. Red Hat OpenShift Service Mesh 2.0.3 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

另外,这个版本有以下新特性:

  • must-gather 数据收集工具中添加了一个选项,用于从指定的 Service Mesh control plane 命名空间中收集信息。如需更多信息,请参阅 OSSM-351
  • 提高了带有数百个命名空间的 Service Mesh control plane 的性能

1.2.2.52. Red Hat OpenShift Service Mesh 2.0.2 的新功能

此 Red Hat OpenShift Service Mesh 发行版本添加了对 IBM Z 和 IBM Power Systems 的支持。它还解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.53. Red Hat OpenShift Service Mesh 2.0.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了 CVE 报告的安全漏洞问题以及程序错误。

1.2.2.54. Red Hat OpenShift Service Mesh 2.0 的新功能

此 Red Hat OpenShift Service Mesh 发行版本添加了对 Istio 1.6.5、Jaeger 1.20.0、Kiali 1.24.2、3scale Istio Adapter 2.0 和 OpenShift Container Platform 4.6 的支持。

另外,这个版本有以下新特性:

  • 简化了 Service Mesh control plane 的安装、升级和管理。
  • 减少 Service Mesh control plane 的资源使用情况和启动时间。
  • 通过降低网络间 control plane 通讯来提高性能。

    • 添加对 Envoy 的 Secret Discovery Service(SDS)的支持。SDS 是一个更加安全有效地向 Envoy side car proxies 发送 secret 的机制。
  • 不再需要使用具有已知安全风险的 Kubernetes Secret。
  • 在轮转证书的过程中提高了性能,因为代理不再需要重启来识别新证书。

    • 添加了对 Istio Telemetry v2 架构的支持,该架构是由 WebAssembly 扩展构建的。这个新架构带来了显著的性能改进。
    • 使用简化的配置将 ServiceMeshControlPlane 资源更新至 v2,以便更轻松地管理 Service Mesh Control Plane。
    • 增加了 WebAsembly 扩展作为技术预览功能

1.2.3. 技术预览

这个版本中的一些功能当前还处于技术预览状态。它们并不适用于在生产环境中使用。

重要

技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

1.2.4. 弃用和删除的功能

之前版本中的一些功能已被弃用或删除。

弃用的功能仍然包含在 OpenShift Container Platform 中,并将继续被支持。但是,这个功能会在以后的发行版本中被删除,且不建议在新的部署中使用。

删除的功能不再存在于产品中。

1.2.4.1. 弃用和删除的功能 Red Hat OpenShift Service Mesh 2.4

v2.1 ServiceMeshControlPlane 资源不再被支持。客户应升级其网格部署,以使用更新的 ServiceMeshControlPlane 资源版本。

对 Istio OpenShift 路由 (IOR) 的支持已弃用,并将在以后的发行版本中删除。

对 Grafana 的支持已弃用,并将在以后的发行版本中删除。

对 Red Hat OpenShift Service Mesh 2.3 中已弃用的以下密码套件的支持已从客户端和服务器端的 TLS 协商中使用的默认密码列表中删除。当从代理发起 TLS 连接时,需要访问需要这些密码套件之一的服务的应用程序将无法连接。

  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-RSA-AES128-SHA
  • AES128-GCM-SHA256
  • AES128-SHA
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-RSA-AES256-SHA
  • AES256-GCM-SHA384
  • AES256-SHA

1.2.4.2. Red Hat OpenShift Service Mesh 2.3 中已弃用和删除的功能

对以下密码套件的支持已弃用。在以后的发行版本中,它们将从客户端和服务器端的 TLS 协商中使用的默认密码列表中删除。

  • ECDHE-ECDSA-AES128-SHA
  • ECDHE-RSA-AES128-SHA
  • AES128-GCM-SHA256
  • AES128-SHA
  • ECDHE-ECDSA-AES256-SHA
  • ECDHE-RSA-AES256-SHA
  • AES256-GCM-SHA384
  • AES256-SHA

ServiceMeshExtension API 在 Red Hat OpenShift Service Mesh 版本 2.2 中已弃用,在 Red Hat OpenShift Service Mesh 版本 2.3 中删除。如果使用 ServiceMeshExtension API,则必须迁移到 WasmPlugin API 以继续使用 WebAssembly 扩展。

1.2.4.3. Red Hat OpenShift Service Mesh 2.2 中已弃用的功能

ServiceMeshExtension API 从版本 2.2 开始已弃用,并将在以后的版本中删除。虽然 ServiceMeshExtension API 仍然在 2.2 版本中被支持,但客户应该开始使用新的 WasmPlugin API。

1.2.4.4. 删除了 Red Hat OpenShift Service Mesh 2.2 中的功能

对于所有平台,此发行版本结束了对基于 Service Mesh 1.1 的 Service Mesh Control Planes 的支持。

1.2.4.5. 删除了 Red Hat OpenShift Service Mesh 2.1 中的功能

在 Service Mesh 2.1 中,Mixer 组件被删除。程序错误修正和支持会在 Service Mesh 2.0 生命周期结束时提供。

如果启用了 Mixer 插件,则不会从 Service Mesh 2.0.x 升级到 2.1。Mixer 插件必须移植到 WebAssembly 扩展。

1.2.4.6. Red Hat OpenShift Service Mesh 2.0 中已弃用的功能

Mixer 组件在版本 2.0 中已弃用,并将在版本 2.1 中删除。虽然在版本 2.0 中仍支持使用 Mixer 来实现扩展,但扩展应该已迁移到新的 WebAsembly 机制。

Red Hat OpenShift Service Mesh 2.0 不再支持以下资源类型:

  • Policy(策略) (authentication.istio.io/v1alpha1)不再被支持。根据策略资源中的具体配置,您可能需要配置多个资源来达到同样效果。

    • 使用 RequestAuthentication (security.istio.io/v1beta1)
    • 使用 PeerAuthentication (security.istio.io/v1beta1)
  • ServiceMeshPolicy (maistra.io/v1)不再被支持。

    • 使用上述 RequestAuthenticationPeerAuthentication,但放置在 Service Mesh control plane 命名空间中。
  • RbacConfig(rbac.istio.io/v1alpha1)不再被支持。

    • AuthorizationPolicy (security.istio.io/v1beta1)替代,其中包含 RbacConfigServiceRoleServiceRoleBinding 的行为。
  • ServiceMeshRbacConfig( maistra.io/v1)不再被支持。

    • 使用上述 AuthorizationPolicy,但保留在 Service Mesh control plane 命名空间中。
  • ServiceRole(rbac.istio.io/v1alpha1)不再被支持。
  • ServiceRoleBinding(rbac.istio.io/v1alpha1)不再被支持。
  • 在 Kiali 中,loginLDAP 策略已被弃用。将来的版本将引入使用 OpenID 供应商的身份验证。

1.2.5. 已知问题

Red Hat OpenShift Service Mesh 中存在以下限制:

  • Red Hat OpenShift Service Mesh 还没有完全支持 IPv6。因此,Red Hat OpenShift Service Mesh 不支持双栈集群。
  • 图形布局 - Kiali 图形的布局会根据应用程序构架和要显示的数据(图形节点数目及其交互)的不同而有所变化。因为创建一个统一布局的难度较大,所以 Kiali 提供了几种不同布局的选择。要选择不同的布局,可从 Graph Settings 菜单中选择一个不同的 Layout Schema
  • 首次从 Kiali 控制台访问相关服务(如分布式追踪平台 (Jaeger) 和 Grafana)时,必须使用 OpenShift Container Platform 登录凭证接受证书并重新进行身份验证。这是因为框架如何显示控制台中的内置页面中存在问题。
  • Bookinfo 示例应用程序不能安装在 IBM Power、IBM Z 和 IBM® LinuxONE 中。
  • IBM Power、IBM Z 和 IBM® LinuxONE 不支持 WebAsembly 扩展。
  • IBM Power、IBM Z 和 IBM® LinuxONE 不支持 LuaJIT。
  • IBM Power、IBM Z 和 IBM® LinuxONE 上不支持单一堆栈 IPv6。

1.2.5.1. Service Mesh 已知问题

Red Hat OpenShift Service Mesh 有以下已知的问题:

  • OSSM-3890 尝试在多租户网格部署中使用网关 API 会生成类似如下的错误消息:

    2023-05-02T15:20:42.541034Z	error	watch error in cluster Kubernetes: failed to list *v1alpha2.TLSRoute: the server could not find the requested resource (get tlsroutes.gateway.networking.k8s.io)
    2023-05-02T15:20:42.616450Z	info	kube	controller "gateway.networking.k8s.io/v1alpha2/TCPRoute" is syncing...

    要在多租户网格部署中支持网关 API,集群中必须存在所有网关 API 自定义资源定义(CRD)文件。

    在多租户网格部署中,禁用了 CRD 扫描,Istio 无法发现集群中存在哪些 CRD。因此,Istio 会尝试监视所有支持的网关 API CRD,但如果这些 CRD 不存在,则会生成错误。

    Service Mesh 2.3.1 及更新的版本支持 v1alpha2v1beta1 CRD。因此,两个 CRD 版本都必须存在才能多租户网格部署来支持网关 API。

    临时解决方案: 在以下示例中,kubectl get 操作会安装 v1alpha2v1beta1 CRD。请注意,URL 包含额外的 experimental 片段,并相应地更新任何现有脚本:

    $ kubectl get crd gateways.gateway.networking.k8s.io ||   { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.5.1" | kubectl apply -f -; }
  • 名为 default 的 SMCP 的 OSSM-2042 Deployment 失败。如果您要创建 SMCP 对象,并将其 version 字段设置为 v2.3,则对象的名称不能是 default。如果名称是 default,则 control plane 无法部署,OpenShift 会生成带有以下信息的 Warning 事件:

    Error processing component mesh-config: error: [mesh-config/templates/telemetryv2_1.6.yaml: Internal error occurred: failed calling webhook "rev.validation.istio.io": Post "https://istiod-default.istio-system.svc:443/validate?timeout=10s": x509: certificate is valid for istiod.istio-system.svc, istiod-remote.istio-system.svc, istio-pilot.istio-system.svc, not istiod-default.istio-system.svc, mesh-config/templates/enable-mesh-permissive.yaml

  • OSSM-1655 Kiali 仪表板在 SMCP 中启用 mTLS 后显示错误。

    在 SMCP 中启用 spec.security.controlPlane.mtls 设置后,Kiali 控制台会显示以下错误消息 No subsets defined

  • OSSM-1505 只有在 OpenShift Container Platform 4.11 中使用 ServiceMeshExtension 资源时才会发生。当在 OpenShift Container Platform 4.11 上使用 ServiceMeshExtension 时,资源永不会变为就绪。如果使用 oc describe ServiceMeshExtension 检查问题,您会看到以下错误:stderr: Error create mount namespace before pivot: function not implemented

    临时解决方案:ServiceMeshExtension 在 Service Mesh 2.2 中已弃用。从 ServiceMeshExtension 迁移到 WasmPlugin 资源。如需更多信息,请参阅从 ServiceMeshExtension 迁移到 WasmPlugin 资源。

  • OSSM-1396 如果一个网关资源包含 spec.externalIPs 设置,而不是在 ServiceMeshControlPlane 更新时重新创建,则该网关会被删除且永远不会重新创建。
  • OSSM-1168 当以单个 YAML 文件形式创建服务网格资源时,Envoy proxy sidecar 不会可靠地注入 pod。当单独创建 SMCP、SMMR 和 Deployment 资源时,部署可以正常工作。
  • OSSM-1115 spec.proxy API 的 concurrency 字段没有传播到 istio-proxy。当使用 ProxyConfig 设置时,concurrency 字段可以正常工作。concurrency 字段指定要运行的 worker 线程数量。如果字段设为 0,则可用的 worker 线程数量等于 CPU 内核数。如果没有设置该字段,则可使用的 worker 线程数量默认为 2

    在以下示例中,concurrency 字段设置为 0

    apiVersion: networking.istio.io/v1beta1
    kind: ProxyConfig
    metadata:
      name: mesh-wide-concurrency
      namespace: <istiod-namespace>
    spec:
      concurrency: 0
  • OSSM-1052 在为服务网格 control plane 中为 ingressgateway 配置 Service ExternalIP 时,不会创建该服务。SMCP 的 schema 缺少该服务的参数。

    临时解决方案:禁用 SMCP spec 中的网关创建,手动管理网关部署(包括 Service、Role 和 RoleBinding)。

  • OSSM-882 适用于 Service Mesh 2.1 及更早版本。命名空间位于 accessible_namespace 列表中,但不出现在 Kiali UI 中。默认情况下,Kiali 不会显示任何以"kube"开头的命名空间,因为这些命名空间通常仅供内部使用,而不是网格的一部分。

    例如,如果您创建一个名为 'akube-a' 的命名空间并将其添加到 Service Mesh member roll 中,Kiali UI 不会显示这个命名空间。这是因为对于定义的排除特征,软件会排除以定义特征开始或包括定义特征的命名空间。

    临时解决方案:更改 Kiali 自定义资源设置,以便使用尖号 (^) 前缀设置。例如:

    api:
      namespaces:
        exclude:
        - "^istio-operator"
        - "^kube-.*"
        - "^openshift.*"
        - "^ibm.*"
        - "^kiali-operator"
  • MAISTRA-2692 删除了 Mixer,在 Service Mesh 2.0.x 中定义的自定义指标无法在 2.1 中使用。可以使用 EnvoyFilter 配置自定义指标。除非有明确记录,红帽不支持 EnvoyFilter 配置。这是因为与底层 Envoy API 耦合紧密,这意味着无法维护向后兼容性。
  • MAISTRA-2648 服务网格扩展目前与 IBM Z 上部署的网格不兼容。
  • MAISTRA-1959 迁移到 2.0 Prometheus 提取(spec.addons.prometheus.scrape 设置为 true)在启用 mTLS 时无法正常工作。另外,当禁用 mTLS 时,Kiali 会显示无关的图形数据。

    可通过将端口 15020 从代理配置中排除来解决这个问题,例如:

    spec:
      proxy:
        networking:
          trafficControl:
            inbound:
              excludedPorts:
              - 15020
  • MAISTRA-453 如果创建新项目并立即部署 pod,则不会进行 sidecar 注入。在创建 pod 前,operator 无法添加 maistra.io/member-of ,因此必须删除 pod 并重新创建它以执行 sidecar 注入操作。
  • MAISTRA-158 应用指向同一主机名的多个网关时,会导致所有网关停止工作。

1.2.5.2. Kiali 已知问题

注意

Kiali 的新问题应该在 OpenShift Service Mesh 项目中创建,Component 设为 Kiali

Kiali 中已知的问题:

  • KIALI-2206 当您第一次访问 Kiali 控制台时,浏览器中没有 Kiali 的缓存数据,Kiali 服务详情页面的 Metrics 标签页中的 “View in grafana” 链接会重定向到错误的位置。只有在第一次访问 Kiali 才会出现这个问题。
  • KIALI-507 Kiali 不支持 Internet Explorer 11。这是因为底层框架不支持 Internet Explorer。要访问 Kiali 控制台,请使用 Chrome 、Edge 、Firefox 或 Safari 浏览器的两个最新版本之一。

1.2.6. 修复的问题

在当前发行版本中解决了以下问题:

  • OSSM-3647 以前,在 Service Mesh control plane (SMCP) v2.2 (Istio 1.12)中,WasmPlugins 仅适用于入站监听程序。从 SMCP v2.3 (Istio 1.14)开始,WasmPlugins 默认应用于入站和出站监听程序,这为 3scale WasmPlugin 的用户引入了回归。现在,添加了环境变量 APPLY_WASM_PLUGINS_TO_INBOUND_ONLY,它允许从 SMCP v2.2 安全地迁移到 v2.3 和 v2.4。

    以下设置应添加到 SMCP 配置中:

    spec:
      runtime:
        components:
          pilot:
            container:
              env:
                APPLY_WASM_PLUGINS_TO_INBOUND_ONLY: "true"

    要确保安全迁移,请执行以下步骤:

    1. 在 SMCP v2.2 中设置 APPLY_WASM_PLUGINS_TO_INBOUND_ONLY
    2. 升级到 2.4。
    3. 在 WasmPlugins 中设置 spec.match[].mode: SERVER
    4. 删除之前添加的环境变量。

在之前的版本中解决了以下问题:

1.2.6.1. Service Mesh 修复的问题

  • OSSM-4851 以前,当 runAsGrouprunAsUserfsGroup 参数为 nil 时,Operator 在网格内部署新 pod 时会出错。现在,添加了 yaml 验证以避免 nil 值。
  • OSSM-3771 以前,对于 Service Mesh Control Plane (SMCP) 中定义的额外入口网关无法禁用 OpenShift 路由。现在,可以将 routeConfig 块添加到每个 additionalIngress 网关中,以便为每个网关启用或禁用 OpenShift 路由。
  • OSSM-4197 在以前的版本中,如果您部署了 'ServiceMeshControlPlane' 资源的 v2.2 或 v2.1,则不会创建 /etc/cni/multus/net.d/ 目录。因此,istio-cni pod 无法就绪,istio-cni pod 日志包含以下消息:

    $ error   Installer exits with open /host/etc/cni/multus/net.d/v2-2-istio-cni.kubeconfig.tmp.841118073: no such file or directory

    现在,如果您部署 'ServiceMeshControlPlane' 资源的 v2.2 或 v2.1,则 /etc/cni/multus/net.d/ 目录已创建,并且 istio-cni pod 变为 ready。

  • OSSM-3993 之前,Kiali 只通过标准 HTTPS 端口 443 上的代理支持 OpenShift OAuth。现在,Kiali 通过非标准 HTTPS 端口支持 OpenShift OAuth。要启用端口,您必须将 spec.server.web_port 字段设置为 Kiali CR 中的代理的非标准 HTTPS 端口。
  • OSSM-3936 在之前的版本中,injection_label_revinjection_label_name 属性的值被硬编码。这导致自定义配置无法在 Kiali 自定义资源定义(CRD)中生效。现在,属性值不会被硬编码。您可以在 spec.istio_labels 规格中自定义 injection_label_revinjection_label_name 属性的值。
  • OSSM-3644 以前,联邦 egress-gateway 收到网络网关端点的错误更新,从而导致额外的端点条目。现在,在服务器端更新了 federation-egress 网关,以便它接收正确的网络网关端点。
  • OSSM-3595 以前,istio-cni 插件有时会在 RHEL 上失败,因为 SELinux 不允许工具 iptables-restore 打开 /tmp 目录中的文件。现在,SELinux 通过 stdin 输入流而不是通过一个文件传递 iptables-restore
  • OSSM-3586 之前,当 Google Cloud Platform (GCP) 元数据服务器不可用时,Istio 代理会较慢。当您升级到 Istio 1.14.6 时,Istio 代理会在 GCP 上按预期启动,即使元数据服务器不可用。
  • OSSM-3025 Istiod 有时无法就绪。有时,当网格包含很多成员命名空间时,为因为 Istiod 中的死锁 导致 Istiod pod 未就绪。现在,死锁已被解决,pod 现在会如预期启动。
  • OSSM-2493 SMCP 中的默认 nodeSelectortolerations 不会传递给 Kiali。您添加到 SMCP.spec.runtime.defaultsnodeSelectortolerations 现在可以传递给 Kiali 资源。
  • OSSM-2492 默认容限没有传递给 Jaeger。您添加到 SMCP.spec.runtime.defaultsnodeSelectortolerations 现在可以传递给 Jaeger 资源。
  • OSSM-2374 如果您删除了其中一个 ServiceMeshMember 资源,则 Service Mesh operator 会删除 ServiceMeshMemberRoll。虽然当您删除最后一个 ServiceMeshMember 时这是预期的行为,但如果它还包含任何成员,Operator 不应该删除 ServiceMeshMemberRoll。这个问题现已解决,Operator 仅在最后一个 ServiceMeshMember 资源被删除时才删除 ServiceMeshMemberRoll。
  • OSSM-2373 登录时尝试获取 OAuth 元数据的错误。要获取集群版本,请使用 system:anonymous 帐户。使用集群的默认捆绑的 ClusterRole 和 ClusterRoleBinding,匿名帐户可以正确地获取版本。如果 system:anonymous 帐户丢失了获取集群版本的权限,OpenShift 身份验证将不可用。

    这个问题已通过使用 Kiali SA 获取集群版本来解决。这可以提高集群上的安全性。

  • OSSM-2371 虽然 Kiali 配置为 "view-only",但用户可以通过 Workload details 的 kebab 菜单更改代理日志级别。这个问题已被解决,当 Kiali 配置为 "view-only" 时,"Set Proxy Log Level" 下的选项被禁用。
  • OSSM-2344 重启 Istiod 会导致 Kiali 使用 port-forward 请求大量 CRI-O。当 Kiali 无法连接到 Istiod,而 Kiali 同时向 istiod 发出大量请求时会出现这种情况。Kiali 现在限制它发送到 istiod 的请求数。
  • OSSM-2335 将鼠标指针拖放到 Traces scatterchart 图表上,有时会导致 Kiali 控制台因为并发后端请求停止响应。
  • OSSM-2221 以前,ServiceMeshControlPlane 命名空间中的网关注入无法进行,因为 ignore-namespace 标签默认应用到命名空间。

    在创建 v2.4 control plane 时,命名空间不再应用 ignore-namespace 标签,并可进行网关注入。

    在以下示例中,oc label 命令从现有部署中的命名空间中删除 ignore-namespace 标签:

    $ oc label namespace <istio_system> maistra.io/ignore-namespace-

    在上例中,<istio_system> 代表 ServiceMeshControlPlane 命名空间的名称。

  • OSSM-2053 使用 Red Hat OpenShift Service Mesh Operator 2.2 或 2.3,在 SMCP 协调过程中,SMMR 控制器会从 SMMR.status.configuredMembers 中删除成员命名空间。这会导致成员命名空间中的服务在一些时间不可用。

    使用 Red Hat OpenShift Service Mesh Operator 2.2 或 2.3,SMMR 控制器不再从 SMMR.status.configuredMembers 中删除命名空间。相反,控制器会将命名空间添加到 SMMR.status.pendingMembers 中,以指示它们不是最新的。在协调过程中,因为每个命名空间与 SMCP 同步,命名空间会自动从 SMMR.status.pendingMembers 中删除。

  • OSSM-1962 在联邦控制器中使用 EndpointSlices。联邦控制器现在使用 EndpointSlices,这可以提高大型部署中的可扩展性和性能。默认情况下启用 PILOT_USE_ENDPOINT_SLICE 标志。禁用标志可防止使用联邦部署。
  • OSSM-1668 一个新的字段 spec.security.jwksResolverCA 已添加到版本 2.1 SMCP 中,但没有存在于 2.2.0 和 2.2.1 版本中。当从存在此字段的 Operator 版本升级到缺少此字段的 Operator 版本时,则 SMCP 中没有 .spec.security.jwksResolverCA 字段。
  • OSSM-1325 istiod pod 崩溃并显示以下出错信息:fatal error: concurrent map iteration and map write
  • OSSM-1211 为故障转移配置联邦服务网格无法正常工作。

    Istiod pilot 日志显示以下错误: envoy connection [C289] TLS error: 337047686:SSL routines:tls_process_server_certificate:certificate verify failed

  • OSSM-1099 Kiali 控制台显示消息 Sorry, there was a problem.Try a refresh or navigate to a different page.
  • OSSM-1074 Pod 注解没有在 pod 中注入。
  • OSSM-999 Kiali retention 无法按预期工作。仪表板图中的日历时间会被问候。
  • OSSM-797 Kiali Operator pod 在安装或更新 Operator 时生成 CreateContainerConfigError
  • kube 开始的 OSSM-722 命名空间从 Kiali 中隐藏。
  • OSSM-569 Prometheus istio-proxy 容器没有 CPU 内存限值。Prometheus istio-proxy sidecar 现在使用 spec.proxy.runtime.container 中定义的资源限值。
  • OSSM-535 支持 SMCP 中的验证消息。Service Mesh Control Plane 中的 ValidationMessages 字段现在可以设置为 True。这会写入资源状态的日志,这在进行故障排除时很有用。
  • OSSM-449 VirtualService 和 Service 会导致一个错误 - "Only unique values for domains are permitted.Duplicate entry of domain."
  • 具有类似名称的 OSSM-419 命名空间都显示在 Kiali 命名空间列表中,即使命名空间可能无法在 Service Mesh Member Role 中定义。
  • OSSM-296 当在 Kiali 自定义资源(CR)中添加健康配置时,不会将其复制到 Kiali configmap 中。
  • OSSM-291 在 Kiali 控制台中,在 Applications、Services 和 Workloads 页面中,"Remove Label from Filters"功能无法正常工作。
  • OSSM-289 在 Kiali 控制台中,'istio-ingressgateway' 和 'jaeger-query' 服务的服务详情页面中没有显示 Traces。Jaeger 中存在 trace。
  • OSSM-287 在 Kiali 控制台中没有显示 Graph 服务中的 trace。
  • OSSM-285 试图访问 Kiali 控制台时会收到以下错误消息:"Error trying to get OAuth Metadata"。

    临时解决方案:重启 Kiali pod。

  • MAISTRA-2735 当 Red Hat OpenShift Service Mesh 2.1 中协调 SMCP 更改时,Service Mesh Operator 会删除的资源。在以前的版本中,Operator 删除了带有以下标签的资源:

    • maistra.io/owner
    • app.kubernetes.io/version

    现在,Operator 会忽略没有包括 app.kubernetes.io/managed-by=maistra-istio-operator 标签的资源。如果创建自己的资源,则不应将 app.kubernetes.io/managed-by=maistra-istio-operator 标签添加到其中。

  • MAISTRA-2687 Red Hat OpenShift Service Mesh 2.1 联邦网关在使用外部证书时不会发送完整的证书链。Service Mesh 联邦出口网关仅发送客户端证书。因为联邦入口网关只知道 root 证书,所以它无法验证客户端证书,除非您将 root 证书添加到联合导入 ConfigMap 中。
  • MAISTRA-2635 替换已弃用的 Kubernetes API。从 Red Hat OpenShift Service Mesh 2.0.8 开始,为保持与 OpenShift Container Platform 4.8 的兼容性,apiextensions.k8s.io/v1beta1 API 已被弃用。
  • MAISTRA-2631 WASM 功能不起作用,因为 podman 因 nsenter 二进制不存在而失败。Red Hat OpenShift Service Mesh 生成以下出错信息:Error: error configuring CNI network plugin exec: "nsenter": executable file not found in $PATH。容器镜像现在包含 nsenter,WASM 可以正常工作。
  • MAISTRA-2534 当 istiod 试图为 JWT 规则中指定的签发者获取 JWKS 时,签发者服务会使用 502 响应。这导致代理容器就绪,并导致部署挂起。Service Mesh 2.0.7 版本中包括了对社区程序漏洞的修复。
  • MAISTRA-2411 当 Operator 使用 ServiceMeshControlPlane 中的 spec.gateways.additionaIngress 创建新的入口网关时,Operator 不会为额外的入口网关创建一个 NetworkPolicy,如默认的 istio-ingressgateway。这导致了来自新网关路由的 503 响应。

    临时解决方案:在 <istio-system> 命名空间中手动创建 NetworkPolicy

  • MAISTRA-2401 CVE-2021-3586 servicemesh-operator:NetworkPolicy 资源为 ingress 资源指定错误的端口。为 Red Hat OpenShift Service Mesh 安装的 NetworkPolicy 资源没有正确指定可访问哪些端口。这允许从任何 pod 访问这些资源上的所有端口。应用到以下资源的网络策略会受到影响:

    • Galley
    • Grafana
    • Istiod
    • Jaeger
    • Kiali
    • Prometheus
    • Sidecar injector
  • MAISTRA-2378 当集群被配置为使用带有 ovs-multitenant 的 OpenShiftSDN,且网格包含大量命名空间(200+),OpenShift Container Platform 网络插件无法快速配置命名空间。Service Mesh 超时会导致从服务网格中持续丢弃命名空间,然后重新加入。
  • MAISTRA-2370 Handle tombstones in listerInformer。在将事件从命名空间缓存转换为聚合缓存时,更新的缓存代码库没有处理 tombstones,从而导致在 go 中出现 panic 的问题。
  • MAISTRA-2117 向 operator 添加可选的 ConfigMap 挂载。CSV 现在包含一个可选的 ConfigMap 卷挂载,它会挂载 smcp-templates ConfigMap (如果存在)。如果 smcp-templates ConfigMap 不存在,则挂载的目录为空。创建 ConfigMap 时,目录会填充 ConfigMap 中的条目,并可在 SMCP.spec.profiles 中引用。不需要重启 Service Mesh operator。

    使用带有修改 CSV 的 2.0 operator 挂载 smcp-templates ConfigMap 的用户可升级到 Red Hat OpenShift Service Mesh 2.1。升级后,您可以继续使用现有的 ConfigMap 及其包含的配置集,而无需编辑 CSV。以前使用不同名称的 ConfigMap 的客户需要重命名 ConfigMap 或升级后更新 CSV。

  • MAISTRA-2010 AuthorizationPolicy 不支持 request.regex.headers 字段。validatingwebhook 会拒绝任何带有字段的 AuthorizationPolicy,即使您禁用该字段,Pilot 也会尝试使用相同的代码验证它,且它无法正常工作。
  • MAISTRA-1979 迁移至 2.0 在将 SMCP.status 从 v2 转换为 v1 时,转换 Webhook 会丢弃以下重要字段:

    • conditions
    • components
    • observedGeneration
    • annotations

      将 operator 升级到 2.0 可能会破坏使用 maistra.io/v1 版本读取 SMCP 状态的客户端工具。

      这还会导致在运行 oc get servicemeshcontrolplanes.v1.maistra.io 时 READY 和 STATUS 列为空。

  • MAISTRA-1947 技术预览 更新至 ServiceMeshExtensions 不会被应用。

    临时解决方案:删除并重新创建 ServiceMeshExtensions

  • MAISTRA-1983 迁移到 2.0 把带有存在无效 ServiceMeshControlPlane 的系统升级到 2.0.0 的问题无法被简单修复。ServiceMeshControlPlane 资源中的无效项会导致无法恢复的错误。在这个版本中,这个错误可以被恢复。您可以删除无效的资源,并将其替换为新资源或编辑资源来修复错误。有关编辑资源的更多信息,请参阅 [配置 Red Hat OpenShift Service Mesh 安装]。
  • MAISTRA-1502 由于在版本 1.0.10 中修复了 CVE,Istio 仪表板将不会出现在 Grafana 的 Home Dashboard 菜单中。要访问 Istio 仪表板,点导航面板中的 Dashboard 菜单,然后选择 Manage 选项卡。
  • MAISTRA-1399 Red Hat OpenShift Service Mesh 不再阻止您安装不支持的 CNI 协议。支持的网络配置没有改变。
  • MAISTRA-1089 迁移到在非 control plane 命名空间中创建的 2.0 网关将自动删除。从 SMCP spec 中删除网关定义后,您需要手动删除这些资源。
  • MAISTRA-858 Envoy 日志中以下与 与 Istio 1.1.x 相关的弃用选项和配置相关的信息是正常的:

    • [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] Using deprecated option 'envoy.api.v2.listener.Filter.config'。This configuration will be removed from Envoy soon.
    • [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] Using deprecated option 'envoy.api.v2.Listener.use_original_dst' from file LDS.proto。This configuration will be removed from Envoy soon.
  • MAISTRA-806 被逐出的 Istio Operator Pod 会导致 mesh 和 CNI 不能被部署。

    临时解决方案:如果在部署 control pane 时 istio-operator pod 被逐出,删除被逐出的 istio-operator pod。

  • MAISTRA-681 当 Service Mesh control plane 有多个命名空间时,可能会导致出现性能问题。
  • MAISTRA-193 当为 citadel 启用了健康检查功能时,会出现预期外的控制台信息。
  • Bugzilla 1821432 OpenShift Container Platform 自定义资源详情页面中的切换控件无法正确更新 CR。OpenShift Container Platform Web 控制台中的 Service Mesh Control Plane (smcp) Overview 页面中的 UI 切换控制有时会更新资源中的错误字段。要更新 SMCP,直接编辑 YAML 内容,或者从命令行更新资源,而不是点击 toggle 控件。

1.3. 了解 Service Mesh

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

1.3.1. 了解服务网格

服务网格(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 平台来监控、网络性能分析,并对现代、云原生的微服务应用程序中组件间的交互进行故障排除。

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

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

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

1.3.4.2. Red Hat OpenShift distributed tracing Platform 架构

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

  • 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 存储的可插拔机制。请注意:在这个发行本中,唯一支持的存储是 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 详情。
  • 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 是默认位置检测库来导出其遥测数据。

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. 后续步骤

1.4. 服务网格部署模型

Red Hat OpenShift Service Mesh 支持几种不同的部署模型,它们可以以不同的方式组合以满足您的业务需求。

在 Istio 中,租户是为一组部署的工作负载共享共同访问权限和特权的用户组。您可以使用租户在不同的团队之间提供一定程度的隔离。您可以使用 istio.io 或服务资源的 NetworkPoliciesAuthorizationPoliciesexportTo 注解来隔离对不同租户的访问。

1.4.1. Cluster-Wide (Single Tenant) 网格部署模型

集群范围的部署包含一个 Service Mesh Control Plane,它监控整个集群的资源。监控整个集群的资源与 control plane 在所有命名空间中使用单个查询来监控 Istio 和 Kubernetes 资源的 Istio 功能非常相似。因此,集群范围的部署会减少发送到 API 服务器的请求数。

与 Istio 类似,集群范围的网格默认包括带有 istio-injection=enabled 命名空间标签的命名空间。您可以通过修改 ServiceMeshMemberRoll 资源的 spec.labelSelectors 字段来更改此标签。

1.4.2. 多租户部署模型

Red Hat OpenShift Service Mesh 安装了一个 ServiceMeshControlPlane,它默认配置为多租户。Red Hat OpenShift Service Mesh 使用多租户 Operator 来管理 Service Mesh control plane 生命周期。在网格内,命名空间用于租期。

Red Hat OpenShift Service Mesh 使用 ServiceMeshControlPlane 资源来管理网格安装,该安装范围默认限制为包含资源的命名空间。您可以使用 ServiceMeshMemberRollServiceMeshMember 资源在网格中包含额外的命名空间。命名空间只能包含在单个网格中,多个网格也可以安装到单个 OpenShift 集群中。

典型的服务网格部署使用单一 Service Mesh control plane 来配置网格中服务间的通信。Red Hat OpenShift Service Mesh 支持"软多租户",其中每个租户有一个 control plane 和一个网格,并且集群中可以有多个独立的 control plane。多租户部署指定可以访问 Service Mesh 的项目,并将 Service Mesh 与其他 control plane 实例隔离。

集群管理员在所有 Istio control plane 间获得控制和可见性,而租户管理员只能控制其特定的 Service Mesh、Kiali 和 Jaeger 实例。

您可以授予团队权限,以便仅将工作负载部署到给定的命名空间或一组命名空间。如果服务网格管理员授予 mesh-user 角色,用户可以创建一个 ServiceMeshMember 资源来将命名空间添加到 ServiceMeshMemberRoll

1.4.3. Multimesh 或联邦部署模型

Federation(联邦) 是一种部署模型,可让您在不同管理域中管理的单独网格间共享服务和工作负载。

Istio 多集群模型需要在网格和远程访问独立网格所在的所有 Kubernetes API 服务器之间具有高度信任。Red Hat OpenShift Service Mesh 联邦针对 Service Mesh 的多集群实施,该方法假设网格之间的信任最小

联邦网格(federated mesh) 是作为单个网格组成的一组网格。每个网格中的服务可以是独特的服务,例如通过从另一个网格中导入服务的网格添加服务,可以为网格中的相同服务提供额外的工作负载,提供高可用性或两者的组合。加入联邦的所有网格都保持单独管理,您必须明确配置要导出哪些服务并从联邦中的其他网格导入。证书生成、指标和追踪集合等支持功能在其各自网格中保持本地。

1.5. Service Mesh 和 Istio 的不同

Red Hat OpenShift Service Mesh 与 Istio 安装的不同之处在于提供额外功能或在 OpenShift Container Platform 上部署时处理不同之处。

1.5.1. Istio 和 Red Hat OpenShift Service Mesh 之间的区别

Service Mesh 和 Istio 中的以下功能不同。

1.5.1.1. 命令行工具

Red Hat OpenShift Service Mesh 的命令行工具是 oc。  Red Hat OpenShift Service Mesh 不支持 istioctl

1.5.1.2. 安装和升级

Red Hat OpenShift Service Mesh 不支持 Istio 安装配置集。

Red Hat OpenShift Service Mesh 不支持 service mesh 的 Canary 升级。

1.5.1.3. 自动注入

上游 Istio 社区安装会在您标记的项目中自动将 sidecar 注入 pod。

Red Hat OpenShift Service Mesh 不会自动将 sidecar 注入任何 pod,而是要求您选择使用没有标记项目的注解注入。这个方法需要较少的权限,且不会与其他 OpenShift Container Platform 功能冲突,比如 builder pod。要启用自动注入,请指定 sidecar.istio.io/inject 标签或注解,如自动 sidecar 注入部分所述。

表 1.3. sidecar 注入标签和注解设置

 上游 IstioRed Hat OpenShift Service Mesh

命名空间标签

支持"启用"和"禁用"

支持"禁用"

Pod 标签

支持 "true" 和 "false"

支持 "true" 和 "false"

Pod 注解

只支持 "false"

支持 "true" 和 "false"

1.5.1.4. Istio 基于角色的访问控制功能

Istio 基于角色的访问控制 (RBAC) 提供了可用来控制对某个服务的访问控制机制。您可以根据用户名或者指定一组属性来识别对象,并相应地应用访问控制。

上游 Istio 社区安装提供的选项包括:标头精确匹配、匹配标头中的通配符,或匹配标头中包括的特定前缀或后缀。

Red Hat OpenShift Service Mesh 使用正则表达式来扩展与请求标头匹配的功能。使用正则表达式指定 request.regex.headers 的属性键。

上游 Istio 社区匹配请求标头示例

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-usernamepolicy
spec:
  action: ALLOW
  rules:
    - when:
        - key: 'request.regex.headers[username]'
          values:
            - "allowed.*"
  selector:
    matchLabels:
      app: httpbin

1.5.1.5. OpenSSL

Red Hat OpenShift Service Mesh 将 BoringSSL 替换为 OpenSSL。OpenSSL 是包含安全套接字层 (SSL) 和传输层 (TLS) 协议的开源实现的软件库。Red Hat OpenShift Service Mesh Proxy 二进制代码动态地将 OpenSSL 库(libssl 和 libcrypto)与底层的 Red Hat Enterprise Linux 操作系统进行链接。

1.5.1.6. 外部工作负载

Red Hat OpenShift Service Mesh 不支持外部工作负载,如在裸机服务器上运行的虚拟机。

1.5.1.7. 虚拟机支持

您可以使用 OpenShift Virtualization 将虚拟机部署到 OpenShift。然后,您可以将网格策略(如 mTLS 或 AuthorizationPolicy)应用到这些虚拟机,就像其它属于网格的 pod 一样。

1.5.1.8. 组件修改

  • maistra-version 标签已添加到所有资源中。
  • 所有 Ingress 资源都已转换为 OpenShift Route 资源。
  • Grafana、分布式追踪(Jaeger)和 Kiali 会被默认启用,并通过 OpenShift 路由公开。
  • Godebug 已从所有模板中删除
  • istio-multi ServiceAccount 和 ClusterRoleBinding 已被删除,同时也删除了 istio-reader ClusterRole。

1.5.1.9. Envoy 过滤器

Red Hat OpenShift Service Mesh 不支持 EnvoyFilter 配置,除非明确记录。由于与底层 Envoy API 紧密耦合,因此无法保持向后兼容性。EnvoyFilter 补丁对 Istio 生成的 Envoy 配置格式非常敏感。如果 Istio 生成的配置有变化,则代表可能会破坏 EnvoyFilter 的应用程序。

1.5.1.10. Envoy 服务

Red Hat OpenShift Service Mesh 不支持基于 QUIC 的服务。

1.5.1.11. Istio Container Network Interface (CNI) 插件

Red Hat OpenShift Service Mesh 包括 CNI 插件,它为您提供了配置应用程序 pod 网络的替代方法。CNI 插件替代了 init-container 网络配置,可在不需要提高访问权限的情况下赋予服务帐户和项目对安全上下文约束 (SCC) 的访问。

1.5.1.12. 全局 mTLS 设置

Red Hat OpenShift Service Mesh 创建一个 PeerAuthentication 资源,在网格内启用或禁用 Mutual TLS 身份验证 (mTLS)。

1.5.1.13. 网关

Red Hat OpenShift Service Mesh 默认安装入口和出口网关。您可以使用以下设置在 ServiceMeshControlPlane (SMCP) 资源中禁用网关安装:

  • spec.gateways.enabled=false 可禁用入口和出口网关。
  • spec.gateways.ingress.enabled=false 禁用入口网关。
  • spec.gateways.egress.enabled=false 禁用出口网关。
注意

Operator 注解了默认网关,以指示它们由 Red Hat OpenShift Service Mesh Operator 生成并管理。

1.5.1.14. 多集群配置

Red Hat OpenShift Service Mesh 对多集群配置的支持仅限于跨多个集群的服务网格的联邦。

1.5.1.15. 自定义证书签名请求 (CSR)

您无法将 Red Hat OpenShift Service Mesh 配置为通过 Kubernetes 证书颁发机构 (CA) 处理 CSR。

1.5.1.16. Istio 网关的路由

Istio 网关的 OpenShift 路由在 Red Hat OpenShift Service Mesh 中被自动管理。每次在 service mesh 中创建、更新或删除 Istio 网关时,都会自动创建、更新或删除 OpenShift 路由。

名为 Istio OpenShift Routing (IOR) 的 Red Hat OpenShift Service Mesh control plane 组件可以用来同步网关路由。如需更多信息,请参阅自动路由创建。

1.5.1.16.1. catch-all 域

不支持 Catch-all("*")。如果在网关定义中找到一个,Red Hat OpenShift Service Mesh 创建路由,但会依赖于 OpenShift 来创建一个默认主机名。这意味着新创建的路由不是 catch all ("*") 路由,而是使用 <route-name> [-<project>].<suffix> 格式的主机名。如需有关默认主机名的工作方式以及 cluster-admin 如何自定义它的更多信息,请参阅 OpenShift Container Platform 文档。如果使用 Red Hat OpenShift Dedicated,请参阅 Red Hat OpenShift Dedicated 的 dedicated-admin 角色。

1.5.1.16.2. 子域

支持子域(例如:"*.domain.com")。但是,OpenShift Container Platform 中不默认启用此功能。这意味着,Red Hat OpenShift Service Mesh 使用子域创建路由,但只有在 OpenShift Container Platform 被配置为启用它时才有效。

1.5.1.16.3. 传输层安全性

支持传输层安全性(TLS)。这意味着,如果网关包含 tls 部分,OpenShift Route 将配置为支持 TLS。

其他资源

1.5.2. 多租户安装

上游 Istio 采用单一租户方法,Red Hat OpenShift Service Mesh 支持集群中的多个独立的 control plane。Red Hat OpenShift Service Mesh 使用多租户 Operator 来管理 control plane 生命周期。

Red Hat OpenShift Service Mesh 默认安装多租户 control plane。您可以指定可以访问 Service Mesh 的项目,并将 Service Mesh 与其他 control plane 实例隔离。

1.5.2.1. 多租户和集群范围的安装

多租户安装和集群范围安装之间的主要区别在于使用的权限范围。组件不再使用集群范围的 Role Based Access Control(RBAC)资源 ClusterRoleBinding

ServiceMeshMemberRoll members 列表中的每个项目都将为每个与 control plane 部署关联的服务帐户都有一个 RoleBinding,每个 control plane 部署只会监视这些成员项目。每个成员项目都有一个 maistra.io/member-of 标签,其中 member-of 值是包含 control plane 安装的项目。

Red Hat OpenShift Service Mesh 配置每个成员项目以确保自身、control plane 和其它成员项目间的网络连接。具体的配置根据 OpenShift Container Platform 软件定义网络 (SDN) 的配置而有所不同。更多详情请参阅“关于 OpenShift SDN”。

如果 OpenShift Container Platform 集群被配置为使用 SDN 插件:

  • NetworkPolicy: Red Hat OpenShift Service Mesh 在每个成员项目中创建一个 NetworkPolicy 资源,允许从其它成员和 control plane 到 pod 的入站网络数据。如果从 Service Mesh 中删除了一个成员,则这个 NetworkPolicy 资源会从项目中删除。

    注意

    这也限制了到成员项目的入站网络数据。如果需要来自非成员项目的入站网络数据,则需要创建一个 NetworkPolicy 来允许这些流量通过。

  • Multitenant: Red Hat OpenShift Service Mesh 将每个成员项目的 NetNamespace 加入到 control plane 项目的 NetNamespace (相当于运行 oc adm pod-network join-projects --to control-plane-project member-project)。如果您从 Service Mesh 中删除一个成员,它的 NetNamespace 与 control plane 分离(相当于运行 oc adm pod-network is isolatedate-projects member-project)。
  • Subnet:没有执行其他配置。

1.5.2.2. 集群范围内的资源

上游 Istio 会依赖于两个集群范围的资源。MeshPolicyClusterRbacConfig。它们与多租户集群不兼容并已被替换,如下所述。

  • ServiceMeshPolicy 替换了用于配置 control-plane-wide 验证策略的 MeshPolicy。这必须与 control plane 在同一个项目中创建。
  • ServicemeshRbacConfig 替换 ClusterRbacConfig 以配置基于 control-plane 范围角色的访问控制。这必须与 control plane 在同一个项目中创建。

1.5.3. Kiali 和服务网格

通过 OpenShift Container Platform 上的 Service Mesh 安装 Kiali 与社区 Kiali 安装不同。为了解决问题、提供额外功能或处理不同之处,这些不同有时是必须的。

  • Kiali 已被默认启用。
  • 默认启用 Ingress 。
  • 对 Kiali ConfigMap 进行了更新。
  • 对 Kiali 的 ClusterRole 设置进行了更新。
  • 不要编辑 ConfigMap,因为您的更改可能会被 Service Mesh 或 Kiali Operator 覆盖。Kiali Operator 管理的文件有 kiali.io/ 标签或注解。更新 Operator 文件应仅限于具有 cluster-admin 权限的用户。如果使用 Red Hat OpenShift Dedicated,则更新 Operator 文件应该仅限于具有 dedicated-admin 权限的用户。

1.5.4. 分布式追踪和服务网格

使用 OpenShift Container Platform 上的 Service Mesh 安装分布式追踪平台 (Jaeger) 与社区 Jaeger 安装不同。为了解决问题、提供额外功能或处理不同之处,这些不同有时是必须的。

  • Service Mesh 默认启用分布式追踪。
  • 为 Service Mesh 默认启用 ingress 。
  • Zipkin 端口名称已改为 jaeger-collector-zipkin(从 http
  • 当选择 productionstreaming 部署选项时,Jaeger 会默认使用 Elasticsearch 作为存储。
  • Istio 的社区版本提供了一个通用的 “tracing” 路由。Red Hat OpenShift Service Mesh 使用由 Red Hat OpenShift distributed tracing Platform (Jaeger) Operator 安装的 "jaeger" 路由,并已受到 OAuth 的保护。
  • Red Hat OpenShift Service Mesh 为 Envoy proxy 使用 sidecar,Jaeger 也为 Jaeger agent 使用 sidecar。这两个 sidecar 是单独配置的,不应该相互混淆。proxy sidecar 会创建和 pod 的入站和出站相关的 span。agent sidecar 收到应用程序提供的 span ,并将其发送到 Jaeger 收集器。

1.6. 准备安装 Service Mesh

在安装 Red Hat OpenShift Service Mesh 之前,您必须订阅 OpenShift Container Platform 并在支持的配置中安装 OpenShift Container Platform。

1.6.1. 先决条件

如需有关 Red Hat OpenShift Service Mesh 生命周期和支持的平台的更多信息,请参阅支持政策

1.6.2. 支持的配置

Red Hat OpenShift Service Mesh 当前发行版本支持以下配置。

1.6.2.1. 支持的平台

Red Hat OpenShift Service Mesh Operator 支持 ServiceMeshControlPlane 资源的多个版本。在以下平台版本中支持以下 2.4 Service Mesh control plane:

  • Red Hat OpenShift Container Platform 版本 4.10 或更高版本。
  • Red Hat OpenShift Dedicated 版本 4。
  • Azure Red Hat OpenShift (ARO) 版本 4。
  • Red Hat OpenShift Service on AWS (ROSA)。

1.6.2.2. 不支持的配置

明确不支持的情形包括:

  • OpenShift Online 不支持 Red Hat OpenShift Service Mesh。
  • Red Hat OpenShift Service Mesh 不支持在 Service Mesh 集群外部管理微服务。

1.6.2.3. 支持的网络配置

Red Hat OpenShift Service Mesh 支持以下网络配置。

  • OpenShift-SDN
  • OVN-Kubernetes 在所有支持的 OpenShift Container Platform 版本中可用。
  • 在 OpenShift Container Platform 上认证并通过 Service Mesh 一致性测试的第三方 Container Network Interface(CNI)插件。如需更多信息,请参阅认证的 OpenShift CNI 插件

1.6.2.4. Service Mesh 支持的配置

  • 此 Red Hat OpenShift Service Mesh 发行版本仅适用于 OpenShift Container Platform x86_64、IBM Z 和 IBM Power。

    • IBM Z 只在 OpenShift Container Platform 4.10 及更新的版本中被支持。
    • IBM Power 只在 OpenShift Container Platform 4.10 及更新的版本中被支持。
  • 将所有 Service Mesh 组件包含在单个 OpenShift Container Platform 集群中的配置。
  • 不集成外部服务的配置,如虚拟机。
  • Red Hat OpenShift Service Mesh 不支持 EnvoyFilter 配置,除非明确记录。

1.6.2.5. Kiali 支持的配置

  • Kiali 控制台只支持 Google Chrome、Microsoft Edge、Mozilla Firefox 或 Apple Safari 浏览器的两个最新版本。
  • 当使用 Red Hat OpenShift Service Mesh (OSSM) 部署 Kiali 时,openshift 验证策略是唯一受支持的身份验证配置。openshift 策略根据 OpenShift Container Platform 的独立基于角色的访问控制 (RBAC) 角色来控制访问。

1.6.2.6. 分布式追踪支持的配置

  • Jaeger 代理是 Jaeger 唯一支持的配置。多租户安装或 OpenShift Dedicated 不支持 Jaeger 作为 daemonset。

1.6.2.7. 支持的 WebAssembly 模块

  • 3scale WebAssembly 是唯一提供 WebAssembly 模块。您可以创建自定义 WebAssembly 模块。

1.6.3. 后续步骤

1.7. 安装 Operator

要安装 Red Hat OpenShift Service Mesh,首先在 OpenShift Container Platform 上安装所需的 Operator,然后创建一个 ServiceMeshControlPlane 资源来部署 control plane。

注意

这一基本安装根据默认的 OpenShift 设置进行配置,不并是针对生产环境用途而设计的。  使用此默认安装验证您的安装,然后为特定环境配置服务网格。

前提条件

以下步骤演示了如何在 OpenShift Container Platform 上安装 Red Hat OpenShift Service Mesh 的基本实例。

1.7.1. Operator 概述

Red Hat OpenShift Service Mesh 需要以下四个 Operator:

  • OpenShift Elasticsearch -(可选)为使用分布式追踪平台 (Jaeger) 进行追踪和日志记录提供数据库存储。它基于开源 Elasticsearch 项目。
  • Red Hat OpenShift distributed tracing 平台 (Jaeger) - 提供分布式追踪以监控复杂分布式系统中的事务并进行故障排除。它基于开源 Jaeger 项目。
  • 红帽提供的 Kiali Operator - 为您的服务网格提供可观察性。您可以在单个控制台中查看配置、监控流量和分析 trace。它基于开源 Kiali 项目。
  • Red Hat OpenShift Service Mesh - 允许您连接、保护、控制和观察组成应用程序的微服务。Service Mesh Operator 定义并监控管理 ServiceMeshControlPlane 资源,这个资源用来管理 Service Mesh 组件的部署、更新和删除操作。它基于开源 Istio 项目。
警告

不要安装 Operators 的 Community 版本。不支持社区 Operator。

1.7.2. 安装 Operator

要安装 Red Hat OpenShift Service Mesh,请按照以下顺序安装 Operator。为每个 Operator 重复上述步骤。

  • OpenShift Elasticsearch
  • Red Hat OpenShift distributed tracing Platform (Jaeger)
  • 红帽提供的 Kiali Operator
  • Red Hat OpenShift Service Mesh
注意

如果您已经安装了 OpenShift Elasticsearch Operator 作为 OpenShift Logging 的一部分,则不需要再次安装 OpenShift Elasticsearch Operator。Red Hat OpenShift distributed tracing Platform (Jaeger) Operator 将使用已安装的 OpenShift Elasticsearch Operator 创建 Elasticsearch 实例。

流程

  1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  2. 在 OpenShift Container Platform Web 控制台中,点击 OperatorsOperatorHub
  3. 在过滤器框中输入 Operator 名称,再选择 Operator 的 Red Hat 版本。不支持 Operator 的社区版本。
  4. Install
  5. 在每个 Operator 的 Install Operator 页面中,接受默认设置。
  6. Install。等待 Operator 安装完毕,然后为列表中的下一个 Operator 重复这些步骤。

    • OpenShift Elasticsearch Operator 安装在 openshift-operators-redhat 命名空间中,并可用于集群中的所有命名空间。
    • Red Hat OpenShift distributed tracing 平台 (Jaeger) 安装在 openshift-distributed-tracing 命名空间中,可用于集群中的所有命名空间。
    • 由红帽提供的 Kiali Operator 和 Red Hat OpenShift Service Mesh Operator 安装在 openshift-operators 命名空间中,并可用于集群中的所有命名空间。
  7. 安装完所有四个 Operator 后,点 OperatorsInstalled Operators 来验证是否安装了您的 Operator。

1.7.3. 将 Service Mesh Operator 配置为在基础架构节点上运行

只有在 Service Mesh Operator 在基础架构节点上运行时才会执行此任务。

如果 Operator 将在 worker 节点上运行,请跳过此任务。

前提条件

  • 必须安装 Service Mesh Operator。
  • 组成部署的节点之一必须是基础架构节点。如需更多信息,请参阅"创建基础架构机器集"。

流程

  1. 列出命名空间中安装的 Operator:

    $ oc -n openshift-operators get subscriptions
  2. 编辑 Service Mesh Operator Subscription 资源,以指定 Operator 应该运行的位置:

    $ oc -n openshift-operators edit subscription <name> 1
    1
    <name> 代表 Subscription 资源的名称。Subscription 资源的默认名称为 servicemeshoperator
  3. Subscription 资源中将 nodeSelectortolerations 添加到 spec.config 中:

    spec:
      config:
        nodeSelector: 1
          node-role.kubernetes.io/infra: ""
        tolerations: 2
        - effect: NoSchedule
          key: node-role.kubernetes.io/infra
          value: reserved
        - effect: NoExecute
          key: node-role.kubernetes.io/infra
          value: reserved
    1
    确保 Operator pod 仅调度到基础架构节点上。
    2
    确保基础架构节点接受 pod。

1.7.4. 验证 Service Mesh Operator 在基础架构节点上运行

流程

  • 验证与 Operator pod 关联的节点是否是一个基础架构节点:

    $ oc -n openshift-operators get po -l name=istio-operator -owide

1.7.5. 后续步骤

  • 在部署 Service Mesh control plane 前,Red Hat OpenShift Service Mesh Operator 不会创建 Service Mesh 自定义资源定义 (CRD)。您可以使用 ServiceMeshControlPlane 资源来安装和配置 Service Mesh 组件。如需更多信息,请参阅创建 ServiceMeshControlPlane

1.8. 创建 ServiceMeshControlPlane

1.8.1. 关于 ServiceMeshControlPlane

control plane 包括 Istiod、Ingress 和 Egress 网关,以及其他组件,如 Kiali 和 Jaeger。control plane 必须部署到与 Service Mesh Operator 和 data plane 应用程序和服务不同的命名空间中。您可以从 OpenShift Container Platform Web 控制台或使用 oc 客户端工具从命令行部署 ServiceMeshControlPlane (SMCP) 的基本安装。

注意

这个基本安装是基于默认的 OpenShift Container Platform 设置配置的,它不适用于生产环境。使用此默认安装来验证安装,然后为您的环境配置 ServiceMeshControlPlane 设置。

注意

Red Hat OpenShift Service on AWS(ROSA)会对您可以创建资源的位置有额外的限制,这会导致默认部署无法正常工作。在 ROSA 环境中部署 SMCP 前,请参阅在 AWS 上安装 Red Hat OpenShift Service Mesh 以了解额外的要求。

注意

Service Mesh 文档使用 istio-system 作为示例项目,但您可以将服务网格部署到任何项目中。

1.8.1.1. 从 web 控制台部署 Service Mesh control plane

您可以使用 Web 控制台部署基本 ServiceMeshControlPlane。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

前提条件

  • 必须安装 Red Hat OpenShift Service Mesh Operator。
  • 具有 cluster-admin 角色的帐户。

流程

  1. 以具有 cluster-admin 角色的用户身份登录到 OpenShift Container Platform web 控制台。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  2. 创建一个名为 istio-system 的项目。

    1. 浏览至 HomeProject
    2. 点击 Create Project
    3. Name 字段中输入 istio-systemServiceMeshControlPlane 资源必须安装在独立于您的微服务和 Operator 的项目中。

      这些步骤使用 istio-system 作为示例,但您可以在任何项目中部署 Service Mesh control plane,只要它与包含您的服务的项目分开。

    4. Create
  3. 导航到 OperatorsInstalled Operators
  4. 点 Red Hat OpenShift Service Mesh Operator,然后点 Istio Service Mesh Control Plane
  5. Istio Service Mesh Control Plane 选项卡中,点 Create ServiceMeshControlPlane
  6. Create ServiceMeshControlPlane 页面中,接受默认的 Service Mesh control plane 版本,以利用该产品的最新版本中提供的功能。control plane 的版本决定了与 Operator 版本无关的可用功能。

    1. Create。Operator 根据您的配置参数创建 pod、服务和 Service Mesh control plane 组件。您可以在以后配置 ServiceMeshControlPlane 设置。
  7. 要验证 control plane 是否已正确安装,请点击 Istio Service Mesh Control Plane 标签页。

    1. 点新的 control plane 的名称。
    2. Resources 标签页来查看由 Operator 创建并配置的 Red Hat OpenShift Service Mesh control plane 资源。

1.8.1.2. 使用 CLI 部署 Service Mesh control plane

您可以使用命令行部署基本的 ServiceMeshControlPlane

前提条件

  • 必须安装 Red Hat OpenShift Service Mesh Operator。
  • 访问 OpenShift CLI(oc)。

流程

  1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. 创建一个名为 istio-system 的项目。

    $ oc new-project istio-system
  3. 使用以下示例,创建一个名为 istio-installation.yamlServiceMeshControlPlane 文件。Service Mesh control plane 的版本决定了与 Operator 版本无关的可用功能。

    版本 2.4 istio-installation.yaml 示例

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
      namespace: istio-system
    spec:
      version: v2.4
      tracing:
        type: Jaeger
        sampling: 10000
      addons:
        jaeger:
          name: jaeger
          install:
            storage:
              type: Memory
        kiali:
          enabled: true
          name: kiali
        grafana:
          enabled: true

  4. 运行以下命令来部署 Service Mesh control plane,其中 <istio_installation.yaml> 包含到您的文件的完整路径。

    $ oc create -n istio-system -f <istio_installation.yaml>
  5. 要观察 pod 部署的进度,请运行以下命令:

    $ oc get pods -n istio-system -w

    您应该看到类似如下的输出:

    NAME                                   READY   STATUS    RESTARTS   AGE
    grafana-b4d59bd7-mrgbr                 2/2     Running   0          65m
    istio-egressgateway-678dc97b4c-wrjkp   1/1     Running   0          108s
    istio-ingressgateway-b45c9d54d-4qg6n   1/1     Running   0          108s
    istiod-basic-55d78bbbcd-j5556          1/1     Running   0          108s
    jaeger-67c75bd6dc-jv6k6                2/2     Running   0          65m
    kiali-6476c7656c-x5msp                 1/1     Running   0          43m
    prometheus-58954b8d6b-m5std            2/2     Running   0          66m

1.8.1.3. 使用 CLI 验证 SMCP 安装

您可以从命令行验证 ServiceMeshControlPlane 创建。

流程

  1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。

    $ oc login https://<HOSTNAME>:6443
  2. 运行以下命令,以验证 Service Mesh control plane 安装,其中 istio-system 是安装 Service Mesh control plane 的命名空间。

    $ oc get smcp -n istio-system

    STATUS 列是 ComponentsReady 时,安装成功完成。

    NAME    READY   STATUS            PROFILES      VERSION   AGE
    basic   10/10   ComponentsReady   ["default"]   2.1.1     66m

1.8.2. 关于 control plane 组件和基础架构节点

基础架构节点提供了一种出于两个主要目的来隔离基础架构工作负载的方法:

  • 要防止发生订阅数量的计费成本
  • 分离基础架构工作负载的维护和管理

您可以将部分或所有 Service Mesh control plane 组件配置为在基础架构节点上运行。

1.8.2.1. 使用 Web 控制台将所有 control plane 组件配置为在基础架构节点上运行

如果 Service Mesh control plane 部署的所有组件都在基础架构节点上运行,请执行此任务。这些部署的组件包括 Istiod、Ingress Gateway 和 Egress 网关,以及 Prometheus、Grafana 和分布式跟踪等可选应用程序。

如果 control plane 将在 worker 节点上运行,请跳过此任务。

前提条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 以具有 cluster-admin 角色的用户身份登录。如果使用 Red Hat OpenShift Dedicated,则以具有 dedicated-admin 角色的用户身份登录。

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. 导航到 OperatorsInstalled Operators
  3. 点 Red Hat OpenShift Service Mesh Operator,然后点 Istio Service Mesh Control Plane
  4. 点 control plane 资源的名称。例如,basic
  5. YAML
  6. nodeSelectortolerations 字段添加到 ServiceMeshControlPlane 资源的 spec.runtime.defaults.pod 规格中,如下例所示:

    spec:
      runtime:
        defaults:
          pod:
            nodeSelector: 1
              node-role.kubernetes.io/infra: ""
            tolerations: 2
            - effect: NoSchedule
              key: node-role.kubernetes.io/infra
              value: reserved
            - effect: NoExecute
              key: node-role.kubernetes.io/infra
              value: reserved
    1
    确保 ServiceMeshControlPlane pod 仅调度到基础架构节点上。
    2
    确保基础架构节点接受执行 pod。
  7. Save
  8. Reload

1.8.2.2. 使用 Web 控制台将独立的 control plane 组件配置为在基础架构节点上运行

如果 Service Mesh control plane 部署的独立组件在基础架构节点上运行,请执行此任务。这些部署的组件包括 Istiod、Ingress Gateway 和 Egress Gateway。

如果 control plane 将在 worker 节点上运行,请跳过此任务。

前提条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 以具有 cluster-admin 角色的用户身份登录。如果使用 Red Hat OpenShift Dedicated,则以具有 dedicated-admin 角色的用户身份登录。

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. 导航到 OperatorsInstalled Operators
  3. 点 Red Hat OpenShift Service Mesh Operator,然后点 Istio Service Mesh Control Plane
  4. 点 control plane 资源的名称。例如,basic
  5. YAML
  6. nodeSelectortolerations 字段添加到 ServiceMeshControlPlane 资源中的 spec.runtime.components.pilot.pod 规格中,如下例所示:

    spec:
      runtime:
        components:
          pilot:
            pod:
              nodeSelector: 1
                node-role.kubernetes.io/infra: ""
              tolerations: 2
              - effect: NoSchedule
                key: node-role.kubernetes.io/infra
                value: reserved
              - effect: NoExecute
                key: node-role.kubernetes.io/infra
                value: reserved
    1
    确保 Istiod pod 仅调度到基础架构节点上。
    2
    确保基础架构节点接受执行 pod。
  7. nodeSelectortolerations 字段添加到 ServiceMeshControlPlane 资源中的 spec.gateways.ingress.runtime.podspec.gateways.egress.runtime.pod 规格中,如下例所示:

    spec:
      gateways:
        ingress:
          runtime:
            pod:
              nodeSelector: 1
                node-role.kubernetes.io/infra: ""
              tolerations: 2
              - effect: NoSchedule
                key: node-role.kubernetes.io/infra
                value: reserved
              - effect: NoExecute
                key: node-role.kubernetes.io/infra
                value: reserved
        egress:
          runtime:
            pod:
              nodeSelector: 3
                node-role.kubernetes.io/infra: ""
              tolerations: 4
              - effect: NoSchedule
                key: node-role.kubernetes.io/infra
                value: reserved
              - effect: NoExecute
                key: node-role.kubernetes.io/infra
                value: reserved
    1 3
    确保网关 pod 仅调度到基础架构节点上
    2 4
    确保基础架构节点接受执行 pod。
  8. Save
  9. Reload

1.8.2.3. 使用 CLI 将所有 control plane 组件配置为在基础架构节点上运行

如果 Service Mesh control plane 部署的所有组件都在基础架构节点上运行,请执行此任务。这些部署的组件包括 Istiod、Ingress Gateway 和 Egress 网关,以及 Prometheus、Grafana 和分布式跟踪等可选应用程序。

如果 control plane 将在 worker 节点上运行,请跳过此任务。

前提条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 以具有 cluster-admin 角色的用户身份登录。如果使用 Red Hat OpenShift Dedicated,则以具有 dedicated-admin 角色的用户身份登录。

流程

  1. 以 YAML 文件的形式打开 ServiceMeshControlPlane 资源:

    $ oc -n istio-system edit smcp <name> 1
    1
    <name> 代表 ServiceMeshControlPlane 资源的名称。
  2. 要在基础架构节点上运行 ServiceMeshControlPlane 部署的所有 Service Mesh 组件,请将 nodeSelectortolerations 字段添加到 ServiceMeshControlPlane 资源中的 spec.runtime.defaults.pod spec 中:

    spec:
      runtime:
        defaults:
          pod:
            nodeSelector: 1
              node-role.kubernetes.io/infra: ""
            tolerations: 2
            - effect: NoSchedule
              key: node-role.kubernetes.io/infra
              value: reserved
            - effect: NoExecute
              key: node-role.kubernetes.io/infra
              value: reserved
    1
    确保 SMCP pod 仅调度到基础架构节点上。
    2
    确保基础架构节点接受 pod。

1.8.2.4. 使用 CLI 将各个 control plane 组件配置为在基础架构节点上运行

如果 Service Mesh control plane 部署的独立组件在基础架构节点上运行,请执行此任务。这些部署的组件包括 Istiod、Ingress Gateway 和 Egress Gateway。

如果 control plane 将在 worker 节点上运行,请跳过此任务。

前提条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 以具有 cluster-admin 角色的用户身份登录。如果使用 Red Hat OpenShift Dedicated,则以具有 dedicated-admin 角色的用户身份登录。

流程

  1. 以 YAML 文件形式打开 ServiceMeshControlPlane 资源。

    $ oc -n istio-system edit smcp <name> 1
    1
    <name> 代表 ServiceMeshControlPlane 资源的名称。
  2. 要在基础架构节点上运行 Istiod 组件,请将 nodeSelectortolerations 字段添加到 ServiceMeshControlPlane 资源中的 spec.runtime.components.pilot.pod spec 中。

    spec:
      runtime:
        components:
          pilot:
            pod:
              nodeSelector: 1
                node-role.kubernetes.io/infra: ""
              tolerations: 2
              - effect: NoSchedule
                key: node-role.kubernetes.io/infra
                value: reserved
              - effect: NoExecute
                key: node-role.kubernetes.io/infra
                value: reserved
    1
    确保 Istiod pod 仅调度到基础架构节点上。
    2
    确保基础架构节点接受 pod。
  3. 要在基础架构节点上运行 Ingress 和 Egress Gateways,请将 nodeSelectortolerations 字段添加到 ServiceMeshControlPlane 资源中的 spec.gateways.ingress.runtime.pod spec 和 spec.gateways.egress.runtime.pod spec 中。

    spec:
      gateways:
        ingress:
          runtime:
            pod:
              nodeSelector: 1
                node-role.kubernetes.io/infra: ""
              tolerations: 2
              - effect: NoSchedule
                key: node-role.kubernetes.io/infra
                value: reserved
              - effect: NoExecute
                key: node-role.kubernetes.io/infra
                value: reserved
        egress:
          runtime:
            pod:
              nodeSelector: 3
                node-role.kubernetes.io/infra: ""
              tolerations: 4
              - effect: NoSchedule
                key: node-role.kubernetes.io/infra
                value: reserved
              - effect: NoExecute
                key: node-role.kubernetes.io/infra
                value: reserved
    1 3
    确保网关 pod 仅调度到基础架构节点上
    2 4
    确保基础架构节点接受 pod。

1.8.2.5. 验证 Service Mesh control plane 在基础架构节点上运行

流程

  • 确认与 Istiod、Ingress Gateway 和 Egress Gateway pod 关联的节点是基础架构节点:

    $ oc -n istio-system get pods -owide

1.8.3. 关于 control plane 和集群范围的部署

集群范围的部署包含一个 Service Mesh Control Plane,它监控整个集群的资源。监控整个集群的资源与 control plane 在所有命名空间中使用单个查询来监控 Istio 和 Kubernetes 资源的 Istio 功能非常相似。因此,集群范围的部署会减少发送到 API 服务器的请求数。

您可以使用 OpenShift Container Platform Web 控制台或 CLI 为集群范围的部署配置 Service Mesh Control Plane。

1.8.3.1. 使用 web 控制台为集群范围的部署配置 control plane

您可以使用 OpenShift Container Platform Web 控制台为集群范围的部署配置 ServiceMeshControlPlane 资源。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

前提条件

  • 安装了 Red Hat OpenShift Service Mesh Operator。
  • 您可以使用具有 cluster-admin 角色的帐户登录,或者将 Red Hat OpenShift Dedicated 与 dedicated-admin 角色搭配使用。

流程

  1. 创建一个名为 istio-system 的项目。

    1. 浏览至 HomeProject
    2. 点击 Create Project
    3. Name 字段中输入 istio-systemServiceMeshControlPlane 资源必须安装在独立于您的微服务和 Operator 的项目中。

      这些步骤使用 istio-system 作为示例。只要 Service Mesh control plane 与包含服务的项目分开,就可以将 Service Mesh control plane 部署到任何项目中。

    4. Create
  2. 导航到 OperatorsInstalled Operators
  3. 点 Red Hat OpenShift Service Mesh Operator,然后点 Istio Service Mesh Control Plane
  4. Istio Service Mesh Control Plane 选项卡中,点 Create ServiceMeshControlPlane
  5. YAML 视图。Service Mesh control plane 的版本决定了与 Operator 版本无关的可用功能。
  6. 修改 YAML 文件的 spec.mode 字段,以指定 ClusterWide

    版本 2.4 istio-installation.yaml 示例

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
      namespace: istio-system
    spec:
      version: v2.4
      mode: ClusterWide

  7. Create。Operator 根据您的配置参数创建 pod、服务和 Service Mesh control plane 组件。如果 ServiceMeshMemberRoll 不存在,Operator 也会创建 ServiceMeshMemberRoll。
  8. 要验证 control plane 是否已正确安装,请点 Istio Service Mesh Control Plane 选项卡。

    1. 点新 ServiceMeshControlPlane 对象的名称。
    2. Resources 选项卡,查看 Operator 创建和配置的 Red Hat OpenShift Service Mesh control plane 资源。

此模块包含在以下 assemblies: * service_mesh/v2x/ossm-create-smcp.adoc :_mod-docs-content-type: PROCEDURE

1.8.3.2. 使用 CLI 为集群范围的部署配置 control plane

您可以使用 CLI 为集群范围的部署配置 ServiceMeshControlPlane 资源。在本例中,istio-system 是 Service Mesh control plane 命名空间的名称。

前提条件

  • 安装了 Red Hat OpenShift Service Mesh Operator。
  • 您可以访问 OpenShift CLI(oc)。

流程

  1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. 创建一个名为 istio-system 的项目。

    $ oc new-project istio-system
  3. 使用以下示例,创建一个名为 istio-installation.yamlServiceMeshControlPlane 文件。

    版本 2.4 istio-installation.yaml 示例

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
      namespace: istio-system
    spec:
      version: v2.4
      mode: ClusterWide

  4. 运行以下命令来部署 Service Mesh control plane,其中 <istio_installation.yaml> 包含到您的文件的完整路径。

    $ oc create -n istio-system -f <istio_installation.yaml>
  5. 要监控 pod 部署的进度,请运行以下命令:

    $ oc get pods -n istio-system -w

    您应该看到类似以下示例的输出:

    输出示例

    NAME                                   READY   STATUS    RESTARTS   AGE
    grafana-b4d59bd7-mrgbr                 2/2     Running   0          65m
    istio-egressgateway-678dc97b4c-wrjkp   1/1     Running   0          108s
    istio-ingressgateway-b45c9d54d-4qg6n   1/1     Running   0          108s
    istiod-basic-55d78bbbcd-j5556          1/1     Running   0          108s
    jaeger-67c75bd6dc-jv6k6                2/2     Running   0          65m
    kiali-6476c7656c-x5msp                 1/1     Running   0          43m
    prometheus-58954b8d6b-m5std            2/2     Running   0          66m

此模块包含在以下 assemblies: * service_mesh/v2x/ossm-create-smcp.adoc 中

1.8.3.3. 为集群范围的网格自定义 member roll

在集群范围的模式中,当您创建 ServiceMeshControlPlane 资源时,也会创建 ServiceMeshMemberRoll 资源。您可以在创建 ServiceMeshMemberRoll 资源后修改它。修改资源后,Service Mesh Operator 不再更改它。如果使用 OpenShift Container Platform Web 控制台修改 ServiceMeshMemberRoll 资源,请接受提示来覆盖修改。

另外,您可以在部署 ServiceMeshControlPlane 资源前创建一个 ServiceMeshMemberRoll 资源。在创建 ServiceMeshControlPlane 资源时,Service Mesh Operator 不会修改 ServiceMeshMemberRoll

注意

ServiceMeshMemberRoll 资源名称必须命名为 default,且必须与 ServiceMeshControlPlane 资源在同一项目命名空间中创建。

将命名空间添加到网格的方法有两种。您可以通过在 spec.members 列表中指定名称来添加命名空间,或者将一组命名空间标签选择器配置为根据其标签包含或排除命名空间。

注意

无论您在 ServiceMeshMemberRoll 资源中如何指定成员,您也可以通过在每个命名空间中创建 ServiceMeshMember 资源,将成员添加到网格中。

1.8.4. 使用 Kiali 验证 SMCP 安装

您可以使用 Kiali 控制台验证 Service Mesh 安装。Kiali 控制台提供了一种方式来验证您的 Service Mesh 组件是否已正确部署和配置。

流程

  1. 以具有 cluster-admin 权限的用户身份登录到 OpenShift Container Platform web 控制台。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  2. 进入 NetworkingRoutes
  3. Routes 页面中,从 Namespace 菜单中选择 Service Mesh control plane 项目,如 istio-system

    Location 列显示每个路由的链接地址。

  4. 如果需要,使用过滤器查找 Kiali 控制台的路由。单击路由 位置 以启动控制台。
  5. 单击 Log In With OpenShift

    第一次登录到 Kiali 控制台时,您会看到 Overview 页面,它会显示服务网格中您有权查看的所有命名空间。当 Overview 页中显示多个命名空间,Kiali 会首先显示具有健康或验证问题的命名空间。

    图 1.1. Kiali Overview 页

    Kiali Overview 页显示 istio-system

    每个命名空间的 tile 会显示标签数量、Istio 配置健康、和 应用程序 健康状态的数量,以及命名空间的流量。如果您验证了控制台安装,且命名空间还没有添加到网格中,则可能无法显示 istio-system 以外的任何数据。

  6. Kiali 有四个仪表板,专门用于安装了 Service Mesh control plane 的命名空间。要查看这些仪表板,请点击 control plane 命名空间的标题 kebabOptions 菜单,如 istio-system,然后选择以下选项之一:

    • Istio Mesh Dashboard
    • Istio Control Plane Dashboard
    • Istio Performance Dashboard
    • Istio Wasm Exetension Dashboard

      图 1.2. Grafana Istio Control Plane Dashboard

      Istio Control Plane Dashboard 显示 info 示例项目的数据

      Kiali 还会安装两个额外的 Grafana 仪表板,它们可从 Grafana Home 页面获得:

    • Istio Workload Dashboard
    • Istio Service Dashboard
  7. 要查看 Service Mesh control plane 节点,点 Graph 页面,从菜单中选择安装 ServiceMeshControlPlane命名空间,如 istio-system

    1. 如有必要,请单击 Display idle nodes
    2. 要了解更多有关 Graph 页面的信息,请点击 Graph tour 链接。
    3. 要查看网格拓扑,请从 Namespace 菜单中从 Service Mesh Member Roll 中选择一个或多个附加命名空间。
  8. 要查看 istio-system 命名空间中的应用程序列表,请点击 Applications 页面。Kiali 显示应用程序的健康状况。

    1. 将鼠标指针悬停在信息图标上,以查看 Details 列中记下的任何其他信息。
  9. 要在 istio-system 命名空间中查看工作负载列表,请点击 Workloads 页面。Kiali 显示工作负载的运行状况。

    1. 将鼠标指针悬停在信息图标上,以查看 Details 列中记下的任何其他信息。
  10. 要查看 istio-system 命名空间中的服务列表,点 Services 页面。Kiali 显示服务和配置的健康状态。

    1. 将鼠标指针悬停在信息图标上,以查看 Details 列中记下的任何其他信息。
  11. 要查看 istio-system 命名空间中的 Istio Configuration 对象列表,点 Istio Config 页面。Kiali 显示配置的健康状况。

    1. 如果出现配置错误,点行,Kiali 会打开配置文件并突出显示错误。

1.8.5. Installing on Red Hat OpenShift Service on AWS (ROSA)

从 2.2 版本开始,Red Hat OpenShift Service Mesh 支持在 AWS 上的 Red Hat OpenShift Service(ROSA)上安装。本节记录了在这个平台上安装 Service Mesh 时的额外要求。

1.8.5.1. 安装位置

在安装 Red Hat OpenShift Service Mesh 并创建 ServiceMeshControlPlane 时,您必须创建一个新命名空间,如 istio-system

1.8.5.2. 所需的 Service Mesh control plane 配置

ServiceMeshControlPlane 文件中的默认配置无法在 ROSA 集群中工作。在 AWS 上的 Red Hat OpenShift Service 上安装时,您必须修改默认的 SMCP 并设置 spec.security.identity.type=ThirdParty

ROSA 的 ServiceMeshControlPlane 资源示例

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
  namespace: istio-system
spec:
  version: v2.4
  security:
    identity:
      type: ThirdParty  #required setting for ROSA
  tracing:
    type: Jaeger
    sampling: 10000
  policy:
    type: Istiod
  addons:
    grafana:
      enabled: true
    jaeger:
      install:
        storage:
          type: Memory
    kiali:
      enabled: true
    prometheus:
      enabled: true
  telemetry:
    type: Istiod

1.8.5.3. 对 Kiali 配置的限制

Red Hat OpenShift Service on AWS 对创建资源并不允许在 Red Hat managed 命名空间中创建 Kiali 资源方面存在额外的限制。

这意味着,在 ROSA 集群中不允许使用 spec.deployment.access_namespaces 的以下通用设置:

  • ['**'] (所有命名空间)
  • default
  • codeready-*
  • openshift-*
  • redhat-*

验证错误消息提供了所有受限命名空间的完整列表。

ROSA 的 Kiali 资源示例

apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  name: kiali
  namespace: istio-system
spec:
  auth:
    strategy: openshift
  deployment:
    accessible_namespaces:   #restricted setting for ROSA
      - istio-system
    image_pull_policy: ''
    ingress_enabled: true
    namespace: istio-system

1.8.6. 其他资源

Red Hat OpenShift Service Mesh 支持集群中的多个独立 control plane。您可以使用 ServiceMeshControlPlane 配置集创建可重复使用的配置。如需更多信息,请参阅创建 control plane 配置集

1.8.7. 后续步骤

1.9. 在服务网格中添加服务

一个项目会包含服务;但是,只有在将项目添加到服务网格时服务才可用。

1.9.1. 关于将项目添加到服务网格中

安装 Operator 并创建 ServiceMeshControlPlane 资源后,将一个或多个项目添加到服务网格中。

注意

在 OpenShift Container Platform 中,项目就基本上就是一个带有额外注解的 Kubernetes 命名空间,如可以在项目中使用的用户 ID 范围。通常,OpenShift Container Platform Web 控制台使用术语“项目(project)”,CLI 使用术语”命名空间 (namespace)”,这两个术语所代表的内容基本上是相同的。

您可以使用 OpenShift Container Platform Web 控制台或 CLI 将项目添加到现有服务网格中。将项目添加到服务网格中有三种方法:

  • ServiceMeshMemberRoll 资源中指定项目名称。
  • ServiceMeshMemberRoll 资源的 spec.labelSelectors 字段中配置标签选择器。
  • 在项目中创建 ServiceMeshMember 资源。

如果使用第一个方法,您必须创建 ServiceMeshMemberRoll 资源。

1.9.2. 创建 Red Hat OpenShift Service Mesh member roll

ServiceMeshMemberRoll 列出属于 Service Mesh control plane 的项目。只有 ServiceMeshMemberRoll 中列出的项目会受到 control plane 的影响。在将项目添加到特定 control plane 部署的 member roll 之前,项目不属于服务网格。

您必须在 ServiceMeshControlPlane 所在的同一个项目中创建一个名为 defaultServiceMeshMemberRoll 资源,如 istio-system

1.9.2.1. 从 Web 控制台创建 member roll

您可从 web 控制台在 Service Mesh member roll 中添加一个或多个项目。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

前提条件

  • 已安装并验证的 Red Hat OpenShift Service Mesh Operator。
  • 要添加到服务网格的现存项目列表。

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. 如果您还没有网格服务,或者您从头开始,请为您的应用程序创建一个项目。它必须与安装 Service Mesh control plane 的项目不同。

    1. 浏览至 HomeProject
    2. Name 字段中输入一个名称。
    3. Create
  3. 导航到 OperatorsInstalled Operators
  4. Project 菜单,从列表中选择部署 ServiceMeshControlPlane 资源的项目,如 istio-system
  5. 点 Red Hat OpenShift Service Mesh Operator。
  6. Istio Service Mesh Member Roll 选项卡。
  7. Create ServiceMeshMemberRoll
  8. 单击 Members,然后在 Value 字段中输入项目名称。您可以添加多个项目,但每个项目只能属于一个 ServiceMeshMemberRoll 资源。
  9. Create

1.9.2.2. 通过 CLI 创建 member roll

您可以使用命令行将项目添加到 ServiceMeshMemberRoll 中。

前提条件

  • 已安装并验证的 Red Hat OpenShift Service Mesh Operator。
  • 要添加到服务网格的项目列表。
  • 访问 OpenShift CLI(oc)。

流程

  1. 登录 OpenShift Container Platform CLI。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. 如果您还没有网格服务,或者您从头开始,请为您的应用程序创建一个项目。它必须与安装 Service Mesh control plane 的项目不同。

    $ oc new-project <your-project>
  3. 要添加项目作为成员,请修改以下示例 YAML:您可以添加多个项目,但每个项目只能属于一个 ServiceMeshMemberRoll 资源。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

    servicemeshmemberroll-default.yaml 示例

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        # a list of projects joined into the service mesh
        - your-project-name
        - another-project-name

  4. 运行以下命令,在 istio-system 命名空间中上传并创建 ServiceMeshMemberRoll 资源。

    $ oc create -n istio-system -f servicemeshmemberroll-default.yaml
  5. 运行以下命令,以验证 ServiceMeshMemberRoll 是否已成功创建。

    $ oc get smmr -n istio-system default

    STATUS 列为 Configured 时,安装成功完成。

1.9.3. 关于使用 ServiceMeshMemberRoll 资源添加项目

使用 ServiceMeshMemberRoll 资源是将项目添加到服务网格的最简单方法。要添加项目,请在 ServiceMeshMemberRoll 资源的 spec.members 字段中指定项目名称。ServiceMeshMemberRoll 资源指定哪个项目由 ServiceMeshControlPlane 资源控制。

使用 'ServiceMeshMemberRoll' 资源镜像添加项目
注意

使用此方法添加项目需要用户具有相关项目中的 update servicemeshmemberrollsupdate pod 特权。

  • 如果您已有要添加到服务网格中的应用程序、工作负载或服务,请查看以下操作:

    • 在 web 控制台中使用 ServiceMeshMemberRoll 资源从网格中添加或删除项目
    • 通过 CLI 使用 ServiceMeshMemberRoll 资源从网格中添加或删除项目
  • 另外,要安装一个名为 Bookinfo 的示例应用程序并将其添加到 ServiceMeshMemberRoll 资源中,请参阅 Bookinfo 示例应用程序教程。

1.9.3.1. 在 web 控制台中使用 ServiceMeshMemberRoll 资源从网格中添加或删除项目

您可以使用 OpenShift Container Platform Web 控制台的 ServiceMeshMemberRoll 资源从网格中添加或删除项目。您可以添加任意数量的项目,但项目只能属于一个网格。

当它对应的 ServiceMeshControlPlane 资源被删除后,ServiceMeshMemberRoll 资源也会被删除。

前提条件

  • 已安装并验证的 Red Hat OpenShift Service Mesh Operator。
  • 现有 ServiceMeshMemberRoll 资源
  • 带有 ServiceMeshMemberRoll 资源的项目名称。
  • 要从网格中添加或删除的项目的名称。

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. 导航到 OperatorsInstalled Operators
  3. Project 菜单,从列表中选择部署了 ServiceMeshControlPlane 资源的项目。例如 istio-system
  4. 点 Red Hat OpenShift Service Mesh Operator。
  5. Istio Service Mesh Member Roll 选项卡。
  6. default 链接。
  7. 点 YAML 标签。
  8. 修改 YAML 以添加项目作为成员(或删除它们来删除现有成员)。您可以添加多个项目,但每个项目只能属于一个 ServiceMeshMemberRoll 资源。

    servicemeshmemberroll-default.yaml 示例

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system #control plane project
    spec:
      members:
        # a list of projects joined into the service mesh
        - your-project-name
        - another-project-name

  9. Save
  10. Reload

1.9.3.2. 使用 CLI 的 ServiceMeshMemberRoll 资源从网格中添加或删除项目

您可以使用 CLI 的 ServiceMeshMemberRoll 资源将一个或多个项目添加到网格中。您可以添加任意数量的项目,但项目只能属于一个网格。

当它对应的 ServiceMeshControlPlane 资源被删除后,ServiceMeshMemberRoll 资源也会被删除。

前提条件

  • 已安装并验证的 Red Hat OpenShift Service Mesh Operator。
  • 现有 ServiceMeshMemberRoll 资源
  • 带有 ServiceMeshMemberRoll 资源的项目名称。
  • 要从网格中添加或删除的项目的名称。
  • 访问 OpenShift CLI(oc)。

流程

  1. 登录 OpenShift Container Platform CLI。
  2. 编辑 ServiceMeshMemberRoll 资源。

    $ oc edit smmr -n <controlplane-namespace>
  3. 修改 YAML 以添加或删除作为成员的项目。您可以添加多个项目,但每个项目只能属于一个 ServiceMeshMemberRoll 资源。

    servicemeshmemberroll-default.yaml 示例

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system #control plane project
    spec:
      members:
        # a list of projects joined into the service mesh
        - your-project-name
        - another-project-name

  4. 保存文件并退出编辑器。

1.9.4. 关于使用 ServiceMeshMember 资源添加项目

ServiceMeshMember 资源提供了一种在不修改 ServiceMeshMemberRoll 资源的情况下将项目添加到服务网格的方法。要添加项目,请在您要添加到服务网格的项目中创建 ServiceMeshMember 资源。当 Service Mesh Operator 处理 ServiceMeshMember 对象时,项目会出现在 ServiceMeshMemberRoll 资源的 status.members 列表中。然后,属于项目中的服务对网格提供。

使用 'ServiceMeshMember' 资源镜像添加项目

网格管理员需要为每个网关用户授予引用 ServiceMeshMember 资源中的 ServiceMeshControlPlane 资源的权限。使用这个权限,网格用户可以将项目添加到网格中,即使该用户没有服务网格项目或 ServiceMeshMemberRoll 资源的直接访问权限。如需更多信息,请参阅创建 Red Hat OpenShift Service Mesh 成员。

1.9.4.1. 在 web 控制台中使用 ServiceMeshMember 资源将项目添加到网格中

您可以在 OpenShift Container Platform Web 控制台中使用 ServiceMeshMember 资源将一个或多个项目添加到网格中。

先决条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 您知道 ServiceMeshControlPlane 资源的名称以及资源所属的项目的名称。
  • 您知道您要添加到网格中的项目名称。
  • 服务网格管理员必须明确授予服务网格的访问权限。管理员可以使用 RoleBindingClusterRoleBinding 为用户分配 mesh-user 角色,为用户授予访问网格的权限。如需更多信息,请参阅创建 Red Hat OpenShift Service Mesh 成员

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. 导航到 OperatorsInstalled Operators
  3. Project 菜单,然后从下拉列表中选择您要添加到网格的项目。例如: istio-system
  4. 点 Red Hat OpenShift Service Mesh Operator。
  5. Istio Service Mesh Member 选项卡。
  6. Create ServiceMeshMember
  7. 接受 ServiceMeshMember 的默认名称。
  8. 点击以展开 ControlPlaneRef
  9. Namespace 字段中,选择 ServiceMeshControlPlane 资源所属的项目。例如: istio-system
  10. Name 字段中输入此命名空间所属的 ServiceMeshControlPlane 资源的名称。例如,basic
  11. Create
  12. 确认创建了 ServiceMeshMember 资源,并且项目已添加到网格中。点资源名称,例如 default。查看屏幕末尾显示的 Conditions 部分。确认 ReconciledReady 条件的 StatusTrue。如果 StatusFalse,请参阅 ReasonMessage 列以了解更多信息。

1.9.4.2. 通过 CLI 使用 ServiceMeshMember 资源将项目添加到网格

您可以通过 CLI 使用 ServiceMeshMember 资源将一个或多个项目添加到网格中。

前提条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 您知道 ServiceMeshControlPlane 资源的名称及其所属项目的名称。
  • 您知道您要添加到网格中的项目名称。
  • 服务网格管理员必须明确授予服务网格的访问权限。管理员可以使用 RoleBindingClusterRoleBinding 为用户分配 mesh-user 角色,为用户授予访问网格的权限。如需更多信息,请参阅创建 Red Hat OpenShift Service Mesh 成员

流程

  1. 登录 OpenShift Container Platform CLI。
  2. ServiceMeshMember 清单创建 YAML 文件。清单将 my-application 项目添加到由 istio-system 命名空间中部署的 ServiceMeshControlPlane 资源创建的服务网格中:

    apiVersion: maistra.io/v1
    kind: ServiceMeshMember
    metadata:
      name: default
      namespace: my-application
    spec:
      controlPlaneRef:
        namespace: istio-system
        name: basic
  3. 应用 YAML 文件以创建 ServiceMeshMember 资源:

    $ oc apply -f <file-name>
  4. 创建 ServiceMeshMember 资源后,验证命名空间是否是网格的一部分。运行以下命令,确认值 True 出现在 READY 列中:

    $ oc get smm default -n my-application

    另外,如果可以访问 ServiceMeshMemberRoll 资源,您还可以确认 my-application 命名空间显示在 ServiceMeshMemberRoll 资源的 status.membersstatus.configuredMembers 字段中。

1.9.5. 关于使用标签选择器添加项目

对于集群范围的部署,您可以使用标签选择器将项目添加到网格中。ServiceMeshMemberRoll 资源中指定的标签选择器可让 Service Mesh Operator 根据命名空间标签向网格添加或删除命名空间。与可以用来指定单个标签选择器的其他标准 OpenShift Container Platform 资源不同,您可以使用 ServiceMeshMemberRoll 资源来指定多个标签选择器。

使用标签选择器镜像添加项目

如果命名空间标签与 ServiceMeshMemberRoll 资源中指定的任何选择器匹配,则命名空间会包含在网格中。

注意

在 OpenShift Container Platform 中,项目就基本上就是一个带有额外注解的 Kubernetes 命名空间,如可以在项目中使用的用户 ID 范围。通常,OpenShift Container Platform Web 控制台使用术语 项目(project),CLI 使用术语 命名空间(namespace),但这两个术语在本质上是相同的。

1.9.5.1. 使用带有 Web 控制台的标签选择器将项目添加到网格中

您可以使用标签选择器通过 OpenShift Container Platform Web 控制台将项目添加到 Service Mesh。

先决条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 部署有一个现有的 ServiceMeshMemberRoll 资源。
  • 以具有 cluster-admin 角色的用户身份登录。如果使用 Red Hat OpenShift Dedicated,则以具有 dedicated-admin 角色的用户身份登录。

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. 导航到 OperatorsInstalled Operators
  3. Project 菜单,从下拉菜单中选择部署 ServiceMeshMemberRoll 资源的项目。例如:istio-system
  4. 点 Red Hat OpenShift Service Mesh Operator。
  5. Istio Service Mesh Member Roll 选项卡。
  6. Create ServiceMeshMember Roll
  7. 接受 ServiceMeshMemberRoll 的默认名称。
  8. Labels 字段中输入键值对,以定义标识服务网格中要包含哪些命名空间的标签。如果项目命名空间具有选择器指定的标签,则项目命名空间会包含在服务网格中。您不需要同时包含这两个标签。

    例如,输入 mykey=myvalue 包括具有此标签的所有命名空间作为网格的一部分。当选择器标识匹配项时,项目命名空间将添加到服务网格中。

    输入 myotherkey=myothervalue 包括具有此标签的所有命名空间作为网格的一部分。当选择器标识匹配项时,项目命名空间将添加到服务网格中。

  9. Create

1.9.5.2. 使用带有 CLI 的标签选择器将项目添加到网格中

您可以使用标签选择器通过 CLI 将项目添加到 Service Mesh 中。

前提条件

  • 已安装 Red Hat OpenShift Service Mesh Operator。
  • 部署有一个现有的 ServiceMeshMemberRoll 资源。
  • 以具有 cluster-admin 角色的用户身份登录。如果使用 Red Hat OpenShift Dedicated,则以具有 dedicated-admin 角色的用户身份登录。

流程

  1. 登录 OpenShift Container Platform CLI。
  2. 编辑 ServiceMeshMemberRoll 资源。

    $ oc edit smmr -n <controlplane_project>

    上例使用 <controlplane_project> 作为示例。只要 Service Mesh control plane 与包含服务的项目分开,就可以将 Service Mesh control plane 部署到任何项目中。

  3. 修改 YAML 文件,以在 ServiceMeshMemberRoll 资源的 spec.memberSelectors 字段中包含命名空间标签选择器。

    注意

    您还可以使用选择器中的 matchExpressions 字段,而不使用 matchLabels 字段。

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      memberSelectors: 1
      - matchLabels: 2
          mykey: myvalue 3
      - matchLabels: 4
          myotherkey: myothervalue 5
    1
    包含用于标识服务网格中包含的项目命名空间的标签选择器。如果项目命名空间具有选择器指定的标签,则项目命名空间会包含在服务网格中。项目命名空间不需要同时包含这两个标签。
    2 3
    使用 mykey=myvalue 标签指定所有命名空间。当选择器标识匹配项时,项目命名空间将添加到服务网格中。
    4 5
    使用 myotherkey=myothervalue 标签指定所有命名空间。当选择器标识匹配项时,项目命名空间将添加到服务网格中。

1.9.6. Bookinfo 示例应用程序

您可以使用 Bookinfo 示例应用程序来测试 OpenShift Container Platform 中的 Red Hat OpenShift Service Mesh 2.4.5 安装。

Bookinfo 应用程序显示一本书的信息,类似于在线书店的单一目录条目。应用会显示一个页面,其中描述了图书详细信息(ISBN、页数和其他信息)以及图书的评论。

Bookinfo 应用程序由这些微服务组成:

  • productpage 微服务调用 detailsreviews 微服务来产生页面信息。
  • details 微服务包括了书的信息。
  • review 微服务包括了书的评论。它同时还会调用 ratings 微服务。
  • ratings微服务包括了带有对本书的评论信息的评分信息。

reviews 微服务有三个版本:

  • 版本 v1 不调用 ratings 服务。
  • 版本 v2 调用 ratings 服务,并以一到五个黑色星来代表对本书的评分。
  • 版本 v3 调用 ratings 服务,并以一到五个红色星来代表对本书的评分。

1.9.6.1. 安装 Bookinfo 应用程序

本教程介绍了如何创建项目、将 Bookinfo 应用程序部署到该项目并在 Service Mesh 中查看正在运行的应用程序来创建示例应用程序。

先决条件

  • 安装了 OpenShift Container Platform 4.1 或更高版本。
  • 安装了 Red Hat OpenShift Service Mesh 2.4.5。
  • 访问 OpenShift CLI(oc)。
  • 具有 cluster-admin 角色的帐户。
注意

Bookinfo 示例应用程序不能安装在 IBM Z 和 IBM Power Systems 上。

注意

本节中的命令假设 Service Mesh control plane 项目为 istio-system。如果在另一个命名空间中安装了 control plane,在运行前编辑每个命令。

流程

  1. 以具有 cluster-admin 权限的用户身份登录到 OpenShift Container Platform web 控制台。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  2. HomeProjects
  3. 点击 Create Project
  4. Project Name 中输入 info,输入 Display NameDescription,然后点 Create

    • 或者,也可以通过 CLI 运行这个命令来创建 info 项目。

      $ oc new-project info
  5. OperatorsInstalled Operators
  6. Project 菜单,使用 Service Mesh control plane 命名空间。在这个示例中,使用 istio-system
  7. Red Hat OpenShift Service Mesh Operator。
  8. Istio Service Mesh Member Roll 选项卡。

    1. 如果您已经创建了 Istio Service Mesh Member Roll,请名称,然后点击 YAML 标签来打开 YAML 编辑器。
    2. 如果您还没有创建 ServiceMeshMemberRoll,点 Create ServiceMeshMemberRoll
  9. 单击 Members,然后在 Value 字段中输入项目名称。
  10. Create 保存更新的 Service Mesh Member Roll。

    1. 或者,将以下示例保存到 YAML 文件中。

      Bookinfo ServiceMeshMemberRoll 示例 servicemeshmemberroll-default.yaml

      apiVersion: maistra.io/v1
      kind: ServiceMeshMemberRoll
      metadata:
        name: default
      spec:
        members:
        - info

    2. 运行以下命令上传该文件,并在 istio-system 命名空间中创建 ServiceMeshMemberRoll 资源。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

      $ oc create -n istio-system -f servicemeshmemberroll-default.yaml
  11. 运行以下命令,以验证 ServiceMeshMemberRoll 是否已成功创建。

    $ oc get smmr -n istio-system -o wide

    STATUS 列为 Configured 时,安装成功完成。

    NAME      READY   STATUS       AGE   MEMBERS
    default   1/1     Configured   70s   ["info"]
  12. 在 CLI 中,通过应用 bookinfo.yaml 文件在 `info` 项目中部署 Bookinfo:

    $ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/platform/kube/bookinfo.yaml

    您应该看到类似如下的输出:

    service/details created
    serviceaccount/info-details created
    deployment.apps/details-v1 created
    service/ratings created
    serviceaccount/info-ratings created
    deployment.apps/ratings-v1 created
    service/reviews created
    serviceaccount/info-reviews created
    deployment.apps/reviews-v1 created
    deployment.apps/reviews-v2 created
    deployment.apps/reviews-v3 created
    service/productpage created
    serviceaccount/info-productpage created
    deployment.apps/productpage-v1 created
  13. 通过应用 info-gateway.yaml 文件创建入站网关 :

    $ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/networking/bookinfo-gateway.yaml

    您应该看到类似如下的输出:

    gateway.networking.istio.io/info-gateway created
    virtualservice.networking.istio.io/info created
  14. 设置 GATEWAY_URL 参数的值:

    $ export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')

1.9.6.2. 添加默认目的地规则

在使用 Bookinfo 应用程序前,您必须首先添加默认目的地规则。根据您是否启用了 mutual TLS 验证,预先配置两个 YAML 文件。

流程

  1. 要添加目的地规则,请运行以下命令之一:

    • 如果没有启用 mutual TLS:

      $ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/networking/destination-rule-all.yaml
    • 如果启用了 nutual TLS:

      $ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/networking/destination-rule-all-mtls.yaml

      您应该看到类似如下的输出:

      destinationrule.networking.istio.io/productpage created
      destinationrule.networking.istio.io/reviews created
      destinationrule.networking.istio.io/ratings created
      destinationrule.networking.istio.io/details created

1.9.6.3. 验证 Bookinfo 安装

要确认示例 Bookinfo 应用程序已被成功部署,请执行以下步骤。

前提条件

  • 安装了 Red Hat OpenShift Service Mesh。
  • 完成安装 Bookinfo 示例应用程序的步骤。

通过 CLI 的步骤

  1. 登录 OpenShift Container Platform CLI。
  2. 验证所有 pod 是否都与此命令就绪:

    $ oc get pods -n info

    所有容器集的状态都应为 Running。您应该看到类似如下的输出:

    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-55b869668-jh7hb        2/2     Running   0          12m
    productpage-v1-6fc77ff794-nsl8r   2/2     Running   0          12m
    ratings-v1-7d7d8d8b56-55scn       2/2     Running   0          12m
    reviews-v1-868597db96-bdxgq       2/2     Running   0          12m
    reviews-v2-5b64f47978-cvssp       2/2     Running   0          12m
    reviews-v3-6dfd49b55b-vcwpf       2/2     Running   0          12m
  3. 运行以下命令来检索产品页面的 URL:

    echo "http://$GATEWAY_URL/productpage"
  4. 在网页浏览器中复制并粘贴输出以验证是否已部署了 Bookinfo 产品页面。

来自 Kiali web 控制台的步骤

  1. 获取 Kiali web 控制台的地址。

    1. 以具有 cluster-admin 权限的用户身份登录 OpenShift Container Platform web 控制台。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
    2. 进入 NetworkingRoutes
    3. Routes 页面中,从 Namespace 菜单中选择 Service Mesh control plane 项目,如 istio-system

      Location 列显示每个路由的链接地址。

    4. 点 Kiali 的 Location 列中的链接。
    5. 单击 Log In With OpenShift。Kiali Overview 屏幕显示每个项目命名空间的标题。
  2. 在 Kiali 中,点 Graph
  3. Namespace 列表中选择 info,从 Graph Type 列表中选择 App graph。
  4. Display 菜单中选择 Display idle nodes

    这将显示定义的节点,但尚未收到或发送请求。它可以确认应用已正确定义,但未报告任何请求流量。

    Kiali 显示 info 应用程序
    • 使用 Duration 菜单增加时间段,以帮助确保捕获旧的流量。
    • 使用 Refresh Rate 菜单刷新流量频率或更小,或者根本不刷新流量。
  5. ServicesWorkloadsIstio Config 查看 info 组件的列表视图,并确认它们健康。

1.9.6.4. 删除 Bookinfo 应用程序

按照以下步骤删除 Bookinfo 应用程序。

先决条件

  • 安装了 OpenShift Container Platform 4.1 或更高版本。
  • 安装了 Red Hat OpenShift Service Mesh 2.4.5。
  • 访问 OpenShift CLI(oc)。
1.9.6.4.1. 删除 Bookinfo 项目

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. HomeProjects
  3. info 菜单 kebab ,然后点 Delete Project
  4. 在确认对话框中键入 info,然后点 Delete

    • 或者,您可以使用 CLI 运行这个命令来创建 info 项目。

      $ oc delete project info
1.9.6.4.2. 从 Service Mesh member roll 中删除 Bookinfo 项目

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. OperatorsInstalled Operators
  3. Project 菜单,从列表中选 istio-system
  4. Red Hat OpenShift Service Mesh Operator 在 Provided APIS 下点 Istio Service Mesh Member Roll 链接。
  5. ServiceMeshMemberRoll 菜单 kebab 并选择 Edit Service Mesh Member Roll
  6. 编辑默认的 Service Mesh Member Roll YAML 并从 members 列表中删除 info

    • 或者,您可以使用 CLI 运行这个命令从 ServiceMeshMemberRoll 中删除 info 项目。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

      $ oc -n istio-system patch --type='json' smmr default -p '[{"op": "remove", "path": "/spec/members", "value":["'"info"'"]}]'
  7. Save 更新 Service Mesh Member Roll。

1.9.7. 后续步骤

1.10. 启用 sidecar 注入

将包含您的服务的命名空间添加到网格后,下一步是在应用程序的 Deployment 资源中启用自动 sidecar 注入功能。您必须为每个部署启用自动 sidecar 注入。

如果您已安装 Bookinfo 示例应用程序,则会部署应用程序,并作为安装过程的一部分注入 sidecar。如果您使用自己的项目和服务,请在 OpenShift Container Platform 上部署应用程序。

如需更多信息,请参阅 OpenShift Container Platform 文档,了解 Deployment 和 DeploymentConfig 对象

注意

通过初始容器启动的流量(在 pod 中应用程序容器之前运行的专用容器)默认无法在服务网格外传输。任何需要在网格外建立网络流量连接的操作初始容器执行都会失败。

有关将初始容器连接到服务的更多信息,请参阅 注入 Service Mesh sidecar 的 pod 中的 CrashLoopBackOff 中的红帽知识库解决方案 initContainer

1.10.1. 先决条件

1.10.2. 启用自动 sidecar 注入

在部署应用程序时,您必须通过将 spec.template.metadata.annotations 中的 spec.template.metadata.annotations 中的注解 sidecar.istio.io/inject 配置为 true 来选择 注入。选择确保 sidecar 注入不会影响 OpenShift Container Platform 的其他功能,如 OpenShift Container Platform 生态系统中的多个框架使用的 builder pod。

先决条件

  • 识别作为服务网格一部分的命名空间,以及需要自动 sidecar 注入的部署。

流程

  1. 要查找部署,请使用 oc get 命令。

    $ oc get deployment -n <namespace>

    例如,若要查看 info 命名空间中 'ratings-v1' 微服务的部署文件,请使用以下命令以 YAML 格式查看资源:

    oc get deployment -n info ratings-v1 -o yaml
  2. 在编辑器中打开应用程序的部署配置 YAML 文件。
  3. spec.template.metadata.annotations.sidecar.istio/inject 添加到 Deployment YAML 中,并将 sidecar.istio.io/inject 设置为 true,如下例所示。

    info deployment-ratings-v1.yaml 中的代码片段示例

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ratings-v1
      namespace: info
      labels:
        app: ratings
        version: v1
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: 'true'

  4. 保存部署配置文件。
  5. 将文件添加回包含应用程序的项目。

    $ oc apply -n <namespace> -f deployment.yaml

    在本例中,info 是包含 ratings-v1 应用程序和 deployment-ratings-v1.yaml 的项目的名称,这是您编辑的文件。

    $ oc apply -n info -f deployment-ratings-v1.yaml
  6. 若要验证资源上传成功,请运行以下命令:

    $ oc get deployment -n <namespace> <deploymentName> -o yaml

    例如,

    $ oc get deployment -n info ratings-v1 -o yaml

1.10.3. 验证 sidecar 注入

Kiali 控制台提供了多种方式来验证应用程序、服务和工作负载是否有 sidecar 代理。

图 1.3. 缺少 sidecar badge

Graph 页面显示一个节点徽标,它显示了以下图形中的 Missing Sidecar

  • 应用程序图
  • 版本的应用程序图
  • 工作负载图

图 1.4. 缺少 sidecar 图标

缺少 Sidecar 图标

Applications 页面在没有 sidecar 的命名空间中任何应用程序的 Details 列中显示一个 Missing Sidecar 图标。

Workloads 页面中为没有 sidecar 的任何应用程序的 Details 列中显示一个 Missing Sidecar 图标。

Services 页面在没有 sidecar 的命名空间中任何应用程序的 Details 列中显示一个 Missing Sidecar 图标。当服务有多个版本时,您可以使用 Service Details 页面查看 Missing Sidecar 图标。

Workload Details 页面有一个特殊的统一 Logs 选项卡,可让您查看和关联应用程序和代理日志。您可以将 Envoy 日志视为验证应用程序工作负载的 sidecar 注入的另一种方式是查看。

Workload Details 页面还具有作为 Envoy 代理或被注入 Envoy 代理的任何工作负载的 Envoy 标签页。此选项卡显示内置的 Envoy 仪表板,其中包含 ClustersListenersRoutesBootstrapConfigMetrics 的子选项卡。

有关启用 Envoy 访问日志的详情,请参考故障排除部分

有关查看 Envoy 日志的详情,请参考 Kiali 控制台中的日志

1.10.4. 通过注解设置代理环境变量

Envoy sidecar 代理的配置由 ServiceMeshControlPlane 管理。

您可以通过在 injection-template.yaml 文件中的部署中添加 pod 注解来为应用程序设置 sidecar 代理的环境变量。环境变量注入 sidecar。

injection-template.yaml 示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource
spec:
  replicas: 7
  selector:
    matchLabels:
      app: resource
  template:
    metadata:
      annotations:
        sidecar.maistra.io/proxyEnv: "{ \"maistra_test_env\": \"env_value\", \"maistra_test_env_2\": \"env_value_2\" }"

警告

在创建自己的自定义资源时,您绝不应包含 maistra.io/ 标签和注解。这些标签和注解表示资源由 Operator 生成和管理。如果您在创建自己的资源时从 Operator 生成的资源复制内容,请不要包含以 maistra.io/ 开头的标签或注解。在下一个协调过程中,Operator 将覆盖或删除这些标签或注解的资源。

1.10.5. 更新 sidecar 代理

要更新 sidecar 代理的配置,应用程序管理员必须重启应用程序 pod。

如果您的部署使用了自动 sidecar 注入功能,则可以通过添加或修改注解来更新部署中的 pod 模板。运行以下命令来重新部署 pod:

$ oc patch deployment/<deployment> -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt": "'`date -Iseconds`'"}}}}}'

如果您的部署没有使用自动 sidecar 注入功能,则必须通过修改部署或 pod 中指定的 sidecar 容器镜像来手动更新 sidecar,然后重启 pod。

1.10.6. 后续步骤

为您的环境配置 Red Hat OpenShift Service Mesh 功能。

1.11. 升级 Service Mesh

要访问 Red Hat OpenShift Service Mesh 的最当前功能,请升级到当前版本 2.4.5。

1.11.1. 了解版本

红帽在产品版本中使用语义版本。语义版本包括 3 个组件号,格式为 X.Y.Z,其中:

  • X 代表主版本。主发行版本通常表示有主要的变化:架构更改、API 更改、模式更改以及类似的重大更新。
  • Y 代表次版本。次发行版本包含了新功能,同时保持向后兼容性。
  • z 代表一个补丁版本(也称为 z-stream 版本)。补丁版本用于提供解决常见漏洞和风险 (CVE) 的解决方案,以及版本中的程序错误修复。新特性通常不会作为补丁版本的一部分发布。

1.11.1.1. 版本对 Service Mesh 升级的影响

根据您要进行的更新版本,升级过程会有所不同。

  • 补丁更新 - 由 Operator Lifecycle Manager(OLM)管理补丁升级;在更新 Operator 时会自动进行。
  • 次版本更新 - 只需要升级到最新的 Red Hat OpenShift Service Mesh Operator 版本,并手动修改 ServiceMeshControlPlane 资源中的 spec.version 值。
  • 主版本更新 - 主版本升级需要更新到最新的 Red Hat OpenShift Service Mesh Operator 版本,并手动修改 ServiceMeshControlPlane 资源中的 spec.version 值。因为主版本的更新可能包含不向后兼容的更改,所以可能需要进行额外的手动更改。

1.11.1.2. 了解 Service Mesh 版本

要了解您在系统上部署的 Red Hat OpenShift Service Mesh 版本,您需要了解如何管理各个组件版本。

  • Operator 版本 - 最新版本为 2.4.5。Operator 版本号仅指示当前安装的 Operator 的版本。因为 Red Hat OpenShift Service Mesh Operator 支持 Service Mesh control plane 的多个版本,所以 Operator 的版本不会决定部署的 ServiceMeshControlPlane 资源的版本。

    重要

    升级到最新的 Operator 版本会自动应用补丁更新,但不会自动将 Service Mesh control plane 升级到最新的次版本。

  • ServiceMeshControlPlane 版本 - ServiceMeshControlPlane 版本决定您使用的 Red Hat OpenShift Service Mesh 版本。ServiceMeshControlPlane 资源中的 spec.version 字段的值控制用于安装和部署 Red Hat OpenShift Service Mesh 的架构和配置设置。创建 Service Mesh control plane 时,您可以使用以下两种方式之一设置版本:

    • 要在 Form View 中配置,请从 Control Plane Version 菜单中选择版本。
    • 要在 YAML View 中配置,请在 YAML 文件中设置 spec.version 的值。

Operator Lifecycle Manager(OLM)不管理 Service Mesh control plane 升级,因此,Operator 和 ServiceMeshControlPlane (SMCP)的版本号可能不匹配,除非您手动升级 SMCP。

1.11.2. 升级注意事项

maistra.io/ 标签或注解不应用于用户创建的自定义资源,因为它表示资源由 Red Hat OpenShift Service Mesh Operator 生成并应该由 Red Hat OpenShift Service Mesh Operator 管理。

警告

在升级过程中,Operator 进行更改(包括删除或替换文件)到包含以下标签或注解来指示 Operator 管理资源的资源。

在升级检查用户创建的自定义资源前,其中包含以下标签或注解:

  • maistra.io/app.kubernetes.io/managed-by 标签设置为 maistra-istio-operator (Red Hat OpenShift Service Mesh)
  • kiali.io/ (Kiali)
  • jaegertracing.io/ (Red Hat OpenShift distributed tracing platform (Jaeger))
  • logging.openshift.io/ (Red Hat Elasticsearch)

在升级前,检查用户为标签或注解创建自定义资源,以指示用户管理的 Operator。从您不想由 Operator 管理的自定义资源中删除标签或注解。

当升级到版本 2.0 时,Operator 只删除与 SMCP 相同的命名空间中使用这些标签的资源。

当升级到 2.1 版本时,Operator 会删除所有命名空间中使用这些标签的资源。

1.11.2.1. 可能会影响升级的已知问题

已知的可能影响升级的问题包括:

  • 当升级 Operator 时,可能会恢复 Jaeger 或 Kiali 的自定义配置。在升级 Operator 前,请注意 Service Mesh production 部署中 Jaeger 或 Kiali 对象的任何自定义配置设置,以便您可以重新创建它们。
  • Red Hat OpenShift Service Mesh 不支持使用 EnvoyFilter 配置,除非明确记录。这是因为与底层 Envoy API 耦合紧密,这意味着无法维护向后兼容性。如果您使用 Envoy Filters,并且因为升级 ServiceMeshControlPlane 引进了的 Envoy 版本导致 Istio 生成的配置已更改,则可能会破坏您可能已经实现的 EnvoyFilter
  • OSSM-1505 ServiceMeshExtension 无法用于 OpenShift Container Platform 版本 4.11。因为 ServiceMeshExtension 在 Red Hat OpenShift Service Mesh 2.2 中已弃用,所以这个已知问题不会被修复,且您必须将扩展迁移到 WasmPluging
  • OSSM-1396 如果一个网关资源包含 spec.externalIPs 设置,而不是在 ServiceMeshControlPlane 更新时重新创建,则该网关会被删除且永远不会重新创建。
  • OSSM-1052 在为服务网格 control plane 中为 ingressgateway 配置 Service ExternalIP 时,不会创建该服务。SMCP 的 schema 缺少该服务的参数。

    临时解决方案:禁用 SMCP spec 中的网关创建,手动管理网关部署(包括 Service、Role 和 RoleBinding)。

1.11.3. 升级 Operator

要让您的 Service Mesh 使用最新的安全修复、程序错误修正和软件更新进行补丁,您需要保持 Operator 为最新版本。您可以通过升级 Operator 来启动补丁更新。

重要

Operator 的版本 不会 决定服务网格的版本。部署的 Service Mesh control plane 的版本决定了您的 Service Mesh 版本。

因为 Red Hat OpenShift Service Mesh Operator 支持 Service Mesh control plane 的多个版本,所以更新 Red Hat OpenShift Service Mesh Operator 不会更新部署的 ServiceMeshControlPlanespec.version 值。另请注意,spec.version 值是一个双数字,如 2.2,补丁更新(如 2.2.1)不会反映在 SMCP 版本值中。

Operator Lifecycle Manager (OLM) 能够控制集群中 Operator 的安装、升级和基于角色的访问控制 (RBAC)。OLM 在 OpenShift Container Platform 中默认运行。OLM 会查询可用的 Operator 以及已安装的 Operator 的升级。

升级 Operator 的具体方式取决于您在安装 Operator 时选择的设置。安装每个 Operator 时,您可以选择一个更新频道和一个批准策略。这两个设置的组合决定了 Operator 的更新时间和方式。

表 1.4. 更新频道和批准策略的交互

 版本化频道"Stable" 或 "Preview" 频道

自动

仅为该版本的次版本自动更新 Operator。将不会自动更新到下一个主要版本(即,从 2.0 升级到 3.0)。手动更改为升级到下一个主要版本所需的 Operator 订阅。

为所有主版本、次版本和补丁版本自动更新 Operator。

Manual(手动)

指定版本的次要和补丁版本需要手动更新。手动更改为升级到下一个主要版本所需的 Operator 订阅。

所有主版本、次版本和补丁版本需要手动更新。

更新 Red Hat OpenShift Service Mesh Operator 时,Operator Lifecycle Manager(OLM)会删除旧的 Operator pod 并启动新的 pod。新的 Operator pod 启动后,协调过程会检查 ServiceMeshControlPlane (SMCP),如果存在可用于任何 Service Mesh control plane 组件的更新容器镜像,它会将这些 Service Mesh control plane pod 替换为使用新容器镜像的用户。

当您升级 Kiali 和 Red Hat OpenShift distributed tracing Platform (Jaeger) Operator 时,OLM 协调过程会扫描集群,并将受管实例升级到新 Operator 的版本。例如,如果您将 Red Hat OpenShift distributed tracing platform (Jaeger) Operator 从 1.30.2 更新至 1.34.1,Operator 会扫描运行分布式追踪平台 (Jaeger) 的实例并将其升级到 1.34.1。

要保留 Red Hat OpenShift Service Mesh 的特定补丁版本,您需要禁用自动更新,并保留在该 Operator 的特定版本。

如需有关升级 Operator 的更多信息,请参阅 Operator Lifecycle Manager 文档。

1.11.4. 升级 control plane

对于次版本和主版本,您必须手动更新 control plane。社区 Istio 项目建议进行金丝雀(Canary)升级,但 Red Hat OpenShift Service Mesh 只支持原位升级。Red Hat OpenShift Service Mesh 要求您按顺序升级到下一个次版本。例如,您必须从 2.0 升级到 2.1 版本,然后再升级到 2.2 版本。您无法直接从 Red Hat OpenShift Service Mesh 2.0 更新至 2.2。

升级服务网格 control plane 时,所有 Operator 受管资源(如网关)也会被升级。

虽然您可以在同一集群中部署多个 control plane 版本,但 Red Hat OpenShift Service Mesh 不支持服务网格的金丝雀升级。也就是说,您可以使用有不同的 spec.version 值的不同 SCMP 资源,但它们无法管理同一个网格。

有关迁移扩展的更多信息,请参阅从 ServiceMeshExtension 迁移到 WasmPlugin 资源

1.11.4.1. 将更改从 2.3 升级到 2.4 版本

将 Service Mesh control plane 从 2.3 升级到 2.4 带来了以下行为更改:

  • 对 Istio OpenShift 路由 (IOR) 的支持已弃用。IOR 功能仍处于启用状态,但将在以后的发行版本中删除。
  • 以下密码套件不再被支持,并从客户端和服务器侧 TLS 协商中使用的密码列表中删除。

    • ECDHE-ECDSA-AES128-SHA
    • ECDHE-RSA-AES128-SHA
    • AES128-GCM-SHA256
    • AES128-SHA
    • ECDHE-ECDSA-AES256-SHA
    • ECDHE-RSA-AES256-SHA
    • AES256-GCM-SHA384
    • AES256-SHA

      当代理启动 TLS 连接时,需要访问使用这些密码套件的服务的应用程序将无法连接。

1.11.4.2. 将更改从 2.2 升级到 2.3

将 Service Mesh control plane 从 2.2 升级到 2.3 引进了以下行为更改:

  • 此发行版本需要使用 WasmPlugin API。对 ServiceMeshExtension API 的支持(在 2.2 中已弃用)现已被删除。如果您在使用 ServiceMeshExtension API 时尝试升级,则升级会失败。

1.11.4.3. 从版本 2.1 升级到 2.2 的变化

将 Service Mesh control plane 从 2.1 升级到 2.2 引进了以下行为更改:

  • istio-node DaemonSet 被重命名为 istio-cni-node,以匹配上游 Istio 中的名称。
  • Istio 1.10 更新了 Envoy,默认使用 eth0 而不是 lo 将流量发送到应用程序容器。
  • 此发行版本添加了对 WasmPlugin API 的支持,并弃用了 ServiceMeshExtension API。

1.11.4.4. 将版本 2.0 升级到 2.1 版

将 Service Mesh control plane 从 2.0 升级到 2.1 引进了以下架构和行为更改。

构架更改

在 Red Hat OpenShift Service Mesh 2.1 中已完全删除 Mixer。如果启用了 Mixer,则无法从 Red Hat OpenShift Service Mesh 2.0.x 版本升级到 2.1。

如果您在从 v2.0 升级到 v2.1 时看到以下信息,请在更新 .spec.version 字段前将现有 Mixer 类型更新为 Istiod 类型:

An error occurred
admission webhook smcp.validation.maistra.io denied the request: [support for policy.type "Mixer" and policy.Mixer options have been removed in v2.1, please use another alternative, support for telemetry.type "Mixer" and telemetry.Mixer options have been removed in v2.1, please use another alternative]”

例如:

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  policy:
    type: Istiod
  telemetry:
    type: Istiod
  version: v2.4

行为更改

  • AuthorizationPolicy 更新:

    • 使用 PROXY 协议时,如果您使用 ipBlocksnotIpBlocks 指定远程 IP 地址,请更新配置以使用 remoteIpBlocks 而不是 RemoteIpBlocks
    • 添加了对嵌套 JSON Web Token(JWT)声明的支持。
  • EnvoyFilter 破坏更改>

    • 必须使用 typed_config
    • XDS v2 不再被支持
    • 弃用的过滤器名称
  • 较旧版本的代理可能会在从更新的代理接收 1xx 或 204 状态代码时报告 503 状态代码。

1.11.4.5. 升级 Service Mesh control plane

要升级 Red Hat OpenShift Service Mesh,您必须更新 Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 资源的版本字段。然后,在配置和应用后,重启应用程序 pod 以更新每个 sidecar 代理及其配置。

先决条件

  • 您正在运行 OpenShift Container Platform 4.9 或更高版本。
  • 您有最新的 Red Hat OpenShift Service Mesh Operator。

流程

  1. 切换到包含 ServiceMeshControlPlane 资源的项目。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

    $ oc project istio-system
  2. 检查 v2 ServiceMeshControlPlane 资源配置以验证其是否有效。

    1. 运行以下命令,将您的 ServiceMeshControlPlane 资源视为 v2 资源。

      $ oc get smcp -o yaml
      提示

      备份 Service Mesh control plane 配置。

  3. 更新 .spec.version 字段并应用配置。

    例如:

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
    spec:
      version: v2.4

    另外,您可以使用 Web 控制台编辑 Service Mesh control plane,而不是使用命令行。在 OpenShift Container Platform Web 控制台中,点 Project 并选择您刚才输入的项目名称。

    1. OperatorsInstalled Operators
    2. 查找 ServiceMeshControlPlane 实例。
    3. 选择 YAML view 并更新 YAML 文件的文本,如上例中所示。
    4. Save

1.11.4.6. 将 Red Hat OpenShift Service Mesh 从版本 1.1 迁移到版本 2.0

从版本 1.1 升级到 2.0 需要手动步骤将工作负载和应用程序迁移到运行新版本的 Red Hat OpenShift Service Mesh 的新实例中。

先决条件

  • 在升级到 Red Hat OpenShift Service Mesh 2.0 之前,您必须升级到 OpenShift Container Platform 4.7。
  • 您必须具有 Red Hat OpenShift Service Mesh 版本 2.0 operator。如果选择了 自动 升级路径,Operator 将自动下载最新信息。但是,您必须执行一些步骤来使用 Red Hat OpenShift Service Mesh 版本 2.0 中的功能。
1.11.4.6.1. 升级 Red Hat OpenShift Service Mesh

要升级 Red Hat OpenShift Service Mesh,必须在新命名空间中创建一个 Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 资源实例。然后,配置完成后,将微服务应用程序和工作负载从旧的网格移到新服务网格中。

流程

  1. 检查 v1 ServiceMeshControlPlane 资源配置,以确保它有效。

    1. 运行以下命令,将您的 ServiceMeshControlPlane 资源视为 v2 资源。

      $ oc get smcp -o yaml
    2. 查看输出中的 spec.techPreview.errored.message 字段,以了解有关任何无效字段的信息。
    3. 如果您的 v1 资源中存在无效字段,则该资源不会被协调,且无法作为 v2 资源编辑。v2 字段的所有更新都会被原始 v1 设置覆盖。要修复无效字段,可以替换、补丁或编辑资源的 v1 版本。您还可以在不修复的情况下删除资源。在资源修复后,它可以被协调,您可以修改或查看资源的 v2 版本。
    4. 要通过编辑文件来修复资源,请使用 oc get 检索资源,在本地编辑文本文件,并将资源替换为您编辑的文件。

      $ oc get smcp.v1.maistra.io <smcp_name> > smcp-resource.yaml
      #Edit the smcp-resource.yaml file.
      $ oc replace -f smcp-resource.yaml
    5. 要使用补丁修复资源,请使用 oc patch

      $ oc patch smcp.v1.maistra.io <smcp_name> --type json --patch '[{"op": "replace","path":"/spec/path/to/bad/setting","value":"corrected-value"}]'
    6. 要通过使用命令行工具编辑资源,请使用 oc edit

      $ oc edit smcp.v1.maistra.io <smcp_name>
  2. 备份 Service Mesh control plane 配置。切换到包含 ServiceMeshControlPlane 资源的项目。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

    $ oc project istio-system
  3. 输入以下命令来检索当前的配置。您的 <smcp_name> 在您的 ServiceMeshControlPlane 资源元数据中指定,如 basic-installfull-install

    $ oc get servicemeshcontrolplanes.v1.maistra.io <smcp_name> -o yaml > <smcp_name>.v1.yaml
  4. ServiceMeshControlPlane 转换为 v2 control plane 版本,其包含您的配置信息作为起点。

    $ oc get smcp <smcp_name> -o yaml > <smcp_name>.v2.yaml
  5. 创建一个项目。在 OpenShift Container Platform 控制台项目菜单中,点 New Project,并为项目输入名称如 istio-system-upgrade。或者,您可以通过 CLI 运行这个命令。

    $ oc new-project istio-system-upgrade
  6. 使用新项目名称更新 v2 ServiceMeshControlPlane 中的 metadata.namespace 字段。在本例中,使用 istio-system-upgrade
  7. version 字段从 1.1 更新至 2.0,或将其从 v2 ServiceMeshControlPlane 中删除。
  8. 在新命名空间中创建一个 ServiceMeshControlPlane。在命令行中,运行以下命令,使用您检索的 ServiceMeshControlPlane 的 v2 版本部署 control plane。在这个示例中将 '<smcp_name.v2> ' 替换为您的文件的路径。

    $ oc create -n istio-system-upgrade -f <smcp_name>.v2.yaml

    另外,您可以使用控制台创建 Service Mesh control plane。在 OpenShift Container Platform web 控制台中点 Project。然后选择您刚刚输入的项目名称。

    1. OperatorsInstalled Operators
    2. Create ServiceMeshControlPlane
    3. 选择 YAML view,把获取的 YAML 文件的内容复制到这个项。检查 apiVersion 字段是否已设置为 maistra.io/v2,并修改 metadata.namespace 字段以使用新命名空间,如 istio-system-upgrade
    4. Create
1.11.4.6.2. 配置 2.0 ServiceMeshControlPlane

为 Red Hat OpenShift Service Mesh 版本 2.0 更改了 ServiceMeshControlPlane 资源。创建 ServiceMeshControlPlane 资源 v2 版本后,修改该资源以利用新功能并适合您的部署。在修改 ServiceMeshControlPlane 资源时,考虑对 Red Hat OpenShift Service Mesh 2.0 规范和行为进行以下更改。您还可以参阅 Red Hat OpenShift Service Mesh 2.0 产品文档来获取您使用的功能的新信息。v2 资源必须用于 Red Hat OpenShift Service Mesh 2.0 安装。

1.11.4.6.2.1. 构架更改

之前的版本使用的架构单元已被 Istiod 替代。在 2.0 中,Service Mesh control plane 组件 Mixer、Pilot、Citadel、Galley 和 sidecar 注入程序功能已合并为一个组件 Istiod。

虽然 Mixer 不再作为 control plane 组件支持,但 Mixer 策略和遥测插件现在可以通过 Istiodi 中的 WASM 扩展支持。如果您需要集成旧的 Mixer 插件,则可为策略和遥测启用混合程序。

安全发现服务 Service(SDS)用于直接从 Istiod 向 sidecar 分发证书和密钥。在 Red Hat OpenShift Service Mesh 1.1 中,secret 由 Citadel 生成,代理使用它来检索其客户端证书和密钥。

1.11.4.6.2.2. 注解更改

v2.0 不再支持以下注解。如果使用其中一个注解,则必须更新工作负载,然后将其移至 v2.0 Service Mesh control plane。

  • sidecar.maistra.io/proxyCPULimit 已被 sidecar.istio.io/proxyCPULimit 替代。如果您在工作负载上使用 sidecar.maistra.io 注解,则必须修改这些工作负载,使其使用相应的 sidecar.istio.io
  • sidecar.maistra.io/proxyMemoryLimit 已替换为 sidecar.istio.io/proxyMemoryLimit
  • 不再支持 sidecar.istio.io/discoveryAddress。另外,默认发现地址已经从 pilot.<control_plane_namespace>.svc:15010(如果启用 mtls,使用端口 15011)变为 istiod-<smcp_name>.<control_plane_namespace>.svc:15012
  • 健康状态端口不再可以被配置,它被硬编码为 15021。* 如果您要定义自定义状态端口,如 status.sidecar.istio.io/port,则必须在将工作负载移至 v2.0 Service Mesh control plane 前删除覆盖。就绪度检查仍然可以通过将状态端口设置为 0 来禁用。
  • Kubernetes Secret 资源不再用于为 sidecar 发布客户端证书。证书现在通过 Istiod 的 SDS 服务发布。如果您需要依赖挂载的 secret,则 v2.0 Service Mesh control plane 中的工作负载将无法使用它们。
1.11.4.6.2.3. 行为更改

Red Hat OpenShift Service Mesh 2.0 中的一些功能与之前的版本不同。

  • 网关上的就绪度端口已从 15020 移到 15021
  • 目标主机可见性包括 VirtualService 以及 ServiceEntry 资源。它包括所有通过 Sidecar 资源实施的限制。
  • 默认启用自动 mutual TLS。代理到代理通信会自动配置为使用 mTLS,而不管是否有全局的验证策略。
  • 当代理与 Service Mesh control plane 通讯时,无论 spec.security.controlPlane.mtls 设置如何,都始终使用安全连接。spec.security.controlPlane.mtls 设置仅在配置 Mixer 遥测或策略的连接时使用。
1.11.4.6.2.4. 不支持资源的迁移详情

Policy(策略) (authentication.istio.io/v1alpha1)不再被支持。

策略资源必须迁移到 v2.0 Service Mesh control planes、PeerAuthentication 和 RequestAuthentication 的新资源类型。根据策略资源中的具体配置,您可能需要配置多个资源来达到同样效果。

双向 TLS

使用 security.istio.io/v1beta1 PeerAuthentication 资源可以实现双向 TLS 强制。传统的 spec.peers.mtls.mode 字段会直接映射到新资源的 spec.mtls.mode 字段。选择条件已从在 spec.targets[x].name 中指定服务名称改为 spec.selector.matchLabels 中的标签选择器。在 PeerAuthentication 中,标签必须与目标列表中指定的服务选择器匹配。任何特定于端口的设置都需要映射到 spec.portLevelMtls

身份验证

spec.origins 中指定的附加验证方法必须映射到 security.istio.io/v1beta1 RequestAuthentication 资源中。spec.selector.matchLabels 必须与 PeerAuthentication 上的相同字段配置相类似。spec.origins.jwt 项中特定于 JWT 主体的配置会映射到 spec.rules 项中的类似字段。

  • spec.origins[x].jwt.triggerRules 必须映射到一个或多个 security.istio.io/v1beta1 AuthorizationPolicy 资源。任何 spec.selector.labels 都必须配置为 RequestAuthentication 上的相同字段。
  • spec.origins[x].jwt.triggerRules.excludedPaths 必须映射到一个 AuthorizationPolicy 中,其 spec.action 设置为 ALLOW,带有与排除路径匹配的 spec.rules[x].to.operation.path 条目。
  • spec.origins[x].jwt.triggerRules.includedPaths 必须映射为一个独立的 AuthorizationPolicy,它的 spec.action 设置为 ALLOW,使用与包含的路径匹配的 spec.rules[x].to.operation.path 条目,以及与 Policy 资源中指定的 spec.origins[x].jwt.issuer 相对应的 spec.rules.[x].from.source.requestPrincipals 的条目。

ServiceMeshPolicy (maistra.io/v1)

ServiceMeshPolicy 通过 spec.istio.global.mtls.enabled(v1 资源)或 spec.security.dataPlane.mtls(v2 资源)自动为 Service Mesh control plane 配置。对于 v2 control plane,在安装过程中创建了一个功能等同的 PeerAuthentication 资源。此功能在 Red Hat OpenShift Service Mesh 版本 2.0 中已弃用

RbacConfig, ServiceRole, ServiceRoleBinding (rbac.istio.io/v1alpha1)

这些资源由 security.istio.io/v1beta1 AuthorizationPolicy 资源替代。

模拟 RbacConfig 行为需要编写默认的 AuthorizationPolicy,其设置取决于 RbacConfig 中指定的 spec.mode。

  • 当将 spec.mode 设置为 OFF 时,不需要任何资源,因为默认策略是 ALLOW,除非对请求应用 AuthorizationPolicy。
  • spec.mode 设为 ON 时,设置 spec: {}。您必须为网格中的所有服务创建 AuthorizationPolicy 策略。
  • spec.mode 设置为 ON_WITH_INCLUSION,必须为每个包含的命名空间中创建一个带有 spec: {} 的 AuthorizationPolicy。AuthorizationPolicy 不支持包括单独的服务。但是,当创建任何适用于该服务的工作负载的 AuthorizationPolicy 后,未明确允许的所有其他请求都将被拒绝。
  • spec.mode 设置为 ON_WITH_EXCLUSION 时,AuthorizationPolicy 不支持它。可创建一个全局 DENY 策略,但必须为每个网格中的每个工作负载创建一个 AuthorizationPolicy,因为没有可用于命名空间或工作负载的 allow-all 策略。

AuthorizationPolicy 包括配置适用的选择器的配置,它类似于 ServiceRoleBinding 提供的函数 ServiceRoleBinding,这与所提供函数 ServiceRole 相似。

ServiceMeshRbacConfig (maistra.io/v1)

这个资源由使用 Service Mesh control plane 命名空间中带有空 spec.selector 的 security.istio.io/v1beta1 AuthorizationPolicy 资源替换。该策略是应用于网格中所有工作负载的默认授权策略。如需具体迁移详情,请参阅上面的 RbacConfig。

1.11.4.6.2.5. Mixer 插件

在版本 2.0 中默认禁用 Mixer 组件。如果您的工作负载依赖 Mixer 插件,必须将 2.0 ServiceMeshControlPlane 版本配置为包含 Mixer 组件。

要启用 Mixer 策略组件,在 ServiceMeshControlPlane 中添加以下片断。

spec:
  policy:
    type: Mixer

要启用 Mixer 遥测组件,在 ServiceMeshControlPlane 中添加以下片断。

spec:
  telemetry:
    type: Mixer

旧版混合程序插件也可以迁移到 WASM,并使用新的 ServiceMeshExtension(maistra.io/v1alpha1)自定义资源进行集成。

Red Hat OpenShift Service Mesh 2.0 不提供上游 Istio 发行本中的内置 WASM 过滤器。

1.11.4.6.2.6. 双向 TLS 的变化

当使用带有特定工作负载 PeerAuthentication 策略的 mTLS 时,如果工作负载策略与命名空间/全局策略不同,则需要一个对应的 DestinationRule 来允许流量。

auto mTLS 默认启用,但可以通过将 ServiceMeshControlPlane 资源中的 spec.security.dataPlane.automtls 设置为 false 来禁用。禁用自动 mTLS 时,可能需要 DestinationRules 进行服务间的正常通信。例如,将一个命名空间的 PeerAuthentication 设置为 STRICT 可能会阻止其他命名空间中的服务访问它们,除非 DestinationRule 为命名空间中的服务配置 TLS 模式。

有关 mTLS 的详情请参考 启用 mutual Transport Layer Security(mTLS)

1.11.4.6.2.6.1. 其他 mTLS 示例

要在 info 示例应用程序中禁用 mTLS For productpage 服务,您的 Policy 资源需要为 Red Hat OpenShift Service Mesh v1.1 进行以下配置。

策略资源示例

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  targets:
  - name: productpage

要在 info 示例应用程序中禁用 mTLS For productpage 服务,请使用以下示例为 Red Hat OpenShift Service Mesh v2.0 配置 PeerAuthentication 资源。

PeerAuthentication 资源示例

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  mtls:
    mode: DISABLE
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage

为了在 info 示例应用程序中为 productpage 服务启用 mTLS,您的 Policy 资源被配置为 Red Hat OpenShift Service Mesh v1.1 如下。

策略资源示例

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  targets:
  - name: productpage
    ports:
    - number: 9000
  peers:
  - mtls:
  origins:
  - jwt:
      issuer: "https://securetoken.google.com"
      audiences:
      - "productpage"
      jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
      jwtHeaders:
      - "x-goog-iap-jwt-assertion"
      triggerRules:
      - excludedPaths:
        - exact: /health_check
  principalBinding: USE_ORIGIN

要在 info 示例应用程序中为 productpage 服务启用 mTLS,使用以下示例为 Red Hat OpenShift Service Mesh v2.0 配置 PeerAuthentication 资源。

PeerAuthentication 资源示例

#require mtls for productpage:9000
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  portLevelMtls:
    9000:
      mode: STRICT
---
#JWT authentication for productpage
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  jwtRules:
  - issuer: "https://securetoken.google.com"
    audiences:
    - "productpage"
    jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
    fromHeaders:
    - name: "x-goog-iap-jwt-assertion"
---
#Require JWT token to access product page service from
#any client to all paths except /health_check
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  action: ALLOW
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  rules:
  - to: # require JWT token to access all other paths
      - operation:
          notPaths:
          - /health_check
    from:
      - source:
          # if using principalBinding: USE_PEER in the Policy,
          # then use principals, e.g.
          # principals:
          # - “*”
          requestPrincipals:
          - “*”
  - to: # no JWT token required to access health_check
      - operation:
          paths:
          - /health_check

1.11.4.6.3. 配置方案

您可以使用这些配置方案配置以下项目。

1.11.4.6.3.1. data plane 中的双向 TLS

通过 ServiceMeshControlPlane 资源中的 spec.security.dataPlane.mtls 为 data plane 通信配置双向 TLS,默认为 false

1.11.4.6.3.2. 自定义签名密钥

Istiod 管理服务代理使用的客户端证书和私钥。默认情况下, Istiod 使用自签名证书作为签名,但您可以配置自定义证书和私钥。有关如何配置签名密钥的更多信息,请参阅 添加外部证书颁发机构密钥和证书

1.11.4.6.3.3. Tracing

Tracing 在 spec.tracing 中配置。目前,Jaeger 是唯一支持的 tracer 类型。sampling 是一个缩放整数,代表 0.01% 增长,例如: 1 为 0.01%,10000 为 100%。可以指定追踪实施和抽样率:

spec:
  tracing:
    sampling: 100 # 1%
    type: Jaeger

Jaeger 在 ServiceMeshControlPlane 资源的 addons 部分进行配置。

spec:
  addons:
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory # or Elasticsearch for production mode
          memory:
            maxTraces: 100000
          elasticsearch: # the following values only apply if storage:type:=Elasticsearch
            storage: # specific storageclass configuration for the Jaeger Elasticsearch (optional)
              size: "100G"
              storageClassName: "storageclass"
            nodeCount: 3
            redundancyPolicy: SingleRedundancy
  runtime:
    components:
      tracing.jaeger: {} # general Jaeger specific runtime configuration (optional)
      tracing.jaeger.elasticsearch: #runtime configuration for Jaeger Elasticsearch deployment (optional)
        container:
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "1Gi"

您可以使用 install 字段自定义 Jaeger 安装。容器配置,如资源限值是在 spec.runtime.components.jaeger 相关字段中配置的。如果存在与 spec.addons.jaeger.name 值匹配的 Jaeger 资源,Service Mesh control plane 将配置为使用现有安装。使用现有的 Jaeger 资源来完全自定义 Jaeger 安装。

1.11.4.6.3.4. 视觉化

Kiali 和 Grafana 在 ServiceMeshControlPlane 资源的 addons 部分进行配置。

spec:
  addons:
    grafana:
      enabled: true
      install: {} # customize install
    kiali:
      enabled: true
      name: kiali
      install: {} # customize install

Grafana 和 Kiali 安装可以通过相应的 install 字段自定义。容器自定义(如资源限制)在 spec.runtime.components.kialispec.runtime.components.grafana 中配置。如果存在与名称值匹配的现有 Kiali 资源,Service Mesh control plane 会配置用于 control plane 的 Kiali 资源。Kiali 资源中的一些字段会被覆盖,如 access_namespaces 列表,以及 Grafana、Prometheus 和追踪的端点。使用现有资源来完全自定义 Kiali 安装。

1.11.4.6.3.5. 资源使用和调度

资源在 spec.runtime.<component> 下配置。支持以下组件名称。

组件描述支持的版本

安全

Citadel 容器

v1.0/1.1

galley

Galley 容器

v1.0/1.1

pilot

Pilot/Istiod 容器

v1.0/1.1/2.0

mixer

istio-telemetry 和 istio-policy 容器

v1.0/1.1

mixer.policy

istio-policy 容器

v2.0

mixer.telemetry

istio-telemetry 容器

v2.0

global.oauthproxy

与不同附加组件搭配使用的 oauth-proxy 容器

v1.0/1.1/2.0

sidecarInjectorWebhook

Sidecar injector Webhook 容器

v1.0/1.1

trace.jaeger

常规 Jaeger 容器 - 可能不会应用所有设置。通过在 Service Mesh control plane 配置中指定现有 Jaeger 资源,支持完全自定义 Jaeger 安装。

v1.0/1.1/2.0

trace.jaeger.agent

特定于 Jaeger 代理的设置

v1.0/1.1/2.0

tracing.jaeger.allInOne

特定于 Jaeger allInOne 的设置

v1.0/1.1/2.0

tracing.jaeger.collector

针对 Jaeger 收集器的设置

v1.0/1.1/2.0

tracing.jaeger.elasticsearch

特定于 Jaeger elasticsearch 部署的设置

v1.0/1.1/2.0

trace.jaeger.query

特定于 Jaeger 查询的设置

v1.0/1.1/2.0

prometheus

prometheus 容器

v1.0/1.1/2.0

kiali

Kiali 容器 - 通过在 Service Mesh control plane 配置中指定现有 Kiali 资源来支持 Kiali 安装的完整自定义。

v1.0/1.1/2.0

grafana

Grafana 容器

v1.0/1.1/2.0

3scale

3scale 容器

v1.0/1.1/2.0

wasmExtensions.cacher

WASM 扩展缓存容器

v2.0 - 技术预览

一些组件支持资源限制和调度。如需更多信息,请参阅性能和可扩展性

1.11.4.6.4. 迁移应用程序和工作负载的后续步骤

将应用程序工作负载移到新网格中,删除旧实例以完成您的升级。

1.11.5. 升级数据平面(data plane)

升级 control plane 后,您的数据平面仍然可以正常工作。但是,为了对 Envoy 代理应用更新以及代理配置的任何更改,您必须重启应用程序 pod 和工作负载。

1.11.5.1. 更新应用程序和工作负载

要完成迁移,重启网格中的所有应用程序 pod,以升级 Envoy sidecar 代理及其配置。

要对部署执行滚动更新,请使用以下命令:

$ oc rollout restart <deployment>

您必须对所有组成网格的应用程序执行滚动更新。

1.12. 管理用户和配置集

1.12.1. 创建 Red Hat OpenShift Service Mesh 成员

ServiceMeshMember 资源为 Red Hat OpenShift Service Mesh 管理员提供了一种将项目添加到服务网格(即使对应用户没有服务网格项目或 member roll)的权限。虽然项目管理员被自动授予在其项目中创建 ServiceMeshMember 资源的权限,但它们不能将其指向任何 ServiceMeshControlPlane,直到服务网格管理员显式授予服务网格访问权限。管理员可以通过授予 mesh-user 用户角色来授予用户访问网格的权限。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

$ oc policy add-role-to-user -n istio-system --role-namespace istio-system mesh-user <user_name>

管理员可以修改 Service Mesh control plane 项目中的 mesh-user 角色绑定,以指定授予访问权限的用户和组。ServiceMeshMember 会将项目添加到它引用的 Service Mesh control plane 项目中的 ServiceMeshMemberRoll

apiVersion: maistra.io/v1
kind: ServiceMeshMember
metadata:
  name: default
spec:
  controlPlaneRef:
    namespace: istio-system
    name: basic

mesh-users 角色绑定在管理员创建 ServiceMeshControlPlane 资源后自动创建。管理员可使用以下命令为用户添加角色。

$ oc policy add-role-to-user

管理员也可以在创建 ServiceMeshControlPlane 资源前创建 mesh-user 角色绑定。例如,管理员可以在与 ServiceMeshControlPlane 资源相同的 oc apply 操作中创建它。

本例为 alice添加一个角色绑定:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: istio-system
  name: mesh-users
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: mesh-user
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: alice

1.12.2. 创建 Service Mesh control plane 配置集

您可以使用 ServiceMeshControlPlane 配置集创建可重复使用的配置。个人用户可以根据自己的配置扩展他们创建的配置集。配置集也可以从其他配置集继承配置信息。例如,您可以为财务团队创建一个财务 control plane,为市场团队创建一个市场 control plane。如果您创建了一个开发模板和一个产品模板,则市场团队成员和财务团队成员就可以根据自己团队的情况对开发模板和生成环境配置集进行扩展。

当您配置 Service Mesh control plane 配置集时,它遵循与 ServiceMeshControlPlane 相同的语法,用户以分级方式继承设置。Operator 附带一个 默认 配置集,带有 Red Hat OpenShift Service Mesh 的默认设置。

1.12.2.1. 创建 ConfigMap

要添加自定义配置集,您必须在 openshift-operators 项目中创建一个名为 smcp-templatesConfigMap。Operator 容器会自动挂载 ConfigMap

前提条件

  • 已安装并验证的 Service Mesh Operator。
  • 具有 cluster-admin 角色的帐户。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  • Operator 部署的位置。
  • 访问 OpenShift CLI(oc)。

流程

  1. cluster-admin 用户身份登录 OpenShift Container Platform CLI。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  2. 在 CLI 中运行这个命令,在 openshift-operators 项目中创建名为 smcp-templates 的 ConfigMap,并将 <profiles-directory> 替换成本地磁盘上的 ServiceMeshControlPlane 文件的位置:

    $ oc create configmap --from-file=<profiles-directory> smcp-templates -n openshift-operators
  3. 您可以使用 ServiceMeshControlPlane 中的 profile 参数指定一个或多个模板。

      apiVersion: maistra.io/v2
      kind: ServiceMeshControlPlane
      metadata:
        name: basic
      spec:
        profiles:
        - default

1.12.2.2. 设置正确的网络策略

Service Mesh 在 Service Mesh control plane 和成员命名空间中创建网络策略,以允许它们之间的流量。在部署前,请考虑以下条件,以确保之前通过 OpenShift Container Platform 路由公开的服务网格中的服务。

  • 进入服务网格的流量必须总是经过 ingress-gateway 才能使 Istio 正常工作。
  • 在不在任何服务网格中的独立命名空间中为服务网格部署服务。
  • 需要在服务网格列出的命名空间中部署的非 mesh 服务应该标记其 maistra.io/expose-route: "true",这可以确保 OpenShift Container Platform 路由到这些服务仍可以正常工作。

1.13. 安全性

如果您的服务网格应用程序由 一 组复杂的微服务组成,您可以使用 Red Hat OpenShift Service Mesh 来定制这些服务间的通信安全性。OpenShift Container Platform 的基础架构以及 Service Mesh 的流量管理功能可帮助您管理应用程序的复杂性和安全微服务。

开始前

如果您有一个项目,请将项目添加到 ServiceMeshMemberRoll 资源中

如果您没有项目,请安装 Bookinfo 示例应用程序 并将其添加到 ServiceMeshMemberRoll 资源中。示例应用程序可以帮助演示安全概念。

1.13.1. 关于 mutual Transport Layer Security(mTLS)

Mutual Transport Layer Security(mTLS)是一个协议,可让双方相互验证。在一些协议(IKE、SSH)中,它是身份验证的默认模式,在其他协议中(TLS)是可选的。您可以在不更改应用程序或服务代码的情况下使用 mTLS。TLS 完全由服务网格基础架构处理,并在两个 sidecar 代理之间进行处理。

默认情况下,Red Hat OpenShift Service Mesh 中的 mTLS 被启用并设置为 permissive 模式,Service Mesh 中的 sidecar 接受明文流量和使用 mTLS 加密的连接。如果网格中的服务需要与网格外的服务进行通信,则 strict 模式的 mTLS 可能会破坏这些服务之间的通信。在将工作负载迁移到 Service Mesh 时使用 permissive 模式。然后,您可以在网格、命名空间或应用程序间启用严格的 mTLS。

在 Service Mesh control plane 级别启用 mTLS 可保护服务网格中的所有流量,而无需重写应用程序和工作负载。您可以在 ServiceMeshControlPlane 资源中的 data plane 级别保护网格中的命名空间。要自定义流量加密连接,请使用 PeerAuthenticationDestinationRule 资源在应用级别上配置命名空间。

1.13.1.1. 在服务网格中启用严格的 mTLS

如果您的工作负载没有与外部服务通信,您可以在网格间快速启用 mTLS,而不中断通信。您可以通过在 ServiceMeshControlPlane 资源中将 spec.security.dataPlane.mtls 设置为 true 来启用它。Operator 会创建所需资源。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  version: v2.4
  security:
    dataPlane:
      mtls: true

您还可以使用 OpenShift Container Platform Web 控制台启用 mTLS。

流程

  1. 登录到 web 控制台。
  2. Project 菜单,选择安装 Service Mesh control plane 的项目,如 istio-system
  3. OperatorsInstalled Operators
  4. Provided APIs 下的 Service Mesh Control Plane
  5. ServiceMeshControlPlane 资源的名称,例如 basic
  6. Details 页面中,单击 Data Plane SecuritySecurity 部分中的切换。
1.13.1.1.1. 为特定服务的入站连接配置 sidecar

您还可以通过创建策略为各个服务配置 mTLS。

流程

  1. 使用以下示例创建 YAML 文件:

    PeerAuthentication 策略示例 policy.yaml

    apiVersion: security.istio.io/v1beta1
    kind: PeerAuthentication
    metadata:
      name: default
      namespace: <namespace>
    spec:
      mtls:
        mode: STRICT

    1. <namespace> 替换为该服务所在的命名空间。
  2. 运行以下命令,在服务所在的命名空间中创建资源。它必须与您刚才创建的 Policy 资源中的 namespace 字段匹配。

    $ oc create -n <namespace> -f <policy.yaml>
注意

如果您不使用自动 mTLS,并且要将 PeerAuthentication 设置为 STRICT,则必须为您的服务创建一个 DestinationRule 资源。

1.13.1.1.2. 为出站连接配置 sidecar

创建一个目标规则将 Service Mesh 配置为在向网格中的其他服务发送请求时使用 mTLS。

流程

  1. 使用以下示例创建 YAML 文件:

    DestinationRule 示例 destination-rule.yaml

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: default
      namespace: <namespace>
    spec:
      host: "*.<namespace>.svc.cluster.local"
      trafficPolicy:
       tls:
        mode: ISTIO_MUTUAL

    1. <namespace> 替换为该服务所在的命名空间。
  2. 运行以下命令,在服务所在的命名空间中创建资源。它必须与您刚才创建的 DestinationRule 资源中的 namespace 字段匹配。

    $ oc create -n <namespace> -f <destination-rule.yaml>
1.13.1.1.3. 设置最小和最大协议版本

如果您的环境对服务网格中的加密流量有具体要求,可以通过在 ServiceMeshControlPlane 资源中设置 spec.security.controlPlane.tls.minProtocolVersionspec.security.controlPlane.tls.maxProtocolVersion 来控制允许的加密功能。这些值在 Service Mesh control plane 资源中配置,定义网格组件在通过 TLS 安全通信时使用的最小和最大 TLS 版本。

默认为 TLS_AUTO,且不指定 TLS 版本。

表 1.5. 有效值

描述

TLS_AUTO

default

TLSv1_0

TLS 版本 1.0

TLSv1_1

TLS 版本 1.1

TLSv1_2

TLS 版本 1.2

TLSv1_3

TLS 版本 1.3

流程

  1. 登录到 web 控制台。
  2. Project 菜单,选择安装 Service Mesh control plane 的项目,如 istio-system
  3. OperatorsInstalled Operators
  4. Provided APIs 下的 Service Mesh Control Plane
  5. ServiceMeshControlPlane 资源的名称,例如 basic
  6. YAML 标签。
  7. 在 YAML 编辑器中插入以下代码片段:将 minProtocolVersion 中的值替换为 TLS 版本值。在本例中,最小 TLS 版本设置为 TLSv1_2

    ServiceMeshControlPlane 代码片段

    kind: ServiceMeshControlPlane
    spec:
      security:
        controlPlane:
          tls:
            minProtocolVersion: TLSv1_2

  8. Save
  9. 单击 Refresh 以验证更改是否已正确更新。

1.13.1.2. 使用 Kiali 验证加密

Kiali 控制台提供了多种方式来验证应用程序、服务和工作负载是否启用了 mTLS 加密。

图 1.5. masthead 图标网格范围 mTLS

启用 mTLS

在 masthead 右侧,Kiali 显示一个锁定图标,当网格为整个服务网格启用了 mTLS 时。这意味着网格中的所有通信都使用 mTLS。

图 1.6. masthead 图标网格范围 mTLS 部分启用

启用 mTLS

当网格以 PERMISSIVE 模式或者网格范围 mTLS 配置出现错误时,Kiali 会显示 hollow 锁定图标。

图 1.7. 安全徽标

安全徽标

Graph 页面有选项,可以在图形边缘上显示 Security badge 来指示启用 mTLS。要在图形上启用安全徽标,请从 Display 菜单的 显示 Badges 下选择 安全 复选框。当边缘显示锁定图标时,它表示至少有一个启用了 mTLS 的请求。如果同时存在 mTLS 和非mTLS 请求,则 side-panel 会显示使用 mTLS 的请求百分比。

Applications details Overview 页会在图形边缘上显示一个 Security 图标,其中至少有一个启用了 mTLS 的请求。

Workloads details Overview 页会在图形边缘上显示一个 Security 图标,其中至少有一个启用了 mTLS 的请求。

Services Details Overview 页会在图形边缘上显示一个 Security 图标,其中至少有一个启用了 mTLS 的请求。另外请注意,Kiali 在 Network 部分显示为 mTLS 配置的端口旁的锁定图标。

1.13.2. 配置基于角色的访问控制(RBAC)

基于角色的访问控制 (RBAC) 对象决定是否允许用户或服务在项目内执行给定的操作。您可以为网格中的工作负载定义 mesh-、namespace- 和工作负载范围访问控制。

要配置 RBAC,在您要配置访问权限的命名空间中创建一个 AuthorizationPolicy 资源。如果要配置网格范围访问,请使用在其中安装 Service Mesh control plane 的项目,如 istio-system

例如,对于 RBAC,您可以创建以下策略:

  • 配置项目内部通信。
  • 允许或拒绝对默认命名空间中所有工作负载的完全访问。
  • 允许或拒绝入口网关访问。
  • 需要令牌才能访问。

授权策略包括选择器、操作和规则列表:

  • selector 字段指定策略的目标。
  • action 字段指定是否允许或拒绝请求。
  • rules 字段指定何时触发操作。

    • from 字段指定请求来源的限制。
    • to 字段指定请求目标和参数的限制。
    • when 字段指定应用该规则的其他条件。

流程

  1. 创建 AuthorizationPolicy 资源。以下示例显示了一个更新 ingress-policy AuthorizationPolicy 的资源,以拒绝 IP 地址访问入口网关。

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: ingress-policy
      namespace: istio-system
    spec:
      selector:
        matchLabels:
          app: istio-ingressgateway
      action: DENY
      rules:
      - from:
        - source:
          ipBlocks: ["1.2.3.4"]
  2. 在编写资源以便在命名空间中创建资源后运行以下命令。命名空间必须与 AuthorizationPolicy 资源中的 metadata.namespace 字段匹配。

    $ oc create -n istio-system -f <filename>

后续步骤

考虑以下示例用于其他通用配置。

1.13.2.1. 配置项目内部通信

您可以使用 AuthorizationPolicy 配置 Service Mesh control plane 来允许或拒绝与网格中的网格或服务通信的流量。

1.13.2.1.1. 限制对命名空间外服务的访问

您可以使用以下 AuthorizationPolicy 资源示例拒绝来自 info 命名空间中没有的源的请求。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: info
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["info"]
1.13.2.1.2. 创建 allow-all 和 default deny-all 授权策略

以下示例显示了一个 allow-all 授权策略,允许对 info 命名空间中的所有工作负载进行完全访问。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
  namespace: info
spec:
  action: ALLOW
  rules:
  - {}

以下示例显示了拒绝对 info 命名空间中所有工作负载的访问的策略。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: info
spec:
  {}

1.13.2.2. 允许或拒绝对入口网关的访问

您可以设置一个授权策略来根据 IP 地址添加 allow 或 deny 列表。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ingress-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
       ipBlocks: ["1.2.3.4", "5.6.7.0/24"]

1.13.2.3. 限制使用 JSON Web 令牌的访问

您可以使用 JSON Web Token(JWT)限制可以访问您的网格的内容。验证后,用户或服务可以访问路由,与该令牌关联的服务。

创建 RequestAuthentication 资源,用于定义工作负载支持的身份验证方法。下面的例子接受由 http://localhost:8080/auth/realms/master 发布的 JWT。

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: "jwt-example"
  namespace: info
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "http://localhost:8080/auth/realms/master"
    jwksUri: "http://keycloak.default.svc:8080/auth/realms/master/protocol/openid-connect/certs"

然后,在同一命名空间中创建一个 AuthorizationPolicy 资源,以用于您创建的 RequestAuthentication 资源。以下示例在向 httpbin 工作负载发送请求时,需要在 Authorization 标头中有一个 JWT。

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "frontend-ingress"
  namespace: info
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

1.13.3. 配置密码套件和 ECDH curves(策展)

密码套件和 Elliptic-curve Diffie-Hellman(ECDH 策展)可以帮助您保护服务网格的安全。您可以使用 spec.security.controlplane.tls.cipherSuites 和 ECDH 策展在 ServiceMeshControlPlane 资源中使用 spec.istio.global.tls.ecdhCurves 定义以逗号隔开的密码套件列表。如果其中任何一个属性为空,则使用默认值。

如果您的服务网格使用 TLS 1.2 或更早版本, cipherSuites 设置就会有效。它在使用 TLS 1.3 时无效。

在以逗号分开的列表中设置密码组合,以优先级顺序进行排列。例如,ecdhCurves: CurveP256, CurveP384CurveP256 设置为比 CurveP384 有更高的优先级。

注意

在配置加密套件时,需要包括 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256。HTTP/2 的支持至少需要其中一个加密套件。

支持的加密套件是:

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

支持的 ECDH Curves 是:

  • CurveP256
  • CurveP384
  • CurveP521
  • X25519

1.13.4. 配置 JSON Web 密钥设置解析器证书颁发机构

您可以从 ServiceMeshControlPlane (SMCP) spec 配置您自己的 JSON Web Key Sets (JWKS)解析器证书颁发机构(CA)。

流程

  1. 编辑 ServiceMeshControlPlane spec 文件:

    $ oc edit smcp <smcp-name>
  2. 通过将 ServiceMeshControlPlane spec 中的 mtls 字段设置为 true,为数据平面启用 mtls,如下例所示:

    spec:
      security:
        dataPlane:
            mtls: true # enable mtls for data plane
        # JWKSResolver extra CA
        # PEM-encoded certificate content to trust an additional CA
        jwksResolverCA: |
            -----BEGIN CERTIFICATE-----
            [...]
            [...]
            -----END CERTIFICATE-----
    ...
  3. 保存更改。OpenShift Container Platform 会自动应用它们。

一个 ConfigMap(如 pilot-jwks-cacerts-<SMCP name>)是由 CA .pem data 创建的。

ConfigMap pilot-jwks-cacerts-<SMCP name> 示例

kind: ConfigMap
apiVersion: v1
data:
  extra.pem: |
      -----BEGIN CERTIFICATE-----
      [...]
      [...]
      -----END CERTIFICATE-----

1.13.5. 添加外部证书颁发机构密钥和证书

默认情况下,Red Hat OpenShift Service Mesh 生成自签名 root 证书和密钥,并使用它们为工作负载证书签名。您还可以使用用户定义的证书和密钥使用用户定义的 root 证书为工作负载证书签名。此任务演示了一个将证书和密钥插入 Service Mesh 的示例。

前提条件

  • 在启用了 mutual TLS 配置证书的情况下安装 Red Hat OpenShift Service Mesh。
  • 这个示例使用 Maistra 存储库中的证书。对于生产环境,请使用您自己的证书颁发机构提供的证书。
  • 部署 Bookinfo 示例应用程序以按照以下说明验证结果。
  • 需要 openssl 才能验证证书。

1.13.5.1. 添加一个现有证书和密钥

要使用现有签名(CA)证书和密钥,必须创建一个信任文件链,其中包括 CA 证书、密钥和 root 证书。您必须为每个对应证书使用以下准确文件名称。CA 证书名为 ca-cert.pem,密钥是 ca-key.pem,签名 ca-cert.pem 的 root 证书名为 root-cert.pem。如果您的工作负载使用中间证书,则必须在 cert-chain.pem 文件中指定它们。

  1. 本地保存 Maistra repo 中的示例证书,,将 <path> 替换为证书的路径。
  2. 创建名为 cacert 的 secret,其中包含输入文件 ca-cert.pemca-key.pemroot-cert.pemcert-chain.pem

    $ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \
        --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \
        --from-file=<path>/cert-chain.pem
  3. ServiceMeshControlPlane 资源中将 spec.security.dataPlane.mtls 设置为 true,并配置 certificateAuthority 字段,如下例所示。默认 rootCADir/etc/cacerts。如果在默认位置挂载了密钥和证书,则不需要设置 privateKey。Service Mesh 从 secret-mount 文件中读取证书和密钥。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
        dataPlane:
          mtls: true
        certificateAuthority:
          type: Istiod
          istiod:
            type: PrivateKey
            privateKey:
              rootCADir: /etc/cacerts
  4. 创建/更改/取消设置 cacert secret 后,Service Mesh control plane istiodgateway pod 必须重启,以便更改生效。使用以下命令重启 pod:

    $ oc -n istio-system delete pods -l 'app in (istiod,istio-ingressgateway, istio-egressgateway)'

    Operator 会在 pod 被删除后自动重新创建。

  5. 重启 info 应用程序 pod,以便 sidecar 代理获取 secret 的更改。使用以下命令重启 pod:

    $ oc -n info delete pods --all

    您应该看到类似如下的输出:

    pod "details-v1-6cd699df8c-j54nh" deleted
    pod "productpage-v1-5ddcb4b84f-mtmf2" deleted
    pod "ratings-v1-bdbcc68bc-kmng4" deleted
    pod "reviews-v1-754ddd7b6f-lqhsv" deleted
    pod "reviews-v2-675679877f-q67r2" deleted
    pod "reviews-v3-79d7549c7-c2gjs" deleted
  6. 使用以下命令验证 pod 是否已创建并就绪:

    $ oc get pods -n info

1.13.5.2. 验证您的证书

使用 Bookinfo 示例应用程序来验证工作负载证书是否由插入到 CA 的证书签名。这个过程要求您在机器上安装 openssl

  1. 要从 info 工作负载中提取证书,请使用以下命令:

    $ sleep 60
    $ oc -n info exec "$(oc -n bookinfo get pod -l app=productpage -o jsonpath={.items..metadata.name})" -c istio-proxy -- openssl s_client -showcerts -connect details:9080 > bookinfo-proxy-cert.txt
    $ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' info-proxy-cert.txt > certs.pem
    $ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pem

    运行此命令后,您的工作目录中应当有三个文件: proxy-cert-1.pemproxy-cert-2.pemproxy-cert-3.pem

  2. 验证 root 证书是否与管理员指定证书相同。将 <path> 替换为证书的路径。

    $ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt

    在终端窗口中运行以下语法:

    $ openssl x509 -in ./proxy-cert-3.pem -text -noout > /tmp/pod-root-cert.crt.txt

    通过在终端窗口中运行以下命令来比较证书。

    $ diff -s /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt

    您应看到以下结果:Files /tmp/root-cert.crt.txt and /tmp/pod-root-cert.crt.txt are identical

  3. 验证 CA 证书是否与管理员指定证书相同。将 <path> 替换为证书的路径。

    $ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt

    在终端窗口中运行以下语法:

    $ openssl x509 -in ./proxy-cert-2.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt

    通过在终端窗口中运行以下命令来比较证书。

    $ diff -s /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt

    您应看到以下结果:Files /tmp/ca-cert.crt.txt and /tmp/pod-cert-chain-ca.crt.txt are identical.

  4. 从 root 证书到工作负载证书验证证书链。将 <path> 替换为证书的路径。

    $ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) ./proxy-cert-1.pem

    您应看到以下结果:./proxy-cert-1.pem: OK

1.13.5.3. 删除证书

要删除您添加的证书,请按照以下步骤操作。

  1. 删除 secret cacert。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

    $ oc delete secret cacerts -n istio-system
  2. ServiceMeshControlPlane 资源中使用自签名 root 证书重新部署 Service Mesh。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
        dataPlane:
          mtls: true

1.13.6. 关于将 Service Mesh 与 cert-manager 和 istio-csr 集成

cert-manager 工具是 Kubernetes 上 X.509 证书管理的解决方案。它提供了一个统一的 API,将应用程序与私钥或公钥基础架构 (PKI) 集成,如 Vault、Google Cloud Certificate Authority Service、Ret 的 Encrypt 和其他供应商。

cert-manager 工具通过尝试在配置的时间尝试续订证书,确保证书有效且最新。

对于 Istio 用户,cert-manager 还提供与 istio-csr 集成,它是一个处理 Istio 代理的证书签名请求 (CSR) 的证书颁发机构 (CA) 服务器。然后,服务器将签名委托给 cert-manager,它将 CSR 转发到配置的 CA 服务器。

注意

红帽支持与 istio-csr 和 cert-manager 集成。红帽不提供对 istio-csr 或社区 cert-manager 组件的直接支持。此处所示的社区 cert-manager 的使用仅用于演示目的。

前提条件

  • 这些 cert-manager 版本之一:

    • cert-manager Operator for Red Hat OpenShift 1.10 或更高版本
    • 社区 cert-manager Operator 1.11 或更高版本
    • cert-manager 1.11 或更高版本
  • OpenShift Service Mesh Operator 2.4 或更高版本
  • istio-csr 0.6.0 或更高版本
注意

为了避免在使用 jetstack/cert-manager-istio-csr Helm chart 安装 istio-csr 服务器时在所有命名空间中创建配置映射,在 istio-csr.yaml 文件中使用以下设置:app.controller.configmapNamespaceSelector: "maistra.io/member-of: <istio-namespace>"

1.13.6.1. 安装 cert-manager

您可以安装 cert-manager 工具来管理 TLS 证书的生命周期,并确保它们有效且最新。如果您在您的环境中运行 Istio,您还可以安装 istio-csr 证书颁发机构 (CA) 服务器,该服务器处理 Istio 代理中的证书签名请求 (CSR)。istio-csr CA 将签名委派给 cert-manager 工具,该工具委托给配置的 CA。

流程

  1. 创建 root 集群签发者:

    $ oc apply -f cluster-issuer.yaml
    $ oc apply -n istio-system -f istio-ca.yaml

    cluster-issuer.yaml 示例

    apiVersion: cert-manager.io/v1
    kind: Issuer
    metadata:
      name: selfsigned-root-issuer
      namespace: cert-manager
    spec:
      selfSigned: {}
    ---
    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
      name: root-ca
      namespace: cert-manager
    spec:
      isCA: true
      duration: 21600h # 900d
      secretName: root-ca
      commonName: root-ca.my-company.net
      subject:
        organizations:
        - my-company.net
      issuerRef:
        name: selfsigned-root-issuer
        kind: Issuer
        group: cert-manager.io
    ---
    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: root-ca
    spec:
      ca:
        secretName: root-ca

    istio-ca.yaml 示例

    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
      name: istio-ca
      namespace: istio-system
    spec:
      isCA: true
      duration: 21600h
      secretName: istio-ca
      commonName: istio-ca.my-company.net
      subject:
        organizations:
        - my-company.net
      issuerRef:
        name: root-ca
        kind: ClusterIssuer
        group: cert-manager.io
    ---
    apiVersion: cert-manager.io/v1
    kind: Issuer
    metadata:
      name: istio-ca
      namespace: istio-system
    spec:
      ca:
        secretName: istio-ca

    注意

    selfsigned-root-issuer issuer 和 root-ca 证书的命名空间是 cert-manager,因为 root-ca 是集群签发者,因此 cert-manager 会在其自己的命名空间中查找引用的 secret。对于 Red Hat OpenShift 的 cert-manager Operator,则自己的命名空间是 cert-manager。

  2. 安装 istio-csr

    $ helm install istio-csr jetstack/cert-manager-istio-csr \
        -n istio-system \
        -f deploy/examples/cert-manager/istio-csr/istio-csr.yaml

    istio-csr.yaml 示例

    replicaCount: 2
    
    image:
      repository: quay.io/jetstack/cert-manager-istio-csr
      tag: v0.6.0
      pullSecretName: ""
    
    app:
      certmanager:
        namespace: istio-system
        issuer:
          group: cert-manager.io
          kind: Issuer
          name: istio-ca
    
      controller:
        configmapNamespaceSelector: "maistra.io/member-of=istio-system"
        leaderElectionNamespace: istio-system
    
      istio:
        namespace: istio-system
        revisions: ["basic"]
    
      server:
        maxCertificateDuration: 5m
    
      tls:
        certificateDNSNames:
        # This DNS name must be set in the SMCP spec.security.certificateAuthority.cert-manager.address
        - cert-manager-istio-csr.istio-system.svc

  3. 部署 SMCP:

    $ oc apply -f mesh.yaml -n istio-system

    mesh.yaml 示例

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
    spec:
      addons:
        grafana:
          enabled: false
        kiali:
          enabled: false
        prometheus:
          enabled: false
      proxy:
        accessLogging:
          file:
            name: /dev/stdout
      security:
        certificateAuthority:
          cert-manager:
            address: cert-manager-istio-csr.istio-system.svc:443
          type: cert-manager
        dataPlane:
          mtls: true
        identity:
          type: ThirdParty
      tracing:
        type: None
    ---
    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
    spec:
      members:
      - httpbin
      - sleep

注意

当配置了 security.certificateAuthority.type: cert-manager 时必须设置 security.identity.type: ThirdParty

验证

使用示例 httpbin 服务和 sleep 应用程序来检查来自入口网关的 mTLS 流量,并验证安装了 cert-manager 工具。

  1. 部署 HTTP 和 sleep 应用程序:

    $ oc new-project <namespace>
    $ oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin.yaml
    $ oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/sleep/sleep.yaml
  2. 验证 sleep 是否可以访问 httpbin 服务:

    $ oc exec "$(oc get pod -l app=sleep -n <namespace> \
       -o jsonpath={.items..metadata.name})" -c sleep -n <namespace> -- \
       curl http://httpbin.<namespace>:8000/ip -s -o /dev/null \
       -w "%{http_code}\n"

    输出示例:

    200

  3. 检查来自 ingress 网关到 httpbin 服务的 mTLS 流量:

    $ oc apply -n <namespace> -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin-gateway.yaml
  4. 获取 istio-ingressgateway 路由:

    INGRESS_HOST=$(oc -n istio-system get routes istio-ingressgateway -o jsonpath='{.spec.host}')
  5. 验证从 ingress 网关到 httpbin 服务的 mTLS 流量:

    $ curl -s -I http://$INGRESS_HOST/headers -o /dev/null -w "%{http_code}" -s

1.13.7. 其他资源

有关如何为 OpenShift Container Platform 安装 cert-manager Operator 的详情,请参考:为 Red Hat OpenShift 安装 cert-manager Operator

1.14. 管理服务网格中的流量

使用 Red Hat OpenShift Service Mesh,您可以控制服务间的流量和 API 调用流。服务网格中的一些服务可能需要在网格内进行通信,其他服务则需要隐藏。您可以管理流量来隐藏特定后端服务、公开服务、创建测试或版本部署,或者在一组服务中添加安全层。

1.14.1. 使用网关

您可以使用网关来管理入站和出站流量,以指定您想要进入或离开网格的流量。网关配置适用于在网格边缘运行的独立的 Envoy 代理,而不是与您的服务负载一同运行的 sidecar Envoy 代理。

与控制进入系统的其他流量的机制不同,如 Kubernetes Ingress API,Red Hat OpenShift Service Mesh 网关可让您获得流量路由所具有的优点和灵活性。

Red Hat OpenShift Service Mesh 网关资源可使用层 4-6 负载均衡属性,比如要公开和配置 Red Hat OpenShift Service Mesh TLS 设置的端口。您可以将常规 Red Hat OpenShift Service Mesh 虚拟服务绑定到网关,并像服务网格中的其它数据平面流量一样管理网关流量,而不将应用程序层流量路由(L7)添加到相同的 API 资源中。

网关主要用于管理入口流量,但您也可以配置出口网关。出口网关可让您为离开网格的流量配置专用退出节点。这可让您限制哪些服务可以访问外部网络,这会为您的服务网格增加安全控制。您还可以使用网关配置纯内部代理。

网关示例

网关资源描述了在网格边缘运行的负载均衡器,接收进入或传出的 HTTP/TCP 连接。该规范描述应当公开的一组端口,要使用的协议类型,以及负载均衡器的 SNI 配置等。

以下示例显示了外部 HTTPS 入口流量的网关配置示例:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

这个网关配置允许来自 ext-host.example.com 的 HTTPS 流量通过端口 443 进入网格,但没有为流量指定路由。

要指定路由并让网关按预期工作,还必须将网关绑定到虚拟服务。您可以使用虚拟服务的网关字段进行此操作,如下例所示:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
    - ext-host-gwy

然后,您可以使用外部流量的路由规则配置虚拟服务。

1.14.1.1. 启用网关注入

网关配置适用于在网格边缘运行的独立的 Envoy 代理,而不是与您的服务负载一同运行的 sidecar Envoy 代理。因为网关是 Envoy 代理,所以您可以将 Service Mesh 配置为自动注入网关,类似于您可以注入 sidecar。

使用自动注入网关,您可以部署和管理独立于 ServiceMeshControlPlane 资源的网关,并使用用户应用程序管理网关。对网关部署使用自动注入可让开发人员完全控制网关部署,同时简化操作。当有新的升级可用时,或者配置已更改,您可以重启网关 pod 来更新它们。这样做使运行网关部署的体验与操作 sidecar 相同。

注意

ServiceMeshControlPlane 命名空间(如 istio-system 命名空间)默认禁用注入。作为安全最佳实践,在与 control plane 不同的命名空间中部署网关。

1.14.1.2. 部署自动网关注入

在部署网关时,您必须通过将注入标签或注解添加到网关 deployment 对象来选择注入。以下示例部署了网关。

前提条件

  • 命名空间必须是网格的成员,方法是在 ServiceMeshMemberRoll 中定义或创建 ServiceMeshMember 资源。

流程

  1. 为 Istio ingress 网关设置唯一标签。需要此设置以确保网关可以选择工作负载。这个示例使用 ingressgateway 作为网关的名称。

    apiVersion: v1
    kind: Service
    metadata:
      name: istio-ingressgateway
      namespace: istio-ingress
    spec:
      type: ClusterIP
      selector:
        istio: ingressgateway
      ports:
      - name: http2
        port: 80
        targetPort: 8080
      - name: https
        port: 443
        targetPort: 8443
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: istio-ingressgateway
      namespace: istio-ingress
    spec:
      selector:
        matchLabels:
          istio: ingressgateway
      template:
        metadata:
          annotations:
            inject.istio.io/templates: gateway
          labels:
            istio: ingressgateway
            sidecar.istio.io/inject: "true" 1
        spec:
          containers:
          - name: istio-proxy
            image: auto 2
    1
    通过将 sidecar.istio.io/inject 字段设置为 "true" 来启用网关注入。
    2
    image 字段设置为 auto,以便镜像在每次 pod 启动时自动更新。
  2. 设置角色以允许读取 TLS 的凭据。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: istio-ingressgateway-sds
      namespace: istio-ingress
    rules:
      - apiGroups: [""]
        resources: ["secrets"]
        verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: istio-ingressgateway-sds
      namespace: istio-ingress
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: istio-ingressgateway-sds
    subjects:
    - kind: ServiceAccount
      name: default
  3. 从集群外部授予新网关的访问权限,在将 spec.security.manageNetworkPolicy 设置为 true 时是必需的。

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: gatewayingress
      namespace: istio-ingress
    spec:
      podSelector:
        matchLabels:
          istio: ingressgateway
      ingress:
        - {}
      policyTypes:
      - Ingress
  4. 入口流量增加时自动缩放 pod。这个示例将最小副本设置为 2,最大副本设置为 5。它还会在利用率达到 80% 时创建另一个副本。

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      labels:
        istio: ingressgateway
        release: istio
      name: ingressgatewayhpa
      namespace: istio-ingress
    spec:
      maxReplicas: 5
      metrics:
      - resource:
          name: cpu
          target:
            averageUtilization: 80
            type: Utilization
        type: Resource
      minReplicas: 2
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: istio-ingressgateway
  5. 指定节点上必须运行的最小 pod 数量。本例确保当 pod 在新节点上重启时有一个副本正在运行。

    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      labels:
        istio: ingressgateway
        release: istio
      name: ingressgatewaypdb
      namespace: istio-ingress
    spec:
      minAvailable: 1
      selector:
        matchLabels:
          istio: ingressgateway

1.14.1.3. 管理入口流量

在 Red Hat OpenShift Service Mesh 中,Ingress Gateway 允许监控、安全性和路由规则等功能应用到进入集群的流量。使用 Service Mesh 网关在服务网格外公开服务。

1.14.1.3.1. 决定入口 IP 和端口

入口配置根据您的环境是否支持外部负载均衡器而有所不同。在集群的入口 IP 和端口中设置一个外部负载均衡器。要确定是否为外部负载均衡器配置了集群的 IP 和端口,请运行以下命令。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

$ oc get svc istio-ingressgateway -n istio-system

该命令会返回命名空间中每个项目的 NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE

如果设置了 EXTERNAL-IP 值,您的环境会有一个外部负载均衡器,供您用于入口网关。

如果 EXTERNAL-IP 值是 <none>,或 <pending>,则您的环境不会为入口网关提供外部负载均衡器。您可以使用服务的节点端口访问网关。

1.14.1.3.1.1. 使用负载均衡器确定入口端口

如果您的环境有外部负载均衡器,请按照以下步骤操作。

流程

  1. 运行以下命令来设置入口 IP 和端口。此命令在终端中设置变量。

    $ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
  2. 运行以下命令来设置入口端口。

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
  3. 运行以下命令来设置安全入口端口。

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
  4. 运行以下命令来设置 TCP 入口端口。

    $ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].port}')
注意

在某些情况下,负载均衡器可能会使用主机名而不是 IP 地址公开。在这种情况下,入口网关的 EXTERNAL-IP 值不是一个 IP 地址。相反,这是一个主机名,上一命令无法设置 INGRESS_HOST 环境变量。

在这种情况下,使用以下命令更正 INGRESS_HOST 值:

$ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
1.14.1.3.1.2. 确定没有负载均衡器的入口端口

如果您的环境没有外部负载均衡器,请确定入口端口并改用节点端口。

流程

  1. 设置入口端口。

    $ export INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
  2. 运行以下命令来设置安全入口端口。

    $ export SECURE_INGRESS_PORT=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
  3. 运行以下命令来设置 TCP 入口端口。

    $ export TCP_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="tcp")].nodePort}')

1.14.1.4. 配置入口网关

入口网关是在网格边缘运行的负载均衡器,接收传入的 HTTP/TCP 连接。它配置公开的端口和协议,但不包括任何流量路由配置。入口流量的流量路由改为使用路由规则配置,这与内部服务请求相同。

以下步骤演示了如何创建网关并配置 VirtualService,以在 Bookinfo 示例应用程序中将服务公开给路径 /productpage/login 的外部流量。

流程

  1. 创建网关以接受流量。

    1. 创建 YAML 文件,并将以下 YAML 复制到其中:

      网关 gateway.yaml 示例

      apiVersion: networking.istio.io/v1alpha3
      kind: Gateway
      metadata:
        name: info-gateway
      spec:
        selector:
          istio: ingressgateway
        servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*"

    2. 应用 YAML 文件。

      $ oc apply -f gateway.yaml
  2. 创建 VirtualService 对象来重写主机标头。

    1. 创建 YAML 文件,并将以下 YAML 复制到其中:

      虚拟服务示例

      apiVersion: networking.istio.io/v1alpha3
      kind: VirtualService
      metadata:
        name: info
      spec:
        hosts:
        - "*"
        gateways:
        - info-gateway
        http:
        - match:
          - uri:
              exact: /productpage
          - uri:
              prefix: /static
          - uri:
              exact: /login
          - uri:
              exact: /logout
          - uri:
              prefix: /api/v1/products
          route:
          - destination:
              host: productpage
              port:
                number: 9080

    2. 应用 YAML 文件。

      $ oc apply -f vs.yaml
  3. 测试网关和 VirtualService 已正确设置。

    1. 设置网关 URL。

      export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
    2. 设置端口号。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

      export TARGET_PORT=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.port.targetPort}')
    3. 测试已明确公开的页面。

      curl -s -I "$GATEWAY_URL/productpage"

      预期的结果为 200

1.14.2. 了解自动路由

在 Service Mesh 中自动管理网关的 OpenShift 路由。每次在 service mesh 中创建、更新或删除 Istio 网关时,都会自动创建、更新或删除 OpenShift 路由。

1.14.2.1. 使用子域的路由

Red Hat OpenShift Service Mesh 使用子域创建路由,但必须配置 OpenShift Container Platform 才能启用它。支持子域,如 *.domain.com,但默认情况下不受支持。在配置通配符主机网关前,配置 OpenShift Container Platform 通配符策略。

如需更多信息,请参阅使用通配符路由

1.14.2.2. 创建子域路由

以下示例在 Bookinfo 示例应用程序中创建了一个网关,它会创建子域路由。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway1
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.info.com
    - info.example.com

Gateway 资源创建以下 OpenShift 路由:您可以使用以下命令来检查是否创建了路由。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

$ oc -n istio-system get routes

预期输出

NAME           HOST/PORT             PATH  SERVICES               PORT  TERMINATION   WILDCARD
gateway1-lvlfn info.example.com        istio-ingressgateway   <all>               None
gateway1-scqhv www.info.com            istio-ingressgateway   <all>               None

如果删除了网关,Red Hat OpenShift Service Mesh 会删除路由。但是,您手动创建的路由不会被 Red Hat OpenShift Service Mesh 修改。

1.14.2.3. 路由标签和注解

有时,OpenShift 路由中需要特定的标签或注解。例如,OpenShift 路由中的一些高级功能通过特殊注释进行管理。请参阅以下"Additional resources"部分中的"特定于路由的注解"。

对于这个和其他用例,Red Hat OpenShift Service Mesh 会将 Istio 网关资源中的所有标签和注解(除 kubectl.kubernetes.io开始的注解外)复制到受管 OpenShift Route 资源中。

如果您在 Service Mesh 创建的 OpenShift Routes 中需要特定的标签或注解,在 Istio 网关资源中创建它们,并将其复制到由 Service Mesh 管理的 OpenShift Route 资源中。

其他资源

1.14.2.4. 禁用自动路由创建

默认情况下,ServiceMeshControlPlane 资源会自动将 Istio 网关资源与 OpenShift 路由同步。禁用自动路由创建功能,如果您有特殊情况或更喜欢手动控制路由,您可以更灵活地控制路由。

1.14.2.4.1. 为特定情况禁用自动路由创建

如果要禁用为特定 Istio 网关的 OpenShift 路由自动管理,您必须将注解 maistra.io/manageRoute: false 添加到网关元数据定义中。Red Hat OpenShift Service Mesh 将忽略带有这个注解的 Istio 网关,同时保持其它 Istio 网关的自动管理。

1.14.2.4.2. 为所有情况禁用自动路由创建

您可以为网格中的所有网关禁用自动管理 OpenShift 路由。

通过将 ServiceMeshControlPlane 字段 gateways.openshiftRoute.enabled 设置为 false 来禁用 Istio 网关和 OpenShift 路由之间的集成。例如,查看以下资源片断。

apiVersion: maistra.io/v1alpha1
kind: ServiceMeshControlPlane
metadata:
  namespace: istio-system
spec:
  gateways:
    openshiftRoute:
      enabled: false

1.14.3. 了解服务条目

服务条目在由 Red Hat OpenShift Service Mesh 内部维护的服务 registry 中添加一个条目。添加服务条目后,Envoy 代理将流量发送到该服务,就像是网格中的服务一样。服务条目允许您进行以下操作:

  • 管理服务网格外运行的服务的流量。
  • 重定向和转发外部目的地的流量,如来自 web 的 API 调用,或转发到旧基础架构中服务的流量。
  • 为外部目的地定义重新尝试、超时和错误注入策略。
  • 在虚拟机 (VM) 中运行网格服务,方法是在网格中添加虚拟机。
注意

将服务从不同集群添加到网格,以便在 Kubernetes 上配置多集群 Red Hat OpenShift Service Mesh 网格。

服务条目示例

以下示例 mesh-external 服务条目将 ext-resource 外部依赖关系添加到 Red Hat OpenShift Service Mesh 服务 registry:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

使用 hosts 字段指定外部资源。您可以完全限定名,也可以使用通配符前缀域名。

您可以配置虚拟服务和目的地规则,以控制到服务条目的流量,其方式与您为网格中的任何其他服务配置流量相同。例如,以下目的地规则将流量路由配置为使用 mutual TLS 来保护到 ext-svc.example.com 外部服务的连接。它被配置为使用服务项:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

1.14.4. 使用 VirtualServices

您可以使用虚拟服务通过 Red Hat OpenShift Service Mesh 将请求动态路由到微服务的不同版本。使用虚拟服务,您可以:

  • 通过单一虚拟服务处理多个应用程序服务。如果网格使用 Kubernetes,您可以配置虚拟服务来处理特定命名空间中的所有服务。虚拟服务使您能够将单体式应用转变为由具有无缝消费者体验的不同微服务组成的服务。
  • 配置流量规则与网关相结合,以控制入口和出口流量。

1.14.4.1. 配置 VirtualServices

使用虚拟服务将请求路由到服务网格中的服务。每个虚拟服务由一组路由规则组成,并按顺序应用。Red Hat OpenShift Service Mesh 会将每个给定给虚拟服务的请求与网格内的特定实际目的地匹配。

如果没有虚拟服务,Red Hat OpenShift Service Mesh 会在所有服务实例间使用最少请求(least requests)负载均衡分配流量。使用虚拟服务时,您可以指定一个或多个主机名的流量行为。虚拟服务的路由规则告知 Red Hat OpenShift Service Mesh 如何将虚拟服务的流量发送到适当的目的地。路由目的地可以是同一服务版本,也可以是完全不同的服务。

流程

  1. 使用以下示例创建 YAML 文件,根据用户连接到应用程序的不同版本将请求路由到 Bookinfo 示例应用程序服务的不同版本。

    VirtualService.yaml 示例

    apiVersion: networking.istio.io/v1alpha3
    kind: VirtualService
    metadata:
      name: reviews
    spec:
      hosts:
      - reviews
      http:
      - match:
        - headers:
            end-user:
              exact: jason
        route:
        - destination:
            host: reviews
            subset: v2
      - route:
        - destination:
            host: reviews
            subset: v3

  2. 运行以下命令以应用 VirtualService.yaml,其中 VirtualService.yaml 是文件的路径。

    $ oc apply -f <VirtualService.yaml>

1.14.4.2. VirtualService 配置参考

参数描述
spec:
  hosts:

hosts 字段列出了路由规则应用到的虚拟服务的目标地址。这是用于向服务发送请求的地址。虚拟服务主机名可以是解析为完全限定域名的 IP 地址、DNS 名称或简短名称。

spec:
  http:
  - match:

http 部分包含虚拟服务的路由规则,这些规则描述路由 HTTP/1.1、HTTP2 和 gRPC 流量与 hosts 字段中指定的目的地的匹配条件和操作。路由规则由您希望流量到达的目的地以及任何指定的匹配条件组成。示例中的第一个路由规则有一个以 match 字段开头的条件。在这个示例中,这个路由适用于来自用户 jason 的所有请求。添加 headersend-userexact 项来选择适当的请求。

spec:
  http:
  - match:
    - destination:

route 部分的 destination 字段指定与这个条件匹配的流量的实际目的地。与虚拟服务的主机不同,目的地的主机必须是 Red Hat OpenShift Service Mesh 服务 registry 中存在的真实目的地。这可以是带有代理的网格服务,或使用 service 条目添加的一个非网格服务。在本例中,主机名是一个 Kubernetes 服务名称:

1.14.5. 了解目的地规则

目的地规则在评估虚拟服务路由规则后应用,它们应用到流量的真实目的地。虚拟服务将流量路由到目的地。目的地规则配置该目的地的网络流量。

默认情况下,Red Hat OpenShift Service Mesh 使用最的请求负载均衡策略,其中池中的服务实例最少活跃连接数接收请求。Red Hat OpenShift Service Mesh 还支持以下模型,您可以在目的地规则中指定对特定服务或服务子集的请求。

  • Random: 请求会随机转发到池里的实例。
  • Weighted: 根据特定百分比将请求转发到池中的实例。
  • Least requests: 将请求转发到请求数量最少的实例。

目的地规则示例

以下目的地规则示例为 my-svc 目的地服务配置三个不同的子集,具有不同的负载均衡策略:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

1.14.6. 了解网络策略

Red Hat OpenShift Service Mesh 自动在 Service Mesh control plane 和应用程序命名空间中创建和管理多个 NetworkPolicies 资源。这是为了确保应用程序和 control plane 可以相互通信。

例如,如果您已将 OpenShift Container Platform 集群配置为使用 SDN 插件,Red Hat OpenShift Service Mesh 会在每个成员项目中创建 NetworkPolicy 资源。这可让从其他网格成员和 control plane 对网格中的所有 pod 的入站网络数据。这也限制了到成员项目的入站网络数据。如果需要来自非成员项目的入站网络数据,则需要创建一个 NetworkPolicy 来允许这些流量通过。如果您从 Service Mesh 中删除命名空间,则此 NetworkPolicy 资源会从项目中删除。

1.14.6.1. 禁用自动 NetworkPolicy 创建

如果要禁用 NetworkPolicy 资源自动创建和管理,例如强制实现公司安全策略,或者允许直接访问网格中的 pod,您可以这样做。您可以编辑 ServiceMeshControlPlane,并将 spec.security.manageNetworkPolicy 设置为 false

注意

当您禁用了 spec.security.manageNetworkPolicy,Red Hat OpenShift Service Mesh 不会创建 任何 NetworkPolicy 对象。系统管理员负责管理网络并修复可能导致的任何问题。

前提条件

  • 安装了 Red Hat OpenShift Service Mesh Operator 2.1.1 或更高版本。
  • ServiceMeshControlPlane 资源更新至 2.1 或更高版本。

流程

  1. 在 OpenShift Container Platform web 控制台中,点击 OperatorsInstalled Operators
  2. Project 菜单中选择安装 Service Mesh control plane 的项目,如 istio-system
  3. 点 Red Hat OpenShift Service Mesh Operator。在 Istio Service Mesh Control Plane 栏中,点 ServiceMeshControlPlane 的名称,如 basic-install
  4. Create ServiceMeshControlPlane Details 页中,点 YAML 修改您的配置。
  5. ServiceMeshControlPlane 字段 spec.security.manageNetworkPolicy 设置为 false,如下例所示。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
          manageNetworkPolicy: false
  6. Save

1.14.7. 为流量管理配置 sidecar

默认情况下,Red Hat OpenShift Service Mesh 配置每个 Envoy 代理,在其相关负载的所有端口上接收流量,并在转发流量时到达网格中的每个工作负载。您可以使用 sidecar 配置进行以下操作:

  • 微调 Envoy 代理接受的端口和协议集合。
  • 限制 Envoy 代理可访问的服务集合。
注意

要优化服务网格的性能,请考虑限制 Envoy 代理配置。

在 Bookinfo 示例应用程序中,配置 Sidecar 以便所有服务都可以访问在同一命名空间和 control plane 中运行的其他服务。使用 Red Hat OpenShift Service Mesh 策略和遥测功能需要这个 Sidecar 配置。

流程

  1. 使用以下示例创建 YAML 文件,以指定您希望 sidecar 配置应用到特定命名空间中的所有工作负载。否则,使用 workloadSelector 选择特定的工作负载。

    sidecar.yaml 示例

    apiVersion: networking.istio.io/v1alpha3
    kind: Sidecar
    metadata:
      name: default
      namespace: info
    spec:
      egress:
      - hosts:
        - "./*"
        - "istio-system/*"

  2. 运行以下命令以应用 sidecar.yaml,其中 sidecar.yaml 是文件的路径。

    $ oc apply -f sidecar.yaml
  3. 运行以下命令,以验证 sidecar 是否已成功创建。

    $ oc get sidecar

1.14.8. 路由教程

本指南使用 Bookinfo 示例应用程序来提供示例应用程序中的路由示例。安装 Bookinfo 应用程序 以了解这些路由示例如何工作。

1.14.8.1. Bookinfo 路由指南

Service Mesh Bookinfo 示例应用程序包含四个独立的微服务,每个服务都有多个版本。安装 Bookinfo 示例应用程序后,reviews 微服务的三个不同版本同时运行。

当您在浏览器中访问 Bookinfo 应用 /product 页面并多次刷新时,有时书的评论输出中会包含星号分级,而其它时候则没有。如果没有可路由的显式默认服务版本,Service Mesh 会将请求路由到所有可用版本。

本教程可帮助您应用将所有流量路由到微服务的 v1 (版本 1)的规则。之后,您可以根据 HTTP 请求标头值应用一条规则来路由流量。

先决条件:

  • 部署 Bookinfo 示例应用程序以使用以下示例。

1.14.8.2. 应用虚拟服务

在以下流程中,虚拟服务通过应用为微服务设定默认版本的虚拟服务,将所有流量路由到每个微服务的 v1

流程

  1. 应用虚拟服务。

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/info/networking/virtual-service-all-v1.yaml
  2. 要验证是否应用了虚拟服务,请使用以下命令显示定义的路由:

    $ oc get virtualservices -o yaml

    该命令返回一个 kind: VirtualService 资源,采用 YAML 格式。

您已将 Service Mesh 配置为路由到 Bookinfo 微服务的 v1 版本,包括 reviews 服务版本 1。

1.14.8.3. 测试新路由配置

通过刷新 Bookinfo 应用程序的 /productpage 来测试新配置。

流程

  1. 设置 GATEWAY_URL 参数的值。您可以在以后使用这个变量查找 Bookinfo 产品页面的 URL。在本例中,istio-system 是 control plane 项目的名称。

    export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
  2. 运行以下命令,以检索产品页面的 URL:

    echo "http://$GATEWAY_URL/productpage"
  3. 在浏览器中打开 Bookinfo 网站。

页面的评论部分显示没有分级星,无论您刷新多少次。这是因为您已将 Service Mesh 配置为将 reviews 服务的所有流量路由到版本 review:v1,此版本的服务无法访问星表分级服务。

您的服务网格现在将流量路由到服务的一个版本。

1.14.8.4. 基于用户身份的路由

更改路由配置,以便特定用户的所有流量都路由到特定的服务版本。在这种情况下,所有来自名为 Jason 的用户的流量都会被路由到服务的 review:v2 中。

Service Mesh 对用户身份没有任何特殊的内置了解。这个示例是启用的,因为 productpage 服务为到 reviews 服务的所有传出 HTTP 请求都添加了一个自定义的 end-user 标头。

流程

  1. 运行以下命令在 Bookinfo 示例应用程序中启用基于用户的路由。

    $ oc apply -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/info/networking/virtual-service-reviews-test-v2.yaml
  2. 运行以下命令,以确认创建了该规则。此命令返回 YAML 格式的所有 kind: VirtualService

    $ oc get virtualservice reviews -o yaml
  3. 在 Bookinfo 应用程序的 /productpage 中,以用户 jason 身份在无需密码的情况下进行登录。
  4. 刷新浏览器。星级分级会出现在每条评论旁。
  5. 以其他用户身份登录(选择任意名称)。刷新浏览器。现在就不会出现星级评分。现在,除 Jason 外,所有用户的流量都会被路由到 review :v1

您已成功配置了 Bookinfo 示例应用程序,以根据用户身份路由流量。

1.15. 指标、日志和追踪

将应用程序添加到网格后,您可以观察通过应用程序的数据流。如果您没有安装自己的应用程序,可以通过安装 Bookinfo 示例应用程序来了解 Red Hat OpenShift Service Mesh 中的可观察性如何工作。

1.15.1. 发现控制台地址

Red Hat OpenShift Service Mesh 提供以下控制台来查看您的服务网格数据:

  • Kiali 控制台 - Kiali 是 Red Hat OpenShift Service Mesh 的管理控制台。
  • Jaeger 控制台 - Jaeger 是 Red Hat OpenShift distributed tracing 平台的管理控制台。
  • Grafana 控制台 - Grafana 为网格管理员提供 Istio 数据的高级查询和指标分析和仪表板。另外,Grafana 可以用来分析服务网格指标。
  • Prometheus 控制台 - Red Hat OpenShift Service Mesh 使用 Prometheus 存储来自服务的遥测信息。

安装 Service Mesh control plane 时,它会为每个安装的组件自动生成路由。获得路由地址后,您可以访问 Kiali、Jaeger、Prometheus 或 Grafana 控制台来查看和管理您的服务网格数据。

前提条件

  • 必须启用并安装组件。例如,如果您没有安装分布式追踪,您将无法访问 Jaeger 控制台。

从 OpenShift 控制台的步骤

  1. 以具有 cluster-admin 权限的用户身份登录到 OpenShift Container Platform web 控制台。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  2. 进入 NetworkingRoutes
  3. Routes 页面中,从 Namespace 菜单中选择 Service Mesh control plane 项目,如 istio-system

    Location 列显示每个路由的链接地址。

  4. 如有必要,使用过滤器来查找您要访问的路由的组件控制台。单击路由 位置 以启动控制台。
  5. 单击 Log In With OpenShift

通过 CLI 操作的步骤

  1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. 切换到 Service Mesh control plane 项目。在本例中,istio-system 是 Service Mesh control plane 项目。运行以下命令:

    $ oc project istio-system
  3. 要获取各种 Red Hat OpenShift Service Mesh 控制台的路由,请运行以下命令:

    $ oc get routes

    这个命令返回 Kiali、Jaeger、Prometheus 和 Grafana web 控制台以及服务网格中任何其他路由的 URL。您应该看到类似如下的输出:

    NAME                    HOST/PORT                         SERVICES              PORT    TERMINATION
    info-gateway        bookinfo-gateway-yourcompany.com  istio-ingressgateway          http2
    grafana                 grafana-yourcompany.com           grafana               <all>   reencrypt/Redirect
    istio-ingressgateway    istio-ingress-yourcompany.com     istio-ingressgateway  8080
    jaeger                  jaeger-yourcompany.com            jaeger-query          <all>   reencrypt
    kiali                   kiali-yourcompany.com             kiali                 20001   reencrypt/Redirect
    prometheus              prometheus-yourcompany.com        prometheus            <all>   reencrypt/Redirect
  4. 将您要从 HOST/PORT 列访问的控制台的 URL 复制到浏览器中以打开控制台。
  5. 单击 Log In With OpenShift

1.15.2. 访问 Kiali 控制台

您可以在 Kiali 控制台中查看应用程序的拓扑、健康和指标。如果您的服务遇到问题,Kiali 控制台可让您通过服务查看数据流。您可以查看不同级别中的与网格组件相关的信息,包括抽象应用程序、服务以及负载。Kiali 还会实时提供命名空间的互动图形视图。

要访问 Kiali 控制台,您必须安装并配置了 Red Hat OpenShift Service Mesh。

安装过程创建了访问 Kiali 控制台的路由。

如果您知道 Kiali 控制台的 URL,您可以直接访问它。如果您不知道 URL,请使用以下指示:

管理员的步骤

  1. 使用管理员角色登录 OpenShift Container Platform Web 控制台。
  2. HomeProjects
  3. 如有必要,在 Projects 页面上,使用过滤器来查找项目的名称。
  4. 点项目的名称,例如 info
  5. Project details 页面中,点 Launcher 部分的 Kiali 链接。
  6. 使用与访问 OpenShift Container Platform 控制台相同的用户名和密码登录到 Kiali 控制台。

    第一次登录到 Kiali 控制台时,您会看到 Overview 页面,它会显示服务网格中您有权查看的所有命名空间。

    如果您验证了控制台安装,且命名空间还没有添加到网格中,则可能无法显示 istio-system 以外的任何数据。

开发人员的步骤

  1. 使用开发人员角色登录 OpenShift Container Platform Web 控制台。
  2. 单击 Project
  3. 如有必要,在 Project Details 页面上,使用过滤器来查找项目的名称。
  4. 点项目的名称,例如 info
  5. Project 页面中,点 Launcher 部分的 Kiali 链接。
  6. 单击 Log In With OpenShift

1.15.3. 在 Kiali 控制台中查看服务网格数据

Kiali Graph 为您的网格流量提供了强大的视觉化功能。拓扑将实时请求流量与您的 Istio 配置信息相结合,可让您快速发现服务网格的行为。多种图形类型允许您将流量视觉化为高级别服务拓扑、低级工作负载拓扑或应用程序级别拓扑。

可以选择的几个图:

  • App 图显示所有标记相同应用程序的总工作负载。
  • Service 图显示网格中各个服务的节点,但所有应用程序和工作负载都不包括在这个图中。它提供了一个高级别的视图,并聚合了定义的服务的所有流量。
  • Versioned App 图 显示每个应用版本的节点。应用程序的所有版本都分组在一起。
  • Workload 图显示服务网格中每个工作负载的节点。此图不要求您使用应用程序和版本标签。如果您的应用程序没有使用 version 标签,请使用此图。

图形节点使用各种信息进行解码,指向虚拟服务和服务条目等各种路由路由选项,以及故障注入和断路器等特殊配置。它可以识别 mTLS 问题、延迟问题、错误流量等。Graph 高度可配置,可以显示流量动画,并具有强大的 Find 和 Hide 功能。

单击 Legend 按钮,以查看图中显示的有关图形、颜色、箭头和徽标的信息。

要查看指标的概述信息,请在图形中选择任意节点或边缘以便在概述详情面板中显示其指标详情。

1.15.3.1. 在 Kiali 中更改图形布局

Kiali 图形的布局可能会根据您的应用程序架构和要显示的数据的不同而有所不同。例如,图形节点的数量及其交互可以决定 Kiali 图形的呈现方式。因为无法创建出适合每种情况的单一布局,Kiali 提供了几种不同布局的选择。

先决条件

  • 如果您没有安装自己的应用程序,请安装 Bookinfo 示例应用程序。然后,通过多次输入以下命令为 Bookinfo 应用程序生成流量。

    $ curl "http://$GATEWAY_URL/productpage"

    此命令模拟访问应用的 productpage 微服务的用户。

流程

  1. 启动 Kiali 控制台。
  2. 单击 Log In With OpenShift
  3. 在 Kiali 控制台中,点 Graph 查看命名空间图。
  4. Namespace 菜单中选择应用程序命名空间,例如 info
  5. 要选择不同的图形布局,请执行以下任一操作:

    • 从图顶部的菜单中选择不同的图形数据分组。

      • 应用程序图
      • 服务图
      • 版本化应用图(默认)
      • 工作负载图
    • 从图形底部的图标中选择不同的图形布局。

      • 布局默认 dagre
      • 布局 1 cose-bilkent
      • 布局 2 cola

1.15.3.2. 在 Kiali 控制台中查看日志

您可以在 Kiali 控制台中查看工作负载的日志。Workload Detail 页面包含一个 Logs 选项卡,显示一个可显示应用程序和代理日志的统一日志视图。您可以选择在 Kiali 中显示日志的频率。

要更改 Kiali 中显示的日志的日志级别,您可以更改工作负载或代理的日志配置。

前提条件

  • 安装和配置 Service Mesh。
  • 已安装并配置了 Kiali。
  • Kiali 控制台的地址。
  • 在网格中添加了应用程序或 Bookinfo 示例应用程序。

流程

  1. 启动 Kiali 控制台。
  2. 单击 Log In With OpenShift

    Kiali Overview 页面会显示添加到具有权限的网格中的命名空间。

  3. 单击 Workloads
  4. Workloads 页面中,从 Namespace 菜单中选择项目。
  5. 如有必要,使用过滤器来查找您要查看的日志的工作负载。单击工作负载名称。例如,单击 ratings-v1
  6. Workload Details 页面中,单击 Logs 选项卡来查看工作负载的日志。
提示

如果没有看到任何日志条目,您可能需要调整 Time Range 或 Refresh 间隔。

1.15.3.3. 在 Kiali 控制台中查看指标

您可以在 Kiali 控制台中查看应用程序、工作负载和服务的入站和出站指标。详情页面包括以下标签页:

  • 入站应用程序指标
  • 出站应用指标
  • 入站工作负载指标
  • 出站工作负载指标
  • 入站服务指标

这些标签页显示预定义的指标仪表板,它们根据相关应用程序、工作负载或服务级别进行定制。应用程序和工作负载详情视图显示请求和响应指标,如卷、持续时间、大小或 TCP 流量。服务详情视图仅显示入站流量的请求和响应指标。

Kiali 允许您选择图表的尺寸来自定义 chart。Kiali 还可以显示源或目标代理指标报告的指标。另外,Kiali 可以覆盖指标上的 trace。

前提条件

  • 安装和配置 Service Mesh。
  • 已安装并配置了 Kiali。
  • Kiali 控制台的地址。
  • (可选)安装和配置了分布式追踪。

流程

  1. 启动 Kiali 控制台。
  2. 单击 Log In With OpenShift

    Kiali Overview 页面会显示添加到具有权限的网格中的命名空间。

  3. 单击 ApplicationsWorkloadsServices
  4. ApplicationsWorkloadsServices 页面上,从 Namespace 菜单中选择项目。
  5. 如有必要,使用过滤器来查找您要查看其日志的应用程序、工作负载或服务。单击 Name
  6. Application DetailstailWorkload DetailsService Details 页面中,单击 Inbound MetricsOutbound Metrics 选项卡来查看指标。

1.15.4. 分布式追踪

分布式追踪是通过跟踪应用中服务调用的路径来跟踪应用中各个服务的性能的过程。每次用户在应用中采取行动时,将执行请求,该请求可能需要许多服务进行交互来生成响应。此请求的路径称为分布式事务。

Red Hat OpenShift Service Mesh 使用 Red Hat OpenShift distributed tracing 平台来允许开发人员查看微服务应用程序中的调用流。

1.15.4.1. 连接现有的分布式追踪实例

如果您在 OpenShift Container Platform 中已有现有的 Red Hat OpenShift distributed tracing Platform (Jaeger) 实例,可以将 ServiceMeshControlPlane 资源配置为使用该实例进行分布式追踪平台。

先决条件

  • 安装和配置 Red Hat OpenShift distributed tracing 平台实例。

流程

  1. 在 OpenShift Container Platform web 控制台中,点击 OperatorsInstalled Operators
  2. Project 菜单,选择安装 Service Mesh control plane 的项目,如 istio-system
  3. 点 Red Hat OpenShift Service Mesh Operator。在 Istio Service Mesh Control Plane 列中,点 ServiceMeshControlPlane 资源的名称,例如 basic
  4. 将分布式追踪平台(Jaeger)实例的名称添加到 ServiceMeshControlPlane

    1. YAML 标签。
    2. 将分布式追踪平台(Jaeger)实例的名称添加到 ServiceMeshControlPlane 资源中的 spec.addons.jaeger.name 中。在以下示例中,distr-tracing-production 是分布式追踪平台(Jaeger)实例的名称。

      分布式追踪配置示例

      spec:
        addons:
          jaeger:
            name: distr-tracing-production

    3. Save
  5. Reload 来验证 ServiceMeshControlPlane 资源已被正确配置。

1.15.4.2. 调整抽样率

trace 是服务网格中服务间的执行路径。一个 trace 由一个或多个范围组成。span 是具有名称、开始时间和持续时间的逻辑工作单元。抽样率决定了 trace 的持久性频率。

Envoy 代理抽样率默认设置为服务网格中 trace 的 100%。高抽样率会消耗集群资源和性能,但在调试问题时很有用。在生产环境中部署 Red Hat OpenShift Service Mesh 前,请将值设置为较小的 trace 部分。例如,将 spec.tracing.sampling 设置为 100 来示例 trace 的 1%。

将 Envoy 代理抽样率配置为代表 0.01% 增量的扩展整数。

在基本安装中,spec.tracing.sampling 设置为 10000,这代表 100% 的 trace 采样。例如:

  • 将值设置为 10 个 trace 的 0.1% 样本。
  • 将值设为 500 个样本 5% 的 trace.
注意

Envoy 代理抽样率适用于 Service Mesh 可用的应用程序,并使用 Envoy 代理。这个抽样率决定了 Envoy 代理收集并跟踪的数据量。

Jaeger 远程抽样率适用于 Service Mesh 外部的应用程序,不要使用 Envoy 代理,如数据库。这种抽样率决定了分布式追踪系统收集和存储的数据量。如需更多信息,请参阅分布式追踪配置选项

流程

  1. 在 OpenShift Container Platform web 控制台中,点击 OperatorsInstalled Operators
  2. Project 菜单并选择安装 control plane 的项目,如 istio-system
  3. 点 Red Hat OpenShift Service Mesh Operator。在 Istio Service Mesh Control Plane 列中,点 ServiceMeshControlPlane 资源的名称,例如 basic
  4. 要调整抽样率,请为 spec.tracing.sampling 设置不同的值。

    1. YAML 标签。
    2. ServiceMeshControlPlane 资源中的 spec.tracing.sampling 设置值。在以下示例中,将它设置为 100

      Jaeger 抽样示例

      spec:
        tracing:
          sampling: 100

    3. Save
  5. Reload 来验证 ServiceMeshControlPlane 资源已被正确配置。

1.15.5. 访问 Jaeger 控制台

要访问 Jaeger 控制台,您必须安装并配置了 Red Hat OpenShift Service Mesh。

安装过程会创建路由来访问 Jaeger 控制台。

如果您知道 Jaeger 控制台的 URL,您可以直接访问它。如果您不知道 URL,请使用以下指示:

从 OpenShift 控制台的步骤

  1. 以具有 cluster-admin 权限的用户身份登录到 OpenShift Container Platform web 控制台。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。
  2. 进入 NetworkingRoutes
  3. Routes 页面中,从 Namespace 菜单中选择 Service Mesh control plane 项目,如 istio-system

    Location 列显示每个路由的链接地址。

  4. 如有必要,使用过滤器来查找 jaeger 路由。单击路由 位置 以启动控制台。
  5. 单击 Log In With OpenShift

Kiali 控制台的步骤

  1. 启动 Kiali 控制台。
  2. 单击左侧导航窗格中的 Distributed Tracing
  3. 单击 Log In With OpenShift

通过 CLI 操作的步骤

  1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。如果使用 Red Hat OpenShift Dedicated,则必须有一个具有 dedicated-admin 角色的帐户。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. 要使用命令行查询路由详情,请输入以下命令。在本例中,istio-system 是 Service Mesh control plane 命名空间。

    $ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
  3. 启动浏览器并进入 https://<JAEGER_URL>,其中 <JAEGER_URL> 是您在上一步中发现的路由。
  4. 使用您用于访问 OpenShift Container Platform 控制台的相同用户名和密码登录。
  5. 如果您已将服务添加到服务网格中并生成了 trace,您可以使用过滤器和 Find Traces 按钮搜索 trace 数据。

    如果您要验证控制台安装,则不会显示 trace 数据。

有关配置 Jaeger 的更多信息,请参阅分布式追踪文档

1.15.6. 访问 Grafana 控制台

Grafana 是一个分析工具,可用于查看、查询和分析服务网格指标。在本例中,istio-system 是 Service Mesh control plane 命名空间。要访问 Grafana,请执行以下操作:

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. Project 菜单,选择安装 Service Mesh control plane 的项目,如 istio-system
  3. 单击 Routes
  4. 点击 Grafana 行的 Location 列中的链接。
  5. 使用 OpenShift Container Platform 凭证登录到 Grafana 控制台。

1.15.7. 访问 Prometheus 控制台

Prometheus 是一个监控和警报工具,可用于收集微服务相关的多维数据。在本例中,istio-system 是 Service Mesh control plane 命名空间。

流程

  1. 登陆到 OpenShift Container Platform Web 控制台。
  2. Project 菜单,选择安装 Service Mesh control plane 的项目,如 istio-system
  3. 单击 Routes
  4. 单击 Prometheus 行的 Location 列中的链接。
  5. 使用 OpenShift Container Platform 凭证登录到 Prometheus 控制台。

1.15.8. 与用户工作负载监控集成

默认情况下,Red Hat OpenShift Service Mesh (OSSM)使用专用的 Prometheus 实例安装 Service Mesh control plane (sMCP),用于从网格收集指标。但是,生产系统需要更高级的监控系统,如 OpenShift Container Platform 监控用户定义的项目。

以下步骤演示了如何将 Service Mesh 与 user-workload 监控集成。

前提条件

  • 启用 user-workload 监控。
  • 安装了 Red Hat OpenShift Service Mesh Operator 2.4。
  • 已安装 Kiali Operator 1.65。

流程

  1. 运行以下命令,为 Kiali 创建到 Thanos 的令牌:

    1. 运行以下命令来设置 SECRET 环境变量:

      $ SECRET=`oc get secret -n openshift-user-workload-monitoring |
       grep  prometheus-user-workload-token | head -n 1 | awk '{print $1 }'`
    2. 运行以下命令设置 TOKEN 环境变量:

      $ TOKEN=`oc get secret $SECRET -n openshift-user-workload-monitoring -o jsonpath='{.data.token}' | base64 -d`
    3. 运行以下命令,为 Kiali 创建令牌:

      $ oc create secret generic thanos-querier-web-token -n istio-system --from-literal=token=$TOKEN
  2. 为 user-workload 监控配置 Kiali:

    apiVersion: kiali.io/v1alpha1
    kind: Kiali
    metadata:
      name: kiali-user-workload-monitoring
      namespace: istio-system
    spec:
      external_services:
        istio:
          url_service_version: 'http://istiod-basic.istio-system:15014/version'
          config_map_name: istio-basic 1
        prometheus:
          auth:
            token: secret:thanos-querier-web-token:token
            type: bearer
            use_kiali_token: false
          query_scope:
            mesh_id: "basic-istio-system"
          thanos_proxy:
            enabled: true
          url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
      version: v1.65
    1
    设置前缀为 istio-ServiceMeshControlPlane 名称。
  3. 为外部 Prometheus 配置 SMCP:

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
      namespace: istio-system
    spec:
      addons:
        prometheus:
          enabled: false 1
        grafana:
          enabled: false 2
        kiali:
          name: kiali-user-workload-monitoring
      meshConfig:
        extensionProviders:
        - name: prometheus
          prometheus: {}
    1
    禁用 OSSM 提供的默认 Prometheus 实例。
    2
    禁用 Grafana。外部 Prometheus 实例不支持它。
  4. 应用自定义网络策略以允许来自监控命名空间的入口流量:

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: user-workload-access
      namespace: info 1
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: monitoring
      podSelector: {}
      policyTypes:
      - Ingress
    1
    自定义网络策略必须应用到所有命名空间。
  5. 应用 Telemetry 对象以启用 Istio 代理中的流量指标:

    apiVersion: telemetry.istio.io/v1alpha1
    kind: Telemetry
    metadata:
      name: enable-prometheus-metrics
      namespace: istio-system 1
    spec:
      selector: 2
        matchLabels:
          app: info
      metrics:
      - providers:
        - name: prometheus
    1
    在 control plane 命名空间中创建的 Telemetry 对象应用到网格中的所有工作负载。要将遥测应用到一个命名空间,请在目标命名空间中创建对象。
    2
    可选:设置 selector.matchLabels spec,将 Telemetry 对象应用到目标命名空间中的特定工作负载。
  6. 应用 ServiceMonitor 对象来监控 Istio control plane:

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: istiod-monitor
      namespace: istio-system 1
    spec:
      targetLabels:
      - app
      selector:
        matchLabels:
          istio: pilot
      endpoints:
      - port: http-monitoring
        interval: 30s
        relabelings:
        - action: replace
          replacement: "basic-istio-system" 2
          targetLabel: mesh_id
    1
    在 Istio control plane 命名空间中创建此 ServiceMonitor 对象,因为它监控 Istiod 服务。在本例中,命名空间是 istio-system
    2
    字符串 "basic-istio-system" 是 SMCP 名称及其命名空间的组合,但只要使用集群中用户工作负载监控的每个网格都是唯一的,可以使用任何标签。第 2 步中配置的 Kiali 资源的 spec.prometheus.query_scope 需要匹配这个值。
    注意

    如果使用 user-workload 监控只有一个网格,则 Kiali 资源中的 mesh_id 重新标记和 spec.prometheus.query_scope 字段都是可选的(但如果 mesh_id 标签被删除,则此处给出的 query_scope 字段应该被删除)。

    如果使用 user-workload 监控可能会有多个网格,则 mesh_id 重新标记s 和 Kiali 资源中的 spec.prometheus.query_scope 字段都是必需的,以便 Kiali 只从关联的网格中看到指标。如果没有部署 Kiali,仍建议应用 mesh_id 重新标记,以便来自不同网格的指标可以区分不同的网格。

  7. 应用 PodMonitor 对象从 Istio 代理收集指标:

    apiVersion: monitoring.coreos.com/v1
    kind: PodMonitor
    metadata:
      name: istio-proxies-monitor
      namespace: istio-system 1
    spec:
      selector:
        matchExpressions:
        - key: istio-prometheus-ignore
          operator: DoesNotExist
      podMetricsEndpoints:
      - path: /stats/prometheus
        interval: 30s
        relabelings:
        - action: keep
          sourceLabels: [__meta_kubernetes_pod_container_name]
          regex: "istio-proxy"
        - action: keep
          sourceLabels: [__meta_kubernetes_pod_annotationpresent_prometheus_io_scrape]
        - action: replace
          regex: (\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})
          replacement: '[$2]:$1'
          sourceLabels: [__meta_kubernetes_pod_annotation_prometheus_io_port,
          __meta_kubernetes_pod_ip]
          targetLabel: __address__
        - action: replace
          regex: (\d+);((([0-9]+?)(\.|$)){4})
          replacement: $2:$1
          sourceLabels: [__meta_kubernetes_pod_annotation_prometheus_io_port,
          __meta_kubernetes_pod_ip]
          targetLabel: __address__
        - action: labeldrop
          regex: "__meta_kubernetes_pod_label_(.+)"
        - sourceLabels: [__meta_kubernetes_namespace]
          action: replace
          targetLabel: namespace
        - sourceLabels: [__meta_kubernetes_pod_name]
          action: replace
          targetLabel: pod_name
        - action: replace
          replacement: "basic-istio-system" 2
          targetLabel: mesh_id
    1
    由于 OpenShift Container Platform 监控会忽略 ServiceMonitorPodMonitor 对象中的 namespaceSelector spec,所以您必须在所有网格命名空间中应用 PodMonitor 对象,包括 control plane 命名空间。
    2
    字符串 "basic-istio-system" 是 SMCP 名称及其命名空间的组合,但只要使用集群中用户工作负载监控的每个网格都是唯一的,可以使用任何标签。第 2 步中配置的 Kiali 资源的 spec.prometheus.query_scope 需要匹配这个值。
    注意

    如果使用 user-workload 监控只有一个网格,则 Kiali 资源中的 mesh_id 重新标记和 spec.prometheus.query_scope 字段都是可选的(但如果 mesh_id 标签被删除,则此处给出的 query_scope 字段应该被删除)。

    如果使用 user-workload 监控可能会有多个网格,则 mesh_id 重新标记s 和 Kiali 资源中的 spec.prometheus.query_scope 字段都是必需的,以便 Kiali 只从关联的网格中看到指标。如果没有部署 Kiali,仍建议应用 mesh_id 重新标记,以便来自不同网格的指标可以区分不同的网格。

  8. 打开 OpenShift Container Platform Web 控制台,检查指标是否可见。

1.15.9. 其他资源

1.16. 性能和可扩展性

默认 ServiceMeshControlPlane 设置不适用于生产环境,它被设计为在一个默认的 OpenShift Container Platform 安装中成功安装,默认的 OpenShift Container Platform 安装是一个有限的资源环境。在验证了成功安装 SMCP 后,您应该修改 SMCP 中定义的设置以适应您的环境。