您可以使用发布序列跨多个环境中的 Google Kubernetes Engine (GKE) 集群管理自动集群升级的顺序。例如，您可以在升级生产集群之前限定试产集群中的新版本。 GKE 还提供了一种使用自定义阶段（预览版）的发布顺序版本，可让您更精细地控制集群升级。
本文档假定您了解以下内容：
如需配置发布顺序，请参阅对集群升级的发布进行排序。概览
借助 GKE 发布序列，您可以为跨环境的集群升级定义特定的有序序列，例如先升级开发环境中的集群，然后升级测试环境中的集群，最后升级生产环境中的集群。这种渐进式策略提供内置的烘烤时间，让您可以在升级到达最关键的系统之前发现并缓解潜在问题。
发布序列基于舰队的概念构建，舰队是映射到环境（例如测试环境）的 GKE 集群的逻辑分组。如需使用此功能，您需要定义由舰队组成的序列，并设置每组之间的过渡时间。当 GKE 选择新版本时，您的集群会按照定义的顺序升级，以便您在将该版本完全部署到生产环境之前验证工作负载。
舰队支持轻量级成员资格，可让您对集群进行逻辑分组以实现发布序列，而无需启用所有舰队级配置和功能。如果您想使用发布序列，但不想使用完整舰队管理的其他功能（例如舰队级命名空间相同性），那么轻量级成员资格是不错的选择。如需了解详情，请参阅轻量级会员。
选择发布顺序策略
GKE 提供两种发布顺序版本。这两个版本都基于相同的核心原则（即基于舰队的渐进式升级），但它们提供的灵活性程度不同。本部分可帮助您确定哪个版本最适合您的使用场景。
基于舰队的发布序列（正式版）：对于大多数生产用例，建议采用此版本。基于舰队的发布序列提供了一种稳定且受支持的方法，用于在各个环境（例如测试环境、预演环境和生产环境）中逐步发布升级，并使用线性舰队序列。
具有自定义阶段的发布序列（预览版）：此版本是基于舰队的模型的升级版，可提供更精细的控制和灵活性。借助自定义阶段，您可以使用标签在舰队中定义特定阶段，因此对于更复杂的发布策略（例如在更广泛的发布之前，先在一小部分生产集群上部署新版本），自定义阶段是不错的选择。如果您需要更大的灵活性，或者想预览最新的发布序列功能，请选择此选项。
基于舰队的发布序列
如需按发布顺序自动升级集群，请使用舰队，其中您已将具有相同发布渠道和次要版本的集群分组到部署阶段。定义舰队序列以及每组集群之间所需的过渡时间。然后，当 GKE 在发布渠道中选择新版本进行自动升级时，您的集群组将按照您定义的顺序升级，并且在生产集群开始升级之前，您可以验证工作负载是否按预期运行新版本。
下图说明了 GKE 如何按舰队的组织自动升级发布序列中的集群：
使用基于舰队的序列时，当 GKE 在此序列中的所有集群所加入的发布渠道中提供新的升级目标时，GKE 会升级此序列中集群的这些舰队，且上游舰队的集群符合下游舰队中集群的新版本要求（最多五个舰队）。在发布序列中，上游是指上一个组，下游是指下一个组。
在舰队之间的已配置过渡期间，您可以确认工作负载在升级的集群上按预期运行。
使用自定义阶段的发布序列
将发布序列与自定义阶段搭配使用时，您可以定义舰队升级顺序并设置浸泡时间。此外，您还可以执行以下操作：
- 定义具有精细阶段的序列，该序列可以使用标签定位舰队中的特定集群子集，因此非常适合分阶段推出等策略。
- 通过新的
RolloutSequence和RolloutAPI 对象，您可以获得更强的控制能力和可观测性。
此方法可让您最灵活地控制集群升级。如需定位舰队中的特定集群子集，您可以使用 label-selector 仅定位具有特定 Kubernetes 标签的集群。
下图说明了 GKE 如何自动升级使用自定义阶段的发布序列中的集群。此阶段以 prod 舰队中具有名为 canary 的 label-selector 的集群为目标：
当此序列中所有集群所注册的发布渠道中有新的升级目标可用时，GKE 会先升级测试舰队中的集群，然后再升级预演舰队中的集群。然后，在生产环境舰队中，GKE 会优先考虑与 label-selector 匹配的集群。由于 prod-cluster-1 带有 canary: true 标签，因此 GKE 会接下来升级此集群。GKE 会在流程结束时升级生产环境舰队（在主要阶段）中的所有剩余集群，因为此阶段没有任何标签选择器。
在阶段之间配置的过渡期间，您可以确认工作负载在升级后的集群上按预期运行。上例展示了生产环境舰队中的一个自定义阶段，但您可以向任何舰队添加多个阶段，也可以仅使用一个具有多个阶段的舰队。
如需详细了解使用自定义阶段的发布顺序，请参阅使用自定义阶段的发布顺序简介。本文档的其余部分仅涉及基于舰队的发布序列。
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 在这些环境中升级集群的顺序。对发布进行排序后，管理员有机会在生产环境升级到新版本之前，验证其工作负载是否使用新 GKE 版本上的集群按预期运行。基于舰队的发布序列图中说明了此序列。
管理员会使用舰队之间的过渡时间，以验证其工作负载是否在新版 GKE 上按预期运行。对于测试舰队，管理员将过渡时间设置为 14 天，以便留出两周时间来测试工作负载的运行情况。 对于预演，他们将过渡时间设置为 7 天，因为在工作负载在测试中运行后不需要更多时间。
管理员还可以覆盖升级到特定版本的默认过渡时间，但在以下情况下，他们可能需要执行这一操作：
- 管理员会在过渡时间完成之前完成版本的资格验证，并且希望继续下一舰队的升级，因此他们会将过渡时间设置为零。
- 管理员需要更多时间来验证新版本的资格，然后才能继续下一舰队的升级，因为他们发现某些工作负载存在问题，因此他们需要将过渡时间设置为最长 30 天。
管理员使用维护期和排除项来确保 GKE 在对银行造成的影响最小时升级集群。GKE 遵循按发布顺序升级的集群的维护可用性。
- 管理员为其集群配置了维护窗口，以便 GKE 仅在工作时间结束后升级集群。
- 如果管理员检测到集群的工作负载存在问题，也会使用维护排除项暂时阻止集群升级。
管理员对其节点混合使用超额配置升级和蓝绿升级，根据这些节点上运行的工作负载，在速度和风险容忍度之间取得平衡。
基于舰队的发布资格
要使集群按发布顺序自动升级，发布序列中所有舰队中的所有集群都必须获得相同的升级目标。集群必须在同一发布渠道中注册，我们建议集群运行同一次要版本，因为升级目标是按次要版本设置的。但对于某些版本（如以下示例中的版本），来自多个次要版本的集群获得相同的目标，这意味着集群在运行多个次要版本的发布序列中可以成功升级。
您可以检查序列中版本发布的状态，以详细了解状态以及版本资格问题是否阻止了升级继续进行。根据版本差异，您可能需要执行操作，例如手动升级集群或从群组中移除集群，以继续升级集群。如果发布序列中的集群没有符合条件的升级目标，则在集群的现有次要版本支持服务结束之前，GKE 不会自动升级该集群。
如需排查发布资格问题，请参阅排查发布资格问题。
GKE 版本示例
例如，2025-R45 版本为在常规渠道中注册的集群中的多个次要版本设置升级目标。升级目标可以是新的次要版本（1.30 到 1.31），也可以只是新的补丁版本（1.31.x-gke.x 到 1.31.13-gke.1023000）。此版本中，在常规渠道中，为集群提供了特定次要版本的新版本：
- 1.30 上的集群已升级到 1.31.13-gke.1023000。
- 1.31 上的集群已升级到 1.32.9-gke.1108000。
- 1.32 上的集群已升级到 1.33.5-gke.1162000。
最上游群组接收所有升级目标
对于序列第一个群组中的集群，没有上游群组来限定新版本，GKE 会升级具有符合条件的升级目标的所有集群，无论这些升级目标彼此是否相同。例如，在序列的第一个群组中，如果某些集群运行的是 1.30，则这些集群可以升级到 1.31.13-gke.1023000，运行 1.32 的集群可以升级到 1.33.5-gke.1162000。这是因为，对于序列中的第一个群组，GKE 将所有升级目标均视为这些集群的合格目标，因为没有上游群组来限定新版本。
上游群组必须仅限定一个版本
下游群组中的集群要开始升级，上游群组必须已成功限定一个共同的升级目标，下游群组中的所有集群都符合该升级目标的条件。如果上游群组中的集群已成功升级到两个不同的版本（当上游群组是序列中的第一个群组时可能会发生这种情况），则上游群组会将这两个版本中较低的版本限定为下游群组的共同升级目标。例如，如果上游群组中的某些集群升级到 1.31.13-gke.1023000，而其他集群升级到 1.33.5-gke.1162000，则该群组会将 1.31.13-gke.1023000 限定为下游群组的通用升级目标。
运行版本高于升级目标的集群不会阻止升级
如果下游群组中的集群运行的版本比上游群组限定的升级目标版本更高，则 GKE 会升级符合升级目标条件的集群，并忽略已运行更高版本的集群。只要下游群组中至少有一个集群符合升级目标的条件，此行为就不会阻止发布序列继续进行。
例如，如果上游群组限定了升级到 1.32，而下游群组中有运行 1.31 和 1.33 的集群，则 GKE 会将运行 1.31 的集群升级到 1.32，并忽略运行 1.33 的集群。
上游群组必须限定与下一个群组的集群匹配的版本
如果上游群组中的集群限定了与下一个群组中集群符合条件的版本不同的版本，则 GKE 也无法自动升级任何下游群组中集群。
例如，如果第一个群组中的所有集群都升级到 1.31.13-gke.1023000，但第二个群组中的集群运行的是较新版本（例如 1.32.9-gke.1108000），则第二个群组的集群不会自动升级。第一个群组符合 1.31.13-gke.1023000 的条件，但第二个群组中的集群（目前为 1.32）仅符合升级目标 1.33.5-gke.1162000 的条件，因此 GKE 无法自动升级这些集群。在这种情况下，如需继续升级，请参阅修复群组之间的资格。
上游群组为下游群组限定了多个升级目标
如果 GKE 在升级下游群组中的集群之前多次升级上游群组中的集群，则 GKE 会将下游群组中的集群升级到上游群组限定的最新版本，前提是下游群组中的集群符合该版本的升级条件。对于控制平面升级，此版本最多可以比下游组中集群的控制平面版本高一个次要版本。对于节点升级，此版本可以等于下游群组中集群的控制平面版本，但不能晚于该版本。
例如，如果您已配置维护排除项来暂时阻止下游组（包括生产集群）升级，则此方案非常适用。不过，您的上游组（包括预生产集群）并未同时使用维护排除项来防止升级。因此，您的上游组升级了多次，确定了多个潜在的升级目标，而下游组未升级。
如果升级未在 30 天内完成，系统将强制进入过渡阶段，以解除序列的阻塞状态
为确保发布序列完成集群升级，如果控制平面或节点升级未在最长升级时间（30 天）内完成，GKE 会开始相应群组的过渡期。在过渡期内，群组中任何剩余集群的升级仍可继续进行。
如需了解详情，请参阅发布序列的状态信息表中 FORCED_SOAKING 对应的行。
基于舰队的发布顺序如何与其他升级功能搭配使用
发布顺序是功能集合中的一项功能，可让您控制集群生命周期的升级方面。本部分介绍如何将此功能与集群升级的一些其他相关可用功能搭配使用。
基于舰队的发布顺序如何与维护窗口和排除项协同工作
使用发布顺序升级集群时，GKE 会参考维护窗口和维护排除项。GKE 仅在集群的维护窗口内开始升级集群。您可以使用维护排除项来暂时阻止集群升级。如果 GKE 由于维护窗口或排除项无法升级集群，则群组中的集群可能无法完成升级。如果由于维护窗口或排除项的原因在 30 天内无法完成集群升级，则无论所有集群是否已完成升级，群组都将进入其过渡阶段。
您可以使用维护排除项作为临时措施，以防止序列发布到某个群组并转到下一个群组。如需了解详情，请参阅延迟完成群组版本发布。
基于舰队的发布顺序如何与弃用使用情况检测搭配使用
GKE 会在检测到某些已弃用的 API 和功能的使用情况时暂停集群升级。此外，对于发布序列中群组内的集群，自动升级也会暂停。如需了解详情，请参阅 Kubernetes 弃用功能如何与 GKE 搭配使用。
发布顺序如何与节点升级策略搭配使用
在发布序列中进行升级时，节点升级将使用其配置的节点升级策略。与没有发布顺序的集群升级一样，GKE 会对 Autopilot 节点使用超额配置升级。如需了解详情，请参阅自动节点升级。
如果节点升级无法在 30 天内完成，则无论所有集群是否已完成升级，该群组都将进入过渡阶段。如果节点升级策略导致标准集群的节点升级需要更长时间才能完成，则可能会发生这种情况，尤其是当节点池较大时。如果维护窗口不够大，导致节点升级无法完成，则也会出现这种情况。
发布顺序如何与发布渠道搭配使用
发布渠道是使用发布顺序的必要条件。发布序列中所有群组的所有集群都必须使用同一发布渠道。
接收顺序中的多个升级
如果新版本成为发布渠道的升级目标，而集群仍在按发布顺序升级到先前的升级目标，则上游群组可能会开始发布新版本，而下游群组仍在接收先前的升级。例如，如果序列中的第三个群组是发布 1.31.12-gke.1265000，则序列中的第一个群组可以并发发布 1.31.13-gke.1008000。
选择基于舰队的发布顺序时的注意事项
如果您想通过在将新版本发布到另一个环境之前在一个环境中部署新版本来管理集群升级，请考虑使用发布顺序。
但是，如果存在以下任一情况，则此策略可能不适合您的环境：
- 您的集群没有使用同一生产环境中的同一发布渠道或次要版本。
- 您需要自动执行无法映射到仅五个部署阶段的升级，因为您只能创建最多包含五组集群的发布序列。您不能将多个发布序列中的群组进行关联，来创建包含五个以上群组的发布序列。基于舰队的序列最多可包含五个舰队。
- 您经常执行手动升级，导致一个群组中的集群具有不同的自动升级目标版本。
基于舰队的发布序列的限制
如需成功通过发布顺序升级集群，您必须遵循以下限制：
- 确保发布序列中的所有集群都在同一发布渠道中注册。我们还建议所有集群运行相同的次要版本，以便限定一个升级目标。如需了解详情，请参阅发布资格。
- 创建没有周期的线性发布序列（一个群组具有一个下游群组作为其上游群组）或分支（一个群组具有多个下游群组）。
- 在同一组织的集群之间创建发布序列。您不能创建包含多个组织中的集群的序列。
基于舰队的发布序列的已知问题
- 如果群组包含来自不同位置的集群，则由于新版本逐步发布，集群升级可能暂时仅对部分集群可用。第一组集群更有可能发生这种情况，并且应在一周内解决。
- 如果发布序列中存在空群组，则此情况如何影响版本资格取决于以下条件：
- 如果空群组没有上游群组，则下游群组不会继续执行集群升级，因为空群组无法限定版本。
- 如果空群组具有上游群组，则所有待处理的集群升级都会进入
COMPLETE状态并传播到下游群组。
后续步骤
- 对集群升级的发布进行排序。
- 了解如何使用自定义阶段进行发布序列。