升级节点池时跳过某个版本

在 1.29 版及更高版本中，Google Distributed Cloud 允许用户集群的控制平面高于集群中的节点池最多两个次要版本。例如，如果用户集群的控制平面为 1.29 版，则集群中的节点池可以为 1.16、1.28 或 1.29 版。此外，使用 Google Distributed Cloud 时，您可以在升级节点池时跳过一个次要版本。使用前面的示例，您可以将版本为 1.16 的节点池直接升级到 1.29 版，并跳过升级到 1.28 版。在升级节点池时跳过次要版本称为跳过版本升级。

Ubuntu 和 COS 节点池支持跳过版本升级，但 Windows 节点池不支持。此外，如果您启用了高级集群，则无法使用此功能。

由于 Kubernetes 限制，用户集群的控制平面必须一次升级一个次要版本。不过，请注意，与升级运行工作负载的节点池相比，仅升级控制平面所需的时间要短得多，风险也更低。

本页介绍了跳过版本升级的一些优势，并提供了通过更改配置文件和运行 gkectl upgrade cluster 来执行跳过版本升级的步骤。

本页面适用于管理底层技术基础架构生命周期的 IT 管理员和运维人员。如需详细了解我们在 Google Cloud 内容中提及的常见角色和示例任务，请参阅常见的 GKE Enterprise 用户角色和任务。 本页面假定您对以下内容有所了解，并能据此规划和执行 Google Distributed Cloud 升级：

跳过版本升级的好处

本部分介绍了使用跳过版本升级的一些优势。

更轻松地让集群保持在受支持的版本

Google Distributed Cloud 每四个月发布一个新的次要版本，每个次要版本都有一年的支持期限。为了让集群保持在受支持的期限内，您必须大约每 4 个月执行一次次要版本升级，如下所示：

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月
1.14 升级
1.15 升级
1.16 升级
1.28 升级
1.29 升级

如果您需要较长的验证期限来验证新次要版本，同时又需要较短的维护窗口来将集群升级到新次要版本，则会遇到此要求带来的挑战。为了克服这些挑战，您可以使用跳过版本升级，通过每 8 个月升级一次集群（而不是每 4 个月升级一次集群），让集群保持在受支持的时间范围内。下表显示了跳过 1.15 版升级意味着您只需在 8 个月后（而不是 4 个月后）升级。

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月

4 月

5 月

6 月

7 月

8 月

9 月

10 月

11 月

12 月

1 月

2 月

3 月
1.14 升级
1.15
1.16 升级
1.28
1.29

在升级节点池时跳过一个次要版本，可以减少保持在受支持版本所需的升级次数。此外，您无需对跳过的次要版本进行限定，因为它只会暂时由控制平面使用。

缩短维护窗口

通过跳过版本升级，您无需扩大维护窗口。升级节点池时跳过一个次要版本所需的时间与将节点池升级到下一个次要版本所需的时间相同，因为节点池中的每个节点都会被耗尽并重新创建一次。因此，跳过版本升级总体上可以节省时间并减少工作负载中断。

摘要

总的来说，跳过版本升级具有以下优势：

  • 将集群升级到受支持的版本：Google Distributed Cloud 支持最近三个次要版本。如果您的集群使用的是不受支持的版本，则在升级节点池时跳过一个次要版本，可以让您的集群通过更少的升级升级到受支持的版本（具体取决于集群版本）。

  • 节省时间：升级节点池时跳过一个次要版本所需的时间与将节点池升级到下一个次要版本所需的时间相同。因此，跳过版本升级大约需要升级节点池两次所用时间的一半。同样，与常规升级相比，跳过版本升级只需要一个验证窗口。

  • 减少中断：升级间隔时间更长，升级和验证所花时间更少，这意味着工作负载运行时间更长，中断次数更少。

在升级期间控制控制平面和节点池版本

在用户集群配置文件中，nodePools[i].gkeOnPremVersion 字段允许特定节点池使用与顶级 gkeOnPremVersion 字段不同的版本。通过更改 nodePools[i].gkeOnPremVersion 字段的值，您可以控制在运行 gkectl upgrade cluster 时升级节点池的时间。如果您未在配置文件中添加 nodePools[i].gkeOnPremVersion，或者将该字段设置为空字符串，则节点池会升级到您在 gkeOnPremVersion 中指定的目标版本。

