升级集群

安装新版 bmctl 时，您可以升级使用较早版本创建的现有集群。将集群升级到最新的 GKE on Bare Metal 版本可为集群新增功能和修复，还可确保您的集群保持受支持状态。您可以使用 bmctl upgrade cluster 命令升级管理员集群、独立集群或用户集群，也可以使用 kubectl 来执行这些操作。

如需详细了解升级流程，请参阅集群升级的生命周期和阶段。

规划升级

本部分包含升级集群之前应考虑内容的信息和链接。

最佳实践

如需了解如何准备集群升级，请参阅 GKE on Bare Metal 集群升级最佳实践。

升级预检检查

预检检查在集群升级的过程中运行，以验证集群状态和节点运行状况。如果预检检查失败，则不会继续集群升级。 如需详细了解预检检查，请参阅了解预检检查。

您可以通过在运行升级之前运行预检检查来检查集群是否已准备好进行升级。如需了解详情，请参阅针对升级进行预检检查。

已知问题

如需了解与集群升级相关的潜在问题，请参阅 Anthos Clusters on Bare Metal 已知问题，并选择升级和更新问题类别。

配置升级选项

在开始集群升级之前，您可以配置以下升级选项来控制升级过程的工作原理：

这些选项可以降低关键应用和服务中断的风险，并显著缩短整体升级时间。这些选项对于具有大量节点和运行重要工作负载的节点池的大型集群特别有用。如需详细了解这些选项的用途以及如何使用它们，请参阅以下部分。

选择性工作器节点池升级

默认情况下，集群升级操作会升级集群中的每个节点和节点池。集群升级可能具有中断性且非常耗时，因为这会导致每个节点被排空，并且重启所有关联的 Pod 并重新调度。本部分介绍如何为集群升级添加或排除选定的工作器节点池，以最大限度地减少工作负载中断。此功能仅适用于用户集群、混合集群和独立集群，因为管理员集群不支持工作器节点池。

在以下情况下，您可以使用选择性节点池升级：

  • 如需在不中断工作负载的情况下获取安全修复程序：您可以仅升级控制平面节点（和负载均衡器节点）以应用 Kubernetes 漏洞修复，而不中断工作器节点池。

  • 如需在升级所有工作器节点之前确认升级的工作器节点子集正常运行，请执行以下操作：您可以先选择性地升级工作器节点池，以确保在升级另一个节点池之前，工作负载已在升级后的节点池上正常运行。

  • 缩短维护窗口：升级大型集群可能非常耗时，并且很难准确预测升级何时完成。集群升级时间与要升级的节点数量成正比。通过排除节点池减少升级的节点数，从而缩短升级时间。您可以多次升级，但较小且可预测的维护窗口可能有助于安排调度。

两个次要版本节点池版本偏差

使用 GKE on Bare Metal 次要版本 1.28 时，工作器节点池版本最多可以比集群（控制平面）版本落后两个次要版本。此 n-2 版本偏差以（预览版）功能的形式提供。n-2

  • 如需启用此预览版功能，请将 preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable 注解添加到您的集群配置文件中：

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...

    如果不启用此预览版功能，则工作器节点池和集群之间的最大版本偏差为一个次要版本。

如需详细了解选择性升级工作器节点池的版本控制规则，请参阅生命周期和集群升级各阶段的节点池版本控制规则。

升级集群控制平面和所选节点池

如需在初始集群升级时选择性地升级工作器节点池，请执行以下操作：

  1. 对于要包含在集群升级中的工作器节点池，请对 NodePool 规范进行以下更改之一：

    • 将 NodePool 规范中的 anthosBareMetalVersion 设置为集群目标升级版本。
    • 在 NodePool 规范中省略 anthosBareMetalVersion 字段。或者将其设置为空字符串。默认情况下，工作器节点池包含在集群升级中。

  2. 对于要从升级中排除的工作器节点池，请将 anthosBareMetalVersion 设置为集群的当前（升级前）版本：

  3. 按照开始升级集群中的说明继续升级。

    集群升级操作会升级以下节点：

    • 集群控制平面节点。
    • 负载均衡器节点池（如果集群使用一个 [spec.loadBalancer.nodePoolSpec]）。默认情况下，负载均衡器节点可以运行常规工作负载。您无法选择性地升级负载均衡器节点池，它始终包含在初始集群升级中。
    • 您尚未从升级中排除的工作器节点池。

例如，假设您的集群为 1.16.0 版，并且有两个工作器节点池：wpool01 和 wpool02。此外，假设您要将控制平面和 wpool01 升级到 1.28.400-gke.77，但您希望 wpool02 保留版本 1.16.0。

