1.11. 升级 Service Mesh


要访问 Red Hat OpenShift Service Mesh 的最当前功能,请升级到当前版本 2.5。

1.11.1. 了解版本

红帽在产品版本中使用语义版本。语义版本包括 3 个组件号,格式为 X.Y.Z,其中:

  • X 代表主版本。主发行版本通常表示有主要的变化:架构更改、API 更改、模式更改以及类似的重大更新。
  • Y 代表次版本。次发行版本包含了新功能,同时保持向后兼容性。
  • z 代表一个补丁版本(也称为 z-stream 版本)。补丁版本用于提供解决常见漏洞和风险 (CVE) 的解决方案,以及版本中的程序错误修复。新特性通常不会作为补丁版本的一部分发布。

1.11.1.1. 版本对 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 值。因为主版本的更新可能包含不向后兼容的更改,所以可能需要进行额外的手动更改。

1.11.1.2. 了解 Service Mesh 版本

要了解您在系统上部署的 Red Hat OpenShift Service Mesh 版本,您需要了解如何管理各个组件版本。

  • Operator 版本 - 最新版本为 2.5。Operator 版本号仅指示当前安装的 Operator 的版本。因为 Red Hat OpenShift Service Mesh Operator 支持 Service Mesh control plane 的多个版本,所以 Operator 的版本不会决定部署的 ServiceMeshControlPlane 资源的版本。

    重要

    升级到最新的 Operator 版本会自动应用补丁更新,但不会自动将 Service Mesh control plane 升级到最新的次版本。

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

    • 要在 Form View 中配置,请从 Control Plane Version 菜单中选择版本。
    • 要在 YAML View 中配置,请在 YAML 文件中设置 spec.version 的值。

Operator Lifecycle Manager(OLM)不管理 Service Mesh control plane 升级,因此,Operator 和 ServiceMeshControlPlane (SMCP)的版本号可能不匹配,除非您手动升级 SMCP。

1.11.2. 升级注意事项

maistra.io/ 标签或注解不应用于用户创建的自定义资源,因为它表示资源由 Red Hat OpenShift Service Mesh Operator 生成并应该由 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 distributed tracing platform (Jaeger))
  • logging.openshift.io/ (Red Hat Elasticsearch)

在升级前,检查用户为标签或注解创建自定义资源,以指示用户管理的 Operator。从您不想由 Operator 管理的自定义资源中删除标签或注解。

当升级到版本 2.0 时,Operator 只删除与 SMCP 相同的命名空间中使用这些标签的资源。

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

1.11.2.1. 可能会影响升级的已知问题

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

  • 当升级 Operator 时,可能会恢复 Jaeger 或 Kiali 的自定义配置。在升级 Operator 前,请注意 Service Mesh production 部署中 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 在为服务网格 control plane 中为 ingressgateway 配置 Service ExternalIP 时,不会创建该服务。SMCP 的 schema 缺少该服务的参数。

    临时解决方案:禁用 SMCP spec 中的网关创建,手动管理网关部署(包括 Service、Role 和 RoleBinding)。

1.11.3. 升级 Operator

要让您的 Service Mesh 使用最新的安全修复、程序错误修正和软件更新进行补丁,您需要保持 Operator 为最新版本。您可以通过升级 Operator 来启动补丁更新。

重要

Operator 的版本 不会 决定服务网格的版本。部署的 Service Mesh control plane 的版本决定了您的 Service Mesh 版本。

因为 Red Hat OpenShift Service Mesh Operator 支持 Service Mesh control plane 的多个版本,所以更新 Red Hat OpenShift Service Mesh Operator 不会更新部署的 ServiceMeshControlPlanespec.version 值。另请注意,spec.version 值是一个双数字,如 2.2,补丁更新(如 2.2.1)不会反映在 SMCP 版本值中。

Operator Lifecycle Manager (OLM) 能够控制集群中 Operator 的安装、升级和基于角色的访问控制 (RBAC)。OLM 默认在 Red Hat OpenShift Service on AWS 中运行。OLM 会查询可用的 Operator 以及已安装的 Operator 的升级。

升级 Operator 的具体方式取决于您在安装 Operator 时选择的设置。安装每个 Operator 时,您可以选择一个更新频道和一个批准策略。这两个设置的组合决定了 Operator 的更新时间和方式。

表 1.4. 更新频道和批准策略的交互
 版本化频道"Stable" 或 "Preview" 频道

自动

仅为该版本的次版本自动更新 Operator。将不会自动更新到下一个主要版本(即,从 2.0 升级到 3.0)。手动更改为升级到下一个主要版本所需的 Operator 订阅。

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

