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

服务网格发行说明

您正在查看不再受支持的 Red Hat OpenShift 服务网格版本的文档。

服务网格 1.0 和 1.1 版控制平面不再受支持。有关升级服务网格控制平面的信息，请参阅升级服务网格。

有关特定 Red Hat OpenShift 服务网格版本的支持状态信息，请参阅产品生命周期页面。

使开源更具包容性

Red Hat 致力于替换我们代码、文档和网络属性中存在问题的语言。我们将从这四个术语开始：master、slave、blacklist 和 whitelist。由于这项工作的巨大性，这些更改将在接下来的几个版本中逐步实施。更多详细信息，请参阅我们首席技术官 Chris Wright 的消息。

Red Hat OpenShift 服务网格简介

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

微服务架构将企业应用程序的工作分解成模块化服务，这可以使扩展和维护更容易。但是，随着基于微服务架构构建的企业应用程序规模和复杂性的增长，它变得难以理解和管理。服务网格可以通过捕获或拦截服务之间的流量来解决这些架构问题，并且可以修改、重定向或创建对其他服务的新的请求。

服务网格基于开源Istio 项目，提供了一种简单的方法来创建已部署服务的网络，该网络提供发现、负载平衡、服务到服务身份验证、故障恢复、指标和监控。服务网格还提供更复杂的运营功能，包括 A/B 测试、金丝雀发布、访问控制和端到端身份验证。

获取支持

如果您在使用本文档中描述的过程或 OpenShift Container Platform 时遇到困难，请访问Red Hat 客户门户。

在客户门户中，您可以

  • 搜索或浏览 Red Hat 知识库中与 Red Hat 产品相关的文章和解决方案。

  • 向 Red Hat 支持提交支持案例。

  • 访问其他产品文档。

要识别集群中的问题，您可以使用OpenShift 集群管理器中的 Insights。Insights 提供有关问题的详细信息，以及（如果可用）如何解决问题的相关信息。

如果您有改进此文档的建议或发现错误，请提交一个关于最相关文档组件的Jira问题。请提供具体的细节，例如章节名称和OpenShift Container Platform版本。

打开支持案例时，向Red Hat支持提供有关集群的调试信息非常有帮助。

must-gather工具使您可以收集有关OpenShift Container Platform集群的诊断信息，包括虚拟机和其他与Red Hat OpenShift Service Mesh相关的数据。

为了获得及时的支持，请同时提供OpenShift Container Platform和Red Hat OpenShift Service Mesh的诊断信息。

关于must-gather工具

oc adm must-gather CLI命令会收集集群中可能需要用于调试问题的最相关信息，包括：

  • 资源定义

  • 服务日志

默认情况下，oc adm must-gather命令使用默认插件镜像并写入./must-gather.local。

或者，您可以使用以下部分中描述的适当参数运行该命令来收集特定信息。

  • 要收集与一个或多个特定功能相关的数据，请使用带有镜像的--image参数，如以下部分所列。

    例如：

    $ oc adm must-gather \
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.3

  • 要收集审计日志，请使用-- /usr/bin/gather_audit_logs参数，如以下部分所述。

    例如：

    $ oc adm must-gather -- /usr/bin/gather_audit_logs

    为了减小文件大小，审计日志不会作为默认信息集的一部分进行收集。

运行oc adm must-gather时，会在集群上的新项目中创建一个具有随机名称的新Pod。数据将在该Pod上收集，并保存在当前工作目录中以must-gather.local开头的新的目录中。

例如：

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...

或者，您可以使用--run-namespace选项在特定命名空间中运行oc adm must-gather命令。

例如：

$ oc adm must-gather --run-namespace <namespace> \
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.3

先决条件

  • 具有cluster-admin角色的用户对集群的访问权限。

  • 已安装OpenShift Container Platform CLI (oc)。

关于收集服务网格数据

您可以使用oc adm must-gather CLI命令收集有关集群的信息，包括与Red Hat OpenShift Service Mesh相关的功能和对象。

