第 1 章 Service Mesh 1.x

1.1. Service Mesh 发行注记

1.1.1. Red Hat OpenShift Service Mesh

Red Hat OpenShift Service Mesh 是一个提供对服务网格(service mesh)的行为信息和操作控制的平台,它为用户提供了一个连接、管理和监控微服务应用程序的统一方法。

术语 服务网格(service mesh)代表在分布式微服务架构中组成应用程序的微服务网络,以及这些微服务间的交互。当服务网格的规模和复杂性增大时,了解和管理它就会变得非常困难。

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

Red Hat OpenShift Service Mesh 提供了一个方便的方法来创建一个部署的服务网络,它可提供发现、负载平衡、服务对服务验证、故障恢复、指标和监控的功能。服务网格还提供更复杂的操作功能,其中包括 A/B 测试、canary 发行版本、速率限制、访问控制以及端到端验证。

1.1.2. 获取支持

如果您在执行本文档所述的某个流程或 OpenShift Container Platform 时遇到问题,请访问 红帽客户门户网站。通过红帽客户门户网站:

  • 搜索或者浏览红帽知识库,了解与红帽产品相关的文章和解决方案。
  • 提交问题单给红帽支持。
  • 访问其他产品文档。

为了识别集群中的问题,您可以在 Red Hat OpenShift Cluster Manager 中使用 Insights。Insights 提供了问题的详细信息,并在有可用的情况下,提供了如何解决问题的信息。

如果您对本文档有任何改进建议,或发现了任何错误,请访问 Bugzilla,针对 OpenShift Container Platform 产品的 Documentation组件提交 Bugzilla 报告。请提供具体详情,如章节名称和 OpenShift Container Platform 版本。

在提交问题单时同时提供您的集群信息,可以帮助红帽支持为您进行排除故障。

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

为了获得快速支持,请提供 OpenShift Container Platform 和 Red Hat OpenShift Service Mesh的诊断信息。

1.1.2.1. 关于 must-gather 工具

oc adm must-gather CLI 命令可收集最有助于解决问题的集群信息,如:

  • 资源定义
  • 审计日志
  • 服务日志

您在运行该命令时,可通过包含 --image 参数来指定一个或多个镜像。指定镜像后,该工具便会收集有关相应功能或产品的信息。

在运行 oc adm must-gather 时,集群上会创建一个新 pod。在该 pod 上收集数据,并保存至以 must-gather.local 开头的一个新目录中。此目录在当前工作目录中创建。

1.1.2.2. 先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift Container Platform CLI (oc)。

1.1.2.3. 关于收集服务网格数据

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

要使用 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

要使用 must-gather 为特定 control plane 命名空间收集 Red Hat OpenShift Service Mesh 数据,您必须指定 Red Hat OpenShift Service Mesh 镜像和命名空间。在本例中,将 <namespace> 替换为您的 control plane 命名空间,如 istio-system

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

1.1.3. Red Hat OpenShift Service Mesh 支持的配置

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

  • Red Hat OpenShift Container Platform 版本 4.x。
注意

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

  • 部署必须包含在一个独立的 OpenShift Container Platform 集群中。
  • 此版本的 Red Hat OpenShift Service Mesh 仅适用于 OpenShift Container Platform x86_64。
  • 此发行版本只支持在 OpenShift 集群中包含所有 Service Mesh 组件的配置。它不支持在集群之外或在多集群场景中管理微服务。
  • 这个版本只支持没有集成外部服务的配置,比如虚拟机。

1.1.3.1. Red Hat OpenShift Service Mesh 支持的 Kiali 配置

  • Kiali 观察控制台只支持 Chrome 、Edge 、Firefox 或 SDomain 浏览器的最新的两个版本。

1.1.3.2. 支持的 Mixer 适配器

  • 此发行版本只支持以下 Mixer 适配器:

    • 3scale Istio Adapter

1.1.4. 新功能

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

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

1.1.4.1. Red Hat OpenShift Service Mesh 1.1.15 版中包含的组件版本

