29 下游群集 #

本章介绍如何使用管理群集对下游群集的不同组件执行各种 Day 2 操作。

29.1 简介 #

本节旨在充当 Day 2 操作文档的起点，在其中可以找到以下信息。

用于在多个下游群集中实现 Day 2 操作的默认组件（第 29.1.1 节 “组件”）。
确定要为特定用例使用哪些 Day 2 资源（第 29.1.2 节 “确定您的用例”）。
Day 2 操作的建议工作流程顺序（第 29.1.3 节 “Day 2 工作流程”）。

29.1.1 组件 #

下面提供了为顺利执行 Day 2 操作而应在管理群集或下游群集上设置的默认组件的说明。

29.1.1.1 Rancher #

注意

如果您的用例需要使用 Fleet（第 6 章 “Fleet”）但不使用 Rancher，可以完全跳过 Rancher 组件的设置。

Rancher 负责管理您的下游群集。应将其部署在您的管理群集上。

有关详细信息，请参见第 4 章 “Rancher”。

29.1.1.2 Fleet #

Fleet 负责多群集资源部署。

通常由 Rancher 组件提供。对于不使用 Rancher 的用例，可将 Fleet 部署为独立组件。

有关将 Fleet 安装为独立组件的详细信息，请参见 Fleet 的安装细节。

有关 Fleet 组件的详细信息，请参见第 6 章 “Fleet”。

重要

本文档主要依赖于 Fleet，更具体地说，依赖于使用 GitRepo 和捆绑包资源（有关详细信息，请参见第 29.1.2 节 “确定您的用例”）来通过 GitOps 自动部署与 Day 2 操作相关的资源。

对于需要使用第三方 GitOps 工具的用例，请参见：

对于操作系统升级 - 第 29.2.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流程”
对于 Kubernetes 发行版升级 - 第 29.3.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流程”
对于 EIB 部署的 Helm chart 升级 - 第 29.4.3.3.4 节 “使用第三方 GitOps 工具进行 Helm chart 升级”
对于 非 EIB 部署的 Helm chart 升级 - 从第 45.1 节 “摘要”页面检索所需 Edge 版本支持的 chart 版本，并在第三方 GitOps 工具中填充 chart 版本和 URL

29.1.1.3 系统升级控制器 (SUC) #

系统升级控制器 (SUC) 负责根据通过名为计划的自定义资源提供的配置数据，在指定节点上执行任务。

注意

为了使 SUC 能够支持不同的 Day 2 操作，请务必将其部署在需要升级的每个下游群集上。

有关 SUC 组件及其如何安置到 Edge 堆栈中的详细信息，请参见系统升级控制器（第 19 章 “系统升级控制器”）组件文档。

有关如何在下游群集上部署 SUC 的信息，请先确定您的用例（第 29.1.2 节 “确定您的用例”），然后参见“系统升级控制器安装 - GitRepo”（第 19.2.1.1 节 “系统升级控制器安装 - GitRepo”）或“系统升级控制器安装 - 捆绑包”（第 19.2.1.2 节 “系统升级控制器安装 - 捆绑包”）。

29.1.2 确定您的用例 #

如前所述，与 Day 2 操作相关的资源将通过 Fleet 的 GitRepo 和捆绑包资源传播到下游群集。

下面提供了有关这些资源的作用，以及应在哪些用例中使用它们来执行 Day 2 操作的详细信息。

29.1.2.1 GitRepo #

GitRepo 是一种 Fleet（第 6 章 “Fleet”）资源，它代表一个 Git 储存库，Fleet 可从中创建捆绑包。每个捆绑包是基于 GitRepo 资源中定义的配置路径创建的。有关详细信息，请参见 GitRepo 文档。

就 Day 2 操作而言，GitRepo 资源通常用于在利用 Fleet GitOps 方法的非隔离环境中部署 SUC 或 SUC 计划。

或者，如果您通过本地 git 服务器镜像储存库设置，则 GitRepo 资源也可用于在隔离环境中部署 SUC 或 SUC 计划。

29.1.2.2 捆绑包 #

捆绑包包含了要在目标群集上部署的原始 Kubernetes 资源。通常它们是基于 GitRepo 资源创建的，但在某些用例中也可以手动部署。有关详细信息，请参见捆绑包文档。

就 Day 2 操作而言，捆绑包资源通常用于在不使用某种形式的本地 GitOps 过程（例如本地 git 服务器）的隔离环境中部署 SUC 或 SUC 计划。

或者，如果您的用例不允许使用 GitOps 工作流程（例如需使用 Git 储存库），则捆绑包资源也可用于在非隔离环境中部署 SUC 或 SUC 计划。

29.1.3 Day 2 工作流程 #

下面是在将下游群集升级到特定 Edge 版本时应遵循的 Day 2 工作流程。

操作系统升级（第 29.2 节 “操作系统升级”）
Kubernetes 版本升级（第 29.3 节 “Kubernetes 版本升级”）
Helm chart 升级（第 29.4 节 “Helm chart 升级”）

29.2 操作系统升级 #

29.2.1 组件 #

本节介绍操作系统升级过程在默认 Day 2 组件（第 29.1.1 节 “组件”）之外使用的自定义组件。

29.2.1.1 systemd.service #

根据 Edge 版本升级时您的操作系统所需的不同升级类型，会创建不同的 systemd.service：

对于需要相同操作系统版本（如 6.0）的 Edge 版本，将创建 os-pkg-update.service。它使用 transactional-update 命令执行常规的软件包升级。
对于需要迁移操作系统版本（例如 5.5 → 6.0）的 Edge 版本，将创建 os-migration.service。它使用 transactional-update 来执行：
- 首先是常规的软件包升级。这样做是为了确保所有软件包在迁移前都是最新版本，避免因软件包版本较旧而导致迁移失败。
- 之后，使用 zypper migration 命令继续执行操作系统迁移过程。

此组件随附于 SUC 计划，该计划应位于需要进行操作系统升级的每个下游群集上。

29.2.2 要求 #

一般：

已在 SCC 中注册的计算机 - 所有下游群集节点都应已注册到 https://scc.suse.com/。只有这样，os-pkg-update.service/os-migration.service 才能成功连接到所需的操作系统 RPM 储存库。
重要
对于需要新操作系统版本的 Edge 版本（例如 Edge 3.1），请确保您的 SCC 密钥支持迁移到新版本（例如，对于 Edge 3.1，SCC 密钥应支持从 SLE Micro 5.5 到 6.0 的迁移）。
确保 SUC 计划容忍度与节点容忍度相匹配 - 如果您的 Kubernetes 群集节点具有自定义污点，请确保在 SUC 计划中为这些污点添加容忍度。默认情况下，SUC 计划仅包含控制平面节点的容忍度。默认容忍度包括：
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  注意
  其他任何容忍度必须添加到每个计划的 .spec.tolerations 部分。与操作系统升级相关的 SUC 计划可以在 suse-edge/fleet-examples 储存库中的 fleets/day2/system-upgrade-controller-plans/os-upgrade 下找到。请确保使用有效储存库版本标记中的计划。
  为控制平面 SUC 计划定义自定义容忍度的示例如下：
  apiVersion: upgrade.cattle.io/v1 kind: Plan metadata: name: os-upgrade-control-plane spec: ... tolerations: # default tolerations - key: "CriticalAddonsOnly" operator: "Equal" value: "true" effect: "NoExecute" - key: "node-role.kubernetes.io/control-plane" operator: "Equal" effect: "NoSchedule" - key: "node-role.kubernetes.io/etcd" operator: "Equal" effect: "NoExecute" # custom toleration - key: "foo" operator: "Equal" value: "bar" effect: "NoSchedule" ...

隔离：

