OpenShift 文档正在迁移，很快将只在 docs.redhat.com（所有 Red Hat 产品文档的所在地）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

升级服务网格

理解版本控制

Red Hat使用语义版本控制来进行产品发布。语义版本控制是一个三部分的数字，格式为X.Y.Z，其中

  • X代表主版本。主版本通常表示某种重大更改：架构更改、API更改、模式更改以及类似的重大更新。

  • Y代表次版本。次版本包含新的功能，同时保持向后兼容性。

  • Z代表补丁版本（也称为z流版本）。补丁版本用于解决常见漏洞和披露 (CVE) 并发布错误修复。新功能通常不会作为补丁版本的一部分发布。

版本控制如何影响服务网格升级

根据您正在进行的更新版本，升级过程有所不同。

  • 补丁更新 - 补丁升级由操作符生命周期管理器 (OLM) 管理；当您更新操作符时，它们会自动发生。

  • 次要升级 - 次要升级需要同时更新到最新的Red Hat OpenShift服务网格操作符版本，并手动修改ServiceMeshControlPlane资源中的spec.version值。

  • 主要升级 - 主要升级需要同时更新到最新的Red Hat OpenShift服务网格操作符版本，并手动修改ServiceMeshControlPlane资源中的spec.version值。由于主要升级可能包含不向后兼容的更改，因此可能需要进行其他手动更改。

了解服务网格版本

为了了解您系统上部署了哪个版本的Red Hat OpenShift服务网格，您需要了解每个组件版本是如何管理的。

  • 操作符版本 - 最新操作符版本为2.6.4。操作符版本号仅指示当前安装的操作符的版本。由于Red Hat OpenShift服务网格操作符支持多个版本的Service Mesh控制平面，因此操作符的版本并不决定已部署ServiceMeshControlPlane资源的版本。

    升级到最新 Operator 版本会自动应用补丁更新，但不会自动将您的服务网格控制平面升级到最新的次要版本。

  • ServiceMeshControlPlane 版本 - ServiceMeshControlPlane 版本决定您正在使用的 Red Hat OpenShift Service Mesh 版本。ServiceMeshControlPlane 资源中 spec.version 字段的值控制用于安装和部署 Red Hat OpenShift Service Mesh 的架构和配置设置。创建服务网格控制平面时，您可以通过两种方式之一设置版本

    • 要在表单视图中配置，请从控制平面版本菜单中选择版本。

    • 要在 YAML 视图中配置，请在 YAML 文件中设置spec.version 的值。

Operator 生命周期管理器 (OLM) 不管理服务网格控制平面升级，因此您的 Operator 和ServiceMeshControlPlane (SMCP) 的版本号可能不匹配，除非您已手动升级您的 SMCP。

升级注意事项

不应在用户创建的自定义资源上使用maistra.io/标签或注释，因为它表示该资源是由 Red Hat OpenShift Service Mesh Operator 生成并应由其管理的。

在升级过程中，Operator 会进行更改，包括删除或替换包含以下标签或注释的资源中的文件，这些标签或注释表示该资源由 Operator 管理。

升级前，请检查包含以下标签或注释的用户创建的自定义资源：

  • maistra.io/ 和 app.kubernetes.io/managed-by 标签设置为maistra-istio-operator (Red Hat OpenShift Service Mesh)

  • kiali.io/ (Kiali)

  • jaegertracing.io/ (Red Hat OpenShift 分布式追踪平台 (Jaeger))

  • logging.openshift.io/ (Red Hat Elasticsearch)

升级前，请检查您创建的自定义资源中是否有指示它们由 Operator 管理的标签或注释。从您不希望 Operator 管理的自定义资源中删除标签或注释。

升级到 2.0 版本时，Operator 只会删除与 SMCP 在同一命名空间中具有这些标签的资源。

升级到 2.1 版本时，Operator 会删除所有命名空间中具有这些标签的资源。

可能影响升级的已知问题

可能影响升级的已知问题包括：

  • 升级 Operator 时，Jaeger 或 Kiali 的自定义配置可能会被还原。升级 Operator 之前，请记下服务网格生产部署中 Jaeger 或 Kiali 对象的任何自定义配置设置，以便您可以重新创建它们。

  • 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 在服务网格控制平面中为 ingressgateway 配置服务ExternalIP时，不会创建服务。SMCP 的模式缺少服务的参数。

    解决方法：在 SMCP规范中禁用网关创建，并完全手动管理网关部署（包括服务、角色和角色绑定）。