以下集群配置文件摘录展示了如何修改集群配置以支持这种部分升级：

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.400-gke.77
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

将节点池升级到当前集群版本

如果您已在集群升级中排除节点池，则可以运行集群升级，使它们升级到目标集群版本。已在集群升级中排除的工作器节点池的 NodePool 规范将 anthosBareMetalVersion 字段设置为先前（升级前）的集群版本。

如需将工作器节点池升级到当前升级的集群版本，请执行以下操作：

  1. 为要升级到当前集群版本的工作器节点池修改集群配置文件中的 NodePool 规范。将 anthosBareMetalVersion 设置为当前（升级后）的集群版本。

    如果选择多个工作器节点池进行升级，则集群规范中的 spec.nodePoolUpgradeStrategy.concurrentNodePools 值将确定并行升级的节点池数量（如有）。如果您不想同时升级工作器节点池，请一次选择一个节点池进行升级。

  2. 按照开始升级集群中的说明继续升级。

    集群升级操作仅升级您之前将 anthosBareMetalVersion 设置为当前升级的集群版本的已排除的工作器节点池。

例如，假设您已将集群升级到版本 1.28.400-gke.77，但节点池 wpool02 仍使用旧的预升级集群版本 1.16.0。工作负载在升级的节点池 wpool01 上正常运行，因此现在您还需要将 wpool02 升级为当前的集群版本。如需升级 wpool02，您可以移除 anthosBareMetalVersion 字段或将其值设置为空字符串。

以下集群配置文件摘录展示了如何修改集群配置以支持这种部分升级：

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.400-gke.77
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

并行升级

在典型的默认集群升级中，每个集群节点按顺序依次升级。本部分介绍如何配置集群和工作器节点池，以便在升级集群时并行升级多个节点。并行升级节点可以显著加快集群升级速度，尤其是对于具有数百个节点的集群。

有两种并行升级策略可用于加快集群升级：

  • 并发节点升级：您可以配置工作器节点池，以便多个节点并行升级。节点的并行升级在 NodePool 规范 (spec.upgradeStrategy.parallelUpgrade) 中进行配置，并且只有工作器节点池中的节点可以并行升级。控制平面或负载均衡器节点池中的节点一次只能升级一个。如需了解详情，请参阅节点升级策略。

  • 并发节点池升级：您可以配置集群，以便并行升级多个节点池。只有工作器节点池可以并行升级。控制平面和负载均衡器节点池一次只能升级一个。

节点升级策略

您可以配置工作器节点池，以便多个节点同时升级 (concurrentNodes)。您还可以为在整个升级过程中运行工作负载的节点数设置最小阈值 (minimumAvailableNodes)。此配置是在 NodePool 规范中进行的。如需详细了解这些字段，请参阅集群配置字段参考文档。

节点升级策略仅适用于工作器节点池。您无法为控制平面或负载均衡器节点池指定节点升级策略。在集群升级期间，控制层面和负载均衡器节点池中的节点会逐个升级。控制平面节点池和负载均衡器节点池在集群规范（controlPlane.nodePoolSpec.nodes 和 loadBalancer.nodePoolSpec.nodes）中指定。

为节点配置并行升级时，请注意以下限制：

  • concurrentNodes 的值不能超过节点池中节点数的 50%，也不能超过固定数量 15（以较小者为准）。例如，如果您的节点池有 20 个节点，则不能指定大于 10 的值。如果您的节点池有 100 个节点，则 15 是您可以指定的最大值。

  • 将 concurrentNodes 与 minimumAvailableNodes 结合使用时，组合值不能超过节点池中的节点总数。例如，如果您的节点池有 20 个节点，并且 minimumAvailableNodes 设置为 18，则 concurrentNodes 不能超过 2。同样，如果 concurrentNodes 设置为 10，则 minimumAvailableNodes 不能超过 10。

以下示例展示了包含 10 个节点的工作器节点池 np1。在升级中，一次升级 5 个节点，并且至少有 4 个节点必须继续可用，才能继续进行升级：

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4

节点池升级策略

您可以配置集群，以便多个工作器节点池并行升级。集群规范中的 nodePoolUpgradeStrategy.concurrentNodePools 布尔值字段指定是否同时升级集群的所有工作器节点池。默认情况下 (1)，节点池会按顺序升级。如果将 concurrentNodePools 设置为 0，则同时升级集群中的每个工作器节点池。