先决条件

  • 具有cluster-admin角色的用户对集群的访问权限。

  • 已安装OpenShift Container Platform CLI (oc)。

步骤

  1. 要使用must-gather收集Red Hat OpenShift Service Mesh数据，您必须指定Red Hat OpenShift Service Mesh镜像。

    $ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8:2.6

  2. 要使用must-gather收集特定服务网格控制平面命名空间的Red Hat OpenShift Service Mesh数据，您必须指定Red Hat OpenShift Service Mesh镜像和命名空间。在此示例中，在gather之后，请将<namespace>替换为您的服务网格控制平面命名空间，例如istio-system。

    $ oc adm must-gather --image=registry.redhat.io/openshift-service-mesh/istio-must-gather-rhel8:2.6 gather <namespace>

    这将创建一个包含以下项目的本地目录：

    • Istio Operator命名空间及其子对象

    • 所有控制平面命名空间及其子对象

    • 属于任何服务网格的所有命名空间及其子对象

    • 所有Istio自定义资源定义 (CRD)

    • 所有Istio CRD对象，例如给定命名空间中的VirtualServices

    • 所有Istio Webhook

Red Hat OpenShift Service Mesh支持的配置

以下是Red Hat OpenShift Service Mesh唯一支持的配置：

  • OpenShift Container Platform版本4.6或更高版本。

Red Hat OpenShift Service Mesh不支持OpenShift Online和Red Hat OpenShift Dedicated。

  • 部署必须包含在一个未联合的单个OpenShift Container Platform集群中。

  • 此版本的Red Hat OpenShift Service Mesh仅适用于OpenShift Container Platform x86_64。

  • 此版本仅支持所有服务网格组件都包含在其运行的OpenShift Container Platform集群中的配置。它不支持管理位于集群外部或多集群场景中的微服务。

  • 此版本仅支持不集成外部服务（例如虚拟机）的配置。

有关Red Hat OpenShift Service Mesh生命周期和支持配置的更多信息，请参阅支持策略。

Red Hat OpenShift Service Mesh上Kiali的支持配置

  • Kiali可观测性控制台仅支持Chrome、Edge、Firefox或Safari浏览器的最新两个版本。

支持的Mixer适配器

  • 此版本仅支持以下Mixer适配器：

    • 3scale Istio适配器

新功能

Red Hat OpenShift Service Mesh在服务网络中统一提供许多关键功能：

  • 流量管理 - 控制服务之间流量和API调用的流动，使调用更可靠，并在面临不利条件时使网络更强大。

  • 服务身份和安全性 - 为网格中的服务提供可验证的身份，并提供保护服务流量在其流经不同信任度网络的能力。

  • 策略执行 - 将组织策略应用于服务之间的交互，确保访问策略得到执行，并且资源在消费者之间公平分配。策略更改是通过配置网格来完成的，而不是通过更改应用程序代码来完成的。

  • 遥测 - 了解服务之间的依赖关系以及它们之间流量的性质和流动，从而能够快速识别问题。

Red Hat OpenShift Service Mesh 1.1.18.2 的新功能

此版本的Red Hat OpenShift Service Mesh解决了常见漏洞和披露 (CVE)。

Red Hat OpenShift Service Mesh 1.1.18.2 版本中包含的组件版本

组件 版本

Istio

1.4.10

Jaeger

1.30.2

Kiali

1.12.21.1

3scale Istio适配器

1.0.0

Red Hat OpenShift Service Mesh 1.1.18.1 的新功能

此版本的Red Hat OpenShift Service Mesh解决了常见漏洞和披露 (CVE)。

Red Hat OpenShift Service Mesh 1.1.18.1 版本中包含的组件版本

组件 版本

Istio

1.4.10

Jaeger

1.30.2

Kiali

1.12.20.1

3scale Istio适配器

1.0.0

Red Hat OpenShift Service Mesh 1.1.18 的新功能

此版本的Red Hat OpenShift Service Mesh解决了常见漏洞和披露 (CVE)。

Red Hat OpenShift Service Mesh 1.1.18 版本中包含的组件版本

组件 版本

Istio

1.4.10