升级 Operator

为了使您的服务网格始终应用最新的安全修复程序、错误修复程序和软件更新，您必须保持 Operator 更新。您可以通过升级 Operator 来启动补丁更新。

Operator 的版本**不**决定您的服务网格的版本。已部署的服务网格控制平面的版本决定您的服务网格版本。

由于 Red Hat OpenShift Service Mesh Operator 支持多个版本的服务网格控制平面，因此更新 Red Hat OpenShift Service Mesh Operator **不会**更新已部署的ServiceMeshControlPlane的spec.version值。另请注意，spec.version值是一个两位数，例如 2.2，补丁更新（例如 2.2.1）不会反映在 SMCP 版本值中。

Operator 生命周期管理器 (OLM) 控制集群中 Operator 的安装、升级和基于角色的访问控制 (RBAC)。OLM 默认情况下在 OpenShift Container Platform 中运行。OLM 查询可用的 Operator 以及已安装 Operator 的升级。

您是否必须采取措施来升级您的 Operator 取决于您在安装它们时选择的设置。安装每个 Operator 时，您都会选择一个**更新通道**和一个**审批策略**。这两个设置的组合决定了何时以及如何更新您的 Operator。

表 1. 更新通道和审批策略的交互
版本化通道 “稳定”或“预览”通道

自动

仅自动更新该版本的次要和补丁版本 Operator。不会自动更新到下一个主要版本（即从 2.0 版本更新到 3.0 版本）。需要手动更改 Operator 订阅才能更新到下一个主要版本。

自动更新所有主要、次要和补丁版本的 Operator。

手动

指定版本的次要和补丁版本需要手动更新。需要手动更改 Operator 订阅才能更新到下一个主要版本。

所有主要、次要和补丁版本都需要手动更新。

更新 Red Hat OpenShift Service Mesh Operator 时，Operator 生命周期管理器 (OLM) 会删除旧的 Operator pod 并启动一个新的 pod。新的 Operator pod 启动后，协调过程会检查ServiceMeshControlPlane (SMCP)，如果服务网格控制平面的任何组件有更新的容器镜像可用，它会将使用新容器镜像的服务网格控制平面 pod 替换掉旧的 pod。

更新 Kiali 和 Red Hat OpenShift 分布式追踪平台 (Jaeger) Operator 时，OLM 协调过程会扫描集群并将托管实例升级到新 Operator 的版本。例如，如果您将 Red Hat OpenShift 分布式追踪平台 (Jaeger) Operator 从 1.30.2 版本更新到 1.34.1 版本，则 Operator 会扫描正在运行的分布式追踪平台 (Jaeger) 实例并将其升级到 1.34.1 版本。

要停留在 Red Hat OpenShift Service Mesh 的特定补丁版本上，您需要禁用自动更新并停留在该特定版本的 Operator 上。

有关升级 Operator 的更多信息，请参阅Operator 生命周期管理器文档。

升级控制平面

对于次要和主要版本，您必须手动更新控制平面。Istio 社区项目建议金丝雀升级，Red Hat OpenShift Service Mesh 只支持就地升级。Red Hat OpenShift Service Mesh 要求您按顺序从每个次要版本升级到下一个次要版本。例如，您必须从 2.0 版本升级到 2.1 版本，然后再升级到 2.2 版本。您不能直接从 Red Hat OpenShift Service Mesh 2.0 升级到 2.2。

当您升级服务网格控制平面时，所有 Operator 管理的资源（例如网关）也会升级。

虽然您可以在同一个集群中部署多个版本的控制平面，但 Red Hat OpenShift Service Mesh 不支持服务网格的金丝雀升级。也就是说，您可以拥有具有不同spec.version值的不同的 SCMP 资源，但它们不能管理同一个网格。

有关迁移扩展的更多信息，请参阅从 ServiceMeshExtension 资源迁移到 WasmPlugin 资源。

从 2.5 版本升级到 2.6 版本的变化

Red Hat OpenShift 分布式追踪平台 (Jaeger) 默认设置更改

此版本默认情况下为新的 ServiceMeshControlPlane 资源实例禁用 Red Hat OpenShift 分布式追踪平台 (Jaeger)。

将现有 ServiceMeshControlPlane 资源实例更新到 Red Hat OpenShift Service Mesh 2.6 版本时，分布式追踪平台 (Jaeger) 默认情况下保持启用状态。

