升级集群

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

如需详细了解升级过程和版本控制规则，请参阅集群升级的生命周期和阶段。

规划升级

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

最佳实践

如需了解如何为集群升级做好准备，请参阅 Google Distributed Cloud 集群升级的最佳做法。

升级预检检查

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

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

已知问题

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

配置升级选项

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

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

选择性工作器节点池升级

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

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

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

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

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

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

对于 1.28 及更高版本的集群，工作器节点池版本最多可落后集群（控制平面）版本两个次要版本。借助 n-2 版本偏差支持，您还可以在将工作器节点池从集群后的两个次要版本升级到与集群相同的次要版本时跳过某个次要发布版本。

这种对工作器节点池的 n-2 版本偏差支持可让您更灵活地规划舰队升级。

例如，如果您的集群是 1.28 版，您可以选择 1.28、1.16 和 1.15 版本拥有工作器节点池。如需将集群升级到 1.29 版，您必须先将任何 1.15 版工作器节点池升级到升级前 1.28 版集群支持的版本。无需将 1.16 版工作器节点池升级到 1.28 版，您就可以将集群升级到 1.29 版。集群升级到版本 1.29 后，如果您决定将版本 1.16 的工作器池升级到版本 1.29，则可以跳过版本 1.28，一步完成升级。

如需了解详情，包括给定集群版本所支持的受支持工作器节点池版本的列表，请参阅节点池版本控制规则

1.29

在 1.29 版中，对于所有集群类型，n-2 对工作器节点池的版本偏差支持已正式发布。对于版本 1.29 的集群，此功能默认处于启用状态。

当我们将此功能从公开预览版过渡到正式版时，在以下情况下，混合集群仍然需要预览版注解。如果您有 1.28.x 版本的混合集群和 1.16.y 版本的工作器节点池，必须先向集群添加 preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable 注解，然后才能将其升级到版本 1.29.z：

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:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1.28

1.28 版中的预览版提供了针对工作器节点池的 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.28.0 版，并且有两个工作器节点池：wpool01 和 wpool02。此外，假设您要将控制平面和 wpool01 升级到 1.29.100-gke.251，但希望 wpool02 保留为 1.28.0 版本。

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

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  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.28.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.29.100-gke.251，但节点池 wpool02 仍为升级前的旧集群版本 1.28.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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  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

回滚节点池升级

许多依赖项（例如与 kubelet 或插件的兼容性）可能会影响工作负载的性能。如果在升级工作器节点池后遇到问题，可以将节点池回滚到其先前版本。

节点池回滚功能适用于 1.29 版集群（控制平面节点为 1.29 版）的预览版。当此功能处于预览版阶段时，您必须向 Cluster 资源添加 preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable 注解才能启用此功能。

如需回滚节点池升级，请按以下步骤操作：

bmctl

使用 bmctl 回滚节点池升级时，您可以修改集群配置文件并使用 bmctl update 命令应用更改：

  1. 在集群配置文件中修改要回滚到先前版本的工作器节点池的 NodePool 规范。将 anthosBareMetalVersion 设置为上一个（升级前）集群版本。

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.500-gke.120
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

    如果选择了多个工作器节点池进行回滚，则集群规范中 spec.nodePoolUpgradeStrategy.concurrentNodePools 的值决定了并行回滚的节点池数量。如果您不想同时回滚工作器节点池，请一次选择一个节点池进行回滚，或者更新 nodePoolUpgradeStrategy 设置。同样，NodePool 规范中 spec.upgradeStrategy.parallelUpgrade.concurrentNodes 的值决定了并行回滚的节点数量。

  2. 使用 bmctl update 应用您的 NodePool 规范更改：

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    请替换以下内容：

    • CLUSTER_NAME：您要更新的集群的名称。

    • ADMIN_KUBECONFIG：管理集群（admin、hybrid 或 standalone）的 kubeconfig 文件的路径。

    回滚会自动开始。

  3. 在回滚运行时，Google Distributed Cloud 会对每个节点执行以下活动：

    • 将节点置于维护模式。
    • 在节点上运行重置作业，使其恢复到干净状态。
    • 在节点上运行机器预检检查。
    • 在节点上运行 machine-init 作业，以在目标回滚（升级前）版本中重新安装该作业。
    • 从维护模式中移除节点。

    回滚成功结束后，NodePool 资源中 nodePool.status.anthosBareMetalVersion 的值将设置为目标回滚版本。

kubectl

您可以使用 kubectl 直接修改 NodePool 资源来回滚节点池升级：

  1. 如需回滚工作器节点池，请打开 NodePool 资源进行修改：

    kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

    请替换以下内容：

    • NODE_POOL_NAME：您要回滚的节点池的名称。

    • CLUSTER_NAMESPACE：要在其中部署节点池的命名空间的名称。这是集群命名空间。

    • ADMIN_KUBECONFIG：管理集群（admin、hybrid 或 standalone）的 kubeconfig 文件的路径。

  2. 将 spec.anthosBareMetalVersion 的值更改为先前（升级前）的版本。

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.500-gke.120
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

  3. 保存并关闭编辑器中的 NodePool 资源。

    回滚会自动开始。

  4. 在回滚运行时，Google Distributed Cloud 会对每个节点执行以下活动：

    • 将节点置于维护模式。
    • 在节点上运行重置作业，使其恢复到干净状态。
    • 在节点上运行机器预检检查。
    • 在节点上运行 machine-init 作业，以在目标回滚（升级前）版本中重新安装该作业。
    • 从维护模式中移除节点。

    回滚成功结束后，NodePool 资源中 nodePool.status.anthosBareMetalVersion 的值将设置为目标回滚版本。

并行升级

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

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

  • 并发节点升级：您可以配置工作器节点池，以便多个节点并行升级。节点的并行升级在 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.29.100-gke.251
  ...
  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. 按照 Google Distributed Cloud 下载内容中的说明下载最新的 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.29.100-gke.251

  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 来执行其他任务，例如健康检查和备份，以确保集群保持良好的工作顺序。

暂停和恢复升级

借助升级暂停和恢复功能，您可以在集群升级完成之前暂停升级。暂停集群升级时，在升级恢复之前，不会触发新的工作器节点升级。

此功能在（预览版）中适用于所有控制平面节点均为次要版本 1.28 或更高版本的集群。此功能已正式发布，适用于所有控制平面节点均为次要版本 1.29 或更高版本的集群。

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

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

  • 您的维护窗口较短，因此您希望在两个窗口之间暂停升级

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

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

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

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

启用升级暂停和继续功能

Google Distributed Cloud 1.29

对于所有控制平面节点均为次要版本 1.29 或更高版本的集群，升级暂停和恢复功能默认处于启用状态。

Google Distributed Cloud 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
  ...
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
  ...
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

    在此示例中，节点为 Google Distributed Cloud 1.16.2 版。