Manual(手动)

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

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

更新 Red Hat OpenShift Service Mesh Operator 时,Operator Lifecycle Manager(OLM)会删除旧的 Operator pod 并启动新的 pod。新的 Operator pod 启动后,协调过程会检查 ServiceMeshControlPlane (SMCP),如果存在可用于任何 Service Mesh control plane 组件的更新容器镜像,它会将这些 Service Mesh control plane pod 替换为使用新容器镜像的用户。

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

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

1.11.4. 升级 control plane

对于次版本和主版本,您必须手动更新 control plane。社区 Istio 项目建议进行金丝雀(Canary)升级,但 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。

升级服务网格 control plane 时,所有 Operator 受管资源(如网关)也会被升级。

虽然您可以在同一集群中部署多个 control plane 版本,但 Red Hat OpenShift Service Mesh 不支持服务网格的金丝雀升级。也就是说,您可以使用有不同的 spec.version 值的不同 SCMP 资源,但它们无法管理同一个网格。

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

1.11.4.1. 将更改从版本 2.4 升级到 2.5

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

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

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

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  gateways:
    openshiftRoute:
      enabled: true
1.11.4.1.2. Istio 代理并发配置增强

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

在以前的版本中,参数的默认设置是 2。

1.11.4.2. 将更改从 2.3 升级到 2.4 版本

将 Service Mesh control plane 从 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 连接时,需要访问使用这些密码套件的服务的应用程序将无法连接。

1.11.4.3. 将更改从 2.2 升级到 2.3

将 Service Mesh control plane 从 2.2 升级到 2.3 包括以下行为更改:

  • 此发行版本需要使用 WasmPlugin API。现在,在 2.2 中弃用的 ServiceMeshExtension API 的支持已被删除。如果您在使用 ServiceMeshExtension API 时尝试升级,则升级会失败。

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

将 Service Mesh control plane 从 2.1 升级到 2.2 引进了以下行为更改:

  • istio-node DaemonSet 被重命名为 istio-cni-node,以匹配上游 Istio 中的名称。
  • Istio 1.10 更新了 Envoy,默认使用 eth0 而不是 lo 将流量发送到应用程序容器。
  • 此发行版本添加了对 WasmPlugin API 的支持,并弃用 ServiceMeshExtension API。

1.11.4.5. 将版本 2.0 升级到 2.1 版

将 Service Mesh control plane 从 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.5

行为更改

  • AuthorizationPolicy 更新:

    • 使用 PROXY 协议时,如果您使用 ipBlocksnotIpBlocks 指定远程 IP 地址,请更新配置以使用 remoteIpBlocks 而不是 RemoteIpBlocks
    • 添加了对嵌套 JSON Web Token(JWT)声明的支持。
  • EnvoyFilter 破坏更改>

    • 必须使用 typed_config
    • XDS v2 不再被支持
    • 弃用的过滤器名称
  • 较旧版本的代理可能会在从更新的代理接收 1xx 或 204 状态代码时报告 503 状态代码。

1.11.4.6. 升级 Service Mesh control plane

要升级 Red Hat OpenShift Service Mesh,您必须更新 Red Hat OpenShift Service Mesh ServiceMeshControlPlane v2 资源的版本字段。然后,在配置和应用后,重启应用程序 pod 以更新每个 sidecar 代理及其配置。

前提条件

  • 您已在 AWS 4.9 或更高版本上运行 Red Hat OpenShift Service。
  • 您有最新的 Red Hat OpenShift Service Mesh Operator。

流程

  1. 切换到包含 ServiceMeshControlPlane 资源的项目。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

    $ oc project istio-system
  2. 检查 v2 ServiceMeshControlPlane 资源配置以验证其是否有效。

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

      $ oc get smcp -o yaml
      提示

      备份 Service Mesh control plane 配置。

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

    例如:

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

    另外,您可以使用 Web 控制台编辑 Service Mesh control plane,而不是使用命令行。在 Red Hat OpenShift Service on AWS Web 控制台中,点 Project 并选择您刚才输入的项目名称。

    1. Operators Installed Operators
    2. 查找 ServiceMeshControlPlane 实例。
    3. 选择 YAML view 并更新 YAML 文件的文本,如上例中所示。
    4. Save