Red Hat OpenShift Service Mesh 2.6 是最后一个包含对 Red Hat OpenShift 分布式追踪平台 (Jaeger) 和 OpenShift Elasticsearch Operator 支持的版本。分布式追踪平台 (Jaeger) 和 OpenShift Elasticsearch Operator 将在下一个版本中移除。如果您目前正在使用分布式追踪平台 (Jaeger) 和 OpenShift Elasticsearch Operator，则必须迁移到 Red Hat OpenShift 分布式追踪平台 (Tempo) 和 Red Hat 版本的 OpenTelemetry。

Envoy sidecar 容器默认设置更改

为了提高 Pod 启动时间，Istio 现在默认在 sidecar 容器中包含一个 startupProbe。在 Envoy sidecar 启动之前，Pod 的就绪探测不会启动。

从 2.4 版本升级到 2.5 版本的变化

Istio OpenShift 路由 (IOR) 默认设置更改

Istio OpenShift 路由 (IOR) 的默认设置已更改。该设置现在默认情况下已禁用。

您可以通过在 ServiceMeshControlPlane 资源的 spec.gateways.openshiftRoute 规范中将 enabled 字段设置为 true 来使用 IOR。

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  gateways:
    openshiftRoute:
      enabled: true

Istio 代理并发配置增强

为了保证跨部署的一致性，Istio 现在根据分配给代理容器的 CPU 限制来配置 concurrency 参数。例如，2500m 的限制会将 concurrency 参数设置为 3。如果您将 concurrency 参数设置为某个值，Istio 将使用该值来配置代理运行的线程数，而不是使用 CPU 限制。

以前，该参数的默认设置为 2。

从 2.3 版本升级到 2.4 版本的变化

将服务网格控制平面从 2.3 版本升级到 2.4 版本会引入以下行为更改

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

从 2.2 版本升级到 2.3 版本的变化

将服务网格控制平面从 2.2 版本升级到 2.3 版本会引入以下行为更改

  • 此版本要求使用 WasmPlugin API。对在 2.2 版本中已弃用的 ServiceMeshExtension API 的支持现已移除。如果您在使用 ServiceMeshExtension API 时尝试升级，则升级将失败。

从 2.1 版本升级到 2.2 版本的变化

将服务网格控制平面从 2.1 版本升级到 2.2 版本会引入以下行为更改

  • istio-node DaemonSet 已重命名为 istio-cni-node，以匹配上游 Istio 中的名称。

  • Istio 1.10 将 Envoy 更新为默认情况下使用 eth0 而不是 lo 将流量发送到应用程序容器。

  • 此版本增加了对 WasmPlugin API 的支持，并弃用了 ServiceMeshExtension API。

从 2.0 版本升级到 2.1 版本的变化

将服务网格控制平面从 2.0 版本升级到 2.1 版本会引入以下架构和行为更改。

架构更改

在 Red Hat OpenShift Service Mesh 2.1 中，Mixer 已完全移除。如果启用了 Mixer，则将阻止从 Red Hat OpenShift Service Mesh 2.0.x 版本升级到 2.1。

如果您在从 v2.0 升级到 v2.1 时看到以下消息，请在更新 .spec.version 字段之前，将现有控制平面规范中的现有 Mixer 类型更新为 Istiod 类型。

An error occurred
admission webhook smcp.validation.maistra.io denied the request: [support for policy.type "Mixer" and policy.Mixer options have been removed in v2.1, please use another alternative, support for telemetry.type "Mixer" and telemetry.Mixer options have been removed in v2.1, please use another alternative]”

例如

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  policy:
    type: Istiod
  telemetry:
    type: Istiod
  version: v2.6
行为更改

  • AuthorizationPolicy 更新

    • 使用 PROXY 协议时，如果您使用 ipBlocks 和 notIpBlocks 来指定远程 IP 地址，请将配置更新为改用 remoteIpBlocks 和 notRemoteIpBlocks。

    • 增加了对嵌套 JSON Web 令牌 (JWT) 声明的支持。

  • EnvoyFilter 破坏性更改

    • 必须使用 typed_config

    • 不再支持 xDS v2

    • 已弃用的过滤器名称

  • 较旧版本的代理在从较新版本的代理接收 1xx 或 204 状态代码时可能会报告 503 状态代码。

升级服务网格控制平面

要升级 Red Hat OpenShift Service Mesh，您必须更新 Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 资源的版本字段。然后，一旦配置并应用它，重新启动应用程序 Pod 以更新每个 sidecar 代理及其配置。

