您可以使用发布顺序在多个环境中管理 Google Kubernetes Engine (GKE) 集群中自动集群升级的顺序。例如，您可以在升级生产集群之前限定试产集群中的新版本。如需使用此功能，您应该熟悉集群升级、发布渠道和舰队管理。
要开始使用，请参阅集群升级的发布顺序。
取得跨环境升级资格
如需按发布顺序自动升级集群，请使用舰队或范围（预览版），其中您已将具有相同发布渠道和次要版本的集群分组到部署阶段。选择舰队序列或范围序列，并定义每组集群之间的过渡时间。然后，当 GKE 在发布渠道中选择新版本进行自动升级时，您的集群组将按照您定义的顺序升级，并且在生产集群开始升级之前，您可以验证工作负载是否按预期运行新版本。
基于舰队的发布序列
下图说明了 GKE 如何按舰队的组织自动升级发布序列中的集群：
使用基于舰队的顺序时，当 GKE 在按此顺序加入所有集群的发布渠道中提供新的升级目标时，GKE 会按此顺序升级这些集群舰队，且上游舰队的集群符合下游舰队中新版本集群的要求，最多允许三个舰队。在舰队之间的已配置过渡期间，您可以确认工作负载在升级的集群上按预期运行。
基于范围的发布序列
如果您需要更精细地组织舰队中的集群，可以在范围之间创建发布序列：
规定范围后，您可以在舰队中创建多个发布序列，每个发布序列都有自己的发布渠道、升级目标和独立的过渡时间。基于范围的发布序列其运作方式与基于舰队的发布序列相同，但升级限定为范围到范围升级，而不是舰队到队列升级。
GKE 如何升级发布序列中的集群
当 GKE 升级集群时，会首先升级控制平面，然后升级节点。在发布序列中，集群仍然使用此过程进行升级，但您也可以控制集群组（舰队或范围）的升级顺序，并指定一个可供选择的过渡时间，即在升级从一个组进行到下一个组之前 GKE 暂停的时长。
发布序列中的集群升级将遵循以下步骤：
- GKE 为特定发布渠道中的次要版本集群设置新的自动升级目标，版本说明中提及了类似于以下消息的内容：“常规渠道中启用了自动升级的控制平面和节点将通过此发布渠道从版本 1.21 升级到版本 1.22.15-gke.1000。”
- GKE 开始将集群控制平面升级到第一组集群中的新版本。在 GKE 升级集群的控制平面后，GKE 将开始升级集群的节点。升级发布序列中的集群时，GKE 会遵循维护可用性。
- GKE 会执行控制平面升级的后续步骤：
- 在第一个组中的所有集群控制平面升级完成后，或者自控制升级开始 30 天后，GKE 开始控制平面升级的过渡期。
- 在第一个群组中的集群控制平面升级过渡期完成后，GKE 会在第二个群组中开始控制平面升级。
- 在控制平面升级的同时，GKE 会为节点升级执行以下后续步骤：
- 在第一个组中的所有集群的节点升级完成或节点升级开始 30 天后，GKE 开始节点升级的过渡期。
- 在第一组中节点升级的过渡期完成后，GKE 将针对控制平面已升级的集群开始第二组中的节点升级。
- GKE 从第二组进入到第三组时会重复这些步骤，直到发布序列的所有群组中的集群都升级到新的升级目标。
当集群在每个组中升级时，请在过渡期间验证工作负载是否使用新 GKE 版本上运行的集群按预期运行。
集群也可能由于维护窗口或排除项、已弃用的 API 使用情况或其他原因而无法升级。如需了解详情，请参阅发布顺序如何与其他升级功能搭配使用。
如何控制发布序列中的升级
对于发布序列中的集群升级，集群组会按您定义的顺序升级，且每个群组会在您选择的各时段内进行过渡。在升级过程中，您可以根据需要检查发布序列的状态和管理发布序列。您还可以通过以下方式控制该过程：
- 对于发布序列中的群组，如果某个特定版本需要更长或更短的过渡时间，则可以覆盖默认过渡时间。
- 对于单个集群升级，您可以继续使用以下工具：
如需了解详情，请参阅发布顺序如何与其他升级功能搭配使用。
示例：社区银行逐步将更改从测试环境发布到生产环境
例如，社区银行的平台管理员管理三个主要部署环境，即测试、预演和生产，在每个环境中，集群组都组织到一个舰队中。根据发布顺序，管理员已将同一发布渠道中的全部三个舰队中的每个集群注册到运行相同次要版本的所有集群，其中在这些舰队中为常规渠道。
管理员使用发布顺序来定义 GKE 在这些环境中升级集群的顺序。对发布进行排序后，管理员有机会在生产环境升级到新版本之前，验证其工作负载是否使用新 GKE 版本上的集群按预期运行。基于舰队的发布序列图演示了此序列。
管理员会在要升级的舰队之间使用过渡时间，以验证其工作负载是否使用新 GKE 版本上的集群按预期运行。对于测试舰队，管理员将过渡时间设置为 14 天，以便留出两周时间来测试工作负载的运行情况。 对于预演，他们将过渡时间设置为 7 天，因为在工作负载在测试中运行后不需要更多时间。
管理员还可以覆盖升级到特定版本的默认过渡时间，但在以下情况下，他们可能需要执行这一操作：
- 管理员会在过渡时间完成之前完成版本的资格验证，并且希望继续下一舰队的升级，因此他们会将过渡时间设置为零。
- 管理员需要更多时间来验证新版本的资格，然后才能继续下一舰队的升级，因为他们发现某些工作负载存在问题，因此他们需要将过渡时间设置为最长 30 天。
管理员使用维护期和排除项来确保 GKE 在升级对银行造成的影响最小时升级集群。GKE 遵循按发布顺序升级的集群的维护可用性。
- 管理员为集群配置了维护期，以确保 GKE 仅在工作时间升级集群。
- 如果管理员检测到集群的工作负载存在问题，也会使用维护排除项暂时阻止升级集群。
管理员对其节点混合使用超额配置升级和蓝绿升级，根据这些节点上运行的工作负载，在速度和风险容忍度之间取得平衡。
管理员切换到基于范围的发布序列
如果管理员决定需要进一步在舰队内对集群进行分组，则可以使用范围。借助范围，它们可以创建具有更多集群分组、可能在不同发布渠道上运行或具有不同过渡时间的独立发布序列。
例如，如果管理员希望数据库团队的集群使用稳定渠道和更长的过渡时间，而前端网站团队的集群使用快速渠道和较短的过渡时间，则他们可以使用范围对现有舰队中的这些集群进行细分，并创建单独的发布序列。 基于范围的发布序列图中说明了此类型的序列。如需为您的环境执行此操作，请按照说明在基于舰队和基于范围的发布序列之间切换。
发布资格
要使集群按发布顺序自动升级，发布序列中所有群组（舰队或范围）中的所有集群都必须获得相同的升级目标。集群必须在同一发布渠道中注册，我们建议集群运行相同的次要版本，因为升级目标按次要版本设置。但对于某些版本（如以下示例中的版本），来自多个次要版本的集群获得相同的目标，这意味着集群在运行多个次要版本的发布序列中可以成功升级。
您可以检查序列中版本发布的状态，以详细了解状态以及版本资格问题是否阻止了升级。根据版本差异，您可能需要执行操作，例如手动升级集群或从群组中移除集群，以继续升级集群。如需排查发布资格问题，请参阅排查发布资格问题。
示例 GKE 版本
例如，2022-R25 版本为在常规渠道中注册的集群中的多个次要版本设置升级目标。升级目标可以是新的次要版本（1.20 到 1.21），也可以是新的补丁程序版本（1.21.x-gke.x 到 1.21.14-gke.4300）。此版本中，在常规渠道中，为集群提供了特定次要版本的新版本：
- 1.20 和 1.21 上的集群已升级到 1.21.14-gke.4300。
- 1.22 上的集群已升级到 1.23.8-gke.1900。
- 1.24 上的集群已升级到 1.24.5-gke.600。
最上游群组接收所有升级目标
对于序列第一个群组中的集群，没有上游群组来限定新版本，GKE 会升级具有符合条件的升级目标的所有集群，无论这些升级目标彼此是否相同。例如，在序列的第一个群组中，如果某些集群运行的是 1.20，则这些集群可以升级到 1.21.14-gke.4300，运行 1.24 的集群可以升级到 1.24.5-gke.600。这是因为，对于序列中的第一个群组，GKE 将所有升级目标均视为这些集群的合格目标，因为没有上游群组来限定新版本。
上游群组必须仅限定一个版本
在任何下游群组中，GKE 是否可以升级集群取决于上游群组是否限定了一个升级目标，其中该群组中的所有集群都符合条件。通常，这意味着所有集群从同一次要版本开始。但是，从示例版本中，1.20 和 1.21 上的集群具有相同的升级目标，因此运行两个版本的集群可以在同一组中将升级限定为 1.21.14-gke.4300。
如果一个群组中的所有集群都没有相同的升级目标，则该群组不能为下一个群组限定升级目标。在这种情况下，GKE 无法自动升级下游群组中的集群。例如，如果第一个群组中的某些集群升级到 1.21.14-gke.4300，其他集群升级到 1.23.8-gke.1900，则第二个群组的集群无法自动升级，因为该群组并未收到一个限定版本。在这种情况下，如需继续升级，请参阅修复群组中的资格要求。
上游群组必须限定与下一个群组的集群匹配的版本
如果上游群组中的集群限定了与下一个群组中集群符合条件的版本不同的版本，则 GKE 也无法自动升级任何下游群组中集群。
例如，如果第一个群组中的所有集群都升级到 1.21.14-gke.4300，但第二个群组中的集群运行 1.22（其中升级目标为 1.23.8-gke.1900），则第二个群组的集群不会自动升级。第一个群组符合 1.21.14-gke.4300 的条件，但第二个群组中的集群（目前为 1.22）仅符合升级目标 1.23.8-gke.1900 的条件，因此 GKE 无法自动升级这些集群。在这种情况下，如需继续升级，请参阅修复群组之间的资格。
发布顺序如何与其他升级功能搭配使用
发布顺序是功能集合中的一项功能，可让您控制集群生命周期的升级方面。本部分介绍如何将此功能与集群升级的一些其他相关可用功能搭配使用。
发布顺序如何与维护窗口和排除项协同工作
使用发布顺序升级集群时，GKE 会参考维护窗口和维护排除项。GKE 仅在集群的维护窗口内开始升级集群。您可以使用维护排除项来暂时阻止集群升级。如果 GKE 由于维护窗口或排除项无法升级集群，则群组中的集群可能无法完成升级。如果由于维护窗口或排除项的原因在 30 天内无法完成集群升级，则无论所有集群是否已完成升级，群组都将进入其过渡阶段。
您可以使用维护排除项作为临时措施，以防止序列发布到某个群组并转到下一个群组。如需了解详情，请参阅延迟完成群组版本发布。
发布顺序如何与弃用使用情况检测搭配使用
GKE 会在检测到某些已弃用的 API 和功能的使用情况时暂停集群升级。此外，对于发布序列中群组内的集群，自动升级也会暂停。如需了解详情，请参阅 Kubernetes 弃用功能如何与 GKE 搭配使用。
发布顺序如何与节点升级策略搭配使用
在发布序列中进行升级时，节点升级将使用其配置的节点升级策略。与没有发布顺序的集群升级一样，GKE 会对 Autopilot 节点使用超额配置升级。如需了解详情，请参阅自动节点升级。
如果节点升级无法在 30 天内完成，则无论所有集群是否已完成升级，该群组都将进入过渡阶段。如果节点升级策略导致标准集群的节点升级需要更长时间才能完成，则可能会发生这种情况，尤其是当节点池较大时。如果维护窗口不够大，导致节点升级无法完成，则也会出现这种情况。如需了解详情，请参阅配置维护窗口时的注意事项。
发布顺序如何与发布渠道搭配使用
发布渠道是使用发布顺序的必要条件。发布序列中所有群组的所有集群都必须使用同一发布渠道。
接收顺序中的多个升级
如果新版本成为发布渠道的升级目标，而集群仍在按发布顺序升级到先前的升级目标，则上游群组可能会开始发布新版本，而下游群组仍在接收先前的升级。例如，如果顺序中的第三个群组是发布 1.24.2-gke.100，则顺序中的第一个群组可以并发发布 1.24.3-gke.500。
选择发布顺序时的注意事项
如果您想通过在将新版本发布到另一个环境之前在一个环境中部署新版本来管理集群升级，请考虑使用发布顺序。
如需创建基于范围的发布序列，您必须在舰队宿主项目中启用 Anthos API（GKE Enterprise）。
但是，如果存在以下任一情况，则此方法可能不适合您的环境：
- 您的集群没有使用同一生产环境中的同一发布渠道或次要版本。
- 您需要自动执行无法映射到部署三个阶段的升级，因为您只能创建最多包含三组集群的发布序列。您不能将多个发布序列中的群组进行关联，来创建包含三个以上群组的发布序列。
- 您不能使用舰队管理。
- 您经常执行手动升级，导致一个组中的集群具有不同的自动升级目标版本。
限制
如需成功通过发布顺序升级集群，您必须遵循以下限制：
- 仅在一个范围内注册集群。如果集群注册了多个范围，GKE 将无法按发布序列自动升级集群。
- 不支持在同一舰队中创建具有多个范围的基于范围的发布序列。
- 创建没有周期的线性发布序列（一个群组具有一个下游群组作为其上游群组）或分支（一个群组具有多个下游群组）。
- 在范围之间创建发布序列，或在舰队之间创建发布序列。您不能在同一序列中创建同时包含舰队和范围的混合序列。
- 确保发布序列中的集群都在同一发布渠道中注册，并且运行相同的次要版本。
已知问题
- 如果群组包含来自不同位置的集群，则由于新版本逐步发布，集群升级可能暂时仅对部分集群可用。第一组集群更有可能发生这种情况，并且应在一周内解决。
- 如果发布序列中存在空群组，则此情况如何影响版本资格取决于以下条件：
- 如果空群组没有上游群组，则下游群组不会继续执行集群升级，因为空群组无法限定版本。
- 如果空群组具有上游群组，则所有待处理的集群升级都会进入
COMPLETE状态并传播到下游群组。
- 由于 GKE 跟踪补丁和次要升级的方式，在检查范围的状态时，您可能会看到类型和版本都相同但状态不同的两个升级。