Cloud Service Mesh 控制平面修订版本

注意： 本指南仅支持使用 Istio API 的 Cloud Service Mesh，不支持 Google Cloud API。如需了解详情，请参阅 Cloud Service Mesh 概览。

本页面适用于集群内和托管式 ISTIOD 控制平面实现。本页不适用于 TRAFFIC_DIRECTOR 控制平面实现，后者是一种多租户全球控制平面，没有单独的修订版本。

本页面介绍了控制层面修订版本的工作原理以及将这些修订版本用于安全服务网格升级（和回滚）的价值。

服务网格安装基础知识

概括来讲，Cloud Service Mesh 安装包括两个主要阶段：

1. 首先，使用 asmcli 工具安装集群内控制平面或配置代管式控制平面。控制平面包含一组负责管理网格配置的系统服务。

2. 接下来，您将在整个环境中部署特殊的边车代理，用于拦截每个工作负载进出网络的通信。代理与控制层面通信以获取其配置，这允许您定向和控制网格的流量（数据层面流量），而无需对工作负载进行任何更改。

   为了部署代理，您需要使用一个称为自动 Sidecar 注入（自动注入）的过程，将代理作为每个工作负载 Pod 中的补充 Sidecar 容器进行运行。您无需修改用于部署工作负载的 Kubernetes 清单，但需要将标签添加到命名空间并重启 Pod。

使用修订版本安全地升级网格

控制流量的能力是使用服务网格的一个主要好处。例如，首次将应用部署到生产环境时，您可以逐渐将流量转移到新版应用。如果您在升级期间检测到问题，则可以将流量迁移回原始版本，从而提供了一种简单、低风险的回滚方法。此过程称为 Canary 版本，它将大幅降低与新部署相关的风险。

注意：另一种类型的升级是就地升级，即通过安装新版本的控制平面进行升级。新的控制层面版本会立即替换旧版本。就地升级存在风险，因为如果发生故障，回滚可能很困难。如需重新注入代理并让它们与新的控制层面版本通信，您必须重启所有命名空间中的所有工作负载。根据网格中的工作负载和命名空间的数量，整个升级过程可能需要一个小时或更长时间。就地升级可能会导致停机，并且应安排在维护窗口。

在 Canary 版升级中使用控制层面修订版本时，您将在现有控制层面的基础上安装单独的新控制层面和配置。安装程序会分配一个称为修订版本的字符串，用于标识新的控制层面。最初，边车代理会继续接收旧版控制层面的配置。您可以为工作负载的命名空间或 Pod 添加新控制平面修订版本标签，以逐步将工作负载与新控制平面相关联。为命名空间或 Pod 添加新修订版本标签后，您需要重启工作负载 Pod 以自动注入新的 Sidecar，然后它们会从新控制平面接收其配置。如果出现问题，您可以将工作负载与之前的控制平面关联，从而轻松回滚。

自动注入的工作原理

自动注入功能使用名为准入控制的 Kubernetes 功能。注册更改准入网络钩子是为了监控新创建的 Pod。此网络钩子配置了命名空间选择器，使其仅匹配正在部署到具有特定标签的命名空间的 Pod。Pod 匹配时，网络钩子会查询由控制层面提供的注入服务，以获取 Pod 的新更改配置，其中包括运行 Sidecar 所需的容器和卷。

1. 在安装过程中会创建网络钩子配置。该网络钩子已在 Kubernetes API 服务器中注册。
2. Kubernetes API 服务器会在与网络钩子 namespaceSelector 匹配的命名空间中查找 Pod 部署。
3. 命名空间已加标签，以便它将通过 namespaceSelector 匹配。
4. 部署到命名空间的 Pod 会触发网络钩子。
5. 控制层面提供的 inject 服务会更改 Pod 规范以自动注入 Sidecar。

什么是修订版本？

用于自动注入的标签与其他任何用户定义的 Kubernetes 标签类似。标签本质上是一个键值对，可用于支持加标签的概念。标签广泛用于标记和修订版本。例如，Git 标记、Docker 标记和 Knative 修订版本。

