本页面介绍了控制层面修订版本的工作原理以及将这些修订版本用于安全服务网格升级（和回滚）的价值。在版本 1.6.8 之前，Anthos Service Mesh 的默认安装过程没有使用控制层面修订版本。引入修订版本可能需要耗费一些精力和修改步骤，但我们强烈建议您引入修订版本，因为它使用修订版本会带来很多好处。
服务网格基础知识
Anthos Service Mesh 安装包含两个主要部分：首先使用 istioctl 命令行工具或 install_asm 脚本安装集群内控制层面，或者配置 Google 管理的控制层面。控制层面包含一组负责管理网格配置的系统服务。接下来，您将在整个环境中部署特殊的边车代理，用于拦截每个工作负载进出网络的通信。代理与控制层面通信以获取其配置，这允许您定向和控制网格的流量（数据层面流量），而无需对工作负载进行任何更改。
为了部署代理，您需要使用一个称为自动 Sidecar 注入（自动注入）的过程，将代理作为每个工作负载 Pod 中的补充 Sidecar 容器进行运行。您无需修改用于部署工作负载的 Kubernetes 清单，但需要将标签添加到命名空间并重启 Pod。
在 Anthos Service Mesh 1.6 之前，您可以通过安装新版控制层面来进行升级，而该版本会立即取代旧版本。此过程称为就地升级，但存在风险，因为如果发生故障，回滚可能会很困难。如需重新注入代理并让它们与新的控制层面版本通信，您必须重启所有命名空间中的所有工作负载。根据网格中的工作负载和命名空间的数量，整个升级过程可能需要一个小时或更长时间。就地升级可能会导致停机，并且应安排在维护期。
使用修订版本安全地升级网格
控制流量的能力是使用服务网格的一个主要好处。例如，首次将应用部署到生产环境时，您可以逐渐将流量转移到新版应用。如果您在升级期间检测到问题，则可以将流量迁移回原始版本，从而提供了一种简单、低风险的回滚方法。此过程称为 Canary 版本，它将大幅降低与新部署相关的风险。
同样，您可以最大限度地降低与升级服务网格本身相关的风险。Anthos Service Mesh 1.6 及更高版本支持使用控制层面修订版本进行 Canary 升级。使用 Canary 升级时，您将在现有控制平面的基础上安装单独的新控制层面和配置。安装程序会分配一个称为修订版本的字符串，用于标识新的控制层面。最初，Sidecar 代理会继续接收旧版控制层面的配置。您可以为工作负载的命名空间添加新控制层面修订版本标签，以逐步将工作负载与新控制平面相关联。为命名空间添加新修订版本标签后，您需要重启工作负载 pod 以注入新的 Sidecar，然后它们会从新控制层面接收其配置。如果出现问题，您可以将工作负载与之前的控制层面关联，从而轻松回滚。
自动注入的工作原理
自动注入功能使用名为准入控制的 Kubernetes 功能。注册更改准入网络钩子是为了监控新创建的 Pod。此网络钩子配置了命名空间选择器，使其仅匹配正在部署到具有特定标签的命名空间的 Pod。Pod 匹配时，网络钩子会查询由控制层面提供的注入服务，以获取 Pod 的新更改配置，其中包括运行 Sidecar 所需的容器和卷。
- 在安装过程中会创建网络钩子配置。向 Kubernetes API 服务器注册网络钩子。
- Kubernetes API 服务器会在与网络钩子
namespaceSelector匹配的命名空间中查找 Pod 部署。 - 命名空间已加标签，以便它将通过
namespaceSelector匹配。 - 部署到命名空间的 Pod 会触发网络钩子。
- 控制层面提供的
inject服务会更改 Pod 规范以注入 Sidecar。
什么是修订版本？
用于自动注入的标签与其他任何用户定义的 Kubernetes 标签类似。标签本质上是一个键值对，可用于支持标记概念。标签广泛用于标记和修订版本，例如 Git 标记、Docker 标记和 Knative 修订版本。
在 Anthos Service Mesh 1.6.8 之前，默认安装过程已确立了一个在网络钩子中配置命名空间选择器的惯例，以使用标签：istio-injection=enabled
在当前的 Anthos Service Mesh 安装过程中，您可以使用修订版本字符串标记已安装的控制平面。安装程序使用修订版本标记每个控制层面对象。键值对中的键是 istio.io/rev，但 Google 管理的控制层面和集群内控制层面的修订版本标签的值不同。
对于集群内控制层面，
istiodService 和 Deployment 具有一个类似于istio.io/rev=asm-198-6的修订版本标签，其中asm-198-6标识 Anthos Service Mesh 版本。修订版本将成为服务名称的一部分，例如istiod-asm-198-6.istio-system。对于 Google 管理的控制层面，修订版本标签对应于发布渠道：
修订版本标签 渠道 istio.io/rev=asm-managed普通 istio.io/rev=asm-managed-rapid快速 istio.io/rev=asm-managed-stable稳定版
如需启用自动注入功能，请向命名空间添加与控制平面上的修订版本标签匹配的修订版本标签。例如，修订版本为 istio.io/rev=asm-198-6 的控制平面会选择命名空间中带有 istio.io/rev=asm-198-6 标签的 Pod，并注入边车代理。
Canary 升级过程
通过修订版本标签，可以执行 Canary 版升级并轻松回滚集群内控制层面。Google 管理的控制采用类似的过程，但您的集群会自动升级到该渠道中的最新版本。
以下步骤描述了此流程的工作原理：
- 从现有的 Anthos Service Mesh 或开源 Istio 安装开始。命名空间使用的是修订版本标签还是
istio-injection=enabled标签无关紧要。 - 安装新版本的控制层面时，请使用修订版本字符串。由于修订版本字符串的原因，新控制层面与现有版本一起安装。新安装包括一个新的网络钩子配置，其
namespaceSelector配置为监控具有特定修订版本标签的命名空间。 - 您可以将 Sidecar 代理迁移到新的控制层面，方法是从命名空间中移除旧标签，添加新的修订版本标签，然后重启 Pod。如果您在 Anthos Service Mesh 中使用修订版本，则必须停止使用
istio-injection=enabled标签。具有修订版本的控制层面不会选择具有istio-injection标签的命名空间中的 Pod，即使存在修订版本标签也是如此。新控制层面的网络钩子会将 Sidecar 注入 Pod 中。 - 仔细测试与升级后的控制层面相关的工作负载，然后继续发布升级或回滚到原始控制层面。
将 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-173-6
选择器可能随正在运行的 Anthos Service Mesh 或 Istio 版本而有所不同。此选择器与具有特定修订版本标签的命名空间匹配，前提是它们也没有 istio-injection 标签。
将 Pod 部署到与选择器匹配的命名空间时，其 Pod 规范将提交给注入器服务进行更改。要调用的注入器服务按如下方式指定：
service:
name: istiod-asm-173-6
namespace: istio-system
path: /inject
port: 443
该服务由控制层面通过端口 443 在 inject 网址路径公开。
rules 部分指定网络钩子应该应用于 Pod 创建过程：
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
scope: '*'
摘要
虽然切换为使用命名空间上的修订版本标签来启用自动注入功能可能需要适应，但修订版本标签可以带来安全的优势，Canary 升级值得付出努力。