36 下游群集 #

重要

以下步骤不适用于由 SUSE Edge for Telco（第 37 章 “SUSE Edge for Telco”）管理的下游群集。有关升级这些群集的说明，请参见第 43.2 节 “下游群集升级”。

本章介绍对下游群集的不同部分执行“Day 2”操作的可能方式。

36.1 Fleet #

本节提供有关如何使用 Fleet（第 8 章 “Fleet”）组件执行“Day 2”操作的信息。

本节将介绍以下主题：

第 36.1.1 节 “组件” - 执行所有“Day 2”操作时需要使用的默认组件。
第 36.1.2 节 “确定您的使用场景” - 概述将使用的 Fleet 自定义资源及其在不同“Day 2”操作场景中的适用性。
第 36.1.3 节 “Day 2 工作流程” - 提供使用 Fleet 执行“Day 2”操作的工作流程指南。
第 36.1.4 节 “操作系统升级” - 说明如何使用 Fleet 进行操作系统升级。
第 36.1.5 节 “Kubernetes 版本升级” - 说明如何使用 Fleet 进行 Kubernetes 版本升级。
第 36.1.6 节 “Helm chart 升级” - 说明如何使用 Fleet 进行 Helm chart 升级。

36.1.1 组件 #

下文将介绍为使用 Fleet 顺利执行“Day 2”操作而应在下游群集上设置的默认组件。

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

注意

必须在每个下游群集上部署。

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

系统会主动利用 SUC 升级操作系统和 Kubernetes 发行版。

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

有关如何部署 SUC 的信息，请先确定您的使用场景（第 36.1.2 节 “确定您的使用场景”），然后参见第 22.2.1.1 节 “系统升级控制器安装 - GitRepo”或第 22.2.1.2 节 “系统升级控制器安装 - 捆绑包”。

36.1.2 确定您的使用场景 #

Fleet 使用两种自定义资源来实现对 Kubernetes 和 Helm 资源的管理。

下文将介绍这些资源的用途，以及在“Day 2”操作情境中它们最适合的使用场景。

36.1.2.1 GitRepo #

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

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

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

36.1.2.2 捆绑包 #

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

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

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

36.1.3 Day 2 工作流程 #

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

操作系统升级（第 36.1.4 节 “操作系统升级”）
Kubernetes 版本升级（第 36.1.5 节 “Kubernetes 版本升级”）
Helm chart 升级（第 36.1.6 节 “Helm chart 升级”）

36.1.4 操作系统升级 #

本节介绍如何使用第 8 章 “Fleet”和第 22 章 “系统升级控制器”执行操作系统升级。

本节将介绍以下主题：

第 36.1.4.1 节 “组件” - 升级过程使用的其他组件。
第 36.1.4.2 节 “概述” - 升级过程概述。
第 36.1.4.3 节 “要求” - 升级过程的要求。
第 36.1.4.4 节 “操作系统升级 - SUC 计划部署” - 关于如何部署负责触发升级过程的 SUC 计划的信息。

36.1.4.1 组件 #

本节介绍操作系统升级过程中使用的自定义组件，这些组件与默认“Day 2”组件（第 36.1.1 节 “组件”）不同。

36.1.4.1.1 systemd.service #

特定节点上的操作系统升级由 systemd.service 处理。

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

对于需要相同操作系统版本（如 6.0）的 Edge 版本，将创建 os-pkg-update.service。它使用 transactional-update 执行常规软件包升级。
对于需要迁移操作系统版本（例如 6.0 → 6.1）的 Edge 版本，将创建 os-migration.service。它使用 transactional-update 来执行：
1. 常规软件包升级，这可确保所有软件包均为最新版本，以减少因软件包版本过旧而导致的迁移失败情况。
2. 利用 zypper migration 命令进行操作系统迁移。

上述服务通过 SUC 计划部署到每个节点，该计划必须位于需要升级操作系统的下游群集上。

36.1.4.2 概述 #

通过 Fleet 和系统升级控制器 (SUC) 来为下游群集节点升级操作系统。

Fleet 用于将 SUC 计划部署到目标群集并对其进行管理。

注意