1.11.4.7. 将 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 operator。如果选择了 自动 升级路径,Operator 将自动下载最新信息。但是,您必须执行一些步骤来使用 Red Hat OpenShift Service Mesh 版本 2.0 中的功能。
1.11.4.7.1. 升级 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 control plane 配置。切换到包含 ServiceMeshControlPlane 资源的项目。在本例中,istio-system 是 Service Mesh control plane 项目的名称。

    $ oc project istio-system
  3. 输入以下命令来检索当前的配置。您的 <smcp_name> 在您的 ServiceMeshControlPlane 资源元数据中指定,如 basic-installfull-install

    $ oc get servicemeshcontrolplanes.v1.maistra.io <smcp_name> -o yaml > <smcp_name>.v1.yaml
  4. ServiceMeshControlPlane 转换为 v2 control plane 版本,其包含您的配置信息作为起点。

    $ oc get smcp <smcp_name> -o yaml > <smcp_name>.v2.yaml
  5. 创建一个项目。在 Red Hat OpenShift Service on AWS 控制台项目菜单中,点 New Project,并为项目输入名称如 istio-system-upgrade。或者,您可以通过 CLI 运行这个命令。

    $ oc new-project istio-system-upgrade
  6. 使用新项目名称更新 v2 ServiceMeshControlPlane 中的 metadata.namespace 字段。在本例中,使用 istio-system-upgrade
  7. version 字段从 1.1 更新至 2.0,或将其从 v2 ServiceMeshControlPlane 中删除。
  8. 在新命名空间中创建一个 ServiceMeshControlPlane。在命令行中,运行以下命令,使用您检索的 ServiceMeshControlPlane 的 v2 版本部署 control plane。在这个示例中将 '<smcp_name.v2> ' 替换为您的文件的路径。

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

    另外,您可以使用控制台创建 Service Mesh control plane。在 Red Hat OpenShift Service on AWS web 控制台中,点 Project。然后选择您刚刚输入的项目名称。

    1. Operators Installed Operators
    2. Create ServiceMeshControlPlane
    3. 选择 YAML view,把获取的 YAML 文件的内容复制到这个项。检查 apiVersion 字段是否已设置为 maistra.io/v2,并修改 metadata.namespace 字段以使用新命名空间,如 istio-system-upgrade
    4. Create
1.11.4.7.2. 配置 2.0 ServiceMeshControlPlane

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

1.11.4.7.2.1. 构架更改

之前的版本使用的架构单元已被 Istiod 替代。在 2.0 中,Service Mesh control plane 组件 Mixer、Pilot、Citadel、Galley 和 sidecar 注入程序功能已合并为一个组件 Istiod。

虽然 Mixer 不再作为 control plane 组件支持,但 Mixer 策略和遥测插件现在可以通过 Istiodi 中的 WASM 扩展支持。如果您需要集成旧的 Mixer 插件,则可为策略和遥测启用混合程序。

安全发现服务 Service(SDS)用于直接从 Istiod 向 sidecar 分发证书和密钥。在 Red Hat OpenShift Service Mesh 1.1 中,secret 由 Citadel 生成,代理使用它来检索其客户端证书和密钥。

1.11.4.7.2.2. 注解更改

v2.0 不再支持以下注解。如果使用其中一个注解,则必须更新工作负载,然后将其移至 v2.0 Service Mesh control plane。

  • 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 Service Mesh control plane 前删除覆盖。就绪度检查仍然可以通过将状态端口设置为 0 来禁用。
  • Kubernetes Secret 资源不再用于为 sidecar 发布客户端证书。证书现在通过 Istiod 的 SDS 服务发布。如果您需要依赖挂载的 secret,则 v2.0 Service Mesh control plane 中的工作负载将无法使用它们。
1.11.4.7.2.3. 行为更改

Red Hat OpenShift Service Mesh 2.0 中的一些功能与之前的版本不同。

  • 网关上的就绪度端口已从 15020 移到 15021
  • 目标主机可见性包括 VirtualService 以及 ServiceEntry 资源。它包括所有通过 Sidecar 资源实施的限制。
  • 默认启用自动 mutual TLS。代理到代理通信会自动配置为使用 mTLS,而不管是否有全局的验证策略。
  • 当代理与 Service Mesh control plane 通讯时,无论 spec.security.controlPlane.mtls 设置如何,都始终使用安全连接。spec.security.controlPlane.mtls 设置仅在配置 Mixer 遥测或策略的连接时使用。
1.11.4.7.2.4. 不支持资源的迁移详情

Policy(策略) (authentication.istio.io/v1alpha1)不再被支持。

策略资源必须迁移到 v2.0 Service Mesh control planes、PeerAuthentication 和 RequestAuthentication 的新资源类型。根据策略资源中的具体配置,您可能需要配置多个资源来达到同样效果。

双向 TLS

使用 security.istio.io/v1beta1 PeerAuthentication 资源可以实现双向 TLS 强制。传统的 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 条目,以及与 Policy 资源中指定的 spec.origins[x].jwt.issuer 相对应的 spec.rules.[x].from.source.requestPrincipals 的条目。

