使用 Anthos Config Management 安全发布

本文档说明了集群运营商和平台管理员如何利用 Anthos Config Management 在多个环境中安全地推出更改。Anthos Config Management 可以帮助您避免同时影响所有环境的错误。

借助 Anthos Config Management,您可以使用存储在 Git 代码库中的文件来管理单个集群、多租户集群和多集群 Kubernetes 配置。Anthos Config Management 整合了三种技术:Config SyncPolicy ControllerConfig Connector。Config Sync 会监控 Git 代码库中所有文件的更新,并自动将更改应用于所有相关集群。政策控制器会管理和强制执行集群中对象的政策。Config Connector 使用 Google Kubernetes Engine (GKE) 自定义资源来管理云资源。

Config Sync 配置可以代表的包括以下各项:

Anthos Config Management 特别适合部署运行在 Anthos 上构建的平台所需的配置、政策和工作负载,例如安全代理、监控代理和证书管理器。

虽然您可以使用 Anthos Config Management 部署面向用户的应用,但我们不建议将其发布生命周期链接到前面提到的管理工作负载的发布生命周期。相反,我们建议您使用专用于应用部署的工具(如持续部署工具),以便应用团队可以负责其发布时间表。

Anthos Config Management 是一款功能强大的产品,它可以管理许多元素,因此您需要使用保护措施,以避免产生重大影响的错误。本文档介绍了创建保护措施的几种方法。第一部分介绍分阶段发布,第二部分重点介绍测试和验证,第三部分介绍了如何使用政策控制器创建保护措施。第四部分介绍了如何监控 Anthos Config Management 部署。

即使仅使用 Config Sync 而不使用完整的 Anthos Config Management 产品,也可以使用本文档中讨论的大多数方法。如果您未使用完整的 Anthos Config Management 产品,但仍想实现与政策控制器相关的方法,则可以成功使用 Gatekeeper。此规则的例外情况是依赖于 Google Cloud Console 中 Anthos Config Management 页面的方法,例如更新 Google Cloud Console 中的 Anthos Config Management 配置。您可以同时使用本文档介绍的多种方法。在下面的部分中,表格指明了哪些方法可以同时使用。

使用 Anthos Config Management 实现分阶段发布

在多集群环境中(这是Anthos用户的常见情况),我们不建议同时在所有集群中应用配置更改。分阶段发布,每个集群(如果您使用命名空间作为应用之间的边界,甚至是每个命名空间)的安全性要好得多,因为这样可以缩短所有错误的影响半径。

您可以通过以下方式使用 Anthos Config Management 实现分阶段发布:

  • 使用 Git 提交或标记来手动将所需的更改应用到集群。
  • 在合并更改时,使用 Git 分支自动应用更改。您可以将不同的分支用于不同的集群组。
  • 使用 ClusterSelectorNamespaceSelector 对象选择性地将更改应用于集群或命名空间的子组。

分阶段发布的所有方法都各有利弊。下表显示了您可以同时使用哪些方法。

X 与 Y 兼容吗? Git 提交或标记 Git 分支 集群选择器 命名空间选择器
Git 提交或标记 不兼容 兼容 兼容
Git 分支 不兼容 兼容 兼容
集群选择器 兼容 兼容 兼容
命名空间选择器 兼容 兼容 兼容

以下决策树可帮助您确定何时使用某一种分阶段发布方法。

适用于发布方法的决策树。

使用 Git 提交或标记

与其他分阶段发布方法相比,使用 Git 提交或标记提供最大的控制,这是最安全的。您可以使用控制台中的“Anthos Config Management”页面同时更新多个集群。如果要逐个对集群应用更改,并精确控制发生更改的时间,请使用此方法。

在此方法中,您需要将每个集群固定到 Anthos Config Management 代码库的特定版本(提交或标记)。此方法与使用 Git 提交作为容器映像标记类似。您可以通过在 ConfigManagement 自定义资源spec.git.syncRev 字段中指定提交或标记来实现此方法。如果您从多个存储库同步配置,则可以通过更新 RootSyncRepoSync 自定义资源来实现此方法。如需详细了解配置字段,请参阅配置运算符。如果您使用 kustomize 等工具来管理 ConfigManagement 自定义资源,则可以减少发布更改所需的手动工作量。借助此类工具,您只需在一个位置更改 syncRev 参数,然后有选择地按照您选择的顺序和速度将新的 ConfigManagement 自定义资源应用到您的集群。