SUC 计划是一种自定义资源，描述了 SUC 为在一组节点上执行特定任务而需要遵循的步骤。有关 SUC 计划的示例，请参见上游储存库。

通过向特定 Fleet 工作区部署 GitRepo 或捆绑包资源将操作系统 SUC 计划分发到各个群集。Fleet 会获取已部署的 GitRepo/捆绑包，并将其内容（操作系统 SUC 计划）部署到目标群集。

注意

GitRepo/捆绑包资源始终部署在管理群集上。使用 GitRepo 还是捆绑包资源取决于具体应用场景，有关详细信息，请参见第 36.1.2 节 “确定您的使用场景”。

操作系统 SUC 计划描述了以下工作流程：

执行操作系统升级前，务必要封锁节点。
务必先升级控制平面节点，再升级工作节点。
升级群集时，务必逐个节点依序升级。

部署操作系统 SUC 计划后，工作流程如下：

SUC 协调已部署的操作系统 SUC 计划，并在每个节点上创建一个 Kubernetes 作业。
Kubernetes 作业创建一个 systemd.service（第 36.1.4.1.1 节 “systemd.service”），用于执行软件包升级或操作系统迁移。
所创建的 systemd.service 触发特定节点上的操作系统升级过程。
重要
操作系统升级过程完成后，相应节点将重引导以应用系统更新。

下面是上述流程的示意图：

36.1.4.3 要求 #

一般：

已在 SCC 中注册的计算机 - 所有下游群集节点都应已注册到 https://scc.suse.com/。只有这样，systemd.service 才能成功连接到所需的 RPM 储存库。
重要
对于需要进行操作系统版本迁移的 Edge 版本（例如 6.0 → 6.1），请确保您的 SCC 密钥支持迁移到新版本。
确保 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 储存库应镜像到本地，以便 systemd.service 可以访问它们。您可以使用 RMT 或 SUMA 来完成该操作。

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

重要

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

从下游群集中去除任何先前部署且与旧版 Edge 相关的 SUC 计划 - 方法是从现有的 GitRepo/捆绑包目标配置中去除相应群集，或完全去除 GitRepo/捆绑包资源。
重用现有的 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..

如第 36.1.4.2 节 “概述”中所述，可以通过以下任意一种方式将 SUC 计划分发到目标群集来完成操作系统升级：

Fleet GitRepo 资源 - 第 36.1.4.4.1 节 “SUC 计划部署 - GitRepo 资源”。
Fleet 捆绑包资源 - 第 36.1.4.4.2 节 “SUC 计划部署 - 捆绑包资源”。

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

对于希望通过第三方 GitOps 工具部署操作系统 SUC 计划的使用场景，请参见第 36.1.4.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流程”。

36.1.4.4.1 SUC 计划部署 - GitRepo 资源 #

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

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

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

36.1.4.4.1.1 GitRepo 创建 - Rancher UI #

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

Edge 团队维护着一个即用型 Fleet。根据您的环境的不同，该 Fleet 可以直接使用或用作模板。

重要

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

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

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

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

36.1.4.4.1.2 GitRepo 创建 - 手动 #

提取 GitRepo 资源：

curl -o os-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.3.0/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.3.0  0/0

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

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

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

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

36.1.4.4.2.1 捆绑包创建 - Rancher UI #

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

重要

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

要通过 Rancher 的 UI 创建捆绑包，请执行以下操作：

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

36.1.4.4.2.2 捆绑包创建 - 手动 #

提取捆绑包资源：

