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

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

概览

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

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

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

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

成功的升级操作会使 status.anthosBareMetalVersionspec.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 是下一个可用的次要版本。在这种情况下,补丁程序版本 XY 不会影响升级逻辑。例如,您可以从 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-serverkube-schedulerkube-controller-manager、etcd)

生命周期控制器,例如 lifecycle-controllers-manageranthos-cluster-operator

Google Kubernetes Engine (GKE) Enterprise 版本平台插件,例如 stackdriver-log-aggregatorgke-connect-agent
控制平面负载均衡器 运行 HAProxy 和 Keepalived 以将流量传输到 kube-apiserver,并运行 MetalLB speaker 来声明虚拟 IP 地址 控制平面负载均衡器静态 Pod(HAProxy、Keepalived)

MetalLB 扬声器

停机时间预期

下表详细介绍了升级集群时预计的停机时间和可能的影响。下表假定您有多个集群节点和一个 HA 控制平面。如果您运行独立集群或没有高可用性控制平面,则预计会产生额外的停机时间。除非另有说明,否则此停机时间适用于管理员集群和用户集群的升级:

组件 停机时间预期 发生停机的时间
Kubernetes 控制平面 API 服务器 (kube-apiserver)、etcd 和调度器 全年无休 不适用
生命周期控制器和 ansible-runner 作业(仅限管理员集群) 全年无休 不适用
Kubernetes 控制平面 loadbalancer-haproxykeepalived 当负载均衡器重定向流量时,短暂停机(少于 1 到 2 分钟)。 开始升级过程。
可观测性 pipeline-stackdrivermetrics-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 卡住,升级也会继续。

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

后续步骤