此外,如果您使用的是 Anthos Config Management(而不是 Config Sync),则可以访问 Google Cloud console 中的 Anthos Config Management 页面。本页面可让您同时更新属于同一 environ 的多个集群的 syncRev 参数。 如果您使用自动化系统来更新 Anthos Config Management 配置,我们建议您不要使用控制台来更改此配置。

例如,以下 ConfigManagement 定义将 Anthos Config Management 配置为使用 1.2.3 标记:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
  git:
    syncRepo: git@example.com:anthos/config-management.git
    # Pin the cluster using a tag
    syncRev: 1.2.3
    secretType: ssh

如果您将此配置应用于集群,Anthos Config Management 将使用 example.com:anthos/config-management.git 代码库的 1.2.3 标记。

如需更新集群,请将 spec.git.syncRev 字段更改为集群的新值。这让您可以定义更新哪些集群以及何时更新。如果需要回滚更改,请将 spec.git.syncRev 字段更改回其原值。

下图展示了此方法的发布过程。首先,您将提交对 Anthos Config Management 代码库的更改,然后更新所有集群上的 ConfigManagement 定义:

Git 提交和标记的发布流程。

我们建议您执行以下操作:

  • 使用 Git 提交 ID,而非标记。由于 Git 运行的方式,可以保证其永远不会更改。例如,git push --force 无法更改 Anthos Config Management 使用的提交。此方法适合用于审核目的,并可以跟踪日志中正在使用的提交。此外,与标记不同,提交 ID 还无需执行额外的步骤。
  • 如果您更愿意使用 Git 标记而不是 Git 提交 ID,并且您使用的是 GitLab,请保护标记以防止其被移动或删除。其他主要 Git 解决方案没有此功能。
  • 如果您想同时更新多个集群,则可以在 Anthos Config Management 控制台页面中执行此操作。如需一次性更新多个集群,这些集群需要属于同一 Environ (并且位于同一项目中)。

使用 Git 分支

如果您希望将更改合并到 Git 代码库中后立即将其应用到群集,请将 Anthos Config Management 配置为使用 Git 分支,而不是提交或标记。在此方法中,您可以在 Git 代码库中创建多个长期分支,并在不同集群中配置 Anthos Config Management 以从不同的分支读取其配置。

例如,一个简单的模式有两个分支:

  • 非生产集群的 staging 分支。
  • 生产集群的 master 分支。

对于非生产集群,请创建 ConfigManagement 对象,并将 spec.git.syncBranch 字段设置为 staging。对于生产集群,请创建 ConfigManagement 对象,并将 spec.git.syncBranch 参数设置为 master。如果您从多个存储库同步配置,请改为在 RootSyncRepoSync 自定义资源中进行此配置。如需了解详情,请参阅配置运算符

例如,以下 ConfigManagement 定义将 Anthos Config Management 配置为使用 master 分支:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
  git:
    syncRepo: git@example.com:anthos/config-management.git
    # This cluster will apply the configuration
    # available on the master branch.
    syncBranch: master
    secretType: ssh

下图展示了此方法的发布过程:

Git 分支的发布过程。

您可以使用两个以上的分支,或者使用映射到环境之外的其他分支,调整此模式以满足特定的需求。如果需要回滚更改,请使用 git revert 命令在同一分支上创建一个新的提交,该分支将从以前的提交中恢复更改。

我们建议您执行以下操作:

  • 处理多个集群时,请至少使用两个 Git 分支来帮助区分生产集群和非生产集群。
  • 大多数 Git 解决方案都可让您使用受保护的分支功能以防止这些分支的删除或未经审核的更改。如需了解详情,请参阅 GitHubGitLabBitbucket 的文档部分。

使用 ClusterSelector 和 NamespaceSelector 对象

Git 分支是跨多个集群进行分阶段发布更改的好方法,这些集群最终都将拥有相同的政策。但是,如果只想对集群或命名空间的子集发布更改,请使用 ClusterSelectorNamespaceSelector 对象。这些对象具有类似的目标:通过这些对象,您可以将其仅应用于具有特定标签的集群或命名空间。