版本规则

升级规则取决于集群的次要版本。

  • 对于 1.30 及更低版本，用户集群的次要版本必须大于或等于管理员集群的次要版本。补丁版本无关紧要。例如，如果用户集群的版本为 1.30.1，则管理员集群可以升级到更高的补丁版本，例如 1.30.3。

  • 对于 1.31 及更高版本，管理员集群版本（包括补丁版本）必须大于或等于用户集群版本。例如，如果管理员集群的版本为 1.31.1，则用户集群可升级到的最高版本为 1.31.1。

如需将集群升级到 1.31 版，您必须先将所有集群升级到 1.30 版。所有集群都升级到 1.30 版后，您可以将管理员集群升级到 1.31 版。之后，您可以将用户集群升级到与管理员集群相同的 1.31 补丁版本。

跳过版本升级序列

升级管理员集群和用户集群的顺序取决于您要升级到的集群版本（称为目标版本）：

1.31

如果用户集群的版本为 1.29，请使用此特殊序列，这表示目标版本为 1.31。当用户集群的版本为 1.29 时，管理该用户集群的管理员集群的版本可以是 1.27、1.28 或 1.29。

  1. 如果您的管理员集群的版本为 1.27，请将其升级到 1.28。
  2. 如果您的管理员集群的版本为 1.28，请将其升级到 1.29。
  3. 仅将用户集群控制平面从源版本 1.29 升级到中间版本 1.30。将节点池保留在源版本。由于控制平面必须一次升级一个次要版本，因此需要中间版本 1.30。
  4. 将管理员集群从 1.29 版升级到中间版本 1.30。
  5. 将管理员集群升级到目标版本 1.31。
  6. 将用户集群控制平面和节点池升级到目标版本 1.31。

1.30 及更低版本

如果目标版本为 1.30 或更低版本，请使用此序列。

假设您的用户集群控制平面和所有节点池的次要版本为 1.N。概括来说，使用跳过版本升级将集群从 1.N 升级到 1.N+2 的过程如下所示：

  1. 仅将控制平面从源版本 1.N 升级到中间版本 1.N+1。将节点池保留为源版本。由于控制平面必须一次升级一个次要版本，因此需要中间版本。
  2. 将控制平面和节点池升级到目标版本 1.N+2。

执行版本跳过升级

本部分介绍了执行版本跳过升级的步骤。

准备工作

  1. 确保集群的当前版本（源版本）为 1.16 或更高版本。请务必检查控制平面 (gkeOnPremVersion) 和所有节点池 (nodePools[i].gkeOnPremVersion) 的版本。

  2. 在 1.29 版及更高版本中，服务器端预检检查默认处于启用状态。请务必检查防火墙规则，以便进行任何必要的更改。

  3. 如需升级到 1.28 版及更高版本，您必须启用 kubernetesmetadata.googleapis.com 并将 kubernetesmetadata.publisher IAM 角色授予日志记录监控服务账号。如需了解详情，请参阅 Google API 和 IAM 要求。

执行升级

1.31

如果用户集群的版本为 1.29，请使用此特殊序列，这意味着目标版本为 1.31。由于版本规则在 1.31 版中发生了变化，因此需要执行此序列。

当用户集群的版本为 1.29 时，管理该用户集群的管理员集群的版本可以是 1.27、1.28 或 1.29。

  1. 如果您的管理员集群的版本为 1.27，请按照相应步骤升级管理员工作站并升级管理员集群到 1.28 版。

  2. 如果您的管理员集群是 1.28 版，请按照相应步骤升级管理员工作站并升级管理员集群到 1.29 版。

  3. 如需节省管理员工作站上的空间，请移除下载的软件包：

    rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