镜像 SUSE RPM 储存库 - 操作系统 RPM 储存库应镜像到本地，以便 os-pkg-update.service/os-migration.service 可以访问它们。方法是使用 RMT 或 SUMA。

29.2.3 更新过程 #

注意

本节假设您将使用 Fleet（第 6 章 “Fleet”）部署操作系统升级 SUC 计划。如果您打算使用其他方法部署 SUC 计划，请参见第 29.2.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流程”。

重要

对于之前使用此过程升级的环境，用户应确保完成以下步骤之一：

从下游群集中去除与旧版 Edge 相关的任何先前部署的 SUC 计划 - 方法是从现有的 GitRepo/Bundle 目标配置中去除所需的下游群集，或完全去除 GitRepo/Bundle 资源。
重用现有的 GitRepo/捆绑包资源 - 方法是将资源的修订版指向一个新标签，该标签包含所需 suse-edge/fleet-examples 版本的正确 Fleet。

这样做是为了避免旧版 Edge 的 SUC 计划之间发生冲突。

如果用户尝试升级，而下游群集上存在现有的 SUC 计划，他们将看到以下 Fleet 错误：

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

操作系统升级过程主要围绕着将 SUC 计划部署到下游群集来进行。这些计划将包含如何以及在哪些节点上部署 os-pkg-update.service/os-migration.service 的相关信息。有关 SUC 计划结构的信息，请参见上游文档。

操作系统升级 SUC 计划通过以下方式提供：

通过 GitRepo 资源 - 第 29.2.4.1 节 “SUC 计划部署 - GitRepo 资源”
通过捆绑包资源 - 第 29.2.4.2 节 “SUC 计划部署 - 捆绑包资源”

要确定使用哪个资源，请参见第 29.1.2 节 “确定您的用例”。

有关升级过程中会发生哪些情况的完整概述，请参见第 29.2.3.1 节 “概述”一节。

29.2.3.1 概述 #

本节旨在介绍操作系统升级过程从头到尾的完整工作流程。

图 29.1︰操作系统升级工作流程 #

操作系统升级步骤：

用户可以根据自己的用例，确定是要使用 GitRepo 还是捆绑包资源将操作系统升级 SUC 计划部署到所需的下游群集。有关如何将 GitRepo/捆绑包映射到特定的一组下游群集的信息，请参见映射到下游群集。
1. 如果您不确定是要使用 GitRepo 还是捆绑包资源进行 SUC 计划部署，请参见第 29.1.2 节 “确定您的用例”。
2. 有关 GitRepo/捆绑包配置选项，请参见第 29.2.4.1 节 “SUC 计划部署 - GitRepo 资源”或第 29.2.4.2 节 “SUC 计划部署 - 捆绑包资源”。
用户将配置的 GitRepo/捆绑包资源部署到其管理群集中的 fleet-default 名称空间。此操作可以手动完成，也可以通过 Rancher UI（如果可用）完成。
Fleet（第 6 章 “Fleet”）持续监控 fleet-default 名称空间，并立即检测新部署的 GitRepo/捆绑包资源。有关 Fleet 监控哪些名称空间的详细信息，请参见 Fleet 的名称空间文档。
如果用户已部署 GitRepo 资源，Fleet 将协调 GitRepo，并根据其路径和 fleet.yaml 配置，在 fleet-default 名称空间中部署捆绑包资源。有关详细信息，请参见 Fleet 的 GitRepo 内容文档。
然后，Fleet 继续将此捆绑包中的 Kubernetes 资源部署到所有目标下游群集。在进行操作系统升级时，Fleet 将部署捆绑包中的以下资源：
1. 工作 SUC 计划 - 告知 SUC 如何在群集工作节点上进行操作系统升级。如果群集仅由控制平面节点组成，则不会对其进行解释。它会在所有控制平面 SUC 计划成功完成后执行。
2. 控制平面 SUC 计划 - 告知 SUC 如何在群集控制平面节点上执行操作系统升级。
3. 脚本密钥 - 在每个 SUC 计划中引用；提供负责创建 os-pkg-update.service/os-migration.service（执行实际的操作系统升级）的 upgrade.sh 脚本。
4. 脚本数据 ConfigMap - 在每个 SUC 计划中引用；提供 upgrade.sh 脚本使用的配置。
  注意
  上述资源将部署在每个下游群集的 cattle-system 名称空间中。
在下游群集上，SUC 将拾取新部署的 SUC 计划，并在与 SUC 计划中定义的节点选择器匹配的每个节点上部署更新 Pod。有关如何监控 SUC 计划 Pod 的信息，请参见第 19.3 节 “监控系统升级控制器计划”。
更新 Pod（部署在每个节点上）会挂载脚本密钥并执行密钥附带的 upgrade.sh 脚本。
upgrade.sh 继续执行以下操作：
1. 根据其配置，确定操作系统是需要更新软件包，还是需要迁移。
2. 基于上述结果，它将创建一个 os-pkg-update.service（用于软件包更新）或 os-migration.service（用于迁移）。该服务将为 oneshot 类型，并将采用以下工作流程：
  1. 对于os-pkg-update.service：
    通过运行 transactional-update cleanup up 更新节点操作系统上的所有软件包版本
    成功执行 transactional-update 后，将安排系统重引导，使软件包版本更新生效
  2. 对于 os-migration.service：
    通过运行 transactional-update cleanup up 来更新节点操作系统上的所有软件包版本。这样做是为了确保不会因为软件包版本较旧而导致操作系统迁移错误。
    继续将操作系统迁移到所需值。迁移通过使用 zypper migration 命令完成。
    安排系统重引导，以便迁移生效
3. 启动 os-pkg-update.service/os-migration.service 并等待其完成。
4. systemd.service 完成其工作后会将 os-pkg-update.service/os-migration.service 从系统中去除，以确保将来不会发生意外的执行/重引导。

操作系统升级过程会在系统重引导后完成。重引导后，操作系统软件包版本将升级，操作系统还可能根据 Edge 版本的要求进行迁移。

29.2.4 操作系统升级 - SUC 计划部署 #

本节介绍如何使用 Fleet 的 GitRepo 和捆绑包资源来编排与 SUC 计划相关的操作系统升级的部署。

29.2.4.1 SUC 计划部署 - GitRepo 资源 #

附带所需操作系统升级 SUC 计划的 GitRepo 资源可通过以下方式之一部署：

通过 Rancher UI 部署 - 第 29.2.4.1.1 节 “GitRepo 创建 - Rancher UI”（如果 Rancher 可用）。
手动将相应资源部署（第 29.2.4.1.2 节 “GitRepo 创建 - 手动”）到管理群集。

部署后，要监控目标群集节点的操作系统升级过程，请参见第 19.3 节 “监控系统升级控制器计划”文档。

29.2.4.1.1 GitRepo 创建 - Rancher UI #

要通过 Rancher UI 创建 GitRepo 资源，请遵循其官方文档。

Edge 团队维护着一个即用型 fleet，用户可以将其添加为 GitRepo 资源的路径。

重要

请务必通过有效的 Edge 版本标记使用此 Fleet 。

对于不需要在 Fleet 附带的 SUC 计划 中包含自定义容忍度的用例，用户可以直接引用 suse-edge/fleet-examples 储存库中的 os-upgrade Fleet 。

在需要自定义容忍度的情况下，用户应从单独的储存库中引用 os-upgrade Fleet，以便能够根据需要将容忍度添加到 SUC 计划中。

有关如何配置 GitRepo 以使用 suse-edge/fleet-examples 储存库中的 Fleet 的示例，请参见此处。

29.2.4.1.2 GitRepo 创建 - 手动 #

提取 GitRepo 资源：