Jaeger

1.24.0

Kiali

1.12.18

3scale Istio适配器

1.0.0

Red Hat OpenShift Service Mesh 1.1.17.1 的新功能

此版本的Red Hat OpenShift Service Mesh解决了常见漏洞和披露 (CVE)。

Red Hat OpenShift Service Mesh 处理 URI 片段的方式变更

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

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

在缓解措施中，请求URI的片段部分会在授权和路由之前被移除。这可以防止URI中包含片段的请求绕过基于不包含片段部分的URI的授权策略。

授权策略所需的更新

Istio 会为主机名本身及其所有匹配端口生成主机名。例如，对于主机名 "httpbin.foo" 的虚拟服务或网关会生成与 "httpbin.foo" 和 "httpbin.foo:*" 匹配的配置。但是，精确匹配授权策略仅匹配为hosts 或 notHosts 字段提供的精确字符串。

如果您使用精确字符串比较的AuthorizationPolicy 资源来确定hosts 或 notHosts规则，则您的集群会受到影响。

您必须更新您的授权策略规则，使用前缀匹配而不是精确匹配。例如，在第一个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:*"]

Red Hat OpenShift Service Mesh 1.1.17 的新功能

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.16 的新功能

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.15 的新功能

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.14 的新功能

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

必须完成一些手动步骤才能解决 CVE-2021-29492 和 CVE-2021-31920。

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字段模式的授权策略，则您的集群会受到此漏洞的影响。这些模式容易受到意外策略绕过的影响。

如果满足以下条件，则您的集群不会受到此漏洞的影响：

  • 您没有授权策略。

  • 您的授权策略未定义paths或notPaths字段。

  • 您的授权策略使用ALLOW action + paths字段或DENY action + notPaths字段模式。这些模式只会导致意外拒绝，而不是策略绕过。对于这些情况，升级是可选的。

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

更新路径规范化配置

Istio 授权策略可以基于 HTTP 请求中的 URL 路径。路径规范化，也称为 URI 规范化，修改和标准化传入请求的路径，以便可以以标准方式处理规范化的路径。句法上不同的路径在路径规范化后可能等效。

在根据授权策略评估请求并路由请求之前，Istio 支持对请求路径执行以下规范化方案

表 1. 规范化方案
选项 描述 示例 备注

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

当您默认允许所有流量时，这是最严格的设置。建议使用此设置，但需要注意的是，您必须彻底测试您的授权策略路由。百分比编码的斜杠和反斜杠字符（%2F、%2f、%5C和%5c）在MERGE_SLASHES规范化之前解码为/或\。

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

更新此设置以缓解 CVE-2021-31920。此设置更安全，但也可能破坏应用程序。在部署到生产环境之前，请测试您的应用程序。

规范化算法按以下顺序执行

  1. 百分比解码%2F、%2f、%5C和%5c。

  2. Envoy 中的RFC 3986和其他规范化，由normalize_path选项实现。

  3. 合并斜杠。

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

路径规范化配置示例

确保Envoy将请求路径规范化以符合您的后端服务的预期，这对系统的安全性至关重要。以下示例可作为您配置系统的参考。规范化的URL路径（如果选择NONE，则为原始URL路径）将：

  1. 用于与授权策略进行检查。

  2. 转发到后端应用程序。

表2. 配置示例
如果您的应用程序…… 选择……

依赖于代理进行规范化

BASE、MERGE_SLASHES 或 DECODE_AND_MERGE_SLASHES

基于RFC 3986规范化请求路径，但不合并斜杠。

BASE

基于RFC 3986规范化请求路径，并合并斜杠，但不解码百分号编码的斜杠。

MERGE_SLASHES

基于RFC 3986规范化请求路径，解码百分号编码的斜杠，并合并斜杠。

DECODE_AND_MERGE_SLASHES

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

NONE

配置您的SMCP以进行路径规范化

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

SMCP v1 pathNormalization
spec:
  global:
    pathNormalization: <option>

Red Hat OpenShift Service Mesh 1.1.13 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.12 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.11 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.10 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.9 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.8 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.7 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.6 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.5 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