当管理员集群和所有用户集群均为 1.29 版时，您可以开始跳过版本升级。

  1. 在以下占位符变量中定义源版本 (1.29)、中间版本 (1.30) 和目标版本 (1.31)。所有版本都必须是采用 x.y.z-gke.N 格式的完整版本号，例如 1.29.700-gke.110。

    版本
    获取当前用户集群的 1.29 版。这是源代码版本。 SOURCE_VERSION
    选择一个中间 1.30 版本。 INTERMEDIATE_VERSION
    选择 1.31 目标版本。从 1.31 次要版本中选择 推荐的补丁。 TARGET_VERSION

  2. 将管理员工作站升级到中间版本 1.30，即 INTERMEDIATE_VERSION。等待系统显示升级成功的消息。

  3. 安装相应的软件包：

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. 再次升级管理员工作站，这次升级到目标 1.31 版本 TARGET_VERSION。等待系统显示升级成功的消息。

  5. 安装相应的软件包：

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. 仅将用户集群控制平面升级到中间版本，如下所示：

    1. 在用户集群配置文件中进行以下更改：

      • 将 gkeOnPremVersion 字段设置为中间版本 INTERMEDIATE_VERSION。

      • 将 nodePools[i].gkeOnPremVersion 中的所有节点池版本设置为来源版本 SOURCE_VERSION。

      更新配置文件后，该文件应类似于以下内容：

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. 升级控制平面：

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      将 USER_CLUSTER_CONFIG 替换为用户集群配置文件的路径。

  7. 将管理员集群配置文件中的 bundlePath 字段设置为软件包的中间版本 1.30：

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz"

  8. 将管理员集群升级到中间版本 1.30：

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  9. 将管理员集群配置文件中的 bundlePath 字段设置为软件包的目标 1.31 版本：

    bundlePath="/var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz"

  10. Upgrade the admin cluster to the target 1.31 version:

    gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE

  11. 将控制平面和节点池升级到目标版本，具体方法如下：

    1. 在用户集群配置文件中进行以下更改：

      • 将 gkeOnPremVersion 字段设置为目标版本 TARGET_VERSION。

      • 将所有 nodePools[i].gkeOnPremVersion 设置为空字符串。

      更新配置文件后，该文件应类似于以下内容：

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. 升级控制平面和节点池：

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

1.30 及更低版本

如果目标版本为 1.30 或更低版本，请使用此序列。

  1. 在以下占位符变量中定义源版本 (1.N)、中间版本 (1.N+1) 和目标版本 (1.N+2)。所有版本都必须是采用 x.y.z-gke.N 格式的完整版本号，例如 1.16.11-gke.25。

    版本
    获取当前集群版本。这是源代码版本 (1.N)。 SOURCE_VERSION
    选择一个中间版本 (1.N+1)。 INTERMEDIATE_VERSION
    选择目标版本 (1.N+2)。从目标次要版本中选择 推荐的补丁。 TARGET_VERSION

  2. 将管理员工作站升级到中间版本 INTERMEDIATE_VERSION。等待系统显示升级成功的消息。

  3. 安装相应的软件包：

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-INTERMEDIATE_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    将 ADMIN_CLUSTER_KUBECONFIG 替换为管理员集群 kubeconfig 文件的路径。

  4. 再次升级管理员工作站，这次升级到目标版本 TARGET_VERSION。等待系统显示升级成功的消息。

  5. 安装相应的软件包：

    gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  6. 仅将控制平面升级到中间版本，如下所示：

    1. 在用户集群配置文件中进行以下更改：

      • 将 gkeOnPremVersion 字段设置为中间版本 INTERMEDIATE_VERSION。

      • 将 nodePools[i].gkeOnPremVersion 中的所有节点池版本设置为来源版本 SOURCE_VERSION。

      更新配置文件后，该文件应类似于以下内容：

      gkeOnPremVersion: INTERMEDIATE_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: SOURCE_VERSION
  ...
- name: pool-2
  gkeOnPremVersion: SOURCE_VERSION
  ...

    2. 升级控制平面：

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

      将 USER_CLUSTER_CONFIG 替换为用户集群配置文件的路径。

  7. 将控制平面和节点池升级到目标版本，如下所示：

    1. 在用户集群配置文件中进行以下更改：

      • 将 gkeOnPremVersion 字段设置为目标版本 TARGET_VERSION。

      • 将所有 nodePools[i].gkeOnPremVersion 设置为空字符串。

      更新配置文件后，该文件应类似于以下内容：

      gkeOnPremVersion: TARGET_VERSION
...
nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  ...
- name: pool-2
  gkeOnPremVersion: ""
  ...

    2. 升级控制平面和节点池：

      gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE

如果您没有任何其他要升级的用户集群，请从管理员工作站中移除软件包以节省空间：

rm /var/lib/gke/bundles/gke-onprem-vsphere-*.tgz

后续步骤