curl -o os-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/gitrepos/day2/os-upgrade-gitrepo.yaml

编辑 GitRepo 配置，在 spec.targets 下指定所需的目标列表。默认情况下，suse-edge/fleet-examples 中的 GitRepo 资源不会映射到任何下游群集。
- 为了匹配所有群集，请将默认的 GitRepo 目标更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 或者，如果您要更细致地选择群集，请参见映射到下游群集

将 GitRepo 资源应用于管理群集：

kubectl apply -f os-upgrade-gitrepo.yaml

查看 fleet-default 名称空间下创建的 GitRepo 资源：

kubectl get gitrepo os-upgrade -n fleet-default

# Example output
NAME            REPO                                              COMMIT         BUNDLEDEPLOYMENTS-READY   STATUS
os-upgrade      https://github.com/suse-edge/fleet-examples.git   release-3.1.2  0/0

29.2.4.2 SUC 计划部署 - 捆绑包资源 #

提供所需操作系统升级 SUC 计划的捆绑包资源可以通过以下方式之一进行部署：

通过 Rancher UI 部署 - 第 29.2.4.2.1 节 “捆绑包创建 - Rancher UI”（如果 Rancher 可用）。
手动将相应资源部署（第 29.2.4.2.2 节 “捆绑包创建 - 手动”）到管理群集。

部署后，要监控目标群集节点的操作系统升级过程，请参见第 19.3 节 “监控系统升级控制器计划”文档。

29.2.4.2.1 捆绑包创建 - Rancher UI #

Edge 团队维护着一个可在以下步骤中使用的即用型捆绑包。

重要

请务必通过有效的 Edge 版本标记使用此捆绑包。

要通过 Rancher 的 UI 创建捆绑包：

在左上角，单击 ☰ → Continuous Delivery（持续交付）
转到高级 > 捆绑包
选择从 YAML 创建
此处可通过以下方式之一创建捆绑包：
注意
在某些用例中，您可能需要在捆绑包附带的 SUC 计划中包含自定义容忍度。请确保在以下步骤生成的捆绑包中包含这些容忍度。
1. 手动将 suse-edge/fleet-examples 中的捆绑包内容复制到从 YAML 创建页面。
2. 从所需的版本标记克隆 suse-edge/fleet-examples 储存库，并在从 YAML 创建页面中选择从文件读取选项。然后导航到捆绑包位置 (bundles/day2/system-upgrade-controller-plans/os-upgrade) 并选择捆绑包文件。这会在从 YAML 创建页面中自动填充捆绑包内容。
更改捆绑包的目标群集：
- 为了匹配所有下游群集，请将默认的捆绑包 .spec.targets 更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 有关更精细的下游群集映射，请参见映射到下游群集。
选择创建

29.2.4.2.2 捆绑包创建 - 手动 #

提取捆绑包资源：

curl -o os-upgrade-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/bundles/day2/system-upgrade-controller-plans/os-upgrade/os-upgrade-bundle.yaml

编辑捆绑包目标配置，在 spec.targets 下提供所需的目标列表。默认情况下，suse-edge/fleet-examples 中的捆绑包资源不会映射到任何下游群集。
- 为了匹配所有群集，请将默认的捆绑包目标更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 或者，如果您要更细致地选择群集，请参见映射到下游群集
将捆绑包资源应用于管理群集：
```
kubectl apply -f os-upgrade-bundle.yaml
```
查看 fleet-default 名称空间下创建的捆绑包资源：
```
kubectl get bundles -n fleet-default
```

29.2.4.3 SUC 计划部署 - 第三方 GitOps 工作流程 #

在某些用例中，用户可能希望将操作系统升级 SUC 计划合并到他们自己的第三方 GitOps 工作流程（例如 Flux）中。

要获取所需的操作系统升级资源，首先请确定您要使用的 suse-edge/fleet-examples 储存库的 Edge 版本标记。

然后，便可以在 fleets/day2/system-upgrade-controller-plans/os-upgrade 中找到资源，其中：

plan-control-plane.yaml - 控制平面节点的系统升级控制器计划资源
plan-worker.yaml - 工作节点的系统升级控制器计划资源。
secret.yaml - 附带 upgrade.sh 脚本的密钥。
config-map.yaml - ConfigMap，提供 upgrade.sh 脚本使用的升级配置。

重要

这些计划资源由系统升级控制器解释，应部署在您要升级的每个下游群集上。有关如何部署系统升级控制器的信息，请参见第 19.2 节 “安装系统升级控制器”。

为了更好地了解如何使用 GitOps 工作流程来部署操作系统升级的 SUC 计划，建议查看有关使用 Fleet 进行更新的过程概述（第 29.2.3.1 节 “概述”）。

29.3 Kubernetes 版本升级 #

重要

本节介绍不是通过 Rancher（第 4 章 “Rancher”）实例创建的下游群集的 Kubernetes 升级过程。有关如何对通过 Rancher 创建的群集进行 Kubernetes 版本升级的信息，请参见升级和回滚 Kubernetes。

29.3.1 组件 #

本节介绍 Kubernetes 升级过程在默认 Day 2 组件（第 29.1.1 节 “组件”）之上使用的自定义组件。

29.3.1.1 rke2-upgrade #

负责升级特定节点的 RKE2 版本的映像。

此组件由 SUC 根据 SUC 计划创建的 Pod 交付。该计划应位于需要进行 RKE2 升级的每个下游群集上。

有关 rke2-upgrade 映像如何执行升级的详细信息，请参见上游文档。

29.3.1.2 k3s-upgrade #

负责升级特定节点的 K3s 版本的映像。

此组件由 SUC 根据 SUC 计划创建的 Pod 交付。该计划应位于需要进行 K3s 升级的每个下游群集上。

有关 k3s-upgrade 映像如何执行升级的详细信息，请参见上游文档。

29.3.2 要求 #

备份您的 Kubernetes 发行版：
1. 对于导入的 RKE2 群集，请参见 RKE2 备份和恢复文档。
2. 对于导入的 K3s 群集，请参见 K3s 备份和恢复文档。
确保 SUC 计划容忍度与节点容忍度相匹配 - 如果您的 Kubernetes 群集节点具有自定义污点，请确保在 SUC 计划中为这些污点添加容忍度。默认情况下，SUC 计划仅包含控制平面节点的容忍度。默认容忍度包括：
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  注意
  其他任何容忍度必须添加到每个计划的 .spec.tolerations 部分下。与 Kubernetes 版本升级相关的 SUC 计划可以在 suse-edge/fleet-examples 储存库中的以下位置找到：
  对于 RKE2 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade
  对于 K3s - fleets/day2/system-upgrade-controller-plans/k3s-upgrade
  请确保使用有效储存库版本标记中的计划。
  为 RKE2 控制平面 SUC 计划定义自定义容忍度的示例如下：
  apiVersion: upgrade.cattle.io/v1 kind: Plan metadata: name: rke2-upgrade-control-plane spec: ... tolerations: # default tolerations - key: "CriticalAddonsOnly" operator: "Equal" value: "true" effect: "NoExecute" - key: "node-role.kubernetes.io/control-plane" operator: "Equal" effect: "NoSchedule" - key: "node-role.kubernetes.io/etcd" operator: "Equal" effect: "NoExecute" # custom toleration - key: "foo" operator: "Equal" value: "bar" effect: "NoSchedule" ...

29.3.3 升级过程 #

注意

本节假设您将使用 Fleet（第 6 章 “Fleet”）部署 SUC 计划。如果您打算使用其他方法部署 SUC 计划，请参见第 29.3.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流程”。

重要

对于之前使用此过程升级的环境，用户应确保完成以下步骤之一：