先决条件

  • 您正在运行 OpenShift Container Platform 4.9 或更高版本。

  • 您拥有最新的 Red Hat OpenShift Service Mesh Operator。

步骤

  1. 切换到包含您的 ServiceMeshControlPlane 资源的项目。在此示例中，istio-system 是服务网格控制平面项目的名称。

    $ oc project istio-system

  2. 检查您的 v2 ServiceMeshControlPlane 资源配置以验证其有效性。

    1. 运行以下命令以将您的 ServiceMeshControlPlane 资源显示为 v2 资源。

      $ oc get smcp -o yaml

      备份您的服务网格控制平面配置。

  3. 更新 .spec.version 字段并应用配置。

    例如

    apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
  name: basic
spec:
  version: v2.6

    或者，您可以使用 Web 控制台编辑服务网格控制平面，而不是使用命令行。在 OpenShift Container Platform Web 控制台中，单击**项目**并选择您刚才输入的项目名称。

    1. 单击**Operators** → **已安装的 Operators**。

    2. 找到您的ServiceMeshControlPlane实例。

    3. 选择**YAML 视图**并更新 YAML 文件的文本，如前面的示例所示。

    4. 单击**保存**。

将 Red Hat OpenShift Service Mesh 从 1.1 版迁移到 2.0 版

从 1.1 版升级到 2.0 版需要手动步骤，这些步骤会将您的工作负载和应用程序迁移到运行新版本的 Red Hat OpenShift Service Mesh 的新实例。

先决条件

  • 在升级到 Red Hat OpenShift Service Mesh 2.0 之前，必须先升级到 OpenShift Container Platform 4.7。

  • 您必须拥有 Red Hat OpenShift Service Mesh 2.0 运算符。如果您选择了**自动**升级路径，则运算符会自动下载最新信息。但是，您必须采取一些步骤才能使用 Red Hat OpenShift Service Mesh 2.0 中的功能。

升级 Red Hat OpenShift Service Mesh

要升级 Red Hat OpenShift Service Mesh，必须在新的命名空间中创建一个 Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 资源的实例。然后，配置完成后，将微服务应用程序和工作负载从旧网格移动到新的服务网格。

步骤

  1. 检查您的 v1 ServiceMeshControlPlane 资源配置以确保其有效。

    1. 运行以下命令以将您的 ServiceMeshControlPlane 资源显示为 v2 资源。

      $ oc get smcp -o yaml

    2. 检查输出中的spec.techPreview.errored.message字段以获取有关任何无效字段的信息。

    3. 如果您的 v1 资源中存在无效字段，则该资源无法协调，也无法作为 v2 资源进行编辑。对 v2 字段的所有更新都将被原始 v1 设置覆盖。要修复无效字段，您可以替换、修补或编辑资源的 v1 版本。您也可以删除资源而无需修复它。修复资源后，可以协调它，然后您可以修改或查看资源的 v2 版本。

    4. 要通过编辑文件来修复资源，请使用oc get检索资源，在本地编辑文本文件，然后用您编辑的文件替换资源。

      $ oc get smcp.v1.maistra.io <smcp_name> > smcp-resource.yaml
#Edit the smcp-resource.yaml file.
$ oc replace -f smcp-resource.yaml

    5. 要使用修补程序修复资源，请使用oc patch。

      $ oc patch smcp.v1.maistra.io <smcp_name> --type json --patch '[{"op": "replace","path":"/spec/path/to/bad/setting","value":"corrected-value"}]'

    6. 要使用命令行工具编辑修复资源，请使用oc edit。

      $ oc edit smcp.v1.maistra.io <smcp_name>

  2. 备份您的服务网格控制平面配置。切换到包含您的ServiceMeshControlPlane资源的项目。在此示例中，istio-system是服务网格控制平面项目的名称。

    $ oc project istio-system

  3. 输入以下命令以检索当前配置。您的<smcp_name>在您的ServiceMeshControlPlane资源的元数据中指定，例如basic-install或full-install。

    $ oc get servicemeshcontrolplanes.v1.maistra.io <smcp_name> -o yaml > <smcp_name>.v1.yaml

  4. 将您的ServiceMeshControlPlane转换为包含有关您的配置信息的 v2 控制平面版本作为起点。

    $ oc get smcp <smcp_name> -o yaml > <smcp_name>.v2.yaml

  5. 创建一个项目。在 OpenShift Container Platform 控制台的“项目”菜单中，单击“新建项目”，然后输入项目的名称，例如istio-system-upgrade。或者，您可以从 CLI 运行此命令。

    $ oc new-project istio-system-upgrade

  6. 使用您的新项目名称更新您 v2 ServiceMeshControlPlane中的metadata.namespace字段。在此示例中，使用istio-system-upgrade。

  7. 将您 v2 ServiceMeshControlPlane中的version字段从 1.1 更新到 2.0 或将其移除。

  8. 在新命名空间中创建一个ServiceMeshControlPlane。在命令行上，运行以下命令以使用您检索到的 v2 版本的ServiceMeshControlPlane部署控制平面。在此示例中，将<smcp_name.v2>替换为您文件的路径。

    $ oc create -n istio-system-upgrade -f <smcp_name>.v2.yaml

    或者，您可以使用控制台创建服务网格控制平面。在 OpenShift Container Platform Web 控制台中，单击**项目**。然后，选择您刚才输入的项目名称。

    1. 单击**Operators** → **已安装的 Operators**。

    2. 单击**创建 ServiceMeshControlPlane**。

    3. 选择**YAML 视图**并将您检索到的 YAML 文件的文本粘贴到该字段中。检查apiVersion字段是否设置为maistra.io/v2，并修改metadata.namespace字段以使用新的命名空间，例如istio-system-upgrade。

    4. 单击**创建**。