此版本还增加了对配置密码套件的支持。

Red Hat OpenShift Service Mesh 1.1.4 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

必须完成手动步骤才能解决CVE-2020-8663。

CVE-2020-8663所需的手动更新

针对CVE-2020-8663: envoy: 接受过多连接时资源耗尽的修复添加了对下游连接的可配置限制。必须配置此限制的配置选项才能减轻此漏洞。

无论您使用的是1.1版本还是1.0版本的Red Hat OpenShift Service Mesh，都需要执行这些手动步骤来缓解此CVE。

这个新的配置选项称为overload.global_downstream_max_connections，它可以配置为代理runtime设置。请执行以下步骤以配置入口网关的限制。

步骤

  1. 创建一个名为bootstrap-override.json的文件，其中包含以下文本，以强制代理覆盖引导模板并从磁盘加载运行时配置。

      {
    "runtime": {
      "symlink_root": "/var/lib/istio/envoy/runtime"
    }
  }

  2. 从bootstrap-override.json文件创建一个密钥，将<SMCPnamespace>替换为您创建服务网格控制平面 (SMCP) 的命名空间。

    $  oc create secret generic -n <SMCPnamespace> gateway-bootstrap --from-file=bootstrap-override.json

  3. 更新SMCP配置以激活覆盖。

    更新后的SMCP配置示例 #1
    apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    gateways:
      istio-ingressgateway:
        env:
          ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
        secretVolumes:
        - mountPath: /var/lib/istio/envoy/custom-bootstrap
          name: custom-bootstrap
          secretName: gateway-bootstrap

  4. 要设置新的配置选项，请创建一个密钥，其中包含overload.global_downstream_max_connections设置的所需值。以下示例使用值为10000

    $  oc create secret generic -n <SMCPnamespace> gateway-settings --from-literal=overload.global_downstream_max_connections=10000

  5. 再次更新SMCP以将密钥安装在Envoy查找运行时配置的位置。

更新后的SMCP配置示例 #2
apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  template: default
#Change the version to "v1.0" if you are on the 1.0 stream.
  version: v1.1
  istio:
    gateways:
      istio-ingressgateway:
        env:
          ISTIO_BOOTSTRAP_OVERRIDE: /var/lib/istio/envoy/custom-bootstrap/bootstrap-override.json
        secretVolumes:
        - mountPath: /var/lib/istio/envoy/custom-bootstrap
          name: custom-bootstrap
          secretName: gateway-bootstrap
        # below is the new secret mount
        - mountPath: /var/lib/istio/envoy/runtime
          name: gateway-settings
          secretName: gateway-settings

从Elasticsearch 5升级到Elasticsearch 6

从Elasticsearch 5更新到Elasticsearch 6时，您必须删除Jaeger实例，然后重新创建Jaeger实例，因为存在证书问题。重新创建Jaeger实例会触发创建一组新的证书。如果您使用的是持久性存储，只要新Jaeger实例的Jaeger名称和命名空间与已删除的Jaeger实例相同，就可以为新Jaeger实例安装相同的卷。

如果Jaeger作为Red Hat Service Mesh的一部分安装，则执行以下操作

  1. 确定Jaeger自定义资源文件的名称

    $ oc get jaeger -n istio-system

    您应该看到如下内容

    NAME     AGE
jaeger   3d21h

  2. 将生成的自定义资源文件复制到临时目录

    $ oc get jaeger jaeger -oyaml -n istio-system > /tmp/jaeger-cr.yaml

  3. 删除Jaeger实例

    $ oc delete jaeger jaeger -n istio-system

  4. 从您复制的自定义资源文件重新创建Jaeger实例

    $ oc create -f /tmp/jaeger-cr.yaml -n istio-system

  5. 删除生成的自定义资源文件的副本

    $ rm /tmp/jaeger-cr.yaml
如果Jaeger未作为Red Hat Service Mesh的一部分安装，则执行以下操作