从下游群集中去除与旧版 Edge 相关的任何先前部署的 SUC 计划 - 方法是从现有的 GitRepo/Bundle 目标配置中去除所需的下游群集，或完全去除 GitRepo/Bundle 资源。
重用现有的 GitRepo/捆绑包资源 - 方法是将资源的修订版指向一个新标签，该标签包含所需 suse-edge/fleet-examples 版本的正确 Fleet。

这样做是为了避免旧版 Edge 的 SUC 计划之间发生冲突。

如果用户尝试升级，而下游群集上存在现有的 SUC 计划，他们将看到以下 Fleet 错误：

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

Kubernetes 版本升级过程主要围绕着将 SUC 计划部署到下游群集来进行。这些计划包含的信息会告知 SUC 要在哪些节点上创建运行 rke2/k3s-upgrade 映像的 Pod。有关 SUC 计划结构的信息，请参见上游文档。

Kubernetes 升级计划通过以下方式交付：

通过 GitRepo 资源 - 第 29.3.4.1 节 “SUC 计划部署 - GitRepo 资源”
通过捆绑包资源 - 第 29.3.4.2 节 “SUC 计划部署 - 捆绑包资源”

要确定使用哪个资源，请参见第 29.1.2 节 “确定您的用例”。

有关更新过程中会发生哪些情况的完整概述，请参见第 29.3.3.1 节 “概述”一节。

29.3.3.1 概述 #

本节旨在介绍 Kubernetes 版本升级过程从头到尾的完整工作流程。

图 29.2︰ Kubernetes 版本升级工作流程 #

Kubernetes 版本升级步骤：

用户可以根据用例，确定是要使用 GitRepo 还是捆绑包资源将 Kubernetes 升级 SUC 计划部署到所需的下游群集。有关如何将 GitRepo/捆绑包映射到特定的一组下游群集的信息，请参见映射到下游群集。
1. 如果您不确定是要使用 GitRepo 还是捆绑包资源进行 SUC 计划部署，请参见第 29.1.2 节 “确定您的用例”。
2. 有关 GitRepo/捆绑包配置选项，请参见第 29.3.4.1 节 “SUC 计划部署 - GitRepo 资源”或第 29.3.4.2 节 “SUC 计划部署 - 捆绑包资源”。
用户将配置的 GitRepo/捆绑包资源部署到其管理群集中的 fleet-default 名称空间。此操作可以手动完成，也可以通过 Rancher UI（如果可用）完成。
Fleet（第 6 章 “Fleet”）持续监控 fleet-default 名称空间，并立即检测新部署的 GitRepo/捆绑包资源。有关 Fleet 监控哪些名称空间的详细信息，请参见 Fleet 的名称空间文档。
如果用户已部署 GitRepo 资源，Fleet 将协调 GitRepo，并根据其路径和 fleet.yaml 配置，在 fleet-default 名称空间中部署捆绑包资源。有关详细信息，请参见 Fleet 的 GitRepo 内容文档。
然后，Fleet 继续将此捆绑包中的 Kubernetes 资源部署到所有目标下游群集。在进行 Kubernetes 版本升级时，Fleet 将部署捆绑包中的以下资源（具体取决于 Kubernetes 发行版）：
1. rke2-upgrade-worker/k3s-upgrade-worker - 告知 SUC 如何在群集工作节点上执行 Kubernetes 升级。如果群集仅由控制平面节点组成，则不做解释。
2. rke2-upgrade-control-plane/k3s-upgrade-control-plane - 告知 SUC 如何在群集控制平面节点上执行 Kubernetes 升级。
  注意
  上述 SUC 计划将部署在每个下游群集的 cattle-system 名称空间中。
在下游群集上，SUC 将拾取新部署的 SUC 计划，并在与 SUC 计划中定义的节点选择器匹配的每个节点上部署更新 Pod。有关如何监控 SUC 计划 Pod 的信息，请参见第 19.3 节 “监控系统升级控制器计划”。
根据您部署的 SUC 计划，更新 Pod 将运行 rke2-upgrade 或 k3s-upgrade 映像，并在每个群集节点上执行以下工作流程：
1. 封锁群集节点 - 为了确保在升级此节点时不会意外调度任何 Pod，我们将此节点标记为不可调度。
2. 将节点操作系统上安装的 rke2/k3s 二进制文件替换为 Pod 当前正在运行的 rke2-upgrade/k3s-upgrade 映像附带的二进制文件。
3. 终止节点操作系统上正在运行的 rke2/k3s 进程 - 这会指示监督程序使用新版本自动重启动 rke2/k3s 进程。
4. 解封群集节点 - 成功完成 Kubernetes 发行版升级后，节点会重新标记为可调度。
  注意
  有关 rke2-upgrade 和 k3s-upgrade 映像工作原理的更多信息，请参见 rke2-upgrade 和 k3s-upgrade 上游项目。

执行上述步骤后，每个群集节点的 Kubernetes 版本应会升级到所需的 Edge 兼容版本。

29.3.4 Kubernetes 版本升级 - SUC 计划部署 #

本节介绍如何使用 Fleet 的 GitRepo 和捆绑包资源来编排 SUC 计划相关的 Kubernetes 升级的部署。

29.3.4.1 SUC 计划部署 - GitRepo 资源 #

可通过以下方式之一部署 GitRepo 资源，该资源中附带了所需的 Kubernetes 升级 SUC 计划：

通过 Rancher UI 部署 - 第 29.3.4.1.1 节 “GitRepo 创建 - Rancher UI”（如果 Rancher 可用）。
手动将相应资源部署（第 29.3.4.1.2 节 “GitRepo 创建 - 手动”）到管理群集。

部署后，要监控目标群集节点的 Kubernetes 升级过程，请参见第 19.3 节 “监控系统升级控制器计划”文档。

29.3.4.1.1 GitRepo 创建 - Rancher UI #

要通过 Rancher UI 创建 GitRepo 资源，请遵循其官方文档。

Edge 团队为 rke2 和 k3s Kubernetes 发行版维护着即用型 Fleet，用户可以将其添加为 GitRepo 资源的路径。

重要

请务必通过有效的 Edge 版本标记使用此 Fleet。

对于不需要在这些 Fleet 附带的 SUC 计划中包含自定义容忍度的用例，用户可以直接引用 suse-edge/fleet-examples 储存库中的 Fleet。

如果需要自定义容忍度，用户应从单独的储存库中引用 Fleet，以便能够根据需要将容忍度添加到 SUC 计划中。

使用 suse-edge/fleet-examples 储存库中的 Fleet 配置 GitRepo 资源的示例：

29.3.4.1.2 GitRepo 创建 - 手动 #

提取 GitRepo 资源：

对于 RKE2 群集：

curl -o rke2-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/gitrepos/day2/rke2-upgrade-gitrepo.yaml

对于 K3s 群集：

curl -o k3s-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/gitrepos/day2/k3s-upgrade-gitrepo.yaml

编辑 GitRepo 配置，在 spec.targets 下指定所需的目标列表。默认情况下，suse-edge/fleet-examples 中的 GitRepo 资源不会映射到任何下游群集。
- 为了匹配所有群集，请将默认的 GitRepo 目标更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 或者，如果您要更细致地选择群集，请参见映射到下游群集

将 GitRepo 资源应用于管理群集：

# RKE2
kubectl apply -f rke2-upgrade-gitrepo.yaml

# K3s
kubectl apply -f k3s-upgrade-gitrepo.yaml

查看 fleet-default 名称空间下创建的 GitRepo 资源：

# RKE2
kubectl get gitrepo rke2-upgrade -n fleet-default

# K3s
kubectl get gitrepo k3s-upgrade -n fleet-default

