• 在 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。
  • 增加了 WebAsembly 扩展作为技术预览功能。

• 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-2221 网关注入无法在 control plane 命名空间中工作。如果您使用网关注入功能在与 control plane 相同的位置创建网关，注入会失败，OpenShift 会生成此消息：

  Warning Failed 10s kubelet, ocp-wide-vh8fd-worker-vhqm9 Failed to pull image "auto": rpc error: code = Unknown desc = reading manifest latest in docker.io/library/auto: errors

  要在 control plane 命名空间中创建网关，请使用 SMCP spec 中的 gateway 参数为网格配置入口和出口网关。

• 名为 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 ServiceMeshExtensions 目前与 IBM Z Systems 上部署的网格不兼容。

• MAISTRA-1959 迁移到 2.0 Prometheus 提取（spec.addons.prometheus.scrape 设置为 true）在启用 mTLS 时无法正常工作。另外，当禁用 mTLS 时，Kiali 会显示无关的图形数据。

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

  spec:
    proxy:
      networking:
        trafficControl:
          inbound:
            excludedPorts:
            - 15020

• MAISTRA-1314 Red Hat OpenShift Service Mesh 尚不支持 IPv6。
• 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 浏览器的两个最新版本之一。

• 不支持 Apache spark。
• IBM Z 和 IBM Power Systems 上不支持通过 AMQ/Kafka 进行流部署。

• OBSDA-220 在某些情况下，如果您尝试使用分布式追踪数据收集拉取镜像，则镜像拉取失败，并显示 Failed to pull image 错误消息。这个问题还没有临时解决方案。

• TRACING-2057 Kafka API 已更新至 v1beta2，以支持 Strimzi Kafka Operator 0.23.0。但是，AMQ Streams 1.6.3 不支持这个 API 版本。如果您有以下环境，将不会升级 Jaeger 服务，您无法创建新的 Jaeger 服务或修改现有的 Jaeger 服务：

  • Jaeger Operator 频道：1.17.x stable 或 1.20.x stable

  • AMQ Streams Operator 频道： amq-streams-1.6.x

    要解决这个问题，将 AMQ Streams Operator 的订阅频道切换到 amq-streams-1.7.x 或 stable。

• OSSM-3644 以前，联邦 egress-gateway 收到网络网关端点的错误更新，从而导致额外的端点条目。现在，在服务器端更新了 federation-egress 网关，以便它接收正确的网络网关端点。
• OSSM-3595 以前，istio-cni 插件有时会在 RHEL 上失败，因为 SELinux 不允许工具 iptables-restore 打开 /tmp 目录中的文件。现在，SELinux 通过 stdin 输入流而不是通过一个文件传递 iptables-restore。
• OSSM-3025 Istiod 有时无法就绪。有时，当网格包含很多成员命名空间时，为因为 Istiod 中的死锁 导致 Istiod pod 未就绪。现在，死锁已被解决，pod 现在会如预期启动。
• OSSM-2493 SMCP 中的默认 nodeSelector 和 tolerations 不会传递给 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 重启 Istiod 会导致 Kiali 使用 port-forward 请求大量 CRI-O。当 Kiali 无法连接到 Istiod，而 Kiali 同时向 istiod 发出大量请求时会出现这种情况。Kiali 现在限制它发送到 istiod 的请求数。
• OSSM-2335 将鼠标指针拖放到 Traces scatterchart 图表上，有时会导致 Kiali 控制台因为并发后端请求停止响应。

• 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 控件。

• OSSM-1910 因为版本 2.6 中引入了问题，所以无法在 OpenShift Container Platform Service Mesh 中建立 TLS 连接。在这个版本中，通过更改服务端口名称以匹配 OpenShift Container Platform Service Mesh 和 Istio 所使用的约定解决了这个问题。
• OBSDA-208 在更新之前，默认的 200m CPU 和 256Mi 内存资源限制可能会导致分布式追踪数据收集在大型集群中持续重启。在这个版本中，通过删除这些资源限值解决了这个问题。
• OBSDA-222 在此更新之前，可以在 OpenShift Container Platform 分布式追踪平台中丢弃 span。为了帮助防止这个问题发生，这个版本会更新版本依赖项。

• TRACING-2337 Jaeger 在 Jaeger 日志中记录一个重复的警告信息，如下所示：

  {"level":"warn","ts":1642438880.918793,"caller":"channelz/logging.go:62","msg":"[core]grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"transport: http2Server.HandleStreams received bogus greeting from client: \\\"\\\\x16\\\\x03\\\\x01\\\\x02\\\\x00\\\\x01\\\\x00\\\\x01\\\\xfc\\\\x03\\\\x03vw\\\\x1a\\\\xc9T\\\\xe7\\\\xdaCj\\\\xb7\\\\x8dK\\\\xa6\\\"\"","system":"grpc","grpc_log":true}

  这个问题已通过只公开查询服务的 HTTP(S)端口而不是 gRPC 端口来解决。