在开始之前，请创建Jaeger自定义资源文件的副本。

  1. 通过删除自定义资源文件来删除Jaeger实例

    $ oc delete -f <jaeger-cr-file>

    例如：

    $ oc delete -f jaeger-prod-elasticsearch.yaml

  2. 从Jaeger自定义资源文件的备份副本重新创建您的Jaeger实例

    $ oc create -f <jaeger-cr-file>

  3. 验证您的Pod是否已重新启动

    $ oc get pods -n jaeger-system -w

Red Hat OpenShift Service Mesh 1.1.3 的新特性

此 Red Hat OpenShift Service Mesh 版本解决了常见漏洞和披露 (CVE) 并修复了错误。

Red Hat OpenShift Service Mesh 1.1.2 的新特性

此版本的Red Hat OpenShift Service Mesh解决了安全漏洞。

Red Hat OpenShift Service Mesh 1.1.1 的新特性

此版本的Red Hat OpenShift Service Mesh增加了对脱机安装的支持。

Red Hat OpenShift Service Mesh 1.1.0 的新特性

此版本的Red Hat OpenShift Service Mesh增加了对Istio 1.4.6和Jaeger 1.17.1的支持。

从1.0到1.1的手动更新

如果您要从Red Hat OpenShift Service Mesh 1.0更新到1.1，则必须更新ServiceMeshControlPlane资源以将控制平面组件更新到新版本。

  1. 在Web控制台中，单击Red Hat OpenShift Service Mesh Operator。

  2. 单击**项目**菜单，然后从列表中选择已部署ServiceMeshControlPlane的项目，例如istio-system。

  3. 单击控制平面的名称，例如basic-install。

  4. 单击YAML，并向ServiceMeshControlPlane资源的spec:添加版本字段。例如，要更新到Red Hat OpenShift Service Mesh 1.1.0，请添加version: v1.1。

spec:
  version: v1.1
  ...

版本字段指定要安装的服务网格版本，默认为最新可用版本。

请注意，对Red Hat OpenShift Service Mesh v1.0的支持已于2020年10月结束。您必须升级到v1.1或v2.0。

已弃用的特性

先前版本中提供的一些功能已被弃用或移除。

已弃用的功能仍然包含在 OpenShift Container Platform 中并继续受支持；但是，它将在该产品的未来版本中移除，不建议用于新的部署。

Red Hat OpenShift Service Mesh 1.1.5 中已弃用的功能

以下自定义资源在 1.1.5 版本中已弃用，并在 1.1.12 版本中已移除

  • Policy - Policy 资源已弃用，将在未来版本中被 PeerAuthentication 资源替换。

  • MeshPolicy - MeshPolicy 资源已弃用，将在未来版本中被 PeerAuthentication 资源替换。

  • v1alpha1 RBAC API - v1alpha1 RBAC策略已被v1beta1 AuthorizationPolicy 弃用。RBAC（基于角色的访问控制）定义了ServiceRole和ServiceRoleBinding对象。

    • ServiceRole

    • ServiceRoleBinding

  • RbacConfig - RbacConfig实现了用于控制Istio RBAC行为的自定义资源定义。

    • ClusterRbacConfig（Red Hat OpenShift Service Mesh 1.0之前的版本）

    • ServiceMeshRbacConfig（Red Hat OpenShift Service Mesh 1.0及更高版本）

  • 在 Kiali 中，login 和 LDAP 策略已弃用。未来版本将引入使用 OpenID 提供程序进行身份验证。

以下组件在本版本中也已弃用，并将被Istiod组件在未来版本中替换。

  • Mixer - 访问控制和使用策略

  • Pilot - 服务发现和代理配置

  • Citadel - 证书生成

  • Galley - 配置验证和分发