# Example output
NAME           REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    https://github.com/suse-edge/fleet-examples.git   release-3.1.2   0/0
rke2-upgrade   https://github.com/suse-edge/fleet-examples.git   release-3.1.2   0/0

29.3.4.2 SUC 计划部署 - 捆绑包资源 #

可通过以下方式之一部署捆绑包资源，该资源中附带了所需的 Kubernetes 升级 SUC 计划：

通过 Rancher UI 部署 - 第 29.3.4.2.1 节 “捆绑包创建 - Rancher UI”（如果 Rancher 可用）。
手动将相应资源部署（第 29.3.4.2.2 节 “捆绑包创建 - 手动”）到管理群集。

部署后，要监控目标群集节点的 Kubernetes 升级过程，请参见第 19.3 节 “监控系统升级控制器计划”文档。

29.3.4.2.1 捆绑包创建 - Rancher UI #

Edge 团队为 rke2 和 k3s Kubernetes 发行版维护着即用型捆绑包，可用于以下步骤。

重要

请务必通过有效的 Edge 版本标记使用此捆绑包。

要通过 Rancher 的 UI 创建捆绑包：

在左上角，单击 ☰ → Continuous Delivery（持续交付）
转到高级 > 捆绑包
选择从 YAML 创建
此处可通过以下方式之一创建捆绑包：
注意
在某些用例中，您可能需要在捆绑包附带的 SUC 计划中包含自定义容忍度。请确保在以下步骤生成的捆绑包中包含这些容忍度。
1. 通过手动将 RKE2 或 K3s 的捆绑包内容从 suse-edge/fleet-examples 复制到 从 YAML 创建页面。
2. 通过从所需的版本标记克隆 suse-edge/fleet-examples 储存库，并在从 YAML 创建页面中选择从文件读取选项。然后导航到所需的捆绑包（对于 RKE2，为 bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml；对于 K3s，为 bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml）。这会在从 YAML 创建页面中自动填充捆绑包内容。
更改捆绑包的目标群集：
- 为了匹配所有下游群集，请将默认的捆绑包 .spec.targets 更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 有关更精细的下游群集映射，请参见映射到下游群集。
创建

29.3.4.2.2 捆绑包创建 - 手动 #

提取捆绑包资源：

对于 RKE2 群集：

curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml

对于 K3s 群集：

curl -o k3s-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml

编辑捆绑包目标配置，在 spec.targets 下提供所需的目标列表。默认情况下，suse-edge/fleet-examples 中的捆绑包资源不会映射到任何下游群集。
- 为了匹配所有群集，请将默认的捆绑包目标更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 或者，如果您要更细致地选择群集，请参见映射到下游群集

将捆绑包资源应用于管理群集：

# For RKE2
kubectl apply -f rke2-plan-bundle.yaml

# For K3s
kubectl apply -f k3s-plan-bundle.yaml

查看 fleet-default 名称空间下创建的捆绑包资源：

# For RKE2
kubectl get bundles rke2-upgrade -n fleet-default

# For K3s
kubectl get bundles k3s-upgrade -n fleet-default

# Example output
NAME           BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    0/0
rke2-upgrade   0/0

29.3.4.3 SUC 计划部署 - 第三方 GitOps 工作流程 #

在某些用例中，用户可能希望将 Kubernetes 升级资源合并到他们自己的第三方 GitOps 工作流程（例如 Flux）中。

要获取所需的升级资源，首先请确定您要使用的 suse-edge/fleet-examples 储存库的 Edge 版本标记。

然后，便可以在以下位置查找资源：

对于 RKE2 群集升级：
- 对于控制平面节点 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-control-plane.yaml
- 对于工作节点 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-agent.yaml
对于 K3s 群集升级：
- 对于控制平面节点 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-control-plane.yaml
- 对于工作节点 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-agent.yaml

重要

为了更好地了解如何使用 GitOps 工作流程来部署 Kubernetes 版本升级的 SUC 计划，建议查看有关使用 Fleet 进行更新的过程概述（第 29.3.3.1 节 “概述”）。

29.4 Helm chart 升级 #

注意

以下章节重点介绍如何使用 Fleet 功能实现 Helm chart 更新。

对于需要使用第三方 GitOps 工具的用例，请参见：

对于 EIB 部署的 Helm chart 升级 - 第 29.4.3.3.4 节 “使用第三方 GitOps 工具进行 Helm chart 升级”。
对于非 EIB 部署的 Helm chart 升级 - 从发行说明（第 45.1 节 “摘要”）页面检索所需 Edge 版本支持的 chart 版本，并在第三方 GitOps 工具中填充 chart 版本和 URL。

29.4.1 组件 #

除了默认的 Day 2 组件（第 29.1.1 节 “组件”）之外，此操作不需要其他自定义组件。

29.4.2 为隔离环境做好准备 #

29.4.2.1 确保您有权访问 Helm chart 的升级 Fleet #

根据环境支持的情况，选择以下选项之一：

将 chart 的 Fleet 资源托管在管理群集可访问的本地 git 服务器上。
使用 Fleet 的 CLI 将 Helm chart 转换为捆绑包，以便直接使用，而不必托管于某处。Fleet 的 CLI 可以从其版本页面中检索，对于 Mac 用户，有一个 fleet-cli Homebrew Formulae。

29.4.2.2 找到 Edge 发行版本的所需资产 #

转到 Day 2 版本页面，找到您要将 chart 升级到的 Edge 3.X.Y 版本，然后单击资产。

从“Assets”（资产）部分下载以下文件：

版本文件	说明
edge-save-images.sh	提取 `edge-release-images.txt` 文件中指定的映像，并将其封装到“.tar.gz”归档中。
edge-save-oci-artefacts.sh	提取与特定 Edge 版本相关的 OCI chart 映像，并将其封装到“.tar.gz”归档中。
edge-load-images.sh	从“.tar.gz”存档加载映像，将它们重新标记并推送到专用注册表。
edge-load-oci-artefacts.sh	获取包含 Edge OCI '.tgz' chart 软件包的目录，并将其加载到专用注册表中。
edge-release-helm-oci-artefacts.txt	包含与特定 Edge 版本相关的 OCI chart 映像的列表。
edge-release-images.txt	包含与特定 Edge 版本相关的映像列表。

29.4.2.3 创建 Edge 版本映像存档 #

在可以访问互联网的计算机上：

将 edge-save-images.sh 设为可执行文件：
```
chmod +x edge-save-images.sh
```

生成映像存档：

./edge-save-images.sh --source-registry registry.suse.com

这将创建一个名为 edge-images.tar.gz 的可加载存档。
注意
如果指定了 -i|--images 选项，存档的名称可能会不同。

将此存档复制到隔离的计算机：

scp edge-images.tar.gz <user>@<machine_ip>:/path

29.4.2.4 创建 Edge OCI chart 映像存档 #

在可以访问互联网的计算机上：

将 edge-save-oci-artefacts.sh 设为可执行文件：
```
chmod +x edge-save-oci-artefacts.sh
```

生成 OCI chart 映像存档：

./edge-save-oci-artefacts.sh --source-registry registry.suse.com

这将创建一个名为 oci-artefacts.tar.gz 的归档。
注意
如果指定了 -a|--archive 选项，归档的名称可能会不同。

将此存档复制到隔离的计算机：

scp oci-artefacts.tar.gz <user>@<machine_ip>:/path

29.4.2.5 将 Edge 版本映像加载到隔离的计算机上 #

在隔离的计算机上：