• TRACING-2009 已更新 Jaeger Operator，使其包含对 Strimzi Kafka Operator 0.23.0 的支持。
• TRACING-1907 Jaeger 代理 sidecar 注入失败，因为应用程序命名空间中缺少配置映射。因为 OwnerReference 字段设置不正确，配置映射会被自动删除，因此应用程序 pod 不会超过 "ContainerCreating" 阶段。已删除不正确的设置。
• TRACING-1725 转入到 TRACING-1631。额外的程序漏洞修复，可确保当存在多个生产环境的 Jaeger 实例，它们使用相同的名称但在不同的命名空间中时，Elasticsearch 证书可以被正确协调。另请参阅 BZ-1918920。
• TRACING-1631 多 Jaeger 生产环境实例使用相同的名称但在不同命名空间中，因此会导致 Elasticsearch 证书问题。安装多个服务网格时，所有 Jaeger Elasticsearch 实例都有相同的 Elasticsearch secret 而不是单独的 secret，这导致 OpenShift Elasticsearch Operator 无法与所有 Elasticsearch 集群通信。
• 在使用 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 捆绑包。
• 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。

• BZ-1918920/LOG-1619 / LOG-1619，Elasticsearch Pod 在更新后不会自动重启。

  临时解决方案：手动重启 pod。

• 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 使用 OpenShift Container Platform (cluster API) API 来获取和解析服务网格配置。Kiali 通过查询集群 API 获取信息，如获取命名空间、服务、部署、pod 和其他实体的定义。Kiali 还提供查询来解析不同集群实体之间的关系。另外，还可以通过查询集群 API 以获取 Istio 配置，比如虚拟服务、目的规则、路由规则、网关、配额等等。
• Jaeger - Jaeger 是可选的，但会作为 Red Hat OpenShift Service Mesh 安装的一部分被默认安装。当您作为 Red Hat OpenShift Service Mesh 安装的一部分安装分布式追踪平台时，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 - 此组件基于开源 Jaeger 项目。
• Red Hat OpenShift distributed tracing 数据收集 - 此组件基于开源 OpenTelemetry 项目。

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

  • 客户端 （Jaeger 客户端、跟踪器、报告程序、客户端库）- 分布式追踪平台客户端是 OpenTracing API 的特定语言实施。它们可以用来为各种现有开源框架（如 Camel (Fuse) 、Spring Boot (RHOAR) 、MicroProfile (RHOAR/Thorntail) 、Wilfly (EAP) 等提供分布式追踪工具。
  • 代理 （Jaeger 代理，Server Queue, Processor Workers）- 分布式追踪平台代理是一个网络守护进程，侦听通过用户数据报协议(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 提供了用于 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 平台用户界面，您可以视觉化您的分布式追踪数据。在搜索页面中，您可以查找 trace，并查看组成一个独立 trace 的 span 详情。

• Red Hat OpenShift distributed tracing 数据收集 - 此组件基于开源 OpenTelemetry 项目。

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

• 与 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.9 或更高版本。
• 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
• OpenShift Container Platform 4.7.32+、OpenShift Container Platform 4.8.12+ 和 OpenShift Container Platform 4.9+ 支持 OVN-Kubernetes。
• 在 OpenShift Container Platform 上认证并通过 Service Mesh 一致性测试的第三方 Container Network Interface(CNI)插件。如需更多信息，请参阅认证的 OpenShift CNI 插件。

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

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

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

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

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

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

前提条件

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

前提条件

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

先决条件

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

前提条件

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

先决条件

• 安装了 OpenShift Container Platform 4.1 或更高版本。
• 安装了 Red Hat OpenShift Service Mesh 2.3.3。
• 访问 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.3.3。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 的值。

• 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）。

• 此发行版本需要使用 WasmPlugin API。对 ServiceMeshExtension API 的支持（在 2.2 中已弃用）现已被删除。如果您在使用 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 状态代码。

先决条件

• 您正在运行 OpenShift Container Platform 4.9 或更高版本。
• 您有最新的 Red Hat OpenShift Service Mesh Operator。

先决条件

• 在升级到 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 中的功能。

前提条件

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

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

前提条件

• 命名空间必须是网格的成员，方法是在 ServiceMeshMemberRoll 中定义或创建 ServiceMeshMember 资源。

其他资源

• 特定于路由的注解。

前提条件

• 安装了 Red Hat OpenShift Service Mesh Operator 2.1.1 或更高版本。
• ServiceMeshControlPlane 资源更新至 2.1 或更高版本。

先决条件：

• 部署 Bookinfo 示例应用程序以使用以下示例。

先决条件

• 如果您没有安装自己的应用程序，请安装 Bookinfo 示例应用程序。然后，通过多次输入以下命令为 Bookinfo 应用程序生成流量。

  $ curl "http://$GATEWAY_URL/productpage"

  此命令模拟访问应用的 productpage 微服务的用户。

前提条件

• 安装和配置 Service Mesh。
• 已安装并配置了 Kiali。
• Kiali 控制台的地址。
• 在网格中添加了应用程序或 Bookinfo 示例应用程序。

• 入站应用程序指标
• 出站应用指标
• 入站工作负载指标
• 出站工作负载指标
• 入站服务指标

前提条件

• 安装和配置 Service Mesh。
• 已安装并配置了 Kiali。
• Kiali 控制台的地址。
• （可选）安装和配置了分布式追踪。

先决条件

• 安装和配置 Red Hat OpenShift 分布式追踪实例。

• 将值设置为 10 个 trace 的 0.1% 样本。
• 将值设为 500 个样本 5% 的 trace.

• 部署更改率。
• 配置更改率。
• 连接到 Istiod 的代理数量。

• 客户端连接数
• 目标请求率
• 请求大小和响应大小
• 代理 worker 线程的数量
• 协议
• CPU 内核
• 代理过滤器的数量和类型，特别是遥测 v2 相关的过滤器。