配置 2.0 ServiceMeshControlPlane

Red Hat OpenShift Service Mesh 2.0 版的ServiceMeshControlPlane资源已更改。创建 v2 版本的ServiceMeshControlPlane资源后，对其进行修改以利用新功能并适应您的部署。在修改ServiceMeshControlPlane资源时，请考虑 Red Hat OpenShift Service Mesh 2.0 的规范和行为的以下更改。您还可以参考 Red Hat OpenShift Service Mesh 2.0 产品文档以获取有关您使用的功能的新信息。v2 资源必须用于 Red Hat OpenShift Service Mesh 2.0 安装。

架构更改

先前版本使用的架构单元已被 Istiod 替换。在 2.0 中，服务网格控制平面组件 Mixer、Pilot、Citadel、Galley 和 sidecar注入功能已组合到单个组件 Istiod 中。

尽管 Mixer 不再作为控制平面组件受支持，但 Mixer 策略和遥测插件现在通过 Istiod 中的 WASM 扩展受支持。如果需要集成旧版 Mixer 插件，可以启用 Mixer 以进行策略和遥测。

秘密发现服务 (SDS) 用于直接从 Istiod 分发证书和密钥到 sidecar。在 Red Hat OpenShift Service Mesh 1.1 版中，秘密是由 Citadel 生成的，代理使用这些秘密来检索其客户端证书和密钥。

注释更改

v2.0 不再支持以下注释。如果您正在使用其中一个注释，则必须在将其移动到 v2.0 服务网格控制平面之前更新您的工作负载。

  • sidecar.maistra.io/proxyCPULimit已被sidecar.istio.io/proxyCPULimit替换。如果您在工作负载上使用的是sidecar.maistra.io注释，则必须修改这些工作负载以改用sidecar.istio.io等效项。

  • sidecar.maistra.io/proxyMemoryLimit已被sidecar.istio.io/proxyMemoryLimit替换。

  • sidecar.istio.io/discoveryAddress不再受支持。此外，默认发现地址已从pilot.<control_plane_namespace>.svc:15010（如果启用了 mtls，则为端口 15011）移动到istiod-<smcp_name>.<control_plane_namespace>.svc:15012。

  • 健康状态端口不再可配置，并且硬编码为 15021。*如果您定义的是自定义状态端口，例如status.sidecar.istio.io/port，则必须在将工作负载移动到 v2.0 服务网格控制平面之前删除覆盖。仍然可以通过将状态端口设置为0来禁用就绪检查。

  • Kubernetes Secret 资源不再用于为 sidecar 分发客户端证书。证书现在通过 Istiod 的 SDS 服务分发。如果您依赖于已安装的密钥，则 v2.0 服务网格控制平面中的工作负载将不再可以使用它们。

行为更改

Red Hat OpenShift Service Mesh 2.0 中的一些功能的工作方式与以前的版本不同。

  • 网关上的就绪端口已从15020移动到15021。

  • 目标主机可见性包括 VirtualService 和 ServiceEntry 资源。它包括通过 Sidecar 资源应用的任何限制。

  • 默认情况下启用自动双向 TLS。代理到代理通信自动配置为使用 mTLS，而不管全局 PeerAuthentication 策略是否到位。

  • 无论spec.security.controlPlane.mtls设置如何，代理与服务网格控制平面通信时始终使用安全连接。spec.security.controlPlane.mtls设置仅在配置Mixer遥测或策略的连接时使用。