curl -o os-upgrade-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.3.0/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
```

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

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

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

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

plan-control-plane.yaml 是用于控制平面节点的 SUC 计划资源。
plan-worker.yaml 是用于工作节点的 SUC 计划资源。
secret.yaml 是一个包含 upgrade.sh 脚本的机密，该脚本负责创建 systemd.service（第 36.1.4.1.1 节 “systemd.service”）。
config-map.yaml 是 ConfigMap，提供 upgrade.sh 脚本使用的升级配置。

重要

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

为了更好地了解如何使用 GitOps 工作流程来部署操作系统升级的 SUC 计划，建议查看第 36.1.4.2 节 “概述”。

36.1.5 Kubernetes 版本升级 #

重要

本节介绍并非通过 Rancher（第 5 章 “Rancher”）实例创建的下游群集的 Kubernetes 升级过程。有关如何对通过 Rancher 创建的群集进行 Kubernetes 版本升级的信息，请参见 Upgrading and Rolling Back Kubernetes。

本节介绍如何使用第 8 章 “Fleet”和第 22 章 “系统升级控制器”执行 Kubernetes 升级。

本节将介绍以下主题：

第 36.1.5.1 节 “组件” - 升级过程使用的其他组件。
第 36.1.5.2 节 “概述” - 升级过程概述。
第 36.1.5.3 节 “要求” - 升级过程的要求。
第 36.1.5.4 节 “K8s 升级 - SUC 计划部署” - 关于如何部署负责触发升级过程的 SUC 计划的信息。

36.1.5.1 组件 #

本节介绍 K8s 升级过程中使用的自定义组件，这些组件与默认“Day 2”组件（第 36.1.1 节 “组件”）不同。

36.1.5.1.1 rke2-upgrade #

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

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

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

36.1.5.1.2 k3s-upgrade #

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

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

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

36.1.5.2 概述 #

通过 Fleet 和系统升级控制器 (SUC) 来为下游群集节点升级 Kubernetes 发行版。

Fleet 用于将 SUC 计划部署到目标群集并对其进行管理。

注意

SUC 计划是一种自定义资源，描述了 SUC 为在一组节点上执行特定任务而需要遵循的步骤。有关 SUC 计划的示例，请参见上游储存库。

通过向特定 Fleet 工作区部署 GitRepo 或捆绑包资源将 K8s SUC 计划分发到各个群集。Fleet 会获取已部署的 GitRepo/捆绑包，并将其内容（K8s SUC 计划）部署到目标群集。

注意

K8s SUC 计划描述了以下工作流程：

执行 K8s 升级前，务必要封锁节点。
务必先升级控制平面节点，再升级工作节点。
始终一次升级一个控制平面节点，一次升级两个工作节点。

部署 K8s SUC 计划后，工作流程如下：

SUC 协调已部署的 K8s SUC 计划，并在每个节点上创建一个 Kubernetes 作业。
根据 Kubernetes 发行版的不同，该作业将创建一个运行 rke2-upgrade（第 36.1.5.1.1 节 “rke2-upgrade”）或 k3s-upgrade（第 36.1.5.1.2 节 “k3s-upgrade”）容器映像的 Pod。
创建的 Pod 将执行以下工作流程：
1. 用 rke2-upgrade/k3s-upgrade 映像中的二进制文件替换节点上现有的 rke2/k3s 二进制文件。
2. 终止正在运行的 rke2/k3s 进程。
终止 rke2/k3s 进程会触发重启，启动运行已更新二进制文件的新进程，从而实现 Kubernetes 发行版版本的升级。

下面是上述流程的示意图：

36.1.5.3 要求 #

备份您的 Kubernetes 发行版：
1. 对于 RKE2 群集，请参见 RKE2 Backup and Restore 文档。
2. 对于 K3s 群集，请参见 K3s Backup and Restore 文档。
确保 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" ...

36.1.5.4 K8s 升级 - SUC 计划部署 #

重要

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

从下游群集中去除任何先前部署且与旧版 Edge 相关的 SUC 计划 - 方法是从现有的 GitRepo/捆绑包目标配置中去除相应群集，或完全去除 GitRepo/捆绑包资源。
重用现有的 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..

如第 36.1.5.2 节 “概述”中所述，可以通过以下任意一种方式将 SUC 计划分发到目标群集来完成 Kubernetes 升级：

Fleet GitRepo 资源（第 36.1.5.4.1 节 “SUC 计划部署 - GitRepo 资源”）
Fleet 捆绑包资源（第 36.1.5.4.2 节 “SUC 计划部署 - 捆绑包资源”）

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

对于希望通过第三方 GitOps 工具部署 K8s SUC 计划的使用场景，请参见第 36.1.5.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流程”。

36.1.5.4.1 SUC 计划部署 - GitRepo 资源 #

提供所需 K8s SUC 计划的 GitRepo 资源可通过以下方式之一进行部署：

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

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

36.1.5.4.1.1 GitRepo 创建 - Rancher UI #

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

Edge 团队为 rke2 和 k3s 这两种 Kubernetes 发行版维护着即用型 Fleet。根据您的环境的不同，这些 Fleet 可以直接使用或用作模板。

重要

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

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

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

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

36.1.5.4.1.2 GitRepo 创建 - 手动 #

提取 GitRepo 资源：

对于 RKE2 群集：

curl -o rke2-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.3.0/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.3.0/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   fleet-default   0/0
rke2-upgrade   https://github.com/suse-edge/fleet-examples.git   fleet-default   0/0

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

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

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

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

36.1.5.4.2.1 捆绑包创建 - Rancher UI #

Edge 团队为 rke2 和 k3s 这两种 Kubernetes 发行版维护着即用型捆绑包。根据您的环境的不同，这些捆绑包可以直接使用或用作模板。

重要

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

要通过 Rancher 的 UI 创建捆绑包，请执行以下操作：

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

36.1.5.4.2.2 捆绑包创建 - 手动 #

提取捆绑包资源：

对于 RKE2 群集：

curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.3.0/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.3.0/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

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

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

要获取所需的 K8s 升级资源，首先请确定您要使用的 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

重要

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

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

36.1.6 Helm chart 升级 #

本节介绍如下内容：

第 36.1.6.1 节 “为隔离环境做好准备” - 包含有关如何将与 Edge 相关的 OCI chart 和映像分发到您的专用注册表的信息。
第 36.1.6.2 节 “升级过程” - 包含有关不同 Helm chart 升级情形及其升级过程的信息。

36.1.6.1 为隔离环境做好准备 #

36.1.6.1.1 确保您有权访问 Helm chart 的 Fleet #

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

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

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

转到“Day 2”版本页面，找到您要将 chart 升级到的 Edge 版本，然后单击 Assets（资产）。

从“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 版本相关的映像列表。

36.1.6.1.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

36.1.6.1.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

36.1.6.1.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 选项下指定的注册表。

36.1.6.1.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
```