在当前的 Cloud Service Mesh 安装过程中，您可以使用修订版本字符串标记已安装的控制平面。安装程序使用修订版本标记每个控制平面对象。键值对中的键是 istio.io/rev，但代管式控制平面和集群内控制平面的修订版本标签的值不同。

• 对于集群内控制平面，istiod Service 和 Deployment 通常具有类似于 istio.io/rev=asm-1215-12 的修订版本标签，其中 asm-1215-12 用于标识 Cloud Service Mesh 版本。修订版本将成为服务名称的一部分，例如 istiod-asm-1215-12.istio-system。

• 对于代管式控制层面，修订版本标签对应于发布渠道：

  修订版本标签	渠道
  istio.io/rev=asm-managed	普通
  istio.io/rev=asm-managed-rapid	快速
  istio.io/rev=asm-managed-stable	稳定版

此外，您还可以选择使用默认注入标签（例如 istio-injection=enabled）。

如需启用自动注入功能，请向命名空间添加与控制平面上的修订版本标签匹配的修订版本标签。例如，修订版本为 istio.io/rev=asm-1215-12 的控制层面会选择命名空间中带有 istio.io/rev=asm-1215-12 标签的 pod，并注入 Sidecar。

Canary 升级过程

通过修订版本标签，可以执行 Canary 版升级并轻松回滚集群内控制平面。代管式控制采用类似的过程，但您的集群会自动升级到该渠道中的最新版本。

以下步骤描述了此流程的工作原理：

1. 从现有的 Cloud Service Mesh 或开源 Istio 安装开始。命名空间使用的是修订版本标签还是 istio-injection=enabled 标签无关紧要。
2. 安装新版本的控制层面时，请使用修订版本字符串。由于修订版本字符串的原因，新控制层面与现有版本一起安装。新安装包括一个新的网络钩子配置，其 namespaceSelector 配置为监控具有特定修订版本标签的命名空间。
3. 您可以将 Sidecar 代理迁移到新的控制层面，方法是从命名空间中移除旧标签，添加新的修订版本标签，然后重启 Pod。如果您在 Cloud Service Mesh 中使用修订版本，则必须停止使用 istio-injection=enabled 标签。具有修订版本的控制层面不会选择具有 istio-injection 标签的命名空间中的 Pod，即使存在修订版本标签也是如此。新控制层面的网络钩子会将 Sidecar 注入 Pod 中。
4. 仔细测试与升级后的控制层面相关的工作负载，然后继续发布升级或回滚到原始控制层面。

将 Pod 与新控制层面关联后，现有控制层面和网络钩子仍然安装。旧网络钩子不会影响已迁移至新控制层面的 Pod。您可以通过移除新的修订版本标签，重新添加原始标签并重启 Pod，将命名空间中的 Pod 回滚到原始控制层面。如果您确定升级完成，则可以移除旧的控制层面。

如需查看使用修订版本升级的详细步骤，请参阅升级指南。

仔细查看变更网络钩子配置

为了更好地了解自动 Sidecar 注入的变更网络钩子，请自行检查配置。使用以下命令：

kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml

您应该会看到您安装的每个控制层面的单独配置。基于修订版本的控制层面的命名空间选择器如下所示：

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-1215-12

选择器可能因您运行的 Cloud Service Mesh 或 Istio 版本而异。此选择器与具有特定修订版本标签的命名空间匹配，前提是它们也没有 istio-injection 标签。

将 Pod 部署到与选择器匹配的命名空间时，其 Pod 规范将提交给注入器服务进行更改。要调用的注入器服务按如下方式指定：

     service:
        name: istiod-asm-1215-12
        namespace: istio-system
        path: /inject
        port: 443

注意： 对于托管式 Cloud Service Mesh，Google 代管式服务由 url:（而不是 service:）指定。

该服务由控制层面通过端口 443 在 inject 网址路径公开。

rules 部分指定网络钩子应该应用于 Pod 创建过程：

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

后续步骤

• 升级 Cloud Service Mesh
• 注入 Sidecar 代理