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

升级服务网格

理解版本控制

Red Hat 使用语义版本控制进行产品发布。语义版本控制是一个 3 部分的数字，格式为 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 资源的版本。

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

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

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

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

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

升级注意事项

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

在升级过程中，运营商会进行更改，包括删除或替换包含以下标签或注释的资源（这些标签或注释表明资源由运营商管理）。

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

  • 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)

升级前，请检查您创建的自定义资源中是否有表明它们由运营商管理的标签或注释。请移除您不希望由运营商管理的自定义资源的标签或注释。

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

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

可能影响升级的已知问题

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

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

  • Red Hat OpenShift Service Mesh 不支持使用EnvoyFilter配置，除非在文档中明确说明。这是由于与底层 Envoy API 紧密耦合，这意味着无法保持向后兼容性。如果您正在使用 Envoy Filters，并且由于升级您的ServiceMeshControlPlane而引入的最新版本的 Envoy 导致 Istio 生成的配置发生了更改，则这可能会破坏您可能已实现的任何EnvoyFilter。

  • OSSM-1505 ServiceMeshExtension 不适用于 OpenShift Dedicated 版本 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规范中禁用网关创建，并完全手动管理网关部署（包括服务、角色和角色绑定）。

升级运营商

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

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

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

Operator Lifecycle Manager (OLM) 控制集群中运营商的安装、升级和基于角色的访问控制 (RBAC)。OLM 在 OpenShift Dedicated 中默认运行。OLM 查询可用的运营商以及已安装运营商的升级。

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

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

自动

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

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

手动

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

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

更新 Red Hat OpenShift Service Mesh 运营商时，Operator Lifecycle Manager (OLM) 会删除旧的运营商 Pod 并启动一个新的 Pod。新的运营商 Pod 启动后，协调过程会检查ServiceMeshControlPlane (SMCP)，如果任何 Service Mesh 控制平面组件都有可用的更新容器镜像，它会将使用新容器镜像的那些 Service Mesh 控制平面 Pod 替换掉。

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

要保留 Red Hat OpenShift Service Mesh 的特定补丁版本，您需要禁用自动更新并保留该特定版本的运营商。

升级控制平面

您必须手动更新次要和主要版本的控制平面。社区 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 版。

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

尽管您可以在同一集群中部署多个版本的控制平面，但 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 版本的更改

将 Service Mesh 控制平面从 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 版本的更改

将 Service Mesh 控制平面从 2.2 版本升级到 2.3 版本会引入以下行为更改

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

从 2.1 版本升级到 2.2 版本的更改

将 Service Mesh 控制平面从 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 版本的更改

将 Service Mesh 控制平面从 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 状态码。

升级 Service Mesh 控制平面

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

先决条件

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

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

步骤

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

    $ oc project istio-system

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

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

      $ oc get smcp -o yaml

      备份您的 Service Mesh 控制平面配置。

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

    例如

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

    或者，您可以使用 Web 控制台编辑 Service Mesh 控制平面，而不是使用命令行。在 OpenShift Dedicated 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 之前，必须升级到 OpenShift Dedicated 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. 备份您的 Service Mesh 控制平面配置。切换到包含 `ServiceMeshControlPlane` 资源的项目。在本例中，`istio-system` 是 Service Mesh 控制平面项目的名称。

    $ oc project istio-system

  3. 输入以下命令以检索当前配置。您的 `` 在 `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 Dedicated 控制台的“项目”菜单中，单击“新建项目”，然后输入项目的名称，例如 `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` 部署控制平面。在本例中，请将 `` 替换为您文件的路径。

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

    或者，您可以使用控制台创建 Service Mesh 控制平面。在 OpenShift Dedicated 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 产品文档，了解有关您使用的功能的新信息。v2 资源必须用于 Red Hat OpenShift Service Mesh 2.0 安装。

架构更改

先前版本使用的架构单元已被 Istiod 替换。在 2.0 版本中，Service Mesh 控制平面组件 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 Service Mesh 控制平面之前更新您的工作负载。

  • `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..svc:15010`（如果启用了 mtls，则为端口 15011）更改为 `istiod-..svc:15012`。

  • 运行状况状态端口不再可配置，并且硬编码为 15021。*如果您定义了自定义状态端口（例如，`status.sidecar.istio.io/port`），则必须在将工作负载移动到 v2.0 Service Mesh 控制平面之前删除该覆盖。仍然可以通过将状态端口设置为 `0` 来禁用就绪性检查。

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

行为更改

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

  • 网关上的就绪性端口已从 `15020` 更改为 `15021`。

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

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

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

不受支持资源的迁移详细信息
策略 (authentication.istio.io/v1alpha1)

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

双向 TLS

使用 `security.istio.io/v1beta1` PeerAuthentication 资源来强制执行双向 TLS。旧的 `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)

通过v1资源中的spec.istio.global.mtls.enabled设置或v2资源中的spec.security.dataPlane.mtls设置，ServiceMeshPolicy已自动为服务网格控制平面配置。对于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)自定义资源进行集成。

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

双向TLS更改

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

自动mTLS默认情况下已启用，但可以通过在ServiceMeshControlPlane资源中将spec.security.dataPlane.automtls设置为false来禁用。禁用自动mTLS时，可能需要DestinationRules才能确保服务之间的正常通信。例如，为一个命名空间设置STRICT的PeerAuthentication可能会阻止其他命名空间中的服务访问它们，除非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 v2.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 v2.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遥测容器

v2.0

global.oauthproxy

与各种附加组件一起使用的OAuth代理容器

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 Agent的特定设置

v1.0/1.1/2.0

tracing.jaeger.allInOne

Jaeger All-in-One的特定设置

v1.0/1.1/2.0

tracing.jaeger.collector

Jaeger Collector的特定设置

v1.0/1.1/2.0

tracing.jaeger.elasticsearch

Jaeger Elasticsearch部署的特定设置

v1.0/1.1/2.0

tracing.jaeger.query

Jaeger Query的特定设置

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扩展缓存容器

2.0版 - 技术预览

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

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

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

升级数据平面

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

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

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

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

$ oc rollout restart <deployment>

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