版本 1.15。此版本已不再受支持。如需了解如何升级到版本 1.16，请参阅最新文档中的升级集群。如需详细了解受支持和不受支持的版本，请参阅最新文档中的版本历史记录页面。

升级集群

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

从 GKE on Bare Metal 1.15.0 版开始，自行管理（管理员、混合或独立）集群的默认升级行为是就地升级。就地升级使用生命周期控制器（而不是引导集群）来管理整个升级流程。此更改简化了流程并降低了资源要求，从而使集群升级更可靠且可伸缩性更强。

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

升级注意事项

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

最佳实践

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

升级预检检查

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

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

已知问题

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

升级管理员集群、独立集群、混合集群或用户集群

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

`bmctl`

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

按照 GKE on Bare Metal 下载中的说明下载最新的 bmctl。
将集群配置文件中的 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.15.11
```
使用 bmctl upgrade cluster 命令完成升级：
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
替换以下内容：
- CLUSTER_NAME：要升级的集群的名称。
- ADMIN_KUBECONFIG：管理员集群 kubeconfig 文件的路径。
集群升级操作会运行预检检查以验证集群状态和节点运行状况。如果预检检查失败，则不会继续集群升级。如需了解问题排查信息，请参阅排查集群安装或升级问题。

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

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

`kubectl`

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

修改集群配置文件，将 anthosBareMetalVersion 设置为升级目标版本。
如需启动升级，请运行以下命令：
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
将 CLUSTER_CONFIG_PATH 替换为已修改集群配置文件的路径。

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

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

并行升级

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

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

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

节点升级策略

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

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

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

concurrentNodes 的值不能超过节点池中节点数的 20% 或 10 个（以较小者为准）。例如，如果您的节点池有 40 个节点，则不能指定大于 8 的值。如果您的节点池有 100 个节点，则 10 是您可以指定的最大值。
将 concurrentNodes 与 minimumAvailableNodes 结合使用时，组合值不能超过节点池中的节点总数。例如，如果您的节点池有 20 个节点，并且 minimumAvailableNodes 设置为 18，则 concurrentNodes 不能超过 2。同样，如果 concurrentNodes 设置为 10，则 minimumAvailableNodes 不能超过 10。

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

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: 2
      minimumAvailableNodes: 5

节点池升级策略

您可以配置集群，以便多个工作器节点池并行升级。集群规范中的 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
  ...

如何执行并行升级

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

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

将 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 个节点在升级过程中必须可用于工作负载。

注意：您无法为控制平面或负载均衡器节点池指定节点升级策略。
将 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.15.0
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
在此示例中，concurrentNodePools 字段设置为 0，这意味着所有工作器节点池在集群升级期间并发升级。节点池中的节点升级策略在 NodePool 规范中定义。
按照上文升级管理员集群、独立集群、混合集群或用户集群部分中的说明升级集群。

如何停用节点的并行升级

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

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

字段	默认值	含义
`nodePoolUpgradeStrategy.concurrentNodePools`（集群规范）	`1`	按顺序逐个升级工作器节点池。
`upgradeStrategy.parallelUpgrade.concurrentNodes`（NodePool 规范）	`1`	按顺序逐个升级节点。
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes`（NodePool 规范）	`0`	不需要确保升级期间任何节点都可用。