登录到专用注册表（如果需要）：
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
将 edge-load-images.sh 设为可执行文件：
```
chmod +x edge-load-images.sh
```
执行脚本，传递之前复制的 edge-images.tar.gz 存档：
```
./edge-load-images.sh --source-registry registry.suse.com --registry <REGISTRY.YOURDOMAIN.COM:PORT> --images edge-images.tar.gz
```
注意
这将从 edge-images.tar.gz 加载所有映像，并将它们重新标记并推送到 --registry 选项下指定的注册表。

29.4.2.6 将 Edge OCI chart 映像加载到隔离的计算机上 #

在隔离的计算机上：

登录到专用注册表（如果需要）：
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
将 edge-load-oci-artefacts.sh 设为可执行文件：
```
chmod +x edge-load-oci-artefacts.sh
```
解压缩复制的 oci-artefacts.tar.gz 存档：
```
tar -xvf oci-artefacts.tar.gz
```
这会使用命名模板 edge-release-oci-tgz-<date> 生成一个目录
将此目录传递给 edge-load-oci-artefacts.sh 脚本，以将 Edge OCI chart 映像加载到专用注册表中：
注意
此脚本假设您的环境中已预装了 Helm CLI。有关 Helm 安装说明，请参见安装 Helm。
```
./edge-load-oci-artefacts.sh --archive-directory edge-release-oci-tgz-<date> --registry <REGISTRY.YOURDOMAIN.COM:PORT> --source-registry registry.suse.com
```

29.4.2.7 为 Kubernetes 发行版创建指向专用注册表的注册表镜像 #

对于 RKE2，请参见 Containerd 注册表配置

对于 K3s，请参见嵌入式注册表镜像

29.4.3 升级过程 #

本节重点介绍以下使用场景的 Helm 升级过程：

我有一个新群集，想要部署和管理 SUSE Helm chart（第 29.4.3.1 节 “我有一个新群集，想要部署和管理 SUSE Helm chart”）
我想升级 Fleet 管理的 Helm chart（第 29.4.3.2 节 “我想升级 Fleet 管理的 Helm chart”）
我想升级 EIB 部署的 Helm chart（第 29.4.3.3 节 “我想升级 EIB 部署的 Helm chart”）

重要

手动部署的 Helm chart 无法可靠升级。我们建议使用第 29.4.3.1 节 “我有一个新群集，想要部署和管理 SUSE Helm chart”方法重新部署这些 Helm chart。

29.4.3.1 我有一个新群集，想要部署和管理 SUSE Helm chart #

适用于想要通过 Fleet 管理其 Helm chart 生命周期的用户。

本节介绍如何：

准备 Fleet 资源（第 29.4.3.1.1 节 “准备 Fleet 资源”）。
部署 Fleet 资源（第 29.4.3.1.2 节 “部署您的 Fleet”）。
管理部署的 Helm chart（第 29.4.3.1.3 节 “管理部署的 Helm chart”）。

29.4.3.1.1 准备 Fleet 资源 #

从您要使用的 Edge 版本标记中获取 Chart 的 Fleet 资源
1. 从选定的 Edge 版本标记修订版导航到 Helm chart Fleet 目录 - fleets/day2/chart-templates/<chart>
2. 如果您打算使用 GitOps 工作流程，请将 chart Fleet 目录复制到 Git 储存库，从那里执行 GitOps。
3. （可选）如果 Helm chart 需要对其值进行配置，请编辑复制的目录中 fleet.yaml 文件内的 .helm.values 配置。
4. （可选）在某些用例中，您可能需要向 chart 的 Fleet 目录添加其他资源，使该目录能够更好地适应您的环境。有关如何增强 Fleet 目录的信息，请参见 Git 储存库内容。

longhorn Helm chart 的示例如下：

用户 Git 储存库结构：

<user_repository_root>
├── longhorn
│   └── fleet.yaml
└── longhorn-crd
    └── fleet.yaml

填充了用户 longhorn 数据的 fleet.yaml 内容：

defaultNamespace: longhorn-system

helm:
  releaseName: "longhorn"
  chart: "longhorn"
  repo: "https://charts.rancher.io/"
  version: "104.2.2+up1.7.3"
  takeOwnership: true
  # custom chart value overrides
  values:
    # Example for user provided custom values content
    defaultSettings:
      deletingConfirmationFlag: true

# https://fleet.rancher.io/bundle-diffs
diff:
  comparePatches:
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: engineimages.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: nodes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: volumes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}

注意

上面只是一些示例值，用于演示基于 longhorn chart 创建的自定义配置。不应将它们视为 longhorn chart 的部署指南。

29.4.3.1.2 部署您的 Fleet #

如果环境支持使用 GitOps 工作流程，您可以使用 GitRepo（第 29.4.3.1.2.1 节 “GitRepo”）或捆绑包（第 29.4.3.1.2.2 节 “捆绑包”）部署 Chart Fleet。

注意

部署 Fleet 时，如果有消息告知已修改，请确保在 Fleet 的 diff 部分添加相应的 comparePatches 项。有关详细信息，请参见产生差异以忽略修改的 GitRepos。

29.4.3.1.2.1 GitRepo #

Fleet 的 GitRepo 资源包含如何访问 chart 的 Fleet 资源以及需要将这些资源应用于哪些群集的相关信息。

可以通过 Rancher UI 或者通过将资源手动部署到管理群集来部署 GitRepo 资源。

用于手动部署的 Longhorn GitRepo 资源示例：

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: longhorn-git-repo
  namespace: fleet-default
spec:
  # If using a tag
  # revision: <user_repository_tag>
  #
  # If using a branch
  # branch: <user_repository_branch>
  paths:
  # As seen in the 'Prepare your Fleet resources' example
  - longhorn
  - longhorn-crd
  repo: <user_repository_url>
  targets:
  # Match all clusters
  - clusterSelector: {}

29.4.3.1.2.2 捆绑包 #

捆绑包资源包含需要由 Fleet 部署的原始 Kubernetes 资源。一般情况下，建议使用 GitRepo 方法，但对于无法支持本地 Git 服务器的隔离环境，捆绑包可以帮助您将 Helm chart Fleet 传播到目标群集。

捆绑包的部署可以通过 Rancher UI（持续交付→高级→捆绑包→从 YAML 创建），也可以通过在正确的 Fleet 名称空间中手动部署捆绑包资源。有关 Fleet 名称空间的信息，请参见上游文档。

使用手动方法部署 Longhorn 捆绑包资源的示例：

导航到 fleets/day2/chart-templates/longhorn/longhorn 下的 Longhorn Chart Fleet：
```
cd fleets/day2/chart-templates/longhorn/longhorn
```
创建一个指示 Fleet 应将 Helm chart 部署到哪些群集的 targets.yaml 文件。在本例中，我们将部署到单个下游群集。有关如何映射更复杂目标的信息，请参见映射到下游群集：
```
cat > targets.yaml <<EOF
targets:
- clusterName: foo
EOF
```
将 Longhorn Helm chart Fleet 转换为捆绑包资源。有关详细信息，请参见将 Helm Chart 转换为捆绑包：
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-bundle > longhorn-bundle.yaml
```
导航到fleets/day2/chart-templates/longhorn/longhorn-crd 下的 Longhorn CRD Chart Fleet：
```
cd fleets/day2/chart-templates/longhorn/longhorn-crd
```
创建一个指示 Fleet 应将 Helm chart 部署到哪些群集的 targets.yaml 文件。在本例中，我们将部署到单个下游群集。有关如何映射更复杂目标的信息，请参见映射到下游群集：
```
cat > targets.yaml <<EOF
targets:
- clusterName: foo
EOF
```
将 Longhorn CRD Helm chart Fleet 转换为捆绑包资源。有关详细信息，请参见将 Helm Chart 转换为捆绑包：
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-crd-bundle > longhorn-crd-bundle.yaml
```
将 longhorn-bundle.yaml 和 longhorn-crd-bundle.yaml 部署到您的管理群集：
```
kubectl apply -f longhorn-crd-bundle.yaml
kubectl apply -f longhorn-bundle.yaml
```