控制平面和负载均衡节点池不受此设置的影响。这些节点池始终按顺序逐个升级。控制平面节点池和负载均衡器节点池在集群规范（controlPlane.nodePoolSpec.nodes 和 loadBalancer.nodePoolSpec.nodes）中指定。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

如何执行并行升级

本部分介绍如何配置集群和工作器节点池以进行并行升级。

如需对工作器节点池和工作器节点池中的节点执行并行升级，请执行以下操作：

  1. 将 upgradeStrategy 部分添加到 NodePool 规范。

    在执行集群更新时，您可以单独应用此清单，也可以将其作为集群配置文件的一部分应用。

    示例如下：

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10

    在此示例中，字段 concurrentNodes 的值为 5，这意味着 5 个节点会并行升级。minimumAvailableNodes 字段设置为 10，这意味着至少有 10 个节点在升级过程中必须可用于工作负载。

  2. 将 nodePoolUpgradeStrategy 部分添加到集群配置文件中的集群规范。

    ---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

    在此示例中，concurrentNodePools 字段设置为 0，这意味着所有工作器节点池在集群升级期间并发升级。节点池中的节点升级策略在 NodePool 规范中定义。

  3. 按照上文升级管理员集群、独立集群、混合集群或用户集群部分中的说明升级集群。

并行升级默认值

默认情况下，并行升级处于停用状态，并且与并行升级相关的字段是可变的。您可以随时移除这些字段或将其设置为默认值，以便在后续升级之前停用该功能。

下表列出了并行升级字段及其默认值：

字段 默认值 含义
nodePoolUpgradeStrategy.concurrentNodePools（集群规范） 1 按顺序逐个升级工作器节点池。
upgradeStrategy.parallelUpgrade.concurrentNodes（NodePool 规范） 1 按顺序逐个升级节点。
upgradeStrategy.parallelUpgrade.minimumAvailableNodes（NodePool 规范） 默认的 minimumAvailableNodes 值取决于 concurrentNodes 的值。
  • 如果未指定 concurrentNodes，则默认情况下 minimumAvailableNodes 为节点池大小的 2/3。
  • 如果指定了 concurrentNodes，则默认情况下 minimumAvailableNodes 是节点池大小减去 concurrentNodes。
 一旦达到 minimumAvailableNodes，升级就会停止，并且仅在可用节点数量大于 minimumAvailableNodes 时继续升级。

开始升级集群

本部分包含升级集群的说明。

bmctl

下载并安装新版 bmctl 时，您可以升级使用较早版本创建的管理员集群、混合集群、独立集群和用户集群。对于给定的 bmctl 版本，集群只能升级到同一版本。

  1. 按照 GKE on Bare Metal 下载中的说明下载最新的 bmctl。

  2. 将集群配置文件中的 anthosBareMetalVersion 更新为升级目标版本。

    升级目标版本必须与下载的 bmctl 文件的版本匹配。以下集群配置文件代码段显示了更新为最新版本的 anthosBareMetalVersion 字段：

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.28.400-gke.77

  3. 使用 bmctl upgrade cluster 命令完成升级：

    bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    替换以下内容：

    • CLUSTER_NAME：要升级的集群的名称。
    • ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。

    集群升级操作会运行预检检查以验证集群状态和节点运行状况。如果预检检查失败，则不会继续集群升级。如需了解问题排查信息，请参阅排查集群安装或升级问题。

    所有集群组件都成功升级后，集群升级操作会执行集群健康检查。最后一步是验证集群是否处于正常运行状态。如果集群未通过所有健康检查，则会继续运行，直到通过为止。所有健康检查都通过后，升级就成功完成。

    如需详细了解集群升级的事件序列，请参阅集群升级的生命周期和阶段。

kubectl

如需使用 kubectl 升级集群，请执行以下步骤：

  1. 修改集群配置文件，将 anthosBareMetalVersion 设置为升级目标版本。

  2. 如需启动升级，请运行以下命令：

    kubectl apply -f CLUSTER_CONFIG_PATH

    将 CLUSTER_CONFIG_PATH 替换为修改后的集群配置文件的路径。

    与使用 bmctl 的升级过程一样，预检检查在集群升级的过程中运行，以验证集群状态和节点运行状况。如果预检检查失败，则系统会停止集群升级。如需排查任何故障问题，请检查集群和相关日志，因为未创建任何引导集群。 如需了解详情，请参阅排查集群安装或升级问题。

虽然您不需要最新版本的 bmctl 来使用 kubectl 进行升级，但我们建议您下载最新的 bmctl。您需要 bmctl 来执行其他任务，例如健康检查和备份，以确保集群保持良好的工作顺序。