不支持资源的迁移详情
策略 (authentication.istio.io/v1alpha1)

策略资源必须迁移到新的资源类型才能与v2.0服务网格控制平面、PeerAuthentication和RequestAuthentication一起使用。根据策略资源中的特定配置，您可能需要配置多个资源才能达到相同的效果。

双向TLS

双向TLS强制执行是使用security.istio.io/v1beta1 PeerAuthentication资源实现的。旧的spec.peers.mtls.mode字段直接映射到新资源的spec.mtls.mode字段。选择条件已从在spec.targets[x].name中指定服务名称更改为在spec.selector.matchLabels中使用标签选择器。在PeerAuthentication中，标签必须与目标列表中命名服务的selector匹配。任何特定于端口的设置都需要映射到spec.portLevelMtls。

身份验证

在spec.origins中指定的其他身份验证方法必须映射到security.istio.io/v1beta1 RequestAuthentication资源。spec.selector.matchLabels必须与PeerAuthentication上的相同字段类似地进行配置。来自spec.origins.jwt项目的JWT主体特定配置映射到spec.rules项目中的类似字段。

  • 策略中指定的spec.origins[x].jwt.triggerRules必须映射到一个或多个security.istio.io/v1beta1 AuthorizationPolicy资源。任何spec.selector.labels都必须与RequestAuthentication上的相同字段类似地进行配置。

  • spec.origins[x].jwt.triggerRules.excludedPaths必须映射到一个AuthorizationPolicy，其spec.action设置为ALLOW，spec.rules[x].to.operation.path条目与排除的路径匹配。

  • spec.origins[x].jwt.triggerRules.includedPaths必须映射到一个单独的AuthorizationPolicy，其spec.action设置为ALLOW，spec.rules[x].to.operation.path条目与包含的路径匹配，并且spec.rules.[x].from.source.requestPrincipals条目与策略资源中指定的spec.origins[x].jwt.issuer对齐。

ServiceMeshPolicy (maistra.io/v1)

ServiceMeshPolicy是通过v1资源中的spec.istio.global.mtls.enabled或v2资源设置中的spec.security.dataPlane.mtls自动为服务网格控制平面配置的。对于v2控制平面，在安装期间会创建一个功能等效的PeerAuthentication资源。此功能在Red Hat OpenShift Service Mesh 2.0中已弃用。

RbacConfig、ServiceRole、ServiceRoleBinding (rbac.istio.io/v1alpha1)

这些资源已被security.istio.io/v1beta1 AuthorizationPolicy资源替换。

模拟RbacConfig行为需要编写一个默认的AuthorizationPolicy，其设置取决于RbacConfig中指定的spec.mode。

  • 当spec.mode设置为OFF时，不需要任何资源，因为默认策略为ALLOW，除非AuthorizationPolicy应用于请求。

  • 当spec.mode设置为ON时，设置spec: {}。您必须为网格中的所有服务创建AuthorizationPolicy策略。

  • spec.mode设置为ON_WITH_INCLUSION时，必须在每个包含的命名空间中创建具有spec: {}的AuthorizationPolicy。AuthorizationPolicy不支持包含单个服务。但是，一旦创建任何应用于服务工作负载的AuthorizationPolicy，所有未明确允许的其他请求都将被拒绝。

  • 当spec.mode设置为ON_WITH_EXCLUSION时，AuthorizationPolicy不支持。可以创建一个全局DENY策略，但是必须为网格中的每个工作负载创建一个AuthorizationPolicy，因为没有可以应用于命名空间或工作负载的允许所有策略。

AuthorizationPolicy包含要应用配置的选择器的配置，这类似于ServiceRoleBinding提供功能，以及应应用的规则，这类似于ServiceRole提供功能。

ServiceMeshRbacConfig (maistra.io/v1)

此资源已替换为在服务网格控制平面的命名空间中使用具有空spec.selector的security.istio.io/v1beta1 AuthorizationPolicy资源。此策略将是应用于网格中所有工作负载的默认授权策略。有关具体的迁移详情，请参见上面的RbacConfig。

Mixer插件

在2.0版中，Mixer组件默认情况下处于禁用状态。如果您依赖于工作负载的Mixer插件，则必须将您的2.0版ServiceMeshControlPlane配置为包含Mixer组件。