例如:

  • 通过使用 ClusterSelector 对象,您可以根据群集所在的国家/地区,针对不同的合规性制度将不同的政策应用于群集。
  • 通过使用 NamespaceSelector 对象,您可以将不同的政策应用于内部团队和外部承包商使用的命名空间。

此外,您还可以使用 ClusterSelectorNamespaceSelector 对象实现高级测试和发布方法,例如:

  • Canary 版本的政策,可让您将新政策部署到一小部分集群和命名空间,以长期研究该政策的影响。
  • A/B 测试,可让您将同一政策的不同版本部署到不同的集群,从而研究政策版本的影响的差异,然后选择最佳版本在所有位置进行部署。

例如,假设一个组织有多个生产集群。平台团队已经使用 Anthos Config Management、ClusterClusterSelector 对象创建了两类生产集群,分别名为 canary-prodprod(请参阅仅配置部分集群)。

平台团队希望通过政策控制器发布政策,以在命名空间上强制显示团队标签,从而便于识别每个命名空间所属的团队。我们已经在试运行模式下推出了此政策的一个版本,现在希望在少数集群上执行此政策。通过使用 ClusterSelector 对象,它们可以创建两个不同的 K8sRequiredLabels 资源,这些资源将应用于不同的集群。

  • K8sRequiredLabels 资源适用于类型为 prod 的集群,并将 enforcementAction 参数设置为 dryrun

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-team
      annotations:
        configmanagement.gke.io/cluster-selector: prod
    Spec:
      enforcementAction: dryrun
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Namespace"]
      parameters:
        labels:
          - key: "team"
    
  • K8sRequiredLabels 资源适用于类型为 canary-prod 的集群,而不使用 enforcementAction 参数,这意味着政策实际上会被强制执行:

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-team
      annotations:
        configmanagement.gke.io/cluster-selector: canary-prod
    spec:
      match:
        kinds:
          - apiGroups: [""]
        kinds: ["Namespace"]
      parameters:
        labels:
          - key: "team"
    

configmanagement.gke.io/cluster-selector 注释允许团队仅在类型为 canary-prod 的集群中强制执行政策,从而防止任何意外副作用传播到整个生产环境。如需详细了解政策控制器的试运行功能,请参阅创建限制条件

我们建议您执行以下操作:

  • 如果您需要对集群或命名空间的一部分无限期地或很长一段时间应用配置更改,请使用 ClusterSelectorNamespaceSelector 对象。
  • 如果您使用选择器来发布更改,请务必小心。如果您使用 Git 提交,则任何错误一次仅影响一个集群,因为您是逐个发布集群的。但如果使用 Git 分支,则任何错误都可能会影响使用该分支的所有集群。如果使用选择器,错误可能会立即影响所有集群。

实施审核、测试和验证

Anthos Config Management 的优势之一在于它可以声明式地管理一切—Kubernetes 资源、云资源和政策。这意味着来源控制管理系统中的文件代表资源(在 Anthos Config Management 情况下,Git 文件)。借助此特性,您可以实现已用于应用的源代码的开发工作流:审核和自动化测试。

实施审核

由于 Anthos Config Management 基于 Git,因此您可以使用首选 Git 解决方案来托管 Anthos Config Management 代码库。您的 Git 解决方案可能具有代码审核功能,您可以使用该功能审核对 Anthos Config Management 代码库所做的更改。

审核 Anthos Config Management 代码库更改的最佳做法与普通代码审核相同,如下所示:

由于 Anthos Config Management 代码库的敏感性,我们还建议您尽可能使用 Git 解决方案进行以下配置:

通过使用这些不同的功能,您可以将针对 Anthos Config Management 代码库的每个更改请求强制执行审批。例如,您可以确保每个更改都至少由平台团队的成员(负责运行集群群的成员)以及安全团队的成员(负责定义并实现安全政策的成员)批准。

我们建议您执行以下操作:

  • 对 Anthos Config Management 代码库强制执行对等审核,并保护您的集群使用的 Git 分支。

实施自动化测试

对代码库进行操作时,通常的最佳做法是实施持续集成。这意味着您要将自动化测试配置为在创建或更新更改请求时运行。在人工审核更改请求之前,自动化测试可以捕获许多错误。这样可以加强开发者的反馈环。您可以使用相同的工具为 Anthos Config Management 代码库实现相同的想法。

