Anthos Service Mesh 控制层面修订版本

本页面介绍了控制层面修订版本的工作原理以及将这些修订版本用于安全服务网格升级（和回滚）的价值。在版本 1.6.8 之前，Anthos Service Mesh 的默认安装过程没有使用控制层面修订版本。引入修订版本可能需要耗费一些精力和修改步骤，但我们强烈建议您引入修订版本，因为它使用修订版本会带来很多好处。

服务网格基础知识

Anthos Service Mesh 安装包含两个主要部分，通常使用 install_asm 脚本自动执行。首先，使用 istioctl 命令行工具和 IstioOperator YAML 文件安装控制层面及其配置。控制层面（也称为 istiod）包含一组负责管理网格配置的系统服务。接下来，您将在整个环境中部署特殊的边车代理，用于拦截每个工作负载进出网络的通信。代理与控制层面通信以获取其配置，这允许您定向和控制网格的流量（数据层面流量），而无需对工作负载进行任何更改。

为了部署代理，您需要使用一个称为自动 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 匹配时，网络钩子会查询由 Istio 提供的注入服务，以获取 Pod 的新更改配置，其中包括运行 Sidecar 所需的容器和卷。

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

什么是修订版本？

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

在 Anthos Service Mesh 1.6.8 之前，默认安装过程已确立了一个在网络钩子中配置命名空间选择器的惯例，以使用标签：istio-injection=enabled

在当前的 Anthos Service Mesh 安装过程中，您可以使用修订版本字符串来标记已安装的控制层面，作为 istioctl 命令的 revision 参数，也作为 IstioOperator 自定义资源中的字段。安装程序使用修订版本标记每个控制层面对象，包括 istiod Service 和 Deployment。修订版本将成为服务名称的一部分，例如 istiod-asm-173-6.istio-system。

命名空间对应的标签键是 istio.io/rev，其值通常设置为指示网格版本。例如，修订版本为 asm-173-6 的控制层面会选择命名空间中带有 istio.io/rev=asm-173-6 标签的 pod，并注入 Sidecar。

Canary 升级过程

修订版本标签可让您执行 Canary 升级并轻松回滚控制层面。

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

1. 从现有的 Anthos Service Mesh 或开源 Istio 安装开始。命名空间使用的是修订版本标签还是 istio-injection=enabled 标签无关紧要。
2. 安装新版本的控制层面时，请使用修订版本字符串。由于修订版本字符串的原因，新控制层面与现有版本一起安装。新安装包括一个新的网络钩子配置，其 namespaceSelector 配置为监控具有特定修订版本标签的命名空间。
3. 您可以将 Sidecar 代理迁移到新的控制层面，方法是从命名空间中移除旧标签，添加新的修订版本标签，然后重启 Pod。如果您在 Anthos 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-173-6

选择器可能随正在运行的 Anthos Service Mesh 或 Istio 版本而有所不同。此选择器与具有特定修订版本标签的命名空间匹配，前提是它们也没有 istio-injection 标签。

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

     service:
        name: istiod-asm-173-6
        namespace: istio-system
        path: /inject
        port: 443

该服务由 inject 网址路径处的端口 443 上的 istiod 公开。

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

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

摘要

虽然切换为使用命名空间上的修订版本标签来启用自动注入功能可能需要适应，但修订版本标签可以带来安全的优势，Canary 升级值得付出努力。

后续步骤

• 安装指南
• 注入边车代理