集群升级的生命周期和阶段

升级 Google Distributed Cloud 时，升级过程涉及多个步骤和多个组件。为帮助监控升级状态或诊断和排查问题，了解运行 bmctl upgrade cluster 命令时发生的情况会很有帮助。本文档详细介绍了集群升级的组成部分和阶段。

概览

升级过程会将 Google Distributed Cloud 集群从其当前版本迁移到更高版本。

此版本信息作为管理员集群中的集群自定义资源存储在以下位置：

  • status.anthosBareMetalVersion：定义集群的当前版本。

  • spec.anthosBareMetalVersion：定义目标版本，在升级过程开始运行时设置。

成功的升级操作会使 status.anthosBareMetalVersion 与 spec.anthosBareMetalVersion 协调一致，以便二者都显示目标版本。

集群版本偏差

集群版本偏差是指管理集群（混合集群或管理员集群）与其受管用户集群之间的版本差异。在添加或升级用户集群时，以下版本规则适用：

1.29

以下规则适用于由 1.29 版管理员集群或混合集群管理的用户集群：

  • 用户集群版本不能高于管理集群（管理员集群或混合集群）版本。

  • （1.29 预览版）用户集群最多可比管理集群版本低两个次要版本。例如，1.29 版管理员集群可以管理 1.16 版用户集群。此 n-2 版本偏差管理作为 1.29 版集群的预览版功能提供。

  • （1.29 预览版）对于给定的管理集群，用户集群无需彼此具有相同的次要版本。例如，1.29 版管理员集群可以管理 1.29 版、1.28 版和 1.16 版用户集群。此混合版本偏差管理作为 1.29 版集群的预览版功能提供。

    预览版多偏差管理功能可让您更灵活地规划舰队升级。例如，您无需将所有版本 1.16 的用户集群升级到版本 1.28，就可以将管理员集群升级到版本 1.29。

1.28 及更低版本

以下规则适用于由 1.28 版或更低版本的管理员集群或混合集群管理的用户集群：

  • 用户集群版本不能高于管理集群（管理员集群或混合集群）版本。

  • 用户集群最高可以比管理集群版本低一个次要版本。例如，1.28 版管理员集群无法管理 1.15 版的用户集群。

  • 对于给定的管理集群，所有受管用户集群必须位于同一次要版本。

如需了解节点池的版本偏差规则，请参阅节点池版本控制规则。

版本规则

下载并安装新版本的 bmctl 时，您可以升级使用 bmctl 早期版本创建或升级的管理员集群、混合集群、独立集群和用户集群。集群不能降级到较低版本。

您只能将集群升级到与您正在使用的 bmctl 版本匹配的版本。也就是说，如果您使用的是 bmctl 的 1.29.100-gke.251 版本，则可以将集群仅升级到 1.29.100-gke.251 版本。

补丁版本升级

对于给定的次要版本，您可以升级到任何更高的补丁程序版本。也就是说，只要 Y 大于 X，您就可以将 1.29.X 版本集群升级到版本 1.29.Y。例如，您可以从 1.28.0 升级到 1.28.100，也可以从 1.28.100 升级到 1.28.300。我们建议您尽可能升级到最新的补丁程序版本，以确保您的集群拥有最新的安全修复程序。

次要版本升级

无论补丁程序版本如何，您都可将集群从一个次要版本升级到下一个次要版本。也就是说，您可以从 1.N.X 升级到 1.N+1.Y；其中，1.N.X 是您的集群版本，N+1 是下一个可用的次要版本。在这种情况下，补丁程序版本 X 和 Y 不会影响升级逻辑。例如，您可以从 1.28.500-gke.120 升级到 1.29.100-gke.251。

升级集群时，您无法跳过次要版本。如果您尝试升级到比集群版本高两个或更多的次要版本，次要版本 bmctl 会发出错误。例如，您无法将版本 1.16.0 的集群升级到版本 1.29.0。

管理员集群可以管理相同或先前次要版本的用户集群。受管用户集群最多只能比管理员集群低一个次要版本，因此在将管理员集群升级到新的次要版本之前，请确保所有受管用户集群都与管理员集群处于同一次要版本中。

节点池版本控制规则

选择性地升级节点池时，以下版本规则适用：

1.29

  • 集群版本必须大于或等于工作器节点池版本。

  • （1.29 正式版）工作器节点池和集群之间的最大版本偏差是两个次要版本。

  • 工作器节点池的版本不得晚于集群版本的时间顺序。早期版本没有更高版本的全面详细信息，这是兼容性要求。

    例如，1.16.6 版是在 1.28.100-gke.146 版之后发布的，因此您无法将集群从 1.16.6 版升级到 1.28.100-gke.146 版，而将工作器节点池保留为 1.16.6 版。同样，如果您将集群升级到版本 1.28.100-gke.146，但选择保留版本 1.16.5 的工作器节点池，那么当集群版本为 1.28.100-gke.146 时，您无法将工作器节点池升级到版本 1.16.6。

1.28

  • 集群版本必须大于或等于工作器节点池版本。

  • （1.28 预览版）如果启用了 n-2 版本偏差预览版功能，则工作器节点池和集群之间的版本偏差上限是两个次要版本。如果您不启用此功能，则工作器节点池和集群之间的最大版本偏差为一个次要版本。

  • 工作器节点池的版本不得晚于集群版本的时间顺序。早期版本没有更高版本的全面详细信息，这是兼容性要求。

    例如，1.16.6 版是在 1.28.100-gke.146 版之后发布的，因此您无法将集群从 1.16.6 版升级到 1.28.100-gke.146 版，而将工作器节点池保留为 1.16.6 版。同样，如果您将集群升级到版本 1.28.100-gke.146，但选择保留版本 1.16.5 的工作器节点池，那么当集群版本为 1.28.100-gke.146 时，您无法将工作器节点池升级到版本 1.16.6。

