本页面简要介绍了升级过程和版本偏差信息，这些信息应该有助于您规划在多集群环境中升级集群的顺序。如需了解更详细的规划信息（包括可帮助您规划升级的核对清单），请参阅升级最佳实践。
升级序列
从 1.7 版开始，就地升级必须始终遵循特定升级序列：
升级管理员工作站。 即使您计划使用 Google Cloud 控制台、Google Cloud CLI 或 Terraform 升级用户集群，我们也建议您这样做。
逐个升级用户集群。 在版本 1.14 及更高版本中，您可以选择将用户集群的控制平面与用户集群中的节点池分开升级。如需了解您可能需要执行此操作的原因，请参阅用户集群升级。
当用户集群中的所有节点池的版本与用户集群的控制平面相同后，用户集群就完全升级了。
管理员集群的次要版本不能高于其管理的任何用户集群的次要版本。如果您的任何用户集群的次要版本与管理员集群的次要版本相同，则您无法升级管理员集群。
当所有用户集群至少比管理员集群高一个次要版本时，您可以选择升级管理员集群。
在 1.28 及更高版本中，升级版本偏差和版本规则已发生变化。如需了解详情，请参阅版本偏差。
用户集群升级
升级用户集群时，您可以选择升级整个用户集群（即，您可以升级控制平面和集群中的所有节点池），也可以升级用户集群的控制平面，并将节点池保留在当前版本。您采用哪种方法取决于多种因素，例如：
- 集群所在的环境（生产环境或非生产环境）。
- 维护窗口的长度。
- 用户集群的版本。
例如，在开发环境中，您可能希望简化流程，同时升级用户集群的控制平面和所有节点池。但在维护窗口较短的生产环境中，您可能希望仅升级控制平面，因为这样可以节省时间，并且在高可用性 (HA) 控制平面中，控制平面升级不应中断用户工作负载。如果控制平面为 1.28 版或更高版本，则您可以在升级节点池时跳过一个次要版本。
Ubuntu 和 COS 节点池支持将节点池与控制平面分开升级，但 Windows 节点池不支持。
选择性升级节点池
在某些情况下，您可能需要升级用户集群中的部分（而不是全部）节点池。例如，升级控制平面后，您可以升级流量较少或运行最不重要的工作负载的节点池。确信工作负载在新版本上正常运行后，您可以升级其他节点池，直到最终升级所有节点池。
选择用于升级用户集群的工具
Google Distributed Cloud 提供了多种用于升级用户集群的工具供您选择。
命令行工具
gkectl，可以在管理员工作站上运行。在升级之前，您需要修改用户集群配置文件，为集群的控制平面设置目标版本，并可选择为节点池设置目标版本。您可以在gkectl的命令行中指定此文件。Google Cloud 控制台、Google Cloud CLI 或 Terraform，您可以从与 GKE On-Prem API 建立网络连接的任何计算机运行。这些标准工具是 GKE On-Prem API 的客户端，该 API 在 Google Cloud 基础设施上运行。
只有在您使用 Terraform 创建用户集群的情况下，才能使用 Terraform 进行升级。
如果您的用户集群是使用
gkectl创建的，则必须在 GKE On-Prem API 中注册该集群，才能使用控制台或 gcloud CLI 进行升级。在 1.16 及更高版本中，使用gkectl创建的集群默认会在 GKE On-Prem API 中注册。对于在早期版本中创建的集群，您可以在创建集群后将其注册。即使您决定使用
gkectl进行升级，也可能需要将集群注册到 GKE On-Prem API 中，以便使用控制台或 gcloud CLI 获取有关集群的信息。
您使用的工具取决于您计划如何升级用户集群：
升级整个集群：您可以使用
gkectl、Google Cloud 控制台、Google Cloud CLI 或 Terraform 升级用户集群（控制平面以及所有节点池）。仅升级控制平面：您可以使用
gkectl、gcloud CLI 或 Terraform 将用户集群的控制平面与节点池分开升级。控制台不支持仅升级控制平面。在升级控制平面后有选择地升级节点池：您可以在升级控制平面后使用
gkectl、gcloud CLI 或 Terraform 升级特定节点池。同时升级控制平面和一个或多个节点池：只有
gkectl支持此用例。
管理员集群升级
当所有用户集群上的控制平面和节点池至少比管理员集群低一个次要版本时，您可以选择升级管理员集群。只有 gkectl 支持升级管理员集群。GKE On-Prem API 客户端不支持升级管理员集群。
版本偏差
版本偏差是管理员集群与其管理的用户集群之间的次要版本差异。在以下部分中，“用户集群版本”是指控制平面和节点池的版本。
此外，版本偏差是用户集群的控制平面与用户集群中的节点池之间的次要版本差异。
在多集群环境中，了解支持的版本偏差和升级版本规则可能会帮助您规划升级集群的顺序。
管理员集群和用户集群版本偏差
管理员集群可以管理不同版本的用户集群。此功能可让您根据组织的需要计划一组用户集群的升级。
1.29 及更高版本
版本偏差与 1.28 中的相同。在 1.29 中，此功能已过渡到正式版阶段。
在 1.29 版及更高版本中，用户集群的次要版本最多可以比管理员集群高 2 个。例如，如果管理员集群的版本为 1.28，则该管理员集群管理的用户集群的版本可以是 1.28、1.29 或 1.30。
一般而言，如果 1.n 是管理员集群的次要版本，那么用户集群可以是 1.n、1.n+1 或 1.n+2。在管理员集群升级至少一个次要版本之前，1.n+2 的用户集群无法升级到下一个次要版本。
1.28
在 1.28 版中，用户集群的次要版本最多可以比管理员集群高 2 个。例如，如果管理员集群的版本为 1.15，则该管理员集群管理的用户集群的版本可以是 1.15、1.16 或 1.28。在将管理员集群升级到至少 1.16 之前，1.28 版用户集群无法升级到 1.29 版。
1.16 及更低版本
在 1.16 版及更低版本中，用户集群的次要版本只能比管理员集群高 1 个。例如，如果管理员集群为 1.15，则该管理员集群管理的用户集群可以是 1.15 或 1.16。
一般而言，如果 1.n 是管理员集群的次要版本，则用户集群可以是 1.n 或 1.n+1。在管理员集群与用户集群处于同一次要版本之前，用户集群无法升级到下一个次要版本。
用户集群控制平面和节点池版本偏差
1.29 及更高版本
版本偏差与 1.28 中的相同。在 1.29 中，此功能已过渡到正式版阶段。
在 1.29 版及更高版本中，用户集群的控制平面最多可以比集群中的节点池高 2 个次要版本。例如，如果用户集群的控制平面为 1.30，则集群中的节点池可以为 1.28、1.29 或 1.30。
一般而言，如果 1.n 是用户集群控制平面的次要版本，则集群中的节点池可以是 1.n、1.n-1 或 1.n-2。在所有节点池都处于 1.n 或 1.n-1 状态之前，用户集群控制平面无法升级到下一个次要版本。
1.28
在 1.28 版中，用户集群的控制平面最多可以比集群中的节点池高 2 个次要版本。例如，如果用户集群的控制平面为 1.28，则集群中的节点池可以为 1.15、1.16 或 1.28。在所有节点池都位于 1.28 或 1.16 之前，用户集群控制平面无法升级到 1.29。
1.16 及更低版本
在 1.16 版及更低版本中，用户集群的控制平面只能比集群中的节点池高 1 个次要版本。例如，如果用户集群的控制平面为 1.16，则集群中的节点池可以为 1.15 或 1.16。
一般而言，如果 1.n 是用户集群控制平面的次要版本，则集群中的节点池可以是 1.n 或 1.n-1。在所有节点池都与控制平面处于同一次要版本之前，用户集群无法升级到下一个次要版本。
管理员集群和用户集群控制平面升级的版本规则
管理员集群和用户集群控制平面升级的版本规则相同。您可以直接升级到同一或下一次要发布版本中的任何版本。例如，您可以从 1.30.0 升级到 1.30.1，或从 1.29.1 升级到 1.30.0。补丁版本不会影响升级版本规则。
如果您要升级到非下一个次要版本，则必须在当前版本和目标版本之间升级每个次要版本的一个版本。不支持跳过次要版本。例如，如果您要从 1.28.x 版升级到 1.30.x 版，则无法直接升级。您必须先从 1.28.x 升级到 1.29.x，然后再升级到 1.30.x。
一般而言，管理集群升级和用户集群控制平面升级仅支持从 1.n 升级到 1.n+1。
节点池升级的版本规则
在 1.28 版及更高版本中，升级用户集群中的节点池时，您可以跳过一个次要版本。例如，如果用户集群控制平面为 1.30 版，而节点池为 1.28 版，则您可以跳过 1.29 版，直接将节点池升级到 1.30 版。补丁版本不会影响升级版本规则。
一般而言，如果用户集群控制平面位于 1.n，则可以将位于 1.n-2 的节点池直接升级到 1.n。升级节点池时跳过一个次要版本可能会缩短升级时间，而不是进行两次节点池升级（从 1.n-2 升级到 1.n-1，然后再升级到 1.n）。这也是您可能希望将用户集群的控制平面与在用户集群上运行的节点池分开升级的另一个原因。
补丁版本升级
我们建议您尽可能升级到最新的补丁版本，以确保您的集群拥有最新的安全修复程序。补丁版本不会影响版本偏差和升级规则。对于给定的次要版本，您可以升级到任何更高的补丁版本。也就是说，只要 Y 大于 X，您就可以将 1.30.X 版本集群升级到版本 1.30.Y。例如，您可以从 1.29.0 升级到 1.29.1，也可以从 1.29.1 升级到 1.29.3。
后续步骤
查看升级最佳实践，并制定升级集群的计划。