36.1.6.1.7 在 Kubernetes 发行版中配置专用注册表 #

对于 RKE2，请参见 Private Registry Configuration

对于 K3s，请参见 Private Registry Configuration

36.1.6.2 升级过程 #

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

重要

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

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

本节介绍如何：

36.1.6.2.1.1 为您的 chart 准备 Fleet 资源 #

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

注意

在某些情况下，Fleet 为 Helm 操作设置的默认超时时长可能不足，导致发生以下错误：

failed pre-install: context deadline exceeded

在此类情况下，请在 fleet.yaml 文件的 helm 配置下添加 timeoutSeconds 属性。

longhorn Helm chart 的示例如下：

用户 Git 储存库结构：

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

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

defaultNamespace: longhorn-system

helm:
  # timeoutSeconds: 10
  releaseName: "longhorn"
  chart: "longhorn"
  repo: "https://charts.rancher.io/"
  version: "106.2.0+up1.8.1"
  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 的部署指南。

36.1.6.2.1.2 部署您的 chart 的 Fleet #

您可以使用 GitRepo（第 36.1.6.2.1.2.1 节 “GitRepo”）或捆绑包（第 36.1.6.2.1.2.2 节 “捆绑包”）来部署 chart 的 Fleet。

注意

部署 Fleet 时，如果收到资源已修改消息，请确保在 Fleet 的 diff 部分添加相应的 comparePatches 项。有关详细信息，请参见 Generating Diffs to Ignore Modified GitRepos。

36.1.6.2.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: {}

36.1.6.2.1.2.2 捆绑包 #

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

捆绑包的部署可以通过 Rancher UI（Continuous Delivery（持续交付）→ Advanced（高级）→ Bundles（捆绑包）→ Create from YAML（基于 YAML 创建））进行，也可以通过在正确的 Fleet 名称空间中手动部署捆绑包资源来完成。有关 Fleet 名称空间的信息，请参见上游文档。

