如果您要从 OpenShift Service Mesh 2.6 迁移，请注意以下重要信息

如果您是当前的 Red Hat OpenShift Service Mesh 用户，在迁移之前，您需要了解 OpenShift Service Mesh 2 和 OpenShift Service Mesh 3 之间的一些重要区别，包括以下内容：

您必须使用 OpenShift Service Mesh 2.6 才能迁移到 OpenShift Service Mesh 3。

Red Hat OpenShift Service Mesh 3 是一个重大更新，其功能集更接近于 Istio 项目。OpenShift Service Mesh 2 基于中游 Maistra 项目，而 OpenShift Service Mesh 3 直接基于 Istio。这意味着 OpenShift Service Mesh 3 使用不同的、简化的运算符进行管理，并为 Istio 的最新稳定功能提供更大的支持。

与 Istio 项目的这种对齐以及在前两个主要版本的 OpenShift Service Mesh 中吸取的经验教训导致了以下变化：

Red Hat OpenShift Service Mesh 3 使用两种新的资源

Red Hat OpenShift Service Mesh 3 的一个重大变化是，Operator 不再与 Istio 控制平面一起安装和管理可观测性组件（如 Prometheus 和 Grafana）。它也不再安装和管理 Red Hat OpenShift 分布式跟踪平台组件，如分布式跟踪平台 (Tempo) 和 Red Hat OpenShift 分布式跟踪数据收集 (以前是 Jaeger 和 Elasticsearch)，或 Kiali。

OpenShift Service Mesh 3 Operator 将其范围限制在与 Istio 相关的资源，可观测性组件由构成 Red Hat OpenShift 可观测性的独立 Operator 支持和管理，例如：

Kiali 和 OpenShift Service Mesh 控制台 (OSSMC) 插件仍然受 Red Hat 提供的 Kiali Operator 支持。

这种简化大大减少了 OpenShift Service Mesh 3 的占用空间和复杂性，同时通过 Red Hat OpenShift 可观测性组件提供了更好、更适合生产环境的可观测性支持。

在 OpenShift Service Mesh 2.4 中，引入了集群范围模式以允许网格具有集群范围，并可以选择使用名为discoverySelectors的 Istio 功能来限制网格。使用discoverySelectors会将 Istio 控制平面的可见性限制为使用标签选择器定义的一组命名空间。这与社区 Istio 的工作方式一致，并允许 Istio 管理集群级资源。有关更多信息，请参阅“标签和选择器”。

OpenShift Service Mesh 3 默认情况下使所有网格都具有集群范围。此更改意味着所有 Istio 控制平面都是集群范围的资源，并且ServiceMeshMemberRoll和ServiceMeshMember资源不再存在，控制平面默认情况下监视或发现整个集群。可以使用discoverySelectors功能来限制控制平面对命名空间的发现。

Red Hat OpenShift Service Mesh 2 支持使用 Pod 注释和标签来配置 sidecar 注射，无需指示工作负载属于哪个控制平面。

在 OpenShift Service Mesh 3 中，即使 Istio 控制平面发现命名空间，该命名空间中存在的工作负载仍然需要包含 sidecar 代理作为服务网格中的工作负载，并能够使用 Istio 的许多功能。

在 OpenShift Service Mesh 3 中，sidecar 注射的工作方式与 Istio 相同，使用 Pod 或命名空间标签来触发 sidecar 注射。但是，可能需要包含一个标签来指示工作负载属于哪个控制平面。

当Istio资源的名称为default并且使用InPlace升级时，只有一个名为default且标签为istio-injection=enabled的IstioRevision用于 sidecar 注射。

但是，在以下情况下需要IstioRevision资源具有不同的名称

如果有多个控制平面实例正在运行，或者您在安装 OpenShift Service Mesh 3 期间选择了RevisionBased更新策略，则IstioRevision资源需要具有与default不同的名称。发生这种情况时，有必要使用一个标签来指示工作负载属于哪个控制平面版本，方法是指定istio.io/rev=<istiorevision_name>。

这些标签可以在工作负载或命名空间级别应用。

您可以通过运行以下命令来检查可用的版本

Red Hat OpenShift Service Mesh 3 支持在同一个集群中存在多个服务网格，但方式不同于 OpenShift Service Mesh 2。集群管理员必须创建多个Istio实例，然后适当地配置discoverySelectors，以确保网格命名空间之间没有重叠。

由于Istio资源是集群范围的，因此它们必须具有唯一的名称才能在同一集群中表示唯一的网格。OpenShift Service Mesh 3 运算符使用此唯一名称来创建名为IstioRevision的资源，其名称格式为{Istio名称}或{Istio名称}-{Istio版本}。

每个IstioRevision实例负责管理单个控制平面。工作负载使用Istio的修订标签（格式为istio.io/rev={IstioRevision名称}）分配到特定的控制平面。带有版本标识符的名称对于支持金丝雀式控制平面升级非常重要。

在Istio中，网关用于管理进入（入口）和离开（出口）网格的流量。Red Hat OpenShift Service Mesh 2部署和管理了带有服务网格控制平面的入口网关和出口网关。入口网关和出口网关都是使用ServiceMeshControlPlane资源配置的。

OpenShift Service Mesh 3 运算符不创建或管理网关。

