第 2 章 迁移前

如果您是一个当前的 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 基于 midstream Maistra 项目，OpenShift Service Mesh 3 依赖于 Istio。这意味着 OpenShift Service Mesh 3 使用不同的简化的 Operator 管理，并为 Istio 的最新稳定功能提供更大的支持。

这与 Istio 项目以及在 OpenShift Service Mesh 前两个主要发行本中学习的经验一致，这会导致以下更改：

Red Hat OpenShift Service Mesh 3 使用以下两个新资源：

oc explain istios.spec.values

$ oc explain istios.spec.values

Red Hat OpenShift Service Mesh 3 的显著变化是 Operator 不再安装和管理可观察组件，如 Prometheus 和带有 Istio control plane 的 Grafana。它还不再安装和管理 Red Hat OpenShift distributed tracing 平台组件，如分布式追踪平台(Tempo)和 Red Hat OpenShift distributed tracing 数据收集（以前 Jaeger 和 Elasticsearch）或 Kiali。

OpenShift Service Mesh 3 Operator 将其范围限制为 Istio 相关资源，并受组成 Red Hat OpenShift Observability 的独立的 Operator 支持和管理的可观察性组件，如下所示：

Kiali 和 OpenShift Service Mesh Console (OSSMC)插件仍然受红帽提供的 Kiali Operator 支持。

这种简化可显著降低 OpenShift Service Mesh 3 的空间和复杂性，同时通过 Red Hat OpenShift Observability 组件为可观察性提供更好的生产级支持。

在 OpenShift Service Mesh 2.4 中，引入了一个 集群范围的 模式，以允许网格成为集群范围的，使用名为 discoverySelectors 的 Istio 功能限制网格。使用 discoverySelectors 将 Istio control plane 的可见性限制为使用标签选择器定义的一组命名空间。这与社区 Istio 工作方式一致，并允许 Istio 管理集群级别资源。如需更多信息，请参阅 "Labels 和 Selectors"。

OpenShift Service Mesh 3 默认使所有网格集群设置为集群范围的。这个变化意味着 Istio control plane 都是集群范围的资源，且资源 ServiceMeshMemberRoll 和 ServiceMeshMember 不再存在，control plane 监视或 发现 整个集群。可以使用 discoverySelectors 功能限制 control plane 的命名空间的发现。

Red Hat OpenShift Service Mesh 2 支持使用 pod 注解和标签来配置 sidecar 注入，且不需要指示哪些 control plane 属于哪个 control plane。

使用 OpenShift Service Mesh 3 时，即使 Istio control plane 发现命名空间，该命名空间中的工作负载仍需要 sidecar 代理作为工作负载包含在服务网格中，并可以使用 Istio 的许多功能。

在 OpenShift Service Mesh 3 中，sidecar 注入的工作方式与 Istio 的作用相同，用于触发 sidecar 注入的 pod 或命名空间标签。但是，可能需要包含指示工作负载所属的 control plane 的标签。

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

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

如果运行多个 control plane 实例，或者您在 OpenShift Service Mesh 3 安装过程中选择了 RevisionBased update 策略，则需要一个 IstioRevision 资源才能具有与默认名称不同的名称。当发生这种情况时，需要使用标签来指示工作负载所属的 control plane 修订，方法是指定 istio.io/rev=<istiorevision_name >。

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

您可以运行以下命令来检查可用的修订版本：

oc get istiorevision

$ oc get istiorevision

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

因为 Istio 资源是集群范围的，它们必须具有唯一的名称来代表同一集群中的唯一网格。OpenShift Service Mesh 3 Operator 使用这个唯一名称来创建名为 IstioRevision 的资源，其名称格式为 {Istio name} 或 {Istio name}-{Istio 版本}。

每个 IstioRevision 实例都负责管理单个 control plane。工作负载使用 Istio 的修订标签（格式为 istio.io/rev={IstioRevision name} ）分配给特定的 control plane。带有版本标识符的名称对于支持 Canary 风格的 control plane 升级非常重要。

在 Istio 中，网关用于管理进入（入口）和退出(egress)网格的流量。Red Hat OpenShift Service Mesh 2 部署和管理一个入口网关和一个 Service Mesh control plane 的出口网关。ingress 网关和出口网关都使用 ServiceMeshControlPlane 资源进行配置。

OpenShift Service Mesh 3 Operator 不会创建和管理网关。

相反，OpenShift Service Mesh 3 中的网关会独立于 Operator 和 control plane 进行创建和管理，使用网关注入或 Kubernetes 网关 API。这提供了更大的灵活性，并确保可将网关完全自定义和管理作为 Red Hat OpenShift GitOps 管道的一部分。这允许在具有相同生命周期的应用程序一起部署和管理网关。

这个更改是出于以下两个原因进行的：

网关可以继续部署到独立于应用程序的节点或命名空间中。例如，集中式网关节点。Istio 网关还有资格部署到 OpenShift Container Platform 基础架构节点上。

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

Red Hat OpenShift Service Mesh 2 使用 Istio OpenShift Routing (IOR)，它会自动为 Istio 网关创建和管理 OpenShift 路由。虽然这非常方便，但作为 Operator 管理这些路由，但它也会造成与管理员管理的许多 Route 资源相关的混淆。Istio OpenShift 路由还缺乏配置独立 路由资源、创建不必要的路由以及更新过程中无法预计的行为的功能。

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

Red Hat OpenShift Service Mesh 2 仅支持原位风格更新，这为大型网格造成风险，在 control plane 更新后，所有工作负载都必须更新至新的 control plane 版本，而无需简单地回滚（如果出现问题）。

OpenShift Service Mesh 3 保留了对简单原位升级的支持，并使用 Istio 的修订功能添加了对 Istio control plane 的 Canary 风格更新的支持。

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

在更新过程中，新的 IstioRevision 使用更新的修订版本标签部署新的 Istio control plane，如 mymesh-v1-22-0。然后，可以使用命名空间或工作负载上的 revision 标签在 control plane 间迁移工作负载，如 istio.io/rev=mymesh-v1-22-0。

将您的 updateStrategy 设置为 RevisionBased 也对集成有影响，如 cert-manager 工具和网关。

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

Red Hat OpenShift Service Mesh 2 支持一个多集群、联邦 （在 OpenShift Service Mesh 2.1 中引入的）形式。每个集群在此拓扑中维护自己的独立 control plane，服务仅根据需要在这些网格之间共享。

联邦网格之间的通信通过 Istio 网关，因此不需要 Service Mesh control plane 监视远程 Kubernetes control plane，就像 Istio 的多集群服务网格拓扑结构一样。联邦是服务网格松散耦合的理想选择，例如由不同管理团队管理的那些。

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

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

Red Hat OpenShift Service Mesh 1 和 2 不包括对 Istioctl 的支持，这是包括许多诊断和调试工具的 Istio 项目的命令行工具。OpenShift Service Mesh 3 引入了对 Istioctl 的支持用于所选命令。

Istio 的安装和管理仅支持 OpenShift Service Mesh 3 Operator。

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

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

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

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

在 OpenShift Service Mesh 3 中，Istio 资源替换了 ServiceMeshControlPlane 资源，不包括这些设置。

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

在 OpenShift Service Mesh 3 中，您可以通过在 Istio 资源中设置 spec.meshConfig.tlsDefaults.minProtocolVersion 来启用最小 TLS 协议。如需更多信息，请参阅"Istio Workload Minimum TLS 版本配置"。

在 OpenShift Service Mesh 2 和 OpenShift Service Mesh 3 中，自动 mTLS 会被默认启用。