• 添加了 envoyExtAuthzGrpc 字段，该字段用于使用 gRPC API 配置外部授权提供程序。
• 解决了常见的漏洞和风险(CVE)。
• 此发行版本在 Red Hat OpenShift Service on AWS 4.10 及更新的版本中被支持。

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

• 简化了 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。

• 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

• 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

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

  • 使用 RequestAuthentication (security.istio.io/v1beta1)
  • 使用 PeerAuthentication (security.istio.io/v1beta1)

• ServiceMeshPolicy (maistra.io/v1)不再被支持。

  • 使用上述 RequestAuthentication 或 PeerAuthentication，但放置在 Service Mesh control plane 命名空间中。

• RbacConfig（rbac.istio.io/v1alpha1）不再被支持。

  • 由 AuthorizationPolicy (security.istio.io/v1beta1)替代，其中包含 RbacConfig、ServiceRole 和 ServiceRoleBinding 的行为。

• ServiceMeshRbacConfig（ maistra.io/v1）不再被支持。

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

• OSSM-6099 在 IPv6 集群上安装 OpenShift Service Mesh 控制台(OSSMC)插件失败。

  临时解决方案：在 IPv4 集群上安装 OSSMC 插件。

• 当 istio-system 标签不匹配发现选择器时，会跳过 OSSM-5556 网关。

  临时解决方案：标记 control plane 命名空间以匹配发现选择器，以避免跳过网关配置。

  ServiceMeshControlPlane 资源示例

  apiVersion: maistra.io/v2
  kind: ServiceMeshControlPlane
  metadata:
    name: basic
    namespace: istio-system
  spec:
    mode: ClusterWide
    meshConfig:
      discoverySelectors:
      - matchLabels:
          istio-discovery: enabled
    gateways:
      ingress:
        enabled: true

  然后，在命令行中运行以下命令：

  oc label namespace istio-system istio-discovery=enabled

• 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 及更新的版本支持 v1alpha2 和 v1beta1 CRD。因此，两个 CRD 版本都必须存在才能多租户网格部署来支持网关 API。

  临时解决方案： 在以下示例中，kubectl get 操作会安装 v1alpha2 和 v1beta1 CRD。请注意，URL 包含额外的 实验性 片段，并相应地更新任何现有脚本：

  $ 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 -; }

