升级 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
版本匹配的版本。也就是说,如果您使用的是 1.29.100-gke.251 版的 bmctl
,则只能将集群升级到 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.600-gke.163
升级到 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.100-gke.251 |
|
|
|
|
1.29.0-gke.1449 |
|
|
|
1.28
集群(控制平面)版本 | 支持的工作器节点池版本 | |||
---|---|---|---|---|
1.28.600-gke.163 |
|
|
|
|
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
集群(控制平面)版本 | 支持的工作器节点池版本 | |||
---|---|---|---|---|
1.16.9 |
|
|
|
|
1.16.8 |
|
|
|
|
1.16.7 |
|
|
|
|
1.16.6 |
|
|
|
|
1.16.5 |
|
|
|
|
1.16.4 |
|
|
|
|
1.16.3 |
|
|
|
|
1.16.2 |
|
|
|
|
1.16.1 |
|
|
||
1.16.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
自定义资源。- 此预检检查会运行其他检查,例如集群升级检查、网络健康检查和节点健康检查。
- 这些额外的检查结果会合并,以报告集群成功升级到目标版本的能力。
如果预检检查成功且没有阻塞问题,则集群中的组件会按指定顺序升级,如下图所示:
在上图中,组件按顺序升级,如下所示:
- 升级首先更新
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
访问引导集群。
要在升级完成后将集群的管理所有权移回,集群会将资源从引导集群转换到升级后的集群。在升级过程中,无需执行手动步骤来透视集群。集群升级成功后,引导集群会被删除。
节点排空
由于节点已排空,Google Distributed Cloud 集群升级可能会导致应用中断。此排空过程会导致在节点上运行的所有 Pod 被关停并在集群中的其余节点上重启。
Deployment 可用于容忍此类中断。Deployment 可以指定应运行应用或服务的多个副本。具有多个副本的应用在升级期间应该不会遇到任何中断。
PodDisruptionBudgets
(PDB)
升级集群时,Google Distributed Cloud 会使用维护模式流程来排空节点。
从 1.29 版开始,节点使用 Eviction API 进行排空,该 API 遵循 PodDisruptionBudgets
(PDB)。PDB 可用于确保指定数量的副本在正常运行条件下始终在集群中运行。借助 PDB,您可以在需要重新安排某个工作负载的 Pod 时仅限中断该工作负载。基于逐出的节点排空在 1.29 版中作为正式版功能提供。
在 1.28 版及更早版本中,当节点在升级期间排空时,Google Distributed Cloud 不遵循 PDB。而是尽量排空节点。某些 Pod 可能会卡在 Terminating
状态,并拒绝空出节点。如果节点上的排空过程时间超过 20 分钟,则即使 Pod 卡住,升级也会继续进行。
如需了解详情,请参阅将节点置于维护模式。