例如,一个不错的起点是在新更改上自动运行 nomos vet 命令。此命令验证您的 Anthos Config Management 代码库的语法是否有效。您可以按照验证配置教程来使用 Cloud Build 实现此测试。您可以将 Cloud Build 与以下选项集成:

正如验证配置教程中所示的,测试是使用容器映像完成的。因此,您可以在运行容器(而不仅仅是 Cloud Build)的任何持续集成解决方案中实施测试。具体来说,您可以使用 GitLab 持续集成实施测试,遵循此示例,其中也包括政策控制器的测试。

为了进一步缩小反馈环,您可以要求用户以 Git 预提交钩子运行 nomos vet 命令。但需要注意的是,一些用户可能无权访问由 Anthos Config Management 管理的 Kubernetes 集群,他们可能无法从工作站运行完整验证。运行 nomos vet --clusters "" 命令,将验证限制为语义和语法检查。

您可以实现您认为有必要或有用的任何其他测试。如果您使用政策控制器,则可以针对其政策实现对建议更改的自动测试,如针对政策控制器政策的更改测试中所述。

我们建议您执行以下操作:

  • 在持续集成流水线中实施测试。对所有建议的更改至少运行 nomos vet 命令。

使用政策控制器

政策控制器是 Kubernetes 动态准入控制器。安装和配置政策控制器时,Kubernetes 可以拒绝不符合预定义规则(称为政策)的更改。

以下是政策控制器的两个示例用例:

  • 强制在 Kubernetes 对象上显示特定标签,
  • 阻止创建特权 pod。

政策模板库可用于实现最常用的政策,但您可以使用名为 Rego 的强大语言编写自己的模板。例如,使用政策控制器时,您可以限制用户可以在入站中配置的主机名(如需了解详情,请参阅此教程)。

与 Config Sync 一样,政策控制器也是 Anthos Config Management 产品的一部分。政策控制器和 Config Sync 具有不同的但互补的用例,如下所示:

  • Config Sync 是一种 GitOps 样式的工具,可让您同时在多个集群中创建任何 Kubernetes 对象。正如简介中所述,Config Sync 特别适用于管理政策。
  • 借助政策控制器,您可以为可在 Kubernetes 中创建的对象定义政策。您可以在自定义资源(是 Kubernetes 对象本身)中定义这些政策。

上述功能是两个应用之间的双向关系。您可以使用 Config Sync 创建受政策控制器强制执行的政策,并且可以使用这些政策来精准控制 Config Sync(或任何其他进程)可以创建哪些对象,如下图所示:

Config Sync 和政策控制器。

Git 代码库、Config Sync、政策控制器、Kubernetes、持续部署 (CD) 系统和用户均通过以下方式相互交互:

  • 用户与 Anthos Config Management Git 代码库进行交互,以创建、更新或删除 Kubernetes 对象。
  • Config Sync 从 Anthos Config Management Git 代码库读取其配置。
  • Config Sync 与 Kubernetes API 服务器交互以创建对象,其中包括政策控制器的政策。
  • 持续交付系统还与 Kubernetes API 服务器交互以创建对象。它可以为政策控制器创建限制条件。但是,我们建议您针对此用例使用 Anthos Config Management,因为它为您提供了一个集中的地方来管理和测试限制条件。
  • Kubernetes API 服务器根据政策控制器的响应,通过 Config Sync 和持续交付系统接受或拒绝对象的创建。
  • 政策控制器会根据其从 Kubernetes API 服务器读取的政策给出响应。

下图演示了这些互动:

Git 代码库、Config Sync、政策控制器、Kubernetes(持续部署系统)和用户之间的互动。

政策控制器可以防止逃避人工审核者和自动测试的政策违反行为,因此您可以将其视为 Kubernetes 集群的最后一道防线。随着 Anthos Config Management 的人工审核者人员数量增加,政策控制器也会变得更加有用。由于社会惰化现象,您拥有的审核者越多,他们持续执行组织中定义的规则的可能性就越小。

针对政策控制器政策的更改进行测试

如果您使用政策控制器,则可以向持续集成流水线添加一些步骤(请参阅实施自动化测试),以针对政策自动测试所建议的更改。自动执行测试可让提出更改建议的用户更快、更清楚地看到反馈。如果您未针对持续集成流水线中的政策测试更改,则必须依靠监控发布中所述的系统来接收 Anthos Config Management 同步错误的提醒。通过根据政策测试这些更改,您可以尽早向提出更改建议的人员清晰地披露所有违规行为。

