自动升级
概述
您可以使用Rancher的system-upgrade-controller来管理RKE2集群的升级。这是一种Kubernetes原生的集群升级方法。它利用一个 Plan自定义资源来声明性地描述要升级的节点及其版本。
该计划定义了升级策略和要求。它还通过 标签选择器定义了哪些节点应该被升级。请参见下方适用于升级RKE2集群的默认计划。有关更高级的计划配置选项,请参见上面链接的计划文档。
Upgrade Controller通过监控计划并选择节点来调度升级,在这些节点上运行升级 作业。当作业成功完成后,控制器将相应地标记运行该作业的节点。
|
如果RKE2集群由Rancher管理,则应使用Rancher的用户界面来管理升级。
|
使用Upgrade Controller
要实现自动升级,您必须执行以下操作:
-
将system-upgrade-controller安装到您的集群中。
-
创建描述要升级的节点组及其方式的计划。
有关system-upgrade-controller的设计和架构或其与RKE2集成的更多详细信息,请参见以下Git仓库:
|
在尝试升级到新版本的RKE2时,适用 Kubernetes版本偏差策略。确保您的计划在升级时不会跳过中间的次要版本。系统升级控制器本身不会保护不支持的 Kubernetes 版本更改。 |
安装
Upgrade Controller清单安装了自定义资源定义、部署、服务帐户、集群角色绑定和配置映射。要安装这些组件,请运行以下命令:
kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/crd.yaml -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yaml
可以通过前面提到的配置映射来配置和自定义Upgrade Controller,但必须删除控制器 Pod 才能应用更改。
配置
服务器节点应始终在代理节点之前升级。
因此,建议您创建至少两个计划:一个用于升级服务器(控制平面)节点,另一个用于升级代理节点。
您可以根据需要创建其他计划,以控制升级在节点之间的推出。 一旦创建计划,控制器将拾取这些计划并开始升级您的集群。
以下两个示例计划将通过针对稳定的发布通道,持续保持您的集群升级到当前稳定版本:
# Server plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: server-plan
namespace: system-upgrade
spec:
concurrency: 1
cordon: true
nodeSelector:
matchExpressions:
- key: node-role.kubernetes.io/control-plane
operator: In
values:
- "true"
serviceAccountName: system-upgrade
upgrade:
image: rancher/rke2-upgrade
channel: https://update.rke2.io/v1-release/channels/stable
# Agent plan
apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
name: agent-plan
namespace: system-upgrade
spec:
concurrency: 1
cordon: true
nodeSelector:
matchExpressions:
- key: node-role.kubernetes.io/control-plane
operator: DoesNotExist
prepare:
args:
- prepare
- server-plan
image: rancher/rke2-upgrade
serviceAccountName: system-upgrade
upgrade:
image: rancher/rke2-upgrade
channel: https://update.rke2.io/v1-release/channels/stable
关于这些计划,有几个重要事项需要指出:
-
计划必须在控制器部署的同一名称空间中创建。
-
concurrency字段指示可以同时升级多少个节点。 -
服务器计划通过指定选择具有
node-role.kubernetes.io/control-plane标签的节点的标签选择器来针对服务器节点。代理计划通过指定选择没有该标签的节点的标签选择器来针对代理节点。 -
代理计划中的`prepare`步骤将导致该计划的升级作业在执行之前等待服务器计划完成。此逻辑内置于用于准备步骤的映像中,并不是Upgrade Controller本身的一部分。
-
两个计划的
channel字段都设置为稳定版本通道的 URL。这将导致控制器监控该URL,并在其解析为新版本时升级集群。这与发布通道配合良好。因此,您可以使用以下通道配置您的计划,以确保您的集群始终自动升级到最新稳定版本的RKE2。或者,您可以省略channel字段,并将version字段设置为 RKE2 的特定版本:apiVersion: upgrade.cattle.io/v1 kind: Plan # ... spec: # ... version: v1.33.4+rke2r1
一旦控制器检测到计划的目标版本已被解析,无论是通过版本字段还是通过轮询通道服务器,升级将开始。
修改计划会导致控制器重新评估该计划,并确定是否需要另一次升级。
如果已配置通道,URL 也会定期轮询以检查新版本。
您可以通过 kubectl 查看计划和作业来监控升级的进度:
kubectl -n system-upgrade get plans -o wide
kubectl -n system-upgrade get jobs
调度升级
通过在计划规范中设置 window 字段,可以限制计划在特定时间窗口内进行。
时间窗口字段与 kured 调度选项 兼容,并采用相同的格式。
例如:
apiVersion: upgrade.cattle.io/v1
kind: Plan
# ...
spec:
# ...
window:
days:
- monday
- tuesday
- wednesday
- thursday
- friday
startTime: 19:00
endTime: 21:00
timeZone: UTC
用于执行计划升级的作业不会在时间窗口外创建。一旦作业被创建,它们可能会在窗口关闭后继续运行。
防止降级
Kubernetes 不支持控制平面组件的降级。升级计划使用的 rke2-upgrade 镜像目前不包括任何检查,以防止计划将 Kubernetes 版本降级。
由 Rancher 提供的集群可以在恢复包含保证可被目标版本 Kubernetes 使用的数据的 etcd 快照时降级。有关更多信息,请参见 Rancher 文档。
未由 Rancher 提供的集群可以通过恢复 etcd 快照,手动回滚到先前的版本。有关更多信息,请参见 回滚 RKE2。