您可以使用发布序列跨多个环境中的 Google Kubernetes Engine (GKE) 集群管理自动集群升级的顺序。例如，您可以在升级生产集群之前限定试产集群中的新版本。 GKE 还提供正式版的发布序列，该序列使用更线性的模型，没有自定义阶段。
本文档假定您了解以下内容：
如需配置发布顺序，请参阅对集群升级的发布进行排序。概览
借助 GKE 发布序列，您可以为跨环境的集群升级定义特定的有序序列，例如先升级开发环境中的集群，然后升级测试环境中的集群，最后升级生产环境中的集群。这种渐进式策略提供内置的烘烤时间，让您可以在升级到达最关键的系统之前发现并缓解潜在问题。
发布序列基于舰队的概念构建，舰队是映射到环境（例如测试环境）的 GKE 集群的逻辑分组。如需使用此功能，您需要定义由舰队组成的序列，并设置每组之间的过渡时间。当 GKE 选择新版本时，您的集群会按照定义的顺序升级，以便您在将该版本完全部署到生产环境之前验证工作负载。
舰队支持轻量级成员资格，可让您对集群进行逻辑分组以实现发布序列，而无需启用所有舰队级配置和功能。如果您想使用发布序列，但不想使用完整舰队管理的其他功能（例如舰队级命名空间相同性），那么轻量级成员资格是不错的选择。如需了解详情，请参阅轻量级会员。
选择发布顺序策略
GKE 提供两种发布顺序版本。这两个版本都基于相同的核心原则（即基于舰队的渐进式升级），但它们提供的灵活性程度不同。本部分可帮助您确定哪个版本最适合您的使用场景。
基于舰队的发布序列 (GA)：此版本已正式发布，是大多数生产环境用例的推荐策略。基于舰队的发布序列提供了一种稳定且受支持的方法，用于在各个环境（例如测试环境、预演环境和生产环境）中逐步发布升级，并使用线性舰队序列。
具有自定义阶段的发布序列（预览版）：此版本是基于舰队的模型的升级版，可提供更精细的控制和灵活性。借助自定义阶段，您可以使用标签在舰队中定义特定阶段，因此非常适合更复杂的发布策略，例如在更大范围的发布之前，先在一小部分生产集群上部署新版本。如果您需要更大的灵活性，或者想要预览最新的发布序列功能，请选择此选项。
本文档的其余部分仅涉及具有自定义阶段的发布序列。
使用自定义阶段的发布序列
将发布序列与自定义阶段搭配使用时，您可以定义舰队升级顺序并设置浸泡时间。此外，您还可以执行以下操作：
- 定义具有精细阶段的序列，该序列可以使用标签定位舰队中的特定集群子集，因此非常适合分阶段推出等策略。
- 通过新的
RolloutSequence和RolloutAPI 对象，您可以获得更强的控制能力和可观测性。
此方法可让您最灵活地控制集群升级。如需定位舰队中的特定集群子集，您可以使用 label-selector 仅定位具有特定 Kubernetes 标签的集群。
下图说明了 GKE 如何自动升级使用自定义阶段的发布序列中的集群。此阶段以 prod 舰队中具有名为 canary 的 label-selector 的集群为目标：
当此序列中所有集群所注册的发布渠道中有新的升级目标可用时，GKE 会先升级测试舰队中的集群，然后再升级预演舰队中的集群。然后，在生产环境舰队中，GKE 会优先考虑与 label-selector 匹配的集群。由于 prod-cluster-1 带有 canary: true 标签，因此 GKE 会接下来升级此集群。GKE 会在流程结束时升级生产环境舰队（在主要阶段）中的所有剩余集群，因为此阶段没有任何标签选择器。
在阶段之间配置的过渡期间，您可以确认工作负载在升级后的集群上按预期运行。上例展示了生产环境舰队中的一个自定义阶段，但您可以向任何舰队添加多个阶段，也可以仅使用一个具有多个阶段的舰队。
主要概念
- 浸泡时间：此时间段是一个可配置的等待时间段，在某个阶段的所有集群升级完毕后开始。通过这段烘烤时间，您可以在一个环境中验证新版本，并在升级继续到下一个环境之前发现潜在问题。您可以为序列中的每个阶段配置最长 30 天的浸泡时间。在预生产阶段延长浸泡时间可为您提供更多验证时间。
RolloutSequence：这是您用于定义升级序列的主要资源。RolloutSequence包含一系列按顺序排列的阶段，用于验证较早阶段中的集群是否已完全升级并已完成过渡期，然后才能继续升级到下一阶段。Rollout：此对象可让您观察序列中单个版本升级的进度。您可以使用Rollout查看发布状态、跟踪进度，以及查看是否有任何集群不符合升级条件以及不符合的原因。- 专用宿主项目：我们建议您使用专用 Google Cloud项目来托管
RolloutSequence对象。将序列放置在专用项目中，可为发布序列提供中立的中央控制点，这与管理 CI/CD 流水线的最佳实践类似。
在专用宿主项目中创建和管理 RolloutSequence 资源。
- 阶段：阶段是指发布序列中的一个步骤。每个阶段都包含一组一起升级的集群。
- 舰队：舰队是用于对集群进行分组的主要方式。发布序列中的阶段只能引用一个舰队。
- 标签选择器：发布序列由一个或多个阶段组成。每个阶段都包含一个舰队中的集群，您可以使用集群上的标签选择器将舰队进一步拆分为多个阶段。这种方法支持分阶段发布等策略，即先升级一小部分生产集群。
GKE 如何升级发布序列中的集群
当 GKE 升级集群时，会首先升级控制平面，然后升级节点。在发布序列中，集群仍然使用此过程进行升级，但您也可以控制集群组（舰队）的升级序列。您还可以指定一个过渡时间，用于定义在升级从一个组进行到下一个组之前 GKE 暂停的时长。
发布序列中的集群升级将遵循以下步骤：
- GKE 会为特定发布渠道中次要版本上的集群设置新的自动升级目标，并发布类似于以下消息的版本说明：“在此版本中，常规渠道中已启用自动升级的控制平面和节点将从版本 1.29 升级到版本 1.30.14-gke.1150000。”
GKE 开始将集群控制平面升级到第一组集群中的新版本。在 GKE 升级集群的控制平面后，GKE 将开始升级集群的节点。 升级发布序列中的集群时，GKE 会遵循维护可用性。
GKE 会为控制平面升级执行以下步骤：
- 在第一个组中的所有集群控制平面升级完成后，GKE 开始控制平面升级的过渡期。如果自控制平面升级开始以来已过去 30 天以上，GKE 也会开始过渡期。
在第一个群组的集群控制平面升级过渡期完成后，GKE 会开始将第二个群组的控制平面升级到新版本。不过，请注意以下几点：
- 在某些情况下，GKE 可能会先多次升级第一组的集群控制平面，然后再升级第二组的集群控制平面。在这种情况下，GKE 会选择同时具有以下属性的最新版本：
- 版本由第一个群组限定。
- 该版本最多比第二组集群的控制平面版本高一个次要版本。
- 如果第二组中集群的控制平面版本高于第一组限定的自动升级目标版本，GKE 不会升级这些集群的控制平面。
- 在某些情况下，GKE 可能会先多次升级第一组的集群控制平面，然后再升级第二组的集群控制平面。在这种情况下，GKE 会选择同时具有以下属性的最新版本：
在控制平面升级的同时，GKE 会为节点升级执行以下步骤：
- 在第一个组中的所有集群的节点升级完成后，GKE 开始节点升级的过渡期。如果自节点升级开始以来已过去 30 天以上，GKE 也会开始过渡期。
- 在第一组的节点升级过渡期结束后，GKE 会开始将第二组的节点升级到新版本。不过，请注意以下几点：
- 在某些情况下，GKE 可能会多次升级第一组的集群节点，然后再升级第二组的集群节点。在这种情况下，GKE 会选择同时具有以下属性的最新版本：
- 版本由第一个群组限定。
- 版本不晚于第二个群组的集群控制平面版本。
- 如果第二组中集群的节点版本高于第一组限定的自动升级目标版本，GKE 不会升级这些节点。
- 在某些情况下，GKE 可能会多次升级第一组的集群节点，然后再升级第二组的集群节点。在这种情况下，GKE 会选择同时具有以下属性的最新版本：
GKE 从第二组进入到第三组时会重复这些步骤，直到发布序列的所有群组中的集群都升级到新的升级目标。
当集群在每个组中升级时，请在过渡期间验证工作负载在集群运行新 GKE 版本的情况下是否按预期运行。
集群也可能由于维护窗口或排除项、已弃用的 API 使用情况或其他原因而无法升级。
如何控制发布序列中的升级
对于发布序列中的集群升级，集群组会按您定义的顺序升级，且每个群组会在您选择的各时段内进行过渡。 在升级过程中，您可以根据需要检查状态和管理发布序列。您还可以通过以下方式控制该过程：
- 您可以修改发布序列中某个群组的默认过渡时间，如果测试表明某个特定版本需要更长或更短的过渡时间，此功能会非常有用。此次对浸泡时间的更改会将默认浸泡时间更新为修改后创建的所有当前和未来发布版本（任何版本）。
- 对于单个集群升级，您可以继续使用以下工具：
示例：社区银行逐步将更改从测试环境发布到生产环境
社区银行的平台管理员管理三个主要部署环境：测试、预演和生产环境。生产集群分布在多个区域，具有不同的严重程度。为了有效管理升级，管理员会将每个环境中的集群分组到舰队中。根据发布顺序的要求，全部三个舰队中的每个集群都已在同一发布渠道（在本例中为常规渠道）中注册，并且所有集群都运行相同的次要版本。
管理员的主要目标是确保在将新 GKE 版本应用于银行的关键生产环境之前，对其进行全面审核。他们还希望先逐步升级低流量区域中的集群，然后再升级高流量区域中的集群，最后升级最重要的区域中的集群。为此，他们使用具有自定义阶段的发布顺序来定义渐进式升级策略，该策略包括根据生产集群的区域为其添加标签。这种方法使他们能够在全面推出之前，先在一小部分生产流量上验证新版本。
为实现此计划，管理员将以下标签应用于生产环境舰队中的集群：
us-west1（流量较低）中的集群带有prod-region: us-west1标签。europe-west1（流量较高）中的集群带有prod-region: europe-west1标签。us-east1（最关键的流量）中的集群未添加标签。序列中舰队的最后一个阶段必须充当所有剩余集群的“兜底”阶段。因此，管理员无需向这些剩余的集群添加标签。
接下来，在用于管理 CI/CD 配置的专用宿主项目中，他们定义了一个 RolloutSequence 对象。此新序列包含五个不同的阶段：
- 测试：此阶段包含
testing舰队中的所有集群。管理员将过渡时间设置为 3 天，以便进行全面验证。 - 预发布：此阶段包括
staging舰队中的所有集群，浸泡时间为 3 天。 us-west1区域中的生产环境：此阶段以生产环境中的所有集群为目标，但使用label-selector仅包含具有prod-region: us-west1标签的集群。在此阶段，管理员可以监控一小部分生产集群在 3 天浸泡时间内的任何问题。- 区域
europe-west1中的生产环境：此阶段包括production舰队中具有prod-region: europe-west1标签的集群。管理员设置了更长的 4 天过渡时间，以便进行更全面的验证。 - 区域
us-east1中的生产：此最终阶段包括production舰队中的其余集群，即us-east1中的所有集群。
这种方法可让管理员精细控制生产升级，在潜在问题影响整个生产环境之前将其捕获，从而显著提高升级过程的安全性和可靠性。
在例行补丁升级期间，银行的自动化测试在暂存环境中顺利完成，速度远超预期。管理员发现新版本稳定，并认为在升级过渡舰队后，三天的过渡时间对于此类常规更新来说过长。
为了加快此发布，管理员修改了 RolloutSequence 定义，并缩短了生产环境群组的 us-west1 阶段的浸泡时间。由于此 RolloutSequence 定义变更会更新所有当前和未来发布阶段的默认浸泡时间，因此管理员记下要点，以便在完成此特定补丁发布阶段后将浸泡时间恢复为原来的 3 天。此方法有助于确保在未来的次要版本升级中，他们能够采用更谨慎的浸泡时间标准。
管理员使用维护期和排除项，以便 GKE 在对银行造成的影响最小时升级集群。GKE 遵循按发布顺序升级的集群的维护可用性。
- 管理员为其集群配置了维护窗口，以便 GKE 仅在工作时间结束后升级集群。
- 如果管理员检测到集群的工作负载存在问题，也会使用维护排除项暂时阻止集群升级。
管理员对其节点混合使用超额配置升级和蓝绿升级，根据这些节点上运行的工作负载，在速度和风险容忍度之间取得平衡。
发布资格
如需通过使用自定义阶段的序列推出版本，集群必须能够从其发布渠道升级到目标版本。当有新的 GKE 版本可用时，如果序列中的集群符合新版本的条件，系统会创建 Rollout 对象。虽然我们建议所有集群都加入同一发布渠道，但如果它们未加入同一发布渠道，GKE 会从序列中最保守的渠道中选择一个版本。例如，如果集群同时使用稳定渠道和常规渠道，GKE 会选择稳定渠道中的版本。
然后，Rollout 会按 RolloutSequence 中定义的阶段逐步执行。在给定阶段内，控制平面发布和节点池发布可以并行运行。此进展过程的一项关键规则是，当阶段处于具有特定版本的 SOAKING 状态时，该阶段不符合开始针对较新版本的新 Rollout 的条件。这种做法有助于确保在开始下一次升级之前，版本已得到充分验证。您可以通过监控 Rollout 对象来观察每个集群的进度和资格条件。如果您发现版本差异导致集群不符合条件，可能需要采取措施（例如手动升级集群）才能继续执行序列。如果集群不符合任何发布条件，则在当前版本达到支持终止日期之前，GKE 不会自动升级该集群。
运行版本高于升级目标的集群不会阻止升级
如果序列中的某个阶段包含运行的版本比发布的目标版本更新的集群，GKE 会升级符合目标版本条件的集群，并忽略已运行更新版本的集群。此行为不会阻止发布序列推进到下一阶段。
例如，如果某个阶段的发布目标版本为 1.32，并且该阶段包含运行 1.31 和 1.33 版本的集群，则 GKE 会将运行 1.31 版本的集群升级到 1.32 版本，并忽略已运行 1.33 版本的集群。
前一阶段为后续阶段确定了多个升级目标
序列中的前一阶段可能会完成多个新版本的发布，而后续阶段则处于暂停状态（例如，因维护排除项而暂停）或仍在处理之前的升级。在这种情况下，当后续阶段准备好接受新升级时，GKE 会将该阶段升级到经过资格认证的最新版本。对于控制平面升级，此版本最多可以比后续阶段的集群控制平面版本高一个次要版本。对于节点升级，此版本可以等于后续阶段集群的控制平面版本，但不能高于该版本。
例如，如果您配置了维护排除期以暂时阻止生产集群升级，则此方案适用。如果您的预生产集群没有相同的维护排除对象，这些集群可能会多次升级，从而符合多个新版本的条件，但您的生产阶段不会升级。
30 天后强制过渡
为确保发布序列完成集群升级，如果控制平面或节点升级未在最长升级时间（30 天）内完成，GKE 会为相应群组启动过渡期。在过渡期内，群组中任何剩余集群的升级仍可继续进行。
发布顺序如何与其他升级功能搭配使用
发布顺序可与其他 GKE 升级功能搭配使用：
- 维护期和排除项：您仍然可以使用维护期和排除项来控制集群何时可以升级以及何时不可以升级。GKE 仅在集群的维护窗口内开始升级集群。您可以使用维护排除项来暂时阻止集群升级。如果 GKE 由于维护窗口或排除项无法升级集群，则阶段中的集群可能无法完成升级。如果由于维护窗口或排除项的原因在 30 天内无法完成集群升级，则无论所有集群是否已完成升级，阶段都将进入其过渡阶段。在给定阶段内，控制平面和节点池的推出可以并行运行。
节点升级策略：发布顺序不会影响您配置的节点升级策略（例如蓝绿升级）。与没有发布顺序的集群升级类似，GKE 会对 Autopilot 节点使用超额配置升级。如需了解详情，请参阅自动节点升级。
如果节点升级无法在 30 天内完成，则无论所有集群是否已完成升级，该群组都将进入过渡阶段。如果节点升级策略导致标准集群的节点升级需要更长时间才能完成，则可能会发生这种情况，尤其是当节点池较大时。如果维护窗口不够大，导致节点升级无法完成，则也会出现这种情况。
发布渠道：我们建议您在发布序列中注册的所有集群都使用同一发布渠道。
弃用使用情况检测：GKE 的弃用使用情况检测功能仍可正常运行，可能会暂停使用已弃用 API 的集群的升级。
手动升级：手动升级序列第一阶段中的集群本身并不会限定相应版本，也不会触发发布以继续进行。自动发布流程由为发布渠道设置的官方自动升级目标驱动。手动升级会更新集群，但只有当该版本成为指定的自动升级目标版本后，发布顺序才会开始推进。
接收顺序中的多个升级
发布渠道用于为集群选择升级目标版本。如果在升级到先前目标版本的过程中有新版本可用，即使后续阶段仍在接收先前的升级，第一阶段也可以开始发布新版本。例如，如果序列中的第三个群组正在发布版本 1.31.12-gke.1265000，则序列中的第一个群组可以并发发布版本 1.31.13-gke.1008000。
选择发布顺序时的注意事项
如果您想通过在将新版本发布到另一个环境之前在一个环境中部署新版本来管理集群升级，请考虑使用发布顺序。
但是，如果存在以下任一情况，则此策略可能不适合您的环境：
- 您的集群没有使用同一生产环境中的同一发布渠道或次要版本。
- 您经常执行手动升级，导致一个群组中的集群具有不同的自动升级目标版本。
限制
如果您使用具有自定义阶段的发布序列来升级集群，则会受到以下限制：
- 您无法使用 Google Cloud 控制台创建或查看具有自定义阶段的发布序列。
- 如果发布序列引用了某个舰队，您必须包含整个舰队。此限制意味着，如果您定义了一个阶段，以仅定位到舰队中的一部分集群（例如，用于分阶段部署），则还必须定义一个后续的“全方位”阶段，其中包含同一舰队中的所有剩余集群。
label-selector此兜底阶段的目标舰队相同，但不包含label-selector，因此会自动包含序列中之前阶段未选择的所有集群。 - 如果您在发布期间修改序列（尤其是会影响参与集群的更改），GKE 会立即取消所有现有的发布。如果您仅修改序列的浸泡时间，GKE 不会取消发布。
- 您无法手动加快特定版本的有效发布。如果您在发布序列定义中修改浸泡时长，则该变更会更新修改后创建的所有当前和未来发布的默认浸泡时间。
- GKE 会自动将已达到支持终止状态的集群升级到受支持的版本，并且此升级可能不会遵循已定义的发布序列。
- 一个阶段最多只能引用一个舰队。您无法在单个阶段中拥有多个舰队。
- 单个舰队只能在一个发布序列中引用。两个发布序列不能引用同一舰队。
已知问题
本部分简要介绍了使用自定义阶段的发布序列的已知问题。
- 如果发布序列中的某个阶段不包含任何集群，系统会跳过该阶段，但仍会等待为该阶段定义的过渡时间结束，然后才会继续发布到下一阶段。