升级 GKE on Bare Metal 集群时，升级过程涉及多个步骤和组件。为帮助监控升级状态或诊断和排查问题，了解运行 bmctl upgrade cluster 命令时发生的情况会有所帮助。本文档详细介绍了集群升级的组件和阶段。
概览
升级过程会将 GKE on Bare Metal 集群从当前版本迁移到更高版本。
此版本信息作为管理员集群中的集群自定义资源存储在以下位置：
status.anthosBareMetalVersion：定义集群的当前版本。spec.anthosBareMetalVersion：定义目标版本，并在升级过程开始运行时进行设置。
如果升级操作成功，会将目标版本从 spec.anthosBareMetalVersion 调整为 status.anthosBareMetalVersion。
版本偏差
版本偏差是指管理员集群与其受管用户集群之间的版本差异。GKE on Bare Metal 集群遵循与 Kubernetes 相同的风格：管理员集群最多可以比其代管式集群提前一个次要版本。
升级的版本规则
下载并安装新版本的 bmctl 时，您可以升级使用 bmctl 早期版本创建或升级的管理员集群、混合集群、独立集群和用户集群。集群不能降级到较低版本。
您只能将集群升级到与您正在使用的 bmctl 版本匹配的版本。也就是说，如果您使用的是 bmctl 1.15.11 版，则可以将集群仅升级到 1.15.11 版。
补丁版本升级
对于给定的次要版本，您可以升级到任何更高的补丁程序版本。也就是说，只要 Y 大于 X，您就可以将 1.15.X 版本集群升级到版本 1.15.Y。例如，您可以从 1.14.0 升级到 1.14.1，也可以从 1.14.1 升级到 1.14.3。我们建议您尽可能升级到最新的补丁程序版本，以确保您的集群拥有最新的安全修复程序。
次要版本升级
无论补丁程序版本如何，您都可将集群从一个次要版本升级到下一个次要版本。也就是说，您可以从 1.N.X 升级到 1.N+1.Y；其中，1.N.X 是您的集群版本，N+1 是下一个可用的次要版本。在这种情况下，补丁程序版本 X 和 Y 不会影响升级逻辑。例如，您可以从 1.14.3 升级到 1.15.11。
升级集群时，您无法跳过次要版本。如果您尝试升级到比集群版本高两个或更多的次要版本，次要版本 bmctl 会发出错误。例如，您无法将版本 1.13.0 的集群升级到版本 1.15.0。
管理员集群可以管理相同或先前次要版本的用户集群。受管用户集群最多只能比管理员集群低一个次要版本，因此在将管理员集群升级到新的次要版本之前，请确保所有受管用户集群都与管理员集群处于同一次要版本中。
以下升级说明中的示例展示了从版本 1.14.2 到 GKE on Bare Metal 1.15.11 的升级过程。
升级组件
组件在节点和集群级层进行升级。在集群级层会升级以下组件：
- 用于网络、可观测性和存储的集群组件。
- 管理员集群、混合集群和独立集群的生命周期控制器。
gke-connect-agent。
集群中的节点以下面的角色之一运行，不同的组件根据节点角色升级：
| 节点的角色 | 函数 | 要升级的组件 |
|---|---|---|
| 工作器 | 运行用户工作负载 | Kubelet、容器运行时（Docker 或 containerd） |
| 控制平面 | 运行 Kubernetes 控制平面、集群生命周期控制器和 Google Kubernetes Engine (GKE) 企业版平台插件 | Kubernetes 控制平面静态 Pod（kubeapi-server、kube-scheduler、kube-controller-manager、etcd）
生命周期控制器（例如 lifecycle-controllers-manager 和 anthos-cluster-operator）Google Kubernetes Engine (GKE) Enterprise 版本平台插件（例如 stackdriver-log-aggregator 和 gke-connect-agent） |
| 控制平面负载均衡器 | 运行 HAProxy 和 Keepalived 以将流量传输到 kube-apiserver，并运行 MetalLB speaker 来声明虚拟 IP 地址 |
控制平面负载均衡器静态 Pod（HAProxy、Keepalived）
MetalLB 扬声器 |
停机时间预期
下表详细介绍了升级集群时预计的停机时间和可能的影响。下表假定您有多个集群节点和一个 HA 控制平面。如果您运行独立集群或没有高可用性控制平面，则预计会产生额外的停机时间。除非另有说明，否则此停机时间适用于管理员集群和用户集群的升级：
| 组件 | 停机时间预期 | 发生停机的时间 |
|---|---|---|
Kubernetes 控制平面 API 服务器 (kube-apiserver)、etcd 和调度器 |
全年无休 | 不适用 |
生命周期控制器和 ansible-runner 作业（仅限管理员集群） |
全年无休 | 不适用 |
Kubernetes 控制平面 loadbalancer-haproxy 和 keepalived |
当负载均衡器重定向流量时，短暂停机（少于 1 到 2 分钟）。 | 开始升级过程。 |
可观测性 pipeline-stackdriver 和 metrics-server |
运算器已排空并升级。停机时间应少于 5 分钟。
DaemonSet 继续运行，没有停机时间。 |
控制平面节点完成升级后。 |
| 容器网络接口 (CNI) | 现有网络路由没有停机时间。 DaemonSet 以二比二部署，没有停机时间。 运算器已排空和升级。停机时间少于 5 分钟。 |
控制平面节点完成升级后。 |
| MetalLB（仅限用户集群） | 运算器已排空并升级。停机时间少于 5 分钟。
现有服务没有停机时间 |
控制平面节点完成升级后。 |
| CoreDNS 和 DNS 自动扩缩器（仅限用户集群） | CoreDNS 有多个使用自动扩缩器的副本。通常没有停机时间。 | 控制平面节点完成升级后。 |
| 本地卷预配工具 | 现有预配的永久性卷 (PV) 没有停机时间。
运算器可能会停机 5 分钟。 |
控制平面节点完成升级后。 |
| Istio/入站流量 | Istio 运算器已排空和升级。停机时间约为 5 分钟。 现有配置的入站流量继续有效。 |
控制平面节点完成升级后。 |
| 其他系统运算器 | 排空和升级时停机 5 分钟。 | 控制平面节点完成升级后。 |
| 用户工作负载 | 取决于设置，例如是否高可用性。 查看您自己的工作负载部署，了解潜在的影响。 |
工作器节点升级时。 |
用户集群升级详情
本部分详细介绍了用户集群升级的组件升级顺序和状态信息。以下部分详细介绍了管理员、混合或独立集群升级与此流程的差异。
下图展示了用户集群升级的预检检查过程：
上图详细介绍了升级过程中发生的步骤：
bmctl upgrade cluster命令会创建PreflightCheck自定义资源。- 此预检检查会运行其他检查，例如集群升级检查、网络健康检查和节点健康检查。
- 这些额外的检查结果会合并，以报告集群成功升级到目标版本的能力。
如果预检检查成功且没有阻塞问题，则集群中的组件会按指定顺序升级，如下图所示：
在上图中，组件按顺序升级，如下所示：
- 升级首先更新
spec.anthosBareMetalVersion字段。 - 控制平面负载均衡器升级。
- 控制平面节点池升级。
- GKE connect、集群插件和负载均衡器节点池并行升级。
- 负载均衡器节点池升级成功后，工作器节点池升级。
当所有组件都升级后，集群健康检查运行。
健康检查继续运行，直到所有检查都通过。
当所有健康检查都通过后，升级即完成。
每个组件在集群自定义资源内都有自己的状态字段。您可以检查以下字段中的状态，以了解升级进度：
| 序列 | 字段名称 | 含义 |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
从控制平面节点池状态复制状态。该字段包含控制平面节点池的节点版本 |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
应用到集群的 lifecycles-controllers-manager 的版本。此字段仅适用于管理员集群、独立集群或混合集群。 |
| 2 | status.anthosBareMetalManifestsVersion |
上次应用清单的集群的版本。 |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
从控制平面负载均衡器节点池状态复制状态。如果未在 Cluster.Spec 中指定单独的控制平面负载均衡器，则此字段为空。 |
| 3 | status.anthosBareMetalVersions |
版本到节点编号的聚合版本映射。 |
| 4 | status.anthosBareMetalVersion |
升级版本的最终状态。 |
管理员、混合和独立集群升级详情
从 bmctl 1.15.0 版开始，自行管理（管理员、混合或独立）集群的默认升级行为是就地升级。也就是说，将集群升级到 1.15.0 或更高版本时，升级会使用生命周期控制器（而不是引导集群）来管理整个升级过程。此更改简化了流程并降低了资源要求，从而使集群升级更可靠且可伸缩性更强。
虽然不建议使用引导集群进行升级，但此选项仍然可用。如需在升级时使用引导集群，请在运行 bmctl upgrade 命令时使用 --use-bootstrap=true 标志。升级的阶段各不相同，具体取决于您使用的方法。
就地升级
自行管理集群的默认就地升级过程类似于用户集群升级过程。但是，当您使用就地升级过程时，系统会在集群预检检查和健康检查运行之前部署新版本的 preflightcheck-operator：
与用户集群升级一样，升级过程首先将 Cluster.spec.anthosBareMetalVersion 字段更新为目标版本。在更新组件之前，需要额外执行两个步骤，如下图所示：lifecycle-controller-manager 会将自身升级到目标版本，然后部署 anthos-cluster-operator 的目标版本。此 anthos-cluster-operator 会执行升级过程的其余步骤：
成功完成后，anthos-cluster-operator 会将目标版本从 spec.anthosBareMetalVersion 调整为 status.anthosBareMetalVersion。
使用引导集群升级
升级管理员集群、混合集群或独立集群的过程与上一部分讨论的用户集群类似。
主要区别在于 bmctl upgrade cluster 命令会启动创建引导集群的过程。此引导集群是一个临时集群，用于在升级期间管理混合集群、管理员集群或独立集群。
将集群的管理所有权转移到引导集群的过程称为“数据透视”。升级的其余部分遵循与用户集群升级相同的过程。
在升级过程中，目标集群中的资源会过时。升级进度仅反映在引导集群的资源中。
如果需要，您可以访问引导集群以帮助监控和调试升级过程。您可以通过 bmctl-workspace/.kindkubeconfig 访问引导集群。
要在升级完成后将集群的管理所有权移回，集群会将资源从引导集群转换到升级后的集群。在升级过程中，无需执行手动步骤来透视集群。集群升级成功后，引导集群会被删除。
节点排空
GKE on Bare Metal 集群升级可能会在节点排空时导致应用中断。此排空过程会导致在节点上运行的所有 Pod 被关停并在集群中的其余节点上重启。
Deployment 可用于容忍此类中断。Deployment 可以指定应运行应用或服务的多个副本。具有多个副本的应用在升级期间应该不会遇到任何中断。
Pod 中断预算 (PDB)
Pod 中断预算 (PDB) 可用于确保规定数量的集群在正常运行条件下始终在集群中运行。借助 PDB，您可以在需要重新安排某个工作负载的 Pod 时仅限中断该工作负载。但是，当节点在升级期间排空时，GKE on Bare Metal 不会遵循 PDB。而是尽量排空节点。某些 Pod 可能会卡在 Terminating 状态，并拒绝虚拟化节点。如果节点上的排空过程时间超过 20 分钟，则即使 Pod 卡住，升级也会继续。