可以利用 Fleet 的将 Helm Chart 转换为捆绑包方法创建用于 Edge Helm chart 的捆绑包。

下面的示例展示了如何基于 longhorn 和 longhorn-crd Helm chart Fleet 模板创建捆绑包资源，以及如何手动将此捆绑包部署到管理群集。

注意

为了阐明工作流程，下面的示例使用了 suse-edge/fleet-examples 目录结构。

导航到 longhorn chart Fleet 模板：

cd fleets/day2/chart-templates/longhorn/longhorn

创建 targets.yaml 文件，该文件将指示 Fleet 应将 Helm chart 部署到哪些群集：
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```
若要更精细地选择下游群集，请参见映射到下游群集。
使用 fleet-cli 将 Longhorn Helm chart Fleet 转换为捆绑包资源。
注意
Fleet 的 CLI 可以从其版本资产页面 (fleet-linux-amd64) 获取。
对于 Mac 用户，有一个 fleet-cli Homebrew Formulae。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-bundle > longhorn-bundle.yaml
```

导航到 longhorn-crd chart Fleet 模板：

cd fleets/day2/chart-templates/longhorn/longhorn-crd

创建 targets.yaml 文件，该文件将指示 Fleet 应将 Helm chart 部署到哪些群集：
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```

使用 fleet-cli 将 Longhorn CRD Helm chart Fleet 转换为捆绑包资源。

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
```

按照以上步骤操作，将 SUSE Storage 部署到所有指定的下游群集上。

36.1.6.2.1.3 管理部署的 Helm chart #

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

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

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

36.1.6.2.3 我要升级通过 EIB 部署的 Helm chart #

第 11 章 “Edge Image Builder” 通过创建 HelmChart 资源并利用 RKE2/K3s Helm 集成功能引入的 helm-controller 来部署 Helm chart。

为确保通过 EIB 部署的 Helm chart 成功升级，用户需要对相应的 HelmChart 资源执行升级操作。

下文提供了以下信息：

升级过程的一般概述（第 36.1.6.2.3.1 节 “概述”）。
必要的升级步骤（第 36.1.6.2.3.2 节 “升级步骤”）。
展示使用所述方法进行 Longhorn chart 升级的示例（第 36.1.6.2.3.3 节 “示例”）。
如何使用其他 GitOps 工具完成升级过程（第 36.1.6.2.3.4 节 “使用第三方 GitOps 工具进行 Helm chart 升级”）。

36.1.6.2.3.1 概述 #

通过 EIB 部署的 Helm chart 由名为 eib-charts-upgrader 的 Fleet 执行升级。

该 Fleet 会处理用户提供的数据，以更新一组特定的 HelmChart 资源。

更新这些资源会触发 helm-controller，后者会升级与修改后的 HelmChart 资源相关联的 Helm chart。

用户只需执行以下操作：

从本地提取需要升级的每个 Helm chart 的归档。
将这些归档传递给 generate-chart-upgrade-data.sh generate-chart-upgrade-data.sh 脚本，该脚本会将这些归档中的数据包含到 eib-charts-upgrader Fleet 中。
将 eib-charts-upgrader Fleet 部署到管理群集。此操作可以通过 GitRepo 或捆绑包资源来完成。

部署后，eib-charts-upgrader 会借助 Fleet 将其资源分发到目标下游群集。

这些资源包括：

一组存储用户提供的 Helm chart 数据的机密。
一个会部署 Pod 的 Kubernetes 作业，该 Pod 会挂载前面提到的机密，并根据这些机密对相应的 HelmChart 资源进行修补。

如前文所述，这会触发 helm-controller，进而执行实际的 Helm chart 升级。

下面是上述流程的示意图：

36.1.6.2.3.2 升级步骤 #

从正确的版本标记处克隆 suse-edge/fleet-example 储存库。
创建用于存储所提取的 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 脚本：
```
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
```
对于 --archive-dir 目录中的每个 chart 归档，该脚本都会生成一个包含 chart 升级数据的 Kubernetes 机密 YAML 文件，并将其存储在 --fleet-path 指定的 Fleet 的 base/secrets 目录中。
generate-chart-upgrade-data.sh 脚本还会对 Fleet 进行其他修改，以确保生成的 Kubernetes 机密 YAML 文件能被 Fleet 部署的工作负载正确使用。
重要
用户不应更改 generate-chart-upgrade-data.sh 脚本生成的内容。