相反，OpenShift Service Mesh 3中的网关是独立于运算符和控制平面使用网关注入或Kubernetes网关API创建和管理的。这提供了更大的灵活性，并确保网关可以作为Red Hat OpenShift GitOps流水线的一部分进行完全自定义和管理。这允许网关与其应用程序一起部署和管理，并具有相同的生命周期。

此更改的原因有两个：

网关可以继续部署到独立于应用程序的节点或命名空间中。例如，一个集中的网关节点。Istio网关仍然可以部署在OpenShift Container Platform基础架构节点上。

如果您正在使用OpenShift Service Mesh 2.6，并且尚未从ServiceMeshControlPlane定义的网关迁移到网关注入，则必须在迁移到OpenShift Service Mesh 3之前遵循OpenShift Service Mesh 2.x网关迁移过程。

OpenShift Route资源允许使用OpenShift Container Platform Ingress Operator管理基于HAProxy的Ingress控制器来公开具有公共URL的应用程序。

Red Hat OpenShift Service Mesh 2使用了Istio OpenShift Routing (IOR)，它自动创建和管理Istio网关的OpenShift路由。虽然这很方便，因为运算符为您管理这些路由，但它也导致了所有权方面的混淆，因为许多Route资源由管理员管理。Istio OpenShift Routing也缺乏配置独立Route资源的能力，创建了不必要的路由，并在更新期间表现出不可预测的行为。

因此，在OpenShift Service Mesh 3中，当需要Route来公开Istio网关时，您必须手动创建和管理它。如果不需要路由，您也可以通过类型为LoadBalancer的Kubernetes服务来公开Istio网关。

Red Hat OpenShift Service Mesh 2仅支持就地式更新，这会为大型网格带来风险，因为在控制平面更新后，所有工作负载都必须更新到新的控制平面版本，如果没有简单的回滚方法，则可能会出现问题。

OpenShift Service Mesh 3保留了对简单就地式更新的支持，并添加了使用Istio的修订功能对Istio控制平面进行金丝雀式更新的支持。

Istio资源使用IstioRevision资源管理Istio修订标签。当Istio资源的updateStrategy类型设置为RevisionBased时，它将使用Istio资源的名称和Istio版本组合创建Istio修订标签，例如mymesh-v1-21-2。

在更新期间，新的IstioRevision将部署具有更新修订标签的新Istio控制平面，例如mymesh-v1-22-0。然后可以使用命名空间或工作负载上的修订标签在控制平面之间迁移工作负载，例如istio.io/rev=mymesh-v1-22-0。

将updateStrategy设置为RevisionBased也会对集成（例如cert-manager工具和网关）产生影响。

您可以将updateStrategy设置为RevisionBased以使用金丝雀更新。

请注意，将updateStrategy设置为RevisionBased也会对OpenShift Service Mesh的一些集成产生影响，例如cert-manager工具集成。

Red Hat OpenShift Service Mesh 2支持一种多集群形式，即联邦，它在OpenShift Service Mesh 2.1中引入。在此拓扑中，每个集群都维护其自己的独立控制平面，服务仅在需要时在这些网格之间共享。

联邦网格之间的通信是通过Istio网关进行的，因此不需要服务网格控制平面来监视远程Kubernetes控制平面，就像Istio的多集群服务网格拓扑一样。当服务网格松散耦合时，例如由不同的管理团队管理的服务网格，联邦是理想的选择。

OpenShift Service Mesh 3还引入了对以下Istio多集群拓扑的支持：

这些拓扑有效地将单个统一的服务网格扩展到多个集群，这在所有参与的集群都由同一个管理团队管理时是理想的选择。Istio的多集群拓扑也适用于在常用管理的应用程序集中实现高可用性或故障转移用例。

Red Hat OpenShift Service Mesh 1和2不包括对Istioctl的支持，Istioctl是Istio项目的命令行实用程序，其中包含许多诊断和调试实用程序。OpenShift Service Mesh 3引入了对Istioctl中某些命令的支持。

Istio的安装和管理仅受OpenShift Service Mesh 3运算符支持。

默认情况下，Red Hat OpenShift Service Mesh 2创建具有以下行为的Kubernetes NetworkPolicy资源：

OpenShift Service Mesh 3 不会创建这些策略。您必须配置环境所需的隔离级别。Istio 通过授权策略提供对服务网格工作负载的细粒度访问控制。更多信息，请参见“授权策略”。

在 Red Hat OpenShift Service Mesh 2 中，您创建了ServiceMeshControlPlane 资源，并通过将spec.security.dataPlane.mtls 设置为true 来启用 mTLS 严格模式。

您可以通过在您的ServiceMeshControlPlane 资源中设置spec.security.controlPlane.tls.minProtocolVersion 或spec.security.controlPlane.tls.maxProtocolVersion 来设置最小和最大 TLS 协议版本。

在 OpenShift Service Mesh 3 中，Istio 资源取代了ServiceMeshControlPlane 资源，并且不包含这些设置。

要在 OpenShift Service Mesh 3 中启用 mTLS 严格模式，您必须应用相应的PeerAuthentication 和DestinationRule 资源。

在 OpenShift Service Mesh 3 中，您可以通过在您的Istio 资源中设置spec.meshConfig.tlsDefaults.minProtocolVersion 来启用最小 TLS 协议版本。更多信息，请参见“Istio 工作负载最小 TLS 版本配置”。

在 OpenShift Service Mesh 2 和 OpenShift Service Mesh 3 中，自动 mTLS 默认情况下仍然启用。