要启用Mixer策略组件，请将以下代码段添加到您的ServiceMeshControlPlane。

spec:
  policy:
    type: Mixer

要启用Mixer遥测组件，请将以下代码段添加到您的ServiceMeshControlPlane。

spec:
  telemetry:
    type: Mixer

旧版Mixer插件也可以迁移到WASM并使用新的ServiceMeshExtension (maistra.io/v1alpha1)自定义资源进行集成。

上游Istio发行版中包含的内置WASM过滤器在Red Hat OpenShift Service Mesh 2.0中不可用。

双向TLS更改

当使用具有特定于工作负载的PeerAuthentication策略的mTLS时，如果工作负载策略与命名空间/全局策略不同，则需要相应的DestinationRule来允许流量。

自动mTLS默认情况下启用，但可以通过在ServiceMeshControlPlane资源中将spec.security.dataPlane.automtls设置为false来禁用。禁用自动mTLS时，可能需要DestinationRules才能确保服务之间正确通信。例如，将一个命名空间的PeerAuthentication设置为STRICT可能会阻止其他命名空间中的服务访问它们，除非DestinationRule为该命名空间中的服务配置了TLS模式。

有关mTLS的信息，请参见启用相互传输层安全性 (mTLS)

其他mTLS示例

要在bookinfo示例应用程序中禁用productpage服务的mTLS，您的策略资源在Red Hat OpenShift Service Mesh v1.1中配置如下。

示例策略资源
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  targets:
  - name: productpage

要在bookinfo示例应用程序中禁用productpage服务的mTLS，请使用以下示例为Red Hat OpenShift Service Mesh 2.0配置您的PeerAuthentication资源。

示例PeerAuthentication资源
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  mtls:
    mode: DISABLE
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage

要在bookinfo示例应用程序中为productpage服务启用具有JWT身份验证的mTLS，您的策略资源在Red Hat OpenShift Service Mesh v1.1中配置如下。

示例策略资源
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  targets:
  - name: productpage
    ports:
    - number: 9000
  peers:
  - mtls:
  origins:
  - jwt:
      issuer: "https://securetoken.google.com"
      audiences:
      - "productpage"
      jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
      jwtHeaders:
      - "x-goog-iap-jwt-assertion"
      triggerRules:
      - excludedPaths:
        - exact: /health_check
  principalBinding: USE_ORIGIN

要在bookinfo示例应用程序中为productpage服务启用具有JWT身份验证的mTLS，请使用以下示例为Red Hat OpenShift Service Mesh 2.0配置您的PeerAuthentication资源。

示例PeerAuthentication资源
#require mtls for productpage:9000
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  portLevelMtls:
    9000:
      mode: STRICT
---
#JWT authentication for productpage
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  jwtRules:
  - issuer: "https://securetoken.google.com"
    audiences:
    - "productpage"
    jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
    fromHeaders:
    - name: "x-goog-iap-jwt-assertion"
---
#Require JWT token to access product page service from
#any client to all paths except /health_check
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  action: ALLOW
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  rules:
  - to: # require JWT token to access all other paths
      - operation:
          notPaths:
          - /health_check
    from:
      - source:
          # if using principalBinding: USE_PEER in the Policy,
          # then use principals, e.g.
          # principals:
          # - “*”
          requestPrincipals:
          - “*”
  - to: # no JWT token required to access health_check
      - operation:
          paths:
          - /health_check

配置方案

您可以使用以下配置方案配置以下项目。

数据平面中的双向 TLS

数据平面通信的双向 TLS 通过 `ServiceMeshControlPlane` 资源中的 `spec.security.dataPlane.mtls` 进行配置，默认值为 `false`。

自定义签名密钥

Istiod 管理服务代理使用的客户端证书和私钥。默认情况下，Istiod 使用自签名证书进行签名，但您可以配置自定义证书和私钥。有关如何配置签名密钥的更多信息，请参见 添加外部证书颁发机构密钥和证书

追踪

追踪在 `spec.tracing` 中配置。目前，唯一支持的追踪器类型是 `Jaeger`。采样是一个缩放整数，表示 0.01% 的增量，例如，1 为 0.01%，10000 为 100%。可以指定追踪实现和采样率。

spec:
  tracing:
    sampling: 100 # 1%
    type: Jaeger

Jaeger 在 `ServiceMeshControlPlane` 资源的 `addons` 部分配置。