• OSSM-2042 Deployment of SMCP named default 会失败。如果您要创建 SMCP 对象，并将其 version 字段设置为 v2.3，则对象的名称不能 是默认的。如果名称是 默认，则 control plane 无法部署，OpenShift 会生成一个带有以下信息的 Warning 事件：

  error processing component mesh-config: error: [mesh-config/templates/telemetryv2_1.6.yaml： 发生内部错误： 调用 Webhook "rev.validation.istio.io"： post "https://istiod-default.istio-system.svc:443/validate?timeout=10s": x509: 证书对 istiod.istio-system.svc、istiod-remote.istio-system.svc, istio-pilot.istio-system.svc 有效，而不是 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 的并发 字段没有传播到 istio-proxy。当使用 ProxyConfig 设置时，并发 字段可以正常工作。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.*"
      - "^kiali-operator"

• MAISTRA-2692 删除了 Mixer，在 Service Mesh 2.0.x 中定义的自定义指标无法在 2.1 中使用。可以使用 EnvoyFilter 配置自定义指标。除非有明确记录，红帽不支持 EnvoyFilter 配置。这是因为与底层 Envoy API 耦合紧密，这意味着无法维护向后兼容性。

• 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 应用指向同一主机名的多个网关时，会导致所有网关停止工作。

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

• 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. 删除之前添加的环境变量。
• OSSM-4851 以前，当 runAsGroup、runAsUser 或 fsGroup 参数为 nil 时，Operator 在网格内部署新 pod 时出错。现在，添加了 yaml 验证以避免 nil 值。
• OSSM-3771 以前，对于 Service Mesh Control Plane (SMCP)中定义的额外入口网关无法禁用 OpenShift 路由。现在，可以将 routeConfig 块添加到 每个额外的Ingress 网关中，以便为每个网关启用或禁用 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_rev 和 injection_label_name 属性的值被硬编码。这导致自定义配置无法在 Kiali 自定义资源定义(CRD)中生效。现在，属性值不会被硬编码。您可以在 spec.istio_labels 规格中自定义 injection_label_rev 和 injection_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 pod 未就绪，因为 Istiod 中的死锁。现在，死锁已被解决，pod 现在会如预期启动。
• OSSM-2493 默认 nodeSelector 和 tolerations 不在 SMCP 中传递给 Kiali。您添加到 SMCP.spec.runtime.defaults 的 nodeSelector 和 tolerations 现在被传递给 Kiali 资源。
• OSSM-2492 默认容限没有传递给 Jaeger。您添加到 SMCP.spec.runtime.defaults 的 nodeSelector 和 tolerations 现在被传递给 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 Restarting 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 on AWS 4.8 兼容，apiextensions.k8s.io/v1beta1 API 从 Red Hat OpenShift Service Mesh 2.0.8 开始已弃用。
• 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 的 OpenShift SDN，且网格包含大量命名空间(200+)，Red Hat OpenShift Service on AWS 网络插件无法快速配置命名空间。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-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 Red Hat OpenShift Service on AWS 自定义资源详情页面中的切换控件无法正确更新 CR。Red Hat OpenShift Service on AWS Web 控制台中的 Service Mesh Control Plane (smcp) Overview 页面中的 UI 切换控制有时会更新资源中的错误字段。要更新 SMCP，直接编辑 YAML 内容，或者从命令行更新资源，而不是点击 toggle 控件。

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

• 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 使用 Red Hat OpenShift Service on AWS (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 数据。

• 健康 – 快速识别应用程序、服务或者工作负载的问题。
• 拓扑 – 以图形的形式显示应用程序、服务或工作负载如何通过 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 路由配置。

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

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

• Red Hat OpenShift distributed tracing Platform (Jaeger)，它基于开源 Jaeger 项目。

  重要

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

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

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

• 红帽构建的 OpenTelemetry - 此组件基于开源 OpenTelemetry 项目。

  • OpenTelemetry Collector - OpenTelemetry Collector 是一个与厂商无关的方式来接收、处理和导出遥测数据。OpenTelemetry Collector 支持开源可观察数据格式，如 Jaeger 和 Prometheus，发送到一个或多个开源或商业后端。Collector 是默认位置检测库来导出其遥测数据。

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

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

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

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

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

• 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：没有执行其他配置。

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

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

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

• 此 Red Hat OpenShift Service Mesh 发行版本仅适用于 Red Hat OpenShift Service on AWS x86_64。
• 将所有 Service Mesh 组件包含在单个 Red Hat OpenShift Service on AWS 集群中的配置。
• 不集成外部服务的配置，如虚拟机。
• Red Hat OpenShift Service Mesh 不支持 EnvoyFilter 配置，除非明确记录。

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

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

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

前提条件

• 必须安装 Red Hat OpenShift Service Mesh Operator。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS web 控制台。

验证

• 要验证 control plane 是否已正确安装，请点击 Istio Service Mesh Control Plane 标签页。

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

前提条件

• 必须安装 Red Hat OpenShift Service Mesh Operator。
• 访问 OpenShift CLI（oc）。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS。

前提条件

• 安装了 Red Hat OpenShift Service Mesh Operator。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS。

验证

• 验证 control plane 是否已正确安装：

  1. 点 Istio Service Mesh Control Plane 标签页。
  2. 点新 ServiceMeshControlPlane 对象的名称。
  3. 点 Resources 选项卡，查看 Operator 创建和配置的 Red Hat OpenShift Service Mesh control plane 资源。

前提条件

• 安装了 Red Hat OpenShift Service Mesh Operator。
• 您可以访问 OpenShift CLI(oc)。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS。

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

前提条件

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

验证

• 运行以下命令，验证命名空间是否为网格的一部分。确认值 True 出现在 READY 列中。

  $ oc get smm default -n my-application

  输出示例

  NAME      CONTROL PLANE        READY   AGE
  default   istio-system/basic   True    2m11s

• 另外，查看 ServiceMeshMemberRoll 资源，以确认 my-application 命名空间显示在 ServiceMeshMemberRoll 资源的 status.members 和 status.configuredMembers 字段中。

  $ oc describe smmr default -n istio-system

  输出示例

  Name:         default
  Namespace:    istio-system
  Labels:       <none>
  # ...
  Status:
  # ...
    Configured Members:
      default
      my-application
  # ...
    Members:
      default
      my-application

前提条件

• 已安装 Red Hat OpenShift Service Mesh Operator。
• 部署有一个现有的 ServiceMeshMemberRoll 资源。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS web 控制台。

前提条件

• 已安装 Red Hat OpenShift Service Mesh Operator。
• 部署有一个现有的 ServiceMeshMemberRoll 资源。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS。

先决条件：

• 安装了 Red Hat OpenShift Service on AWS 4.1 或更高版本。
• 安装了 Red Hat OpenShift Service Mesh 2.5。
• 访问 OpenShift CLI（oc）。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS。

前提条件

• 安装了 Red Hat OpenShift Service Mesh。
• 完成安装 Bookinfo 示例应用程序的步骤。
• 以具有 dedicated-admin 角色的用户身份登录到 Red Hat OpenShift Service on AWS。

前提条件

• 安装了 Red Hat OpenShift Service on AWS 4.1 或更高版本。
• 安装了 Red Hat OpenShift Service Mesh 2.5。
• 访问 OpenShift CLI（oc）。

• 补丁更新 - 由 Operator Lifecycle Manager(OLM)管理补丁升级；在更新 Operator 时会自动进行。
• 次版本更新 - 只需要升级到最新的 Red Hat OpenShift Service Mesh Operator 版本，并手动修改 ServiceMeshControlPlane 资源中的 spec.version 值。
• 主版本更新 - 主版本升级需要更新到最新的 Red Hat OpenShift Service Mesh Operator 版本，并手动修改 ServiceMeshControlPlane 资源中的 spec.version 值。因为主版本的更新可能包含不向后兼容的更改，所以可能需要进行额外的手动更改。

• Operator 版本 - 最新版本为 2.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 时，可能会恢复 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 无法用于 Red Hat OpenShift Service on AWS 版本 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）。

• 对 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 连接时，需要访问使用这些密码套件的服务的应用程序将无法连接。

• 此发行版本需要使用 WasmPlugin API。现在，在 2.2 中弃用的 ServiceMeshExtension API 的支持已被删除。如果您在使用 ServiceMeshExtension API 时尝试升级，则升级会失败。

• istio-node DaemonSet 被重命名为 istio-cni-node，以匹配上游 Istio 中的名称。
• Istio 1.10 更新了 Envoy，默认使用 eth0 而不是 lo 将流量发送到应用程序容器。
• 此发行版本添加了对 WasmPlugin API 的支持，并弃用 ServiceMeshExtension API。

行为更改

• AuthorizationPolicy 更新：

  • 使用 PROXY 协议时，如果您使用 ipBlocks 和 notIpBlocks 指定远程 IP 地址，请更新配置以使用 remoteIpBlocks 而不是 RemoteIpBlocks。
  • 添加了对嵌套 JSON Web Token(JWT)声明的支持。

• EnvoyFilter 破坏更改>

  • 必须使用 typed_config
  • XDS v2 不再被支持
  • 弃用的过滤器名称
• 较旧版本的代理可能会在从更新的代理接收 1xx 或 204 状态代码时报告 503 状态代码。

前提条件

• 您已在 AWS 4.9 或更高版本上运行 Red Hat OpenShift Service。
• 您有最新的 Red Hat OpenShift Service Mesh Operator。

前提条件

• 在升级到 Red Hat OpenShift Service Mesh 2.0 之前，您必须升级到 Red Hat OpenShift Service on AWS 4.7。
• 您必须具有 Red Hat OpenShift Service Mesh 版本 2.0 operator。如果选择了 自动 升级路径，Operator 将自动下载最新信息。但是，您必须执行一些步骤来使用 Red Hat OpenShift Service Mesh 版本 2.0 中的功能。

前提条件

• 已安装并验证的 Service Mesh Operator。
• 具有 cluster-admin 角色的帐户。如果使用 Red Hat OpenShift Dedicated，则必须有一个具有 dedicated-admin 角色的帐户。
• Operator 部署的位置。
• 访问 OpenShift CLI（oc）。

• 进入服务网格的流量必须总是经过 ingress-gateway 才能使 Istio 正常工作。
• 在不在任何服务网格中的独立命名空间中为服务网格部署服务。
• 需要在服务网格列出的命名空间中部署的非 mesh 服务应该标记其 maistra.io/expose-route: "true"，这可以确保 Red Hat OpenShift Service on AWS 路由到这些服务仍可以正常工作。