已知问题

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

  • Red Hat OpenShift Service Mesh 不支持 IPv6，因为它不受上游 Istio 项目支持，也不受 OpenShift Container Platform 完全支持。

  • 图形布局 - Kiali 图形的布局可能会根据您的应用程序架构和要显示的数据（图形节点数量及其交互）而有所不同。由于创建适用于所有情况的单个布局很困难（如果不是不可能的话），因此 Kiali 提供了多种不同布局的选择。要选择不同的布局，您可以从图形设置菜单中选择不同的布局模式。

  • 第一次从 Kiali 控制台访问 Jaeger 和 Grafana 等相关服务时，必须接受证书并使用您的 OpenShift Container Platform 登录凭据重新进行身份验证。这是由于框架在控制台中显示嵌入页面的方式存在问题。

服务网格已知问题

以下是 Red Hat OpenShift Service Mesh 中的已知问题

  • Jaeger/Kiali 运算符升级被阻止，运算符处于挂起状态 使用安装了 Service Mesh 1.0.x 的 Jaeger 或 Kiali 运算符进行升级时，运算符状态显示为“挂起”。

    解决方法：请参阅链接的知识库文章以了解更多信息。

  • Istio-14743 由于此 Red Hat OpenShift Service Mesh 版本所基于的 Istio 版本的限制，目前有几个应用程序与 Service Mesh 不兼容。有关详细信息，请参阅链接的社区问题。

  • MAISTRA-858 描述与 Istio 1.1.x 相关的已弃用选项和配置 的以下 Envoy 日志消息是预期的

    • [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] 使用已弃用的选项“envoy.api.v2.listener.Filter.config”。此配置将很快从 Envoy 中移除。

    • [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] 使用来自文件 lds.proto 的已弃用选项“envoy.api.v2.Listener.use_original_dst”。此配置将很快从 Envoy 中移除。

  • MAISTRA-806 驱逐 Istio Operator Pod 会导致网格和 CNI 未部署。

    解决方法：如果在部署控制平面时驱逐了istio-operator pod，请删除驱逐的istio-operator pod。

  • MAISTRA-681 当控制平面具有许多命名空间时，可能会导致性能问题。

  • MAISTRA-465 Maistra 运算符无法为运算符指标创建服务。

  • MAISTRA-453 如果创建新项目并立即部署 Pod，则不会发生 sidecar 注入。运算符在创建 Pod 之前未能添加maistra.io/member-of，因此必须删除并重新创建 Pod 才能进行 sidecar 注入。

  • MAISTRA-158 应用引用相同主机名的多个网关将导致所有网关停止运行。

Kiali 已知问题

Kiali 的新问题应在OpenShift Service Mesh项目中创建，并将Component设置为Kiali。

以下是 Kiali 中的已知问题

  • KIALI-2206 首次访问 Kiali 控制台时，如果 Kiali 没有缓存的浏览器数据，“查看 Grafana”链接（位于 Kiali 服务详细信息页面的指标选项卡上）会重定向到错误的位置。只有在第一次访问 Kiali 时才会遇到此问题。

  • KIALI-507 Kiali 不支持 Internet Explorer 11。这是因为底层框架不支持 Internet Explorer。要访问 Kiali 控制台，请使用 Chrome、Edge、Firefox 或 Safari 浏览器的两个最新版本之一。

已修复的问题

当前版本已解决以下问题

