升级集群

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

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

规划升级

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

最佳实践

如需了解如何帮助为集群升级做好准备，请参阅 Anthos Clusters on Bare Metal 集群升级的最佳做法。

升级预检检查

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

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

已知问题

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

配置升级选项

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

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

选择性工作器节点池升级

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例如，假设您的集群是 1.15.0 版本且具有两个工作器节点池：wpool01 和 wpool02。此外，假设您要将控制平面和 wpool01 升级到 1.16.8，但希望 wpool02 保留版本 1.15.0。

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

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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.15.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.16.8，但节点池 wpool02 仍使用旧版预升级集群版本 1.15.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.16.8
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.8
  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.16.8
  ...
  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.16.8

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