1.16

  • 集群版本必须大于或等于工作器节点池版本。

  • 工作器节点池和集群之间的最大版本偏差为一个次要版本。

  • 工作器节点池的版本不得晚于集群版本的时间顺序。早期版本没有更高版本的全面详细信息，这是兼容性要求。

    例如，1.16.6 版是在 1.28.100-gke.146 版之后发布的，因此您无法将集群从 1.16.6 版升级到 1.28.100-gke.146 版，而将工作器节点池保留为 1.16.6 版。同样，如果您将集群升级到版本 1.28.100-gke.146，但选择保留版本 1.16.5 的工作器节点池，那么当集群版本为 1.28.100-gke.146 时，您无法将工作器节点池升级到版本 1.16.6。

下表列出了特定集群版本允许的受支持节点池版本：

1.29

集群（控制平面）版本 支持的工作器节点池版本
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1.28

集群（控制平面）版本 支持的工作器节点池版本
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

集群（控制平面）版本 支持的工作器节点池版本
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

升级组件

组件在节点和集群级层进行升级。在集群级层会升级以下组件：

  • 用于网络、可观测性和存储的集群组件。
  • 管理员集群、混合集群和独立集群的生命周期控制器。
  • gke-connect-agent。

集群中的节点以下面的角色之一运行，不同的组件根据节点角色升级：

节点的角色 函数 要升级的组件
工作器 运行用户工作负载 Kubelet、容器运行时（Docker 或 containerd）
控制平面 运行 Kubernetes 控制平面、集群生命周期控制器和 Google Kubernetes Engine (GKE) Enterprise 版平台插件 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 自定义资源。
  • 此预检检查会运行其他检查，例如集群升级检查、网络健康检查和节点健康检查。
  • 这些额外的检查结果会合并，以报告集群成功升级到目标版本的能力。

如果预检检查成功且没有阻塞问题，则集群中的组件会按指定顺序升级，如下图所示：

控制平面负载均衡器和控制平面节点池先升级，然后 GKE Connect、集群插件，以及负载均衡器节点池和工作器节点池升级。

在上图中，组件按顺序升级，如下所示：

  1. 升级首先更新 spec.anthosBareMetalVersion 字段。
  2. 控制平面负载均衡器升级。
  3. 控制平面节点池升级。
  4. GKE connect、集群插件和负载均衡器节点池并行升级。
    1. 负载均衡器节点池升级成功后，工作器节点池升级。

  5. 当所有组件都升级后，集群健康检查运行。

    健康检查继续运行，直到所有检查都通过。

  6. 当所有健康检查都通过后，升级即完成。

每个组件在集群自定义资源内都有自己的状态字段。您可以检查以下字段中的状态，以了解升级进度：

序列 字段名称 含义
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：

在集群预检检查对集群运行其他健康检查之前，系统会部署新版本的 preflightcheck-operator。

与用户集群升级一样，升级过程首先将 Cluster.spec.anthosBareMetalVersion 字段更新为目标版本。在更新组件之前会运行另外两个步骤，如下图所示：lifecycle-controller-manager 将自身升级到目标版本，然后部署 anthos-cluster-operator 的目标版本。此 anthos-cluster-operator 会执行升级过程的其余步骤：

runtime-controller-manager 和 anthos-cluster-operator 先部署完成，然后集群的其余部分采用与用户集群中的组件相同的顺序升级。

成功后，anthos-cluster-operator 会将目标版本从 spec.anthosBareMetalVersion 调整为 status.anthosBareMetalVersion。

使用引导集群升级

升级管理员集群、混合集群或独立集群的过程与上一部分讨论的用户集群类似。

主要区别在于 bmctl upgrade cluster 命令会启动创建引导集群的过程。此引导集群是一个临时集群，用于在升级期间管理混合集群、管理员集群或独立集群。

将集群的管理所有权转移到引导集群的过程称为“数据透视”。升级的其余部分遵循与用户集群升级相同的过程。

在升级过程中，目标集群中的资源会过时。升级进度仅反映在引导集群的资源中。

如果需要，您可以访问引导集群以帮助监控和调试升级过程。您可以通过 bmctl-workspace/.kindkubeconfig 访问引导集群。

要在升级完成后将集群的管理所有权移回，集群会将资源从引导集群转换到升级后的集群。在升级过程中，无需执行手动步骤来透视集群。集群升级成功后，引导集群会被删除。

节点排空

Google Distributed Cloud 集群升级可能会导致应用中断，因为节点已排空。此排空过程会导致在节点上运行的所有 Pod 被关停并在集群中的其余节点上重启。

Deployment 可用于容忍此类中断。Deployment 可以指定应运行应用或服务的多个副本。具有多个副本的应用在升级期间应该不会遇到任何中断。

PodDisruptionBudgets (PDB)

升级集群时，Google Distributed Cloud 会使用维护模式流程排空节点。

从版本 1.29 开始，Eviction API 支持 PodDisruptionBudgets (PDB) 功能，从而将节点排空。PDB 可用于确保指定数量的副本在正常运行条件下始终在集群中运行。借助 PDB，您可以在需要重新调度工作负载的 Pod 时，限制工作负载的中断情况。基于逐出的节点排空已作为正式版 1.29 版提供。

在 1.28 版及更早版本中，当节点在升级过程中排空时，Google Distributed Cloud 不会遵循 PDB。而是尽量排空节点。某些 Pod 可能会卡在 Terminating 状态并拒绝空出节点。当节点上的排空过程耗时超过 20 分钟时，即使 Pod 卡住，升级也会继续。

如需了解详情，请参阅将节点置于维护模式。

后续步骤