组件版本

Istio

1.4.8

Jaeger

1.17.8

Kiali

1.12.16

3scale Istio Adapter

1.0.0

1.1.4.2. Red Hat OpenShift Service Mesh 1.1.15 的新功能

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

1.1.4.3. Red Hat OpenShift Service Mesh 1.1.14 的新功能

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

重要

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

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

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

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

根据 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 配置不同。

1.1.4.3.2. 更新路径规范化配置

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

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

表 1.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

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

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

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

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

  1. Percent-decode %2F, %2f, %5C%5c
  2. RFC 3986 和其他由 Envoy 中规范化 _path 选项实现的规范化。
  3. 合并斜杠。
警告

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

1.1.4.3.3. 路径规范配置示例

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

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

表 1.2. 配置示例

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

依赖于代理进行规范化

BASEMERGE_SLASHES 或 © ODE_AND_MERGE_SLASHES

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

BASE

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

MERGE_SLASHES

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

DECODE_AND_MERGE_SLASHES

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

NONE

1.1.4.3.4. 为路径规范化配置 SMCP

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

SMCP v1 路径 Normalization

spec:
  global:
    pathNormalization: <option>

1.1.4.4. Red Hat OpenShift Service Mesh 1.1.13 的新功能

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

1.1.4.5. Red Hat OpenShift Service Mesh 1.1.12 的新功能

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

1.1.4.6. Red Hat OpenShift Service Mesh 1.1.11 的新功能

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

1.1.4.7. Red Hat OpenShift Service Mesh 1.1.10 的新功能

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

1.1.4.8. Red Hat OpenShift Service Mesh 1.1.9 的新功能

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

1.1.4.9. Red Hat OpenShift Service Mesh 1.1.8 的新功能

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

1.1.4.10. Red Hat OpenShift Service Mesh 1.1.7 的新功能

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

1.1.4.11. Red Hat OpenShift Service Mesh 1.1.6 的新功能

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

1.1.4.12. Red Hat OpenShift Service Mesh 1.1.5 的新功能

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

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

1.1.4.13. Red Hat OpenShift Service Mesh 1.1.4 的新功能

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

注意

要解决 CVE-2020-8663 的问题,则必须完成手动步骤。

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

对于 CVE-2020-8663: envoy: Resource exhaustion when accepting too many connections 的问题,为下游连接添加了一个可配置的限制。必须配置这个限制的配置选项来减轻这个安全漏洞的影响。

重要

无论您使用 1.1 版本还是使用 Red Hat OpenShift Service Mesh 1.0 版本,需要手动步骤来缓解这个 CVE。

这个新配置选项称为 overload.global_downstream_max_connections,它作为一个代理的 runtime 设置可以进行配置。在 Ingress Gateway 上执行以下步骤配置限制。