遵循这些步骤将确保 Longhorn 部署在所有指定的目标群集上。

29.4.3.1.3 管理部署的 Helm chart #

通过 Fleet 部署后，要进行 Helm chart 升级，请参见第 29.4.3.2 节 “我想升级 Fleet 管理的 Helm chart”。

29.4.3.2 我想升级 Fleet 管理的 Helm chart #

确定需要将 chart 升级到哪个版本，以便它与所需的 Edge 版本兼容。有关每个 Edge 版本兼容的 Helm chart 版本，可参见发行说明（第 45.1 节 “摘要”）。
在 Fleet 监控的 Git 储存库中，根据发行说明（第 45.1 节 “摘要”）中所述，将 Helm chart 的 fleet.yaml 文件中的 chart 版本和储存库更改为正确的值。
提交更改并将其推送到储存库后，会触发所需 Helm chart 的升级

29.4.3.3 我想升级 EIB 部署的 Helm chart #

EIB 通过创建 HelmChart 资源并利用 RKE2/K3s Helm 集成功能引入的 helm-controller 来部署 Helm chart。

为了确保 EIB 部署的 Helm chart 成功升级，用户需要对 EIB 为 Helm chart 创建的 HelmChart 资源进行升级。

下文提供了以下信息：

EIB 部署的 Helm chart 升级工作流程的一般概述（第 29.4.3.3.1 节 “概述”）。
成功完成 EIB 部署的 Helm chart 的升级须执行的升级步骤（第 29.4.3.3.2 节 “升级步骤”）。
展示使用所述方法进行 Longhorn chart 升级的示例（第 29.4.3.3.3 节 “示例”）。
如何使用其他 GitOps 工具完成升级过程（第 29.4.3.3.4 节 “使用第三方 GitOps 工具进行 Helm chart 升级”）。

29.4.3.3.1 概述 #

本节旨在概述升级 EIB 部署的一个或多个 Helm chart 所要执行的步骤。有关完成 Helm chart 升级所需执行的步骤的详细说明，请参见第 29.4.3.3.2 节 “升级步骤”。

图 29.3︰ Helm chart 升级工作流程 #

该工作流程的第一个步骤是用户提取其 chart 要升级到的新 Helm chart 存档。
存档随后应放置在 generate-chart-upgrade-data.sh 脚本将处理的目录中。
然后，用户继续执行 generate-chart-upgrade-data.sh 脚本，为提供的归档目录中的每个 Helm chart 存档生成 Kubernetes 密钥 YAML 文件。这些密钥将自动置于 Fleet 之下，用于升级 Helm chart。请参见升级步骤（第 29.4.3.3.2 节 “升级步骤”）一节中的进一步说明。
脚本执行成功完成后，用户应继续配置和部署捆绑包或 GitRepo 资源，将所有需要的 K8s 资源送达目标群集。
1. 该资源部署在管理群集上的 fleet-default 名称空间下。
Fleet（第 6 章 “Fleet”）会检测已部署的资源，解析其数据并将其资源部署到指定的目标群集。部署的资源中最值得注意的是：
1. eib-charts-upgrader - 部署 Chart 升级 Pod 的作业。eib-charts-upgrader-script 以及所有 Helm chart 升级数据密钥都安装在 Chart 升级 Pod 内。
2. eib-charts-upgrader-script - 一个附带脚本的密钥，Chart 升级 Pod 将使用该脚本为现有的 HelmChart 资源打补丁。
3. Helm chart 升级数据密钥 - 由 generate-chart-upgrade-data.sh 脚本基于用户提供的数据创建的密钥 YAML 文件。不得编辑密钥 YAML 文件。
部署 Chart 升级 Pod 后会执行 eib-charts-upgrader-script 密钥中的脚本，该脚本执行以下操作：
1. 处理其他密钥提供的所有 Helm chart 升级数据。
2. 检查提供的每项 chart 升级数据是否都有 HelmChart 资源。
3. 继续使用相应 Helm chart 的密钥提供的数据为 HelmChart 资源打补丁。
RKE2/K3s helm-controller 会持续监控对现有 HelmChart 资源的编辑。当检测到 HelmChart 的补丁时，它会协调更改，然后继续升级 HelmChart 资源后面的 chart。

29.4.3.3.2 升级步骤 #

克隆您要使用的 Edge 版本标记中的 suse-edge/fleet-examples 储存库。
创建用于存储所提取的 Helm chart 存档的目录。
```
mkdir archives
```

在新创建的存档目录中，提取要升级到的 Helm chart 存档：

cd archives
helm pull [chart URL | repo/chartname]

# Alternatively if you want to pull a specific version:
# helm pull [chart URL | repo/chartname] --version 0.0.0

从所需的版本标记下载 generate-chart-upgrade-data.sh 脚本。
执行 generate-chart-upgrade-data.sh 脚本：
重要
用户不应更改 generate-chart-upgrade-data.sh 脚本生成的内容。
```
chmod +x ./generate-chart-upgrade-data.sh

./generate-chart-upgrade-data.sh --archive-dir /foo/bar/archives/ --fleet-path /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
脚本将执行以下逻辑：
1. 验证用户是否提供了指向可以启动 Helm chart 升级的有效 Fleet 的 --fleet-path。
2. 处理用户创建的存档目录（例如 /foo/bar/archives/）中的所有 Helm chart 存档。
3. 为每个 Helm chart 存档创建一个 Kubernetes 密钥 YAML 资源。此资源将包含：
  1. 需要打补丁的 HelmChart 资源的名称。
  2. HelmChart 资源的新版本。
  3. base64 编码的 Helm chart 存档，将用于替换 HelmChart 当前运行的配置。
4. 每个 Kubernetes 密钥 YAML 资源都将被转移到 --fleet-path 下提供的 eib-charts-upgrader Fleet 路径内的 base/secrets 目录。
5. 此外，generate-chart-upgrade-data.sh 脚本会确保其移动的密钥将被拾取并用于 Helm chart 升级逻辑。具体方式是：
  1. 编辑 base/secrets/kustomization.yaml 文件以包含新添加的资源。
  2. 编辑 base/patches/job-patch.yaml 文件，将新添加的密钥包含到挂载配置中。
成功运行 generate-chart-upgrade-data.sh 后，suse-edge/fleet-examples 储存库的以下目录中应该会发生更改：
1. fleets/day2/eib-charts-upgrader/base/patches
2. fleets/day2/eib-charts-upgrader/base/secrets

以下步骤取决于您运行的环境：

对于支持 GitOps 的环境（例如：非隔离环境，或虽是隔离环境但支持本地 Git 服务器）：
1. 将 fleets/day2/eib-charts-upgrader Fleet 复制到您将用于 GitOps 的储存库中。确保 Fleet 包含 generate-chart-upgrade-data.sh 脚本所做的更改。
2. 配置将用于附带 eib-charts-upgrader Fleet 所有资源的 GitRepo 资源。
  1. 要通过 Rancher UI 进行 GitRepo 配置和部署，请参见在 Rancher UI 中访问 Fleet。
  2. 有关 GitRepo 的手动配置和部署，请参见创建部署。
对于不支持 GitOps 的环境（例如，隔离且不允许使用本地 Git 服务器的环境）：
1. 从 rancher/fleet 版本页面下载 fleet-cli 二进制文件。对于 Mac 用户，可以使用 Homebrew Formulae - fleet-cli。
2. 导航到 eib-charts-upgrader Fleet：
```
cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
3. 创建指示 Fleet 在哪里部署资源的 targets.yaml 文件：
```
cat > targets.yaml <<EOF
targets:
- clusterSelector: {} # Change this with your target data
EOF
```
  有关如何映射目标群集的信息，请参见上游文档。
