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