流程

  1. 使用以下文本创建名为 bootstrap-override.json 的文件,以强制代理覆盖 bootstrap 模板并从磁盘加载运行时配置:

      {
        "runtime": {
          "symlink_root": "/var/lib/istio/envoy/runtime"
        }
      }
  2. bootstrap-override.json 文件创建 secret,将 <SMCPnamespace> 替换为您在其中创建服务网格 control plane(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 设置的 secret。以下示例使用 10000

    $  oc create secret generic -n <SMCPnamespace> gateway-settings --from-literal=overload.global_downstream_max_connections=10000
  5. 再次更新 SMCP,将 secret 挂载到 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

1.1.4.13.2. 从 Elasticsearch 5 升级到 Elasticsearch 6

从 Elasticsearch 5 更新至 Elasticsearch 6 时,必须删除 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 实例:

    $ oc create -f <jaeger-cr-file>
  3. 验证您的 Pod 已重启:

    $ oc get pods -n jaeger-system -w

1.1.4.14. Red Hat OpenShift Service Mesh 1.1.3 的新功能

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

1.1.4.15. Red Hat OpenShift Service Mesh 1.1.2 的新功能

此 Red Hat OpenShift Service Mesh 发行版本解决了一个安全漏洞问题。

1.1.4.16. Red Hat OpenShift Service Mesh 1.1.1 的新功能

此 Red Hat OpenShift Service Mesh 发行版本增加了对断开连接的安装的支持。

1.1.4.17. Red Hat OpenShift Service Mesh 1.1.0 的新功能

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

1.1.4.17.1. 从 1.0 手动更新到 1.1

如果要从 Red Hat OpenShift Service Mesh 1.0 更新至 1.1,您必须更新 ServiceMeshControlPlane 资源,以便将 control plane 组件更新至新版本。

  1. 在 web 控制台中,点 Red Hat OpenShift Service Mesh Ooperator。
  2. Project 菜单,然后从列表中选择部署了 ServiceMeshControlPlane 的项目,如 istio-system
  3. 点 control plane 的名称,例如 basic-install
  4. 点 YAML,并将版本字段添加到 ServiceMeshControlPlane 资源的 spec: 中。例如,要升级到 Red Hat OpenShift Service Mesh 1.1.0,请添加 version: v1.1
spec:
  version: v1.1
  ...

version 字段指定要安装的 Service Mesh 版本,默认为最新可用版本。

注意

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

1.1.5. 已弃用的功能

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

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

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

以下自定义资源在此发行版本中已弃用,并将在以后的发行版本中删除。

  • Policy - Policy 资源已弃用,并将在以后的版本中由 PeerAuthentication 资源替代。
  • MeshPolicy - MeshPolicy 资源已弃用,并将在以后的版本中由 PeerAuthentication 资源替代。
  • v1alpha1 RBAC API - v1alpha1 RBAC 策略已弃用,使用 v1beta1 AuthorizationPolicy。RBAC(Role Based Access Control)定义 ServiceRoleServiceRoleBinding 对象。

    • ServiceRole
    • ServiceRoleBinding
  • RbacConfig - RbacConfig 实施自定义资源定义来控制 Istio RBAC 行为。

    • ClusterRbacConfig(Red Hat OpenShift Service Mesh 1.0 以前的版本)
    • ServiceMeshRbacConfig (Red Hat OpenShift Service Mesh 版本 1.0 及更新版本)
  • 在 Kiali 中,loginLDAP 策略已被弃用。将来的版本将引入使用 OpenID 供应商的身份验证。

本发行版本中还弃用了以下组件,并将在以后的版本中被 Istiod 组件替代。

  • Mixer - 访问控制及使用策略
  • Pilot - 服务发现和代理配置
  • Citadel - 证书生成
  • Galley - 配置验证和发布

1.1.6. 已知问题

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

  • Red Hat OpenShift Service Mesh 不支持 IPv6,因为上游 Istio 项目不支持它,OpenShift 也不完全支持它。
  • 图形布局 - Kiali 图形的布局会根据应用程序构架和要显示的数据(图形节点数目及其交互)的不同而有所变化。因为创建一个统一布局的难度较大,所以 Kiali 提供了几种不同布局的选择。要选择不同的布局,可从 Graph Settings 菜单中选择一个不同的 Layout Schema
  • 您第一次从 Kiali 控制台访问相关服务(如 Jaeger 和 Grafana)时,必须使用 OpenShift Container Platform 登录凭证接受证书并重新进行身份验证。这是因为框架如何显示控制台中的内置页面中存在问题。

1.1.6.1. Service Mesh 已知问题

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

  • Maistra-1502 由于在版本 1.0.10 中修复了 CVE,Istio 仪表板将不会出现在 Grafana 的 Home Dashboard 菜单中。Istio 仪表板仍然存在。要访问它们,在导航框中点 Dashboard 菜单,并选 Manage 标签页。
  • Bug 1821432 OpenShift Container Platform Control Resource details 页面中的 Toggle 控件无法正确更新 CR。OpenShift Container Platform Web 控制台中的 Service Mesh Control Plane (smcp) Overview 页面中的 UI 切换控制有时会更新资源中的错误字段。要更新 SMCP,直接编辑 YAML 内容,或者从命令行更新资源,而不是点击 toggle 控件。
  • 在对安装了 Service Mesh 1.0.x 的 Jaeger 或 Kiali Operator 进行升级时,Jaeger/Kiali Operator 的升级过程可能会无法完成,Operator 的状态会显示为 Pending 。这个问题的解决方案正在开发中,您可以使用一个临时解决方案。详情请查看链接的知识库文章。
  • Istio-14743 因为此 Red Hat OpenShift Service Mesh 版本所基于的 Istio 版本的限制,目前有一些应用程序与 Service Mesh 还不兼容。详参阅社区的相关链接。
  • 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 当 control plane 有多个命名空间时,可能会导致出现性能问题。
  • MAISTRA-465 Maistra Operator 无法为 operator 指标数据创建服务。
  • MAISTRA-453 如果创建新项目并立即部署 pod,则不会进行 sidecar 注入。在创建 pod 前,operator 无法添加 maistra.io/member-of ,因此必须删除 pod 并重新创建它以执行 sidecar 注入操作。
  • MAISTRA-193 当为 citadel 启用了健康检查功能时,会出现预期外的控制台信息。
  • MAISTRA-158 应用指向同一主机名的多个网关时,会导致所有网关停止工作。

1.1.6.2. 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.1.6.3. Jaeger 已知问题

Jaeger 中存在的限制:

  • 虽然 Kafka publisher 是 Jaeger 的一部分,但它并不被支持。
  • 不支持 Apache spark。
  • 仅支持自置备的 Elasticsearch 实例。此发行版本不支持外部 Elasticsearch 实例。

Jaeger 中已知的问题:

  • TRACING-1166 目前无法在断开网络连接的环境中使用 Jaeger 流策略。当一个 Kafka 集群被置备时,它会产生一个错误: Failed to pull image registry.redhat.io/amq7/amq-streams-kafka-24-rhel7@sha256:f9ceca004f1b7DCCB3b82d9a8027961f9fe4104e0ed69752c0bdd8078b4a1076
  • TRACING-809 Jaeger Ingester 与 Kafka 2.3 不兼容。当存在两个或多个 Jaeger Ingester 实例时,它会不断在日志中生成重新平衡信息。这是由于在 Kafka 2.3 里存在一个程序错误,它已在 Kafka 2.3.1 中修复。如需更多信息,请参阅 Jaegertracing-1819

1.1.7. 修复的问题

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

1.1.7.1. Service Mesh 修复的问题

  • MAISTRA-2371 Handle tombstones in listerInformer。在将事件从命名空间缓存转换为聚合缓存时,更新的缓存代码库没有处理 tombstones,从而导致在 go 中出现 panic 的问题。
  • MAISTRA-1352 Cert-manager 自定义资源定义(CRD)已针对这个发行版本和以后的版本被删除。如果您已经安装了 Red Hat OpenShift Service Mesh,如果没有使用 cert-manager,则必须手动删除 CRD。

    要删除 CRD,请运行以下命令:

    $ oc delete crd clusterissuers.certmanager.k8s.io
    $ oc delete crd issuers.certmanager.k8s.io
    $ oc delete crd certificates.certmanager.k8s.io
    $ oc delete crd orders.certmanager.k8s.io
    $ oc delete crd challenges.certmanager.k8s.io
  • MAISTRA-1649 不同命名空间中的无标头服务会有冲突。在不同命名空间中部署无头服务时,端点配置会被合并,并导致推送到 sidecar 的 Envoy 配置无效。
  • 当控制器在拥有者引用中未设置时, kubernetesenv 中的 Maistra-1541 会导致 Panic。如果 pod 没有指定控制器的 ownerReference,则会导致 kubernetesenv cache.go 代码出现 panic。
  • 在使用 Istio sidecar 时,在 Agent 和 Collector 间的连接会出现 TRACING-1300 失败。对 Jaeger Operator 的更新默认启用了 Jaeger sidecar 代理和 Jaeger Collector 之间的 TLS 通信。
  • TRACING-1208 访问 Jaeger UI 时的身份验证 "500 Internal Error" 错误。当尝试使用 OAuth 验证 UI 时,会得到 500 错误,因为 oauth-proxy sidecar 不信任安装时使用 additionalTrustBundle 定义的自定义 CA 捆绑包。
  • OSSM-99 从没有标签(label)的直接 Pod 产生的工作负载可能会导致 Kiali 崩溃。
  • OSSM-93 IstioConfigList 无法根据两个或者更多名称进行过滤。
  • OSSM-92 在 VS/DR YAML 编辑页面中取消未保存的更改不会取消更改。
  • OSSM-90 trace 没有包括在服务详情页中。
  • MAISTRA-1001 关闭 HTTP/2 连接可能会导致 istio-proxy 中的分段错误。
  • MAISTRA-932 添加了 requires 元数据,以添加 Jaeger operator 和 Elasticsearch operator 之间的依赖关系。确保在安装 Jaeger operator 时,它将自动部署 Elasticsearch operator(如果不可用)。
  • MAISTRA-862 Galley 在多次命名空间删除和重新创建后丢弃了监控并停止了向其他组件提供配置。
  • MAISTRA-833 Pilot 在多次命名空间删除和重新创建后停止了交付配置。
  • MAISTRA-684 istio-operator 中默认的 Jaeger 版本为 1.12.0,它与 Red Hat OpenShift Service Mesh 0.12.TechPreview 提供的 Jaeger 版本 1.13.1 不匹配。
  • MAISTRA-622 在 Maistra 0.12.0/TP12 中,permissive 模式无法正常工作。用户可以使用 Plain text 模式或 Mutual TLS 模式,但不能使用 permissive 模式。
  • MAISTRA-572 Jaeger 无法与 Kiali 一起使用。在这个版本中,Jaeger 被配置为使用 OAuth 代理,但它被配置为只能通过浏览器进行配置,且不允许服务访问。Kiali 无法正确与 Jaeger 端点沟通,它会认为 Jaeger 被禁用。请参阅 TRACING-591
  • MAISTRA-357 在 OpenShift 4 Beta on AWS 中,默认无法通过端口 80 之外的 ingress 网关访问 TCP 或 HTTPS 服务。AWS 负载均衡器有一个健康检查,它可验证服务端点中的端口 80 是否活跃。如果服务没有在端口 80 中运行,负载均衡器健康检查就会失败。
  • MAISTRA-348 OpenShift 4 Beta on AWS 不支持端口 80 或 443 之外的 ingress 网关流量。如果您将 ingress 网关配置为使用 80 或 443 以外的端口号处理 TCP 流量,作为临时解决方案,您必须使用 AWS 负载均衡器提供的服务主机名,而不是使用 OpenShift 路由器。

1.1.7.2. Kiali 修复的问题

  • KIALI-3239 如果一个 Kiali Operator pod 失败且状态为 “Evicted”,它会阻塞 Kiali operator 的部署。解决办法是删除被逐出的 pod,并重新部署 Kiali operator。
  • KIALI-3118 当对 ServiceMeshMemberRoll 进行修改后(例如,添加或删除了项目),Kiali pod 会重新启动,并在 Kiali pod 重新启动的过程中在 Graph 页中显示错误信息。
  • KIALI-3096 Runtime metrics 在 Service Mesh 中失败。在 Service Mesh 和 Prometheus 之间有一个 OAuth 过滤器,需要向 Prometheus 传递一个 bearer 令牌才会授予访问权限。Kiali 已被更新为在与 Prometheus 服务器通讯时使用这个令牌,但应用程序的 metrics 当前会有 403 错误。
  • KIALI-3070 此程序错误只会影响自定义 dashboard,它不会影响默认的 dashboard。当您在 metrics 设置中选择标签并刷新页面时,会在菜单中保留您的选择,但您的选择不会在图表中显示。
  • KIALI-2686 当 control plane 有多个命名空间时,可能会导致出现性能问题。