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) 并发布错误修复。新功能通常不会作为补丁版本的一部分发布。

编辑

版本控制如何影响 Service Mesh 升级

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

  • 补丁更新 - 补丁升级由 Operator Lifecycle Manager (OLM) 管理；当您更新 Operator 时，它们会自动发生。

  • 次要升级 - 次要升级需要同时更新到最新的 Red Hat OpenShift Service Mesh Operator 版本，并手动修改 ServiceMeshControlPlane 资源中的 spec.version 值。

  • 主要升级 - 主要升级需要同时更新到最新的 Red Hat OpenShift Service Mesh Operator 版本，并手动修改 ServiceMeshControlPlane 资源中的 spec.version 值。由于主要升级可能包含不向后兼容的更改，因此可能需要进行额外的更改。

编辑

理解 Service Mesh 版本

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

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

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

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

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

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

Operator Lifecycle Manager (OLM) 不管理 Service Mesh 控制平面升级，因此您的 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 之前，请记下 Service Mesh 生产部署中 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 在 Service Mesh 控制平面中为 ingressgateway 配置 Service ExternalIP 时，不会创建服务。SMCP 的模式缺少服务的参数。

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

编辑

升级 Operator

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

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

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

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

您是否需要采取措施升级您的 Operator 取决于您安装它们时选择的设置。安装每个 Operator 时，您都选择了一个**更新通道**和一个**审批策略**。这两个设置的组合决定了 Operator 的更新时间和方式。

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

自动

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

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

手动

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

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

更新 Red Hat OpenShift 服务网格 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 服务网格的特定补丁版本，您需要禁用自动更新并保留该特定版本的 Operator。

编辑

升级控制平面

您必须手动更新次要和主要版本的控制平面。社区 Istio 项目推荐金丝雀升级，Red Hat OpenShift 服务网格仅支持就地升级。Red Hat OpenShift 服务网格要求您按顺序从每个次要版本升级到下一个次要版本。例如，您必须从版本 2.0 升级到版本 2.1，然后升级到版本 2.2。您不能直接从 Red Hat OpenShift 服务网格 2.0 更新到 2.2。

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

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

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

从版本 2.5 升级到版本 2.6 的更改

编辑

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

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

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

Red Hat OpenShift 服务网格 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 代理及其配置。

先决条件

  • 您正在 AWS 上运行 Red Hat OpenShift Service 4.9 或更高版本。

  • 您拥有最新的 Red Hat OpenShift Service Mesh 运算符。

步骤

  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 控制台编辑服务网格控制平面，而不是使用命令行。在 AWS 上的 Red Hat OpenShift Service Web 控制台中，单击**项目**并选择您刚才输入的项目名称。

    1. 单击**运算符**→**已安装的运算符**。

    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 之前，必须先升级到 Red Hat OpenShift Service on AWS 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. 创建一个项目。在 AWS 控制台项目菜单上的 Red Hat OpenShift Service 中，单击新建项目并输入项目的名称，例如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

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

    1. 单击**运算符**→**已安装的运算符**。

    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 产品文档，了解您所用功能的新信息。Red Hat OpenShift Service Mesh 2.0 安装必须使用 v2 资源。

架构更改

先前版本使用的架构单元已被 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 中，标签必须与目标列表中命名服务的选择器匹配。任何特定于端口的设置都需要映射到 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插件来运行工作负载，则必须将Mixer组件配置到您的2.0版ServiceMeshControlPlane中。

要启用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更改

当使用mTLS和特定于工作负载的PeerAuthentication策略时，如果工作负载策略与命名空间/全局策略不同，则需要相应的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配置Policy资源。

Policy资源示例
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配置Policy资源。

Policy资源示例
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中配置。如果存在与name值匹配的现有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注入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>

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