您可以依据在持续集成流水线中使用政策控制器教程在 Cloud Build 中实现此测试。如前面的实现自动化测试中所述,您可以将 Cloud Build 与 GitHub 和 Bitbucket 集成。您还可以使用 GitLab 持续集成实现此测试。如需查看实现示例,请参阅此代码库

我们建议您执行以下操作:

  • 如果使用政策控制器,请在持续集成流水线中针对其政策验证建议的更改。

监控发布

即使您实施了本文档涵盖的所有安全措施,也仍然可能出现错误。以下是两种常见的错误类型:

  • 不会导致 Config Sync 本身出现问题,但会妨碍工作负载正常运行的错误,例如因过于限制 NetworkPolicy 会阻止工作负载的组件进行通信。
  • 导致 Config Sync 无法将更改应用到集群的错误,例如无效的 Kubernetes 清单或准入控制器拒绝的对象。之前介绍的方法应该可以捕获大多数此类错误。

在 Anthos Config Management 级别检测前面第一项目符号中描述的错误几乎是不可能的,因为这需要了解每个工作负载的状态。因此,最好通过现有监控系统来检测这些错误,以便在应用出现异常时收到提醒。

检测前面的第二项目符号(如果您已实施所有的保护措施,这应该很少见)中所述的错误需要特定的设置。默认情况下,Anthos Config Management 会向其日志写入错误(默认情况下,您会在 Cloud Logging 中找到)。Anthos Config Management 控制台页面中也会显示错误。日志和控制台通常都不足以检测错误,因为您可能不会一直监视它们。自动错误检测的最简单方法是运行 nomos status 命令,该命令说明了集群中是否出现错误。

您还可以设置更高级的解决方案,并针对错误自动发出提醒。Anthos Config Management 以 Prometheus 格式公开指标。您可以使用 Prometheus 抓取这些指标,还可以配置 Prometheus 指标导入到 Cloud Monitoring,或者可以使用与 Prometheus 格式兼容的任何监控解决方案。如需了解详情,请参阅监控 Anthos Config Management

在监控系统中拥有 Anthos Config Management 指标后,创建提醒,以便在 gkeconfig_monitor_errors 指标大于 0 时收到通知。如需了解详情,请参阅 Cloud Monitoring 的管理提醒政策或 Prometheus 的提醒规则

使用 Anthos Config Management 安全发布的机制的摘要

下表总结了本文档前面描述的各种机制。这些机制都不是互斥的。您可以选择使用其中的少部分或全部用于不同目的。

机制 适合的场景 不适合的场景 用例示例
Git 提交 ID 和标记 使用特定的 Git 提交 ID 或标记来精确控制集群更改的应用。 请勿对集群之间长期存在的差异使用 Git 提交 ID 或标记。使用集群选择器。 所有集群都配置为应用 12345 Git 提交。使用要测试的新提交 abcdef 进行更改。您可以更改单个集群的配置,以使用此新提交来验证更改。
Git 分支 如果要将相同的更改发布到多个环境,请依次使用多个 Git 分支。 请勿对集群之间长期存在的差异使用多个 Git 分支。分支将出现明显分化,并且很难合并回去。 首先在暂存分支中合并更改,然后由暂存群集在其中进行选择。
然后在主分支中合并更改,生产集群将在其中进行选择。
集群选择器和命名空间选择器 针对集群和命名空间之间长期存在的差异使用选择器。 请勿将选择器用于跨多个环境的分阶段发布。如果您想在暂存时先测试修改,然后再将其部署到生产环境中,请使用单独的 Git 分支。 如果应用团队需要对开发集群的完整访问权限,但对生产集群只需要只读权限,请使用 ClusterSelector 对象将正确的 RBAC 政策仅应用于相关集群。
对等审核 使用对等审核,确保相关团队批准更改。 人工审核者并非能发现所有错误,尤其是语法错误等内容。 您的组织要求安全团队必须审核会影响多个系统的配置更改。让安全团队成员审核更改。
持续集成流水线中的自动化测试 使用自动化测试来发现建议的更改中出现的错误。 自动化测试无法完全替代人工审核者。同时使用 在所有建议的更改上运行 nomos vet 命令会确认代码库是有效的 Anthos Config Management 配置。
政策控制器 强制执行组织级政策,并直接在 Kubernetes API 服务器级层实施安全措施。 政策控制器不能用于创建、更新或删除政策(这是 Anthos Config Management 的角色)。政策控制器只能强制执行政策。 安全团队使用 Anthos Config Management 创建政策控制器限制条件,以防止用户创建特权容器,即使在直接由应用团队管理的命名空间中也是如此。
针对政策控制器限制条件的更改进行测试。 确保 Anthos Config Management 应用更改时,政策控制器不会拒绝更改。 在持续集成流水线中针对政策控制器限制条件的更改进行测试并非在集群上启用政策控制器的替代。 每个命名空间都必须具有“团队”标签以标识其所有者。用户想要创建新的命名空间,并忘记在其建议的更改中添加此标签。在人工审核更改之前,持续集成流水线可以捕获错误。
监控同步错误 确保 Anthos Config Management 实际将更改应用到集群。 仅当 Anthos Config Management 尝试应用无效代码库或 Kubernetes API 服务器拒绝某些对象时,才会发生同步错误。如果您尚未在政策控制器政策中编码所有限制条件,则不会检测到违反这些限制条件的资源。 用户绕过所有测试并审核,并将无效更改提交到 Anthos Config Management 代码库。此更改无法应用于您的集群。如果您监控的是同步错误,则会在发生错误时收到提醒。