ServiceMeshPolicy (maistra.io/v1)

ServiceMeshPolicy 通过 spec.istio.global.mtls.enabled(v1 资源)或 spec.security.dataPlane.mtls(v2 资源)自动为 Service Mesh control plane 配置。对于 v2 control plane,在安装过程中创建了一个功能等同的 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,因为没有可用于命名空间或工作负载的 allow-all 策略。

AuthorizationPolicy 包括配置适用的选择器的配置,它类似于 ServiceRoleBinding 提供的函数 ServiceRoleBinding,这与所提供函数 ServiceRole 相似。

ServiceMeshRbacConfig (maistra.io/v1)

这个资源由使用 Service Mesh control plane 命名空间中带有空 spec.selector 的 security.istio.io/v1beta1 AuthorizationPolicy 资源替换。该策略是应用于网格中所有工作负载的默认授权策略。如需具体迁移详情,请参阅上面的 RbacConfig。

1.11.4.7.2.5. Mixer 插件

在版本 2.0 中默认禁用 Mixer 组件。如果您的工作负载依赖 Mixer 插件,必须将 2.0 ServiceMeshControlPlane 版本配置为包含 Mixer 组件。

要启用 Mixer 策略组件,在 ServiceMeshControlPlane 中添加以下片断。

spec:
  policy:
    type: Mixer

要启用 Mixer 遥测组件,在 ServiceMeshControlPlane 中添加以下片断。

spec:
  telemetry:
    type: Mixer

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

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

1.11.4.7.2.6. 双向 TLS 的变化

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

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

有关 mTLS 的详情,请参考启用 mutual Transport Layer Security (mTLS)

1.11.4.7.2.6.1. 其他 mTLS 示例

要在 info 示例应用程序中禁用 mTLS For productpage 服务,您的 Policy 资源需要为 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

要在 info 示例应用程序中禁用 mTLS For productpage 服务,请使用以下示例为 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

为了在 info 示例应用程序中为 productpage 服务启用 mTLS,您的 Policy 资源被配置为 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

要在 info 示例应用程序中为 productpage 服务启用 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

1.11.4.7.3. 配置方案

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

1.11.4.7.3.1. data plane 中的双向 TLS

通过 ServiceMeshControlPlane 资源中的 spec.security.dataPlane.mtls 为 data plane 通信配置双向 TLS,默认为 false

1.11.4.7.3.2. 自定义签名密钥

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

1.11.4.7.3.3. Tracing

Tracing 在 spec.tracing 中配置。目前,Jaeger 是唯一支持的 tracer 类型。sampling 是一个缩放整数,代表 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"

您可以使用 install 字段自定义 Jaeger 安装。容器配置,如资源限值是在 spec.runtime.components.jaeger 相关字段中配置的。如果存在与 spec.addons.jaeger.name 值匹配的 Jaeger 资源,Service Mesh control plane 将配置为使用现有安装。使用现有的 Jaeger 资源来完全自定义 Jaeger 安装。

1.11.4.7.3.4. 视觉化

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.kialispec.runtime.components.grafana 中配置。如果存在与名称值匹配的现有 Kiali 资源,Service Mesh control plane 会配置用于 control plane 的 Kiali 资源。Kiali 资源中的一些字段会被覆盖,如 access_namespaces 列表,以及 Grafana、Prometheus 和追踪的端点。使用现有资源来完全自定义 Kiali 安装。

1.11.4.7.3.5. 资源使用和调度

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

组件描述支持的版本

安全

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

trace.jaeger

常规 Jaeger 容器 - 可能不会应用所有设置。通过在 Service Mesh control plane 配置中指定现有 Jaeger 资源,支持完全自定义 Jaeger 安装。

v1.0/1.1/2.0

trace.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

trace.jaeger.query

特定于 Jaeger 查询的设置

v1.0/1.1/2.0

prometheus

prometheus 容器

v1.0/1.1/2.0

kiali

Kiali 容器 - 通过在 Service Mesh control plane 配置中指定现有 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 - 技术预览

一些组件支持资源限制和调度。如需更多信息,请参阅性能和可扩展性

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

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

1.11.5. 升级数据平面(data plane)

升级 control plane 后,您的数据平面仍然可以正常工作。但是,为了对 Envoy 代理应用更新以及代理配置的任何更改,您必须重启应用程序 pod 和工作负载。

1.11.5.1. 更新应用程序和工作负载

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

要对部署执行滚动更新,请使用以下命令:

$ oc rollout restart <deployment>

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.