服务网格已修复的问题

  • MAISTRA-2371 在 listerInformer 中处理墓碑。更新的缓存代码库在将事件从命名空间缓存转换为聚合缓存时未处理墓碑，从而导致 go 协程中出现恐慌。

  • OSSM-542 旋转后，Galley 未使用新证书。

  • OSSM-99 从没有标签的直接 Pod 生成的负载可能会使 Kiali 崩溃。

  • OSSM-93 IstioConfigList 无法按两个或多个名称进行筛选。

  • OSSM-92 取消 VS/DR YAML 编辑页面上的未保存更改不会取消更改。

  • OSSM-90 服务详细信息页面上没有跟踪。

  • MAISTRA-1649 无头服务在不同的命名空间中发生冲突。在不同的命名空间中部署无头服务时，端点配置会合并，并导致无效的 Envoy 配置被推送到 sidecar。

  • MAISTRA-1541 当控制器未设置在所有者引用上时，kubernetesenv 中出现恐慌。如果 Pod 的 ownerReference 未指定控制器，这将导致kubernetesenv cache.go代码中出现恐慌。

  • 已移除本版本及后续版本控制平面安装中的MAISTRA-1352 Cert-manager 自定义资源定义 (CRD)。如果您已安装 Red Hat OpenShift Service Mesh，则如果未使用 cert-manager，则必须手动移除 CRD。

  • 关闭 HTTP/2 连接可能会导致MAISTRA-1001 `istio-proxy` 中出现分段错误。

  • 添加了MAISTRA-932 `requires` 元数据，以在 Jaeger Operator 和 OpenShift Elasticsearch Operator 之间添加依赖关系。确保在安装 Jaeger Operator 时，如果 OpenShift Elasticsearch Operator 不可用，则会自动部署它。

  • 在多次命名空间删除和重新创建后，Galley 丢弃了监视器并停止向其他组件提供配置。MAISTRA-862

  • 在多次命名空间删除和重新创建后，Pilot 停止交付配置。MAISTRA-833

  • MAISTRA-684 `istio-operator` 中的默认 Jaeger 版本为 1.12.0，与 Red Hat OpenShift Service Mesh 0.12.TechPreview 中提供的 Jaeger 版本 1.13.1 不匹配。

  • 在 Maistra 0.12.0/TP12 中，宽松模式不起作用。MAISTRA-622 用户可以选择使用纯文本模式或相互 TLS 模式，但不能使用宽松模式。

  • Jaeger 无法与 Kiali 一起使用。MAISTRA-572 在此版本中，Jaeger 配置为使用 OAuth 代理，但也仅配置为通过浏览器工作，并且不允许服务访问。Kiali 无法与 Jaeger 端点正确通信，它认为 Jaeger 已禁用。另请参见 TRACING-591。

  • 在 AWS 上的 OpenShift 4 Beta 中，默认情况下，无法通过除端口 80 之外的端口上的入口网关访问 TCP 或 HTTPS 服务。MAISTRA-357 AWS 负载均衡器有一个运行状况检查，用于验证服务端点上的端口 80 是否处于活动状态。如果没有在端口 80 上运行的服务，则负载均衡器运行状况检查将失败。

  • AWS 上的 OpenShift 4 Beta 不支持除 80 或 443 之外的端口上的入口网关流量。MAISTRA-348 如果您将入口网关配置为处理端口号不是 80 或 443 的 TCP 流量，则必须使用 AWS 负载均衡器提供的服务主机名而不是 OpenShift 路由器作为解决方法。

  • 启用 Citadel 的运行状况检查时，会显示意外的控制台信息消息。MAISTRA-193

  • Bug 1821432 OpenShift Container Platform 控制资源详细信息页面中的切换控件无法正确更新 CR。OpenShift Container Platform Web 控制台中服务网格控制平面 (SMCP) 概述页面中的 UI 切换控件有时会更新资源中的错误字段。要更新 ServiceMeshControlPlane 资源，请直接编辑 YAML 内容或从命令行更新资源，而不是单击切换控件。

Kiali 已修复的问题

  • 如果 Kiali Operator pod 由于“已驱逐”状态而失败，则会阻止 Kiali operator 部署。KIALI-3239 解决方法是删除已驱逐的 pod 并重新部署 Kiali operator。

  • 例如，在更改 ServiceMeshMemberRoll（例如添加或删除项目）后，Kiali pod 将重新启动，然后在 Kiali pod 重新启动期间在“图形”页面上显示错误。KIALI-3118

  • 服务网格中的运行时指标失败。KIALI-3096 服务网格和 Prometheus 之间存在 OAuth 过滤器，需要在授予访问权限之前将持有者令牌传递给 Prometheus。Kiali 已更新为在与 Prometheus 服务器通信时使用此令牌，但应用程序指标目前出现 403 错误。

  • 此错误仅影响自定义仪表板，而不影响默认仪表板。KIALI-3070 当您在指标设置中选择标签并刷新页面时，您的选择会保留在菜单中，但您的选择不会显示在图表上。

  • 当控制平面具有许多命名空间时，可能会导致性能问题。KIALI-2686