暂停和恢复升级

使用 GKE on Bare Metal 次要版本 1.28，您可以暂停和恢复集群升级。集群升级暂停后，系统不会触发新的节点升级，直到升级恢复为止。此功能仅适用于所有控制平面节点均为次要版本 1.28 或更高版本的集群。

您可能会出于以下原因暂停升级：

  • 您在升级过程中检测到集群工作负载出现问题，想要暂停升级以调查该问题

  • 您的维护期较短，因此您需要在这两个窗口之间暂停升级

在集群升级暂停期间，支持以下操作：

如果在升级暂停期间添加新节点，则在升级恢复并完成之前，系统不会在该节点上运行机器检查作业。

集群升级暂停期间，以下集群操作不受支持：

活跃集群升级暂停时，您无法启动新的集群升级。

启用升级暂停和恢复功能

虽然升级暂停和恢复功能处于预览版阶段，但可以通过集群资源中的注解启用该功能。

如需启用升级暂停和恢复功能，请按以下步骤操作：

  1. 向集群配置文件添加 preview.baremetal.cluster.gke.io/upgrade-pause-and-resume 注解：

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
...

  2. 如需应用更改，请更新您的集群：

    bmctl update CLUSTER_NAME

    nodePoolUpgradeStrategy.pause 字段是可变的。您可以随时添加和更新。

暂停升级

如需暂停集群升级，您可以在集群规范中将 nodePoolUpgradeStrategy.pause 设置为 true。

如需暂停活跃集群升级，请按以下步骤操作：

  1. 将 nodePoolUpgradeStrategy.pause 添加到集群配置文件中，并将其设置为 true：

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
        preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...

    如果您使用 bmctl 启动升级，则需要一个新的终端窗口来执行下一步。

  2. 如需应用更改，请更新您的集群：

    bmctl update CLUSTER_NAME

    升级操作已暂停。系统不会触发新的节点升级。

  3. 如果您使用 bmctl 启动升级，并且计划长时间暂停，请按 Ctrl+C 退出 bmctl，否则，请让 bmctl 保持运行状态。

    bmctl CLI 未检测到升级暂停状态的变化，因此不会自动退出。但是，当您退出 bmctl 时，它会停止将升级进度记录到管理员工作站上集群文件夹中的 cluster-upgrade-TIMESTAMP 日志文件和 Cloud Logging 中。因此，对于短暂的暂停，您可能需要让 bmctl 保持运行状态。如果您在升级暂停期间让 bmctl 长时间运行，则最终会超时。

恢复已暂停的升级

如需恢复已暂停的集群升级，您可以在集群规范中将 nodePoolUpgradeStrategy.pause 设置为 false，或从规范中移除 nodePoolUpgradeStrategy.pause。

如需恢复已暂停的集群升级，请按以下步骤操作：

  1. 将 nodePoolUpgradeStrategy.pause 设置为集群配置文件，并将其设置为 false：

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
        preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

    或者，您也可以移除 pause 字段，因为它的默认值为 false。

  2. 如需应用更改，请更新您的集群：

    bmctl update CLUSTER_NAME

    升级操作会从中断的地方继续。

  3. 如需检查升级的状态，请先获取 status 中包含 anthosBareMetalVersion 的资源列表：

    kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces

    替换以下内容：

    • RESOURCE：您要获取的资源的名称。Cluster、NodePool 和 BareMetalMachine 资源都包含 anthosBareMetalVersion 状态信息。

    • ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。

    以下示例展示了 BareMetalMachine 自定义资源的响应格式。每个 BareMetalMachine 对应一个集群节点。

    NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2

  4. 如需查看 status.anthosBareMetalVersion（资源的当前版本），请检索各个资源的详细信息：

    kubectl describe RESOURCE RESOURCE_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

    以下示例显示了 IP 地址为 192.0.2.53 的集群节点的 BareMetalMachine 详细信息：

    Name:         192.0.2.53
Namespace:    cluster-nuc-user001
...
API Version:  infrastructure.baremetal.cluster.gke.io/v1
Kind:         BareMetalMachine
Metadata:
  Creation Timestamp:  2023-09-22T17:52:09Z
  ...
Spec:
  Address:                    192.0.2.53
  Anthos Bare Metal Version:  1.16.2
  ...
Status:
  Anthos Bare Metal Version:  1.16.2

    在此示例中，节点位于 GKE on Bare Metal 版本 1.16.2。