发布策略示例

此部分使用本文其余部分中介绍的概念,帮助您为组织中的所有集群创建端到端发布策略。此策略假设您拥有开发、预演和生产方面的单独环境(如 Environ 示例 1 - 方法 1 中所示)。

在此场景中,您可以使用特定的 Git 提交内容将每个集群配置为与 Anthos Config Management Gitit 代码库同步。将更改部署到给定 Environ 分为 4 个步骤:

  1. 首先更新环境中的单个(“Canary”)集群以使用新提交。
  2. 您可以通过运行测试监控发布来验证一切是否按预期运行。
  3. 您将更新环境中的其他集群。
  4. 您可以再次验证一切是否按预期运行。

如需在所有集群中部署更改,请为每个环境重复此过程。从技术上讲,您可以在任何分支的任何 Git 提交中应用此方法。不过,我们建议您采用以下流程,在审核流程中尽早找出问题:

  1. 当有人在 Anthos Config Management Git 代码库中打开更改请求时,请将更改部署到其中一个开发集群。
  2. 如果更改请求被接受并合并到主分支,请按照前文所述在所有环境变量中运行完整部署。

虽然某些更改可能仅针对特定的 Environ 设备,但我们建议您最终将所有更改部署到所有 Environ。此策略可消除跟踪哪个 Environ 应与哪个提交同步的问题。请特别留意仅应用于生产环境的更改,因为在之前的环境中无法进行适当的测试。例如,这意味着,等待部署到 Canary 版集群和其余集群之间会增加问题等待时间。

总而言之,完整的端到端部署如下所示:

  1. 有人打开更改请求。
  2. 自动运行验证和验证,并且完成手动审核。
  3. 您可以手动触发作业,以将更改部署到开发环境中的 Canary 集群。自动端对端测试在此集群中运行。
  4. 如果一切正常,请将主分支上的更改请求合并到一起。
  5. 合并会触发自动化作业,将新的主要分支提示提交部署到开发环境中的 Canary 集群。自动化的端到端测试在此集群中运行(以检测大约同时创建和合并的两个变更请求之间的潜在不兼容性)。
  6. 以下作业一个接一个地运行(您手动触发它们,或在预定义的时间之后触发以允许用户报告回归):
    1. 部署到开发环境的所有集群。
    2. 在开发环境中的集群中运行测试和验证。
    3. 部署到预演环境的 Canary 集群。
    4. 在预演环境的 Canary 集群中运行测试和验证。
    5. 部署到预演环境的所有集群。
    6. 在预演环境的集群中运行测试和验证。
    7. 部署到生产环境的 Canary 集群。
    8. 在生产环境的 Canary 集群中运行测试和验证。
    9. 部署到生产环境的所有集群。
    10. 在生产环境中的集群中运行测试和验证。

全面发布流程。

后续步骤