spec:
  addons:
    jaeger:
      name: jaeger
      install:
        storage:
          type: Memory # or Elasticsearch for production mode
          memory:
            maxTraces: 100000
          elasticsearch: # the following values only apply if storage:type:=Elasticsearch
            storage: # specific storageclass configuration for the Jaeger Elasticsearch (optional)
              size: "100G"
              storageClassName: "storageclass"
            nodeCount: 3
            redundancyPolicy: SingleRedundancy
  runtime:
    components:
      tracing.jaeger: {} # general Jaeger specific runtime configuration (optional)
      tracing.jaeger.elasticsearch: #runtime configuration for Jaeger Elasticsearch deployment (optional)
        container:
          resources:
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "1Gi"

Jaeger 安装可以通过 `install` 字段进行自定义。容器配置（例如资源限制）在 `spec.runtime.components.jaeger` 相关的字段中配置。如果存在与 `spec.addons.jaeger.name` 值匹配的 Jaeger 资源，则服务网格控制平面将配置为使用现有安装。使用现有的 Jaeger 资源可以完全自定义您的 Jaeger 安装。

可视化

Kiali 和 Grafana 在 `ServiceMeshControlPlane` 资源的 `addons` 部分配置。

spec:
  addons:
    grafana:
      enabled: true
      install: {} # customize install
    kiali:
      enabled: true
      name: kiali
      install: {} # customize install

Grafana 和 Kiali 安装可以通过各自的 `install` 字段进行自定义。容器自定义（例如资源限制）在 `spec.runtime.components.kiali` 和 `spec.runtime.components.grafana` 中配置。如果存在与名称值匹配的现有 Kiali 资源，则服务网格控制平面将配置 Kiali 资源以与控制平面一起使用。一些 Kiali 资源中的字段将被覆盖，例如 `accessible_namespaces` 列表，以及 Grafana、Prometheus 和追踪的端点。使用现有资源可以完全自定义您的 Kiali 安装。

资源利用率和调度

资源在 `spec.runtime.<component>` 下配置。支持以下组件名称。

组件 描述 支持的版本

security

Citadel 容器

v1.0/1.1

galley

Galley 容器

v1.0/1.1

pilot

Pilot/Istiod 容器

v1.0/1.1/2.0

mixer

istio-telemetry 和 istio-policy 容器

v1.0/1.1

mixer.policy

istio-policy 容器

v2.0

mixer.telemetry

istio-telemetry 容器

v2.0

global.oauthproxy

与各种附加组件一起使用的 oauth-proxy 容器

v1.0/1.1/2.0

sidecarInjectorWebhook

sidecar injector webhook 容器

v1.0/1.1

tracing.jaeger

通用 Jaeger 容器 - 可能并非所有设置都适用。通过在服务网格控制平面配置中指定现有 Jaeger 资源，支持完全自定义 Jaeger 安装。

v1.0/1.1/2.0

tracing.jaeger.agent

Jaeger 代理的特定设置

v1.0/1.1/2.0

tracing.jaeger.allInOne

Jaeger allInOne 的特定设置

v1.0/1.1/2.0

tracing.jaeger.collector

Jaeger 收集器的特定设置

v1.0/1.1/2.0

tracing.jaeger.elasticsearch

Jaeger elasticsearch 部署的特定设置

v1.0/1.1/2.0

tracing.jaeger.query

Jaeger 查询的特定设置

v1.0/1.1/2.0

prometheus

prometheus 容器

v1.0/1.1/2.0

kiali

Kiali 容器 - 通过在服务网格控制平面配置中指定现有 Kiali 资源，支持完全自定义 Kiali 安装。

v1.0/1.1/2.0

grafana

Grafana 容器

v1.0/1.1/2.0

3scale

3scale 容器

v1.0/1.1/2.0

wasmExtensions.cacher

WASM 扩展缓存器容器

v2.0 - 技术预览

某些组件支持资源限制和调度。有关更多信息，请参见 性能和可扩展性。

迁移应用程序和工作负载的后续步骤

将应用程序工作负载移动到新的网格并移除旧实例以完成升级。

升级数据平面

升级控制平面后，您的数据平面仍将继续运行。但是，为了将更新应用于 Envoy 代理和任何对代理配置的更改，您必须重新启动您的应用程序 pod 和工作负载。

更新您的应用程序和工作负载

要完成迁移，请重新启动网格中的所有应用程序 pod 以升级 Envoy sidecar 代理及其配置。

要执行部署的滚动更新，请使用以下命令

$ oc rollout restart <deployment>

您必须对构成网格的所有应用程序执行滚动更新。