以下步骤因您运行的环境而异：

对于支持 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 二进制文件。对于 Linux，请下载 fleet-linux-amd64。对于 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:
# To match all downstream clusters
- clusterSelector: {}
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 拾取，且其内容将部署到用户在之前的步骤中指定的目标群集上。有关该过程的概述，请参见第 36.1.6.2.3.1 节 “概述”。

有关如何跟踪升级过程的信息，请参见第 36.1.6.2.3.3 节 “示例”。

重要

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

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

36.1.6.2.3.3 示例 #

注意

以下示例展示了如何在下游群集上将通过 EIB 部署的 Helm chart 从一个版本升级到另一个版本。请注意，本示例中使用的版本并非推荐版本。有关特定 Edge 版本的推荐版本，请参见发行说明（第 52.1 节 “摘要”）。

使用场景：

名为 doc-example 的群集正在运行旧版 Longhorn。

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

kubernetes:
  helm:
    charts:
    - name: longhorn-crd
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    - name: longhorn
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    repositories:
    - name: rancher-charts
      url: https://charts.rancher.io/
...

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

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

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

git clone -b release-3.3.0 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.8.1 CRD archive
helm pull rancher-charts/longhorn-crd --version 106.2.0+up1.8.1

# Pull the Longhorn 1.8.1 chart archive
helm pull rancher-charts/longhorn --version 106.2.0+up1.8.1

在 archives 目录之外，从 suse-edge/fleet-examples 版本标记处下载 generate-chart-upgrade-data.sh 脚本。

目录设置如下所示：

.
├── archives
|   ├── longhorn-106.2.0+up1.8.1.tgz
│   └── longhorn-crd-106.2.0+up1.8.1.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-106.2.0+up1.8.1.tgz
│   └── longhorn-crd-106.2.0+up1.8.1.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-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   │       └── longhorn-crd-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

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

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   fleets/day2/eib-charts-upgrader/base/patches/job-patch.yaml
	modified:   fleets/day2/eib-charts-upgrader/base/secrets/kustomization.yaml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	fleets/day2/eib-charts-upgrader/base/secrets/longhorn-VERSION.yaml
	fleets/day2/eib-charts-upgrader/base/secrets/longhorn-crd-VERSION.yaml

为 eib-charts-upgrader Fleet 创建捆绑包：
1. 首先，导航到 Fleet：
```
cd ./fleet-examples/fleets/day2/eib-charts-upgrader
```
2. 然后创建 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 UI 部署捆绑包：
图 36.1︰通过 Rancher UI 部署捆绑包 #

在此处选择 Read from File（从文件读取），并找到系统上的 bundle.yaml 文件。
此时会在 Rancher UI 中自动填充捆绑包。
选择 Create（创建）。
成功部署后，捆绑包如下所示：
图 36.2︰已成功部署的捆绑包 #

成功部署捆绑包后，要监控升级过程，请执行以下操作：

验证升级 Pod 的日志：
现在验证 helm-controller 针对升级过程创建的 Pod 日志：
1. Pod 名称将使用以下模板 - helm-install-longhorn-<random-suffix>
2. Pod 将位于部署了 HelmChart 资源的名称空间中。在本例中为 kube-system 名称空间。
  图 36.3︰成功升级的 Longhorn chart 的日志 #
导航到 Rancher 的 HelmChart 部分（More Resources（更多资源）→ HelmChart），验证 HelmChart 版本是否已更新。选择部署了该 chart 的名称空间，在本例中为 kube-system。
最后检查 Longhorn Pod 是否正在运行。

在完成上述验证后，可以确定 Longhorn Helm chart 已升级到 106.2.0+up1.8.1 版本。

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

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

要生成升级过程所需的资源，可以使用 generate-chart-upgrade-data.sh 脚本将用户提供的数据填充到 eib-charts-upgrader Fleet。有关如何执行此操作的详细信息，请参见第 36.1.6.2.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 设置中。

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