4. 使用 fleet-cli 将 Fleet 转换为捆绑包资源：
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
  这将创建一个捆绑包 (bundle.yaml) ，其中包含来自 eib-charts-upgrader Fleet 的所有模板资源。
  有关 fleet apply 命令的详细信息，请参见 fleet apply。
  有关将 Fleet 转换为捆绑包的详细信息，请参见将 Helm Chart 转换为捆绑包。
5. 通过以下方式之一部署捆绑包：
  1. 通过 Rancher UI - 导航到 Continuous Delivery（持续交付）→ Advanced（高级）→ Bundles（捆绑包）→ Create from YAML（基于 YAML 创建），然后粘贴 bundle.yaml 内容，或单击 Read from File（从文件读取）选项并传递文件。
  2. 手动 - 在管理群集内手动部署 bundle.yaml 文件。

执行这些步骤可成功部署 GitRepo/捆绑包资源。资源将由 Fleet 拾取，且其内容将部署到用户在之前步骤中指定的目标群集上。有关该过程的概述，请参见“概述”（第 29.4.3.3.1 节 “概述”）部分。

有关如何跟踪升级过程的信息，请参见本文档的“示例”（第 29.4.3.3.3 节 “示例”）部分。

重要

成功验证 chart 升级后，去除捆绑包/GitRepo 资源。

这将从下游群集中去除不再需要的升级资源，确保将来不会发生版本冲突。

29.4.3.3.3 示例 #

注意

下面的示例说明了如何将 EIB 部署的 Helm chart 从一个版本升级到另一个版本。示例中的版本并非版本建议。特定 Edge 版本的版本建议请参见发行说明（第 45.1 节 “摘要”）。

用例：

一个名为 doc-example 的群集正在运行 Rancher 的 Longhorn 103.3.0+up1.6.1 版本。

群集已通过 EIB 进行部署，使用以下映像定义代码段：

kubernetes:
  helm:
    charts:
    - name: longhorn-crd
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 103.3.0+up1.6.1
    - name: longhorn
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 103.3.0+up1.6.1
    repositories:
    - name: rancher-charts
      url: https://charts.rancher.io/
...

图 29.4︰ doc-example 安装的 Longhorn 版本 #

Longhorn 需要升级到与 Edge 3.1 版兼容的版本。这意味着它需要升级到 104.2.2+up1.7.3。
假设负责管理 doc-example 群集的管理群集是隔离的，不支持本地 Git 服务器，并且具有有效的 Rancher 设置。

按照升级步骤（第 29.4.3.3.2 节 “升级步骤”）进行操作：

从 release-3.1.2 标记克隆 suse-edge/fleet-example 储存库。

git clone -b release-3.1.2 https://github.com/suse-edge/fleet-examples.git

创建存储 Longhorn 升级存档的目录。
```
mkdir archives
```

提取所需的 Longhorn chart 存档版本：

# First add the Rancher Helm chart repository
helm repo add rancher-charts https://charts.rancher.io/

# Pull the Longhorn 1.7.3 CRD archive
helm pull rancher-charts/longhorn-crd --version 104.2.2+up1.7.3

# Pull the Longhorn 1.7.3 chart archive
helm pull rancher-charts/longhorn --version 104.2.2+up1.7.3

在 archives 目录之外，从 release-3.1.2 版本标记下载 generate-chart-upgrade-data.sh 脚本。

目录设置如下所示：

.
├── archives
|   ├── longhorn-104.2.2+up1.7.3.tgz
│   └── longhorn-crd-104.2.2+up1.7.3.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
|   |   |   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       └── kustomization.yaml
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

执行 generate-chart-upgrade-data.sh 脚本：

# First make the script executable
chmod +x ./generate-chart-upgrade-data.sh

# Then execute the script
./generate-chart-upgrade-data.sh --archive-dir ./archives --fleet-path ./fleet-examples/fleets/day2/eib-charts-upgrader

脚本执行后的目录结构如下所示：

.
├── archives
|   ├── longhorn-104.2.2+up1.7.3.tgz
│   └── longhorn-crd-104.2.2+up1.7.3.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
│   │   │   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       ├── kustomization.yaml
│   │   │   │   │       ├── longhorn-104-2-0-up1-7-1.yaml <- secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   │       └── longhorn-crd-104-2-0-up1-7-1.yaml <- secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

git 中更改的文件如下所示：

图 29.5︰ generate-chart-upgrade-data.sh 对 fleet-examples 的更改 #

由于管理群集不支持 GitOps 工作流程，因此需要为 eib-charts-upgrader Fleet 创建捆绑包：
1. 首先，导航到 Fleet：
```
cd ./fleet-examples/fleets/day2/eib-charts-upgrader
```
2. 然后创建以 doc-example 群集为目标的 targets.yaml 文件：
```
cat > targets.yaml <<EOF
targets:
- clusterName: doc-example
EOF
```
3. 然后使用 fleet-cli 二进制文件将 Fleet 转换为捆绑包：
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
4. 现在，在您的管理群集计算机上传输 bundle.yaml。
由于管理群集正在运行 Rancher，请通过 Rancher UI 部署捆绑包：
图 29.6︰通过 Rancher UI 部署捆绑包 #

在这里选择从文件读取，并找到系统上的 bundle.yaml 文件。
此时会在 Rancher UI 中自动填充捆绑包：
图 29.7︰自动填充的捆绑包代码段 #

选择创建。
成功部署后，捆绑包如下所示：
图 29.8︰已成功部署的捆绑包 #

成功部署捆绑包后，要监控升级过程：

首先，验证升级 Pod 的日志：
图 29.9︰查看升级 Pod 日志 #
现在验证 helm-controller 为升级创建的 Pod 日志：
1. Pod 名称将使用以下模板 - helm-install-longhorn-<random-suffix>
2. Pod 将位于部署 HelmChart 资源的名称空间中。在本例中为默认名称空间。
  图 29.10︰成功升级的 Longhorn chart 的日志 #
检查 HelmChart 版本是否已更改：
图 29.11︰更改后的 Longhorn 版本 #
最后检查 Longhorn Pod 是否正在运行：
图 29.12︰验证实例管理器 Pod 的示例 #

在完成上述验证后，可以确信 Longhorn Helm chart 已从 103.3.0+up1.6.1 升级到 104.2.2+up1.7.3。

29.4.3.3.4 使用第三方 GitOps 工具进行 Helm chart 升级 #

在某些用例中，用户可能希望将此升级过程与除 Fleet 以外的 GitOps 工作流程（例如 Flux）配合使用。

要生成升级过程所需的资源，可以使用 generate-chart-upgrade-data.sh 脚本将用户提供的数据填充到 eib-charts-upgrader Fleet。有关如何执行此操作的详细信息，请参见“升级步骤”（第 29.4.3.3.2 节 “升级步骤”）。

完成所有设置后，可以使用 kustomize 生成一个可在群集中部署的完整工作解决方案：

cd /foo/bar/fleets/day2/eib-charts-upgrader

kustomize build .

如果想将解决方案包含在 GitOps 工作流程中，可以去除 fleet.yaml 文件，并将其余内容用作有效的 Kustomize 设置。只是别忘了先运行 generate-chart-upgrade-data.sh 脚本，以便其可以将您想要升级到的 Helm chart 的数据填充到 Kustomize 设置中。

要了解如何使用此工作流程，可以查看“概述”（第 29.4.3.3.1 节 “概述”）和“升级步骤”（第 29.4.3.3.2 节 “升级步骤”）章节。