适用范围 SUSE Edge 3.6

33 下游集群 #

本节介绍了对您的 downstream 集群的不同部分执行“第 2 天”操作的可能方法。

33.1 Fleet #

本节提供有关如何使用 Fleet (第 6 章 “Fleet”) 组件执行“第 2 天”操作的信息。

本节涵盖以下主题：

第 33.1.1 节 “组件” - 用于所有“第 2 天”操作的默认组件。
第 33.1.2 节 “确定您的用例” - 提供将要使用的 Fleet 自定义资源概述，以及它们对不同“第 2 天”操作用例的适用性。
第 33.1.3 节 “Day 2 工作流” - 提供使用 Fleet 执行“第 2 天”操作的工作流程指南。
第 33.1.4 节 “操作系统升级” - 描述如何使用 Fleet 进行操作系统升级。
第 33.1.5 节 “Kubernetes 版本升级” - 描述如何使用 Fleet 进行 Kubernetes 版本升级。
第 33.1.6 节 “Helm chart 升级” - 描述如何使用 Fleet 进行 Helm chart 升级。

33.1.1 组件 #

您可以在下方找到应在您的 downstream 集群上设置的默认组件说明，以便您能够使用 Fleet 成功执行“第 2 天”操作。

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

注意

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

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

*SUC*被主动用于升级操作系统和 Kubernetes 发行版。

有关 SUC 组件及其如何适配 Edge 堆栈的更多信息，请参阅第 18 章 “系统升级控制器”。

有关如何部署 SUC 的信息，请先确定您的用例 (第 33.1.2 节 “确定您的用例”)，然后参考系统升级控制器安装 - GitRepo (第 18.2.1.1 节 “System Upgrade Controller 安装 - GitRepo”) 或系统升级控制器安装 - Bundle (第 18.2.1.2 节 “系统升级控制器安装 - Bundle”)。

33.1.2 确定您的用例 #

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

您可以在下方找到有关这些资源的目的以及它们在“第 2 天”操作背景下最适合的用例的信息。

33.1.2.1 GitRepo #

GitRepo 是一个 Fleet (第 6 章 “Fleet”) 资源，它代表一个 Fleet 可以从中创建 Bundles 的 Git 储存库。每个 Bundle 都是基于 GitRepo 资源内定义的配置路径创建的。有关详细信息，请参见 GitRepo 文档。

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

或者，GitRepo 资源也可用于在 隔离的 环境中部署 SUC 或 SUC Plans，前提是您通过本地 git 服务器镜像您的储存库设置。

33.1.2.2 捆绑包 #

Bundles 包含将部署在目标集群上的原始 Kubernetes 资源。通常它们是从 GitRepo 资源创建的，但在某些用例中也可以手动部署它们。有关详细信息，请参考 Bundle 文档。

在“Day 2”操作的背景下，Bundle 资源通常用于在不使用某种 本地 GitOps 流程（例如 本地 git 服务器）的 隔离的 环境中部署 SUC 或 SUC Plans。

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

33.1.3 Day 2 工作流 #

以下是升级 downstream 集群到特定 Edge 版本时应遵循的“Day 2”工作流。

操作系统升级 (第 33.1.4 节 “操作系统升级”)
Kubernetes 版本升级 (第 33.1.5 节 “Kubernetes 版本升级”)
Helm chart 升级 (第 33.1.6 节 “Helm chart 升级”)

33.1.4 操作系统升级 #

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

本节涵盖以下主题：

第 33.1.4.1 节 “组件” - 升级过程中使用的附加组件。
第 33.1.4.2 节 “概述” - 升级过程概述。
第 33.1.4.3 节 “要求” - 升级过程的要求。
第 33.1.4.4 节 “操作系统升级 - SUC 计划部署” - 有关如何部署负责触发升级过程的 SUC plans 的信息。

33.1.4.1 组件 #

本节涵盖 OS upgrade 过程在默认“第 2 天”组件 (第 33.1.1 节 “组件”) 之外使用的自定义组件。

33.1.4.1.1 systemd.service #

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

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

对于需要相同操作系统版本（例如 6.1）的 Edge 版本，将创建 os-pkg-update.service。它使用事务更新来执行常规软件包升级。
对于需要操作系统版本迁移（例如 6.1 → 6.2）的 Edge 版本，将创建 os-migration.service。它使用事务更新来执行：
1. 常规软件包升级，确保所有软件包均为最新，以减少迁移过程中因旧软件包版本导致的任何故障。
2. 利用 zypper migration 命令进行操作系统迁移。

上述服务通过 SUC plan 在每个节点上部署，该服务必须位于需要操作系统升级的 downstream 集群上。

33.1.4.2 概述 #

downstream 集群节点的操作系统升级是通过利用 Fleet 和 System Upgrade Controller (SUC) 完成的。

Fleet 用于在目标集群上部署和管理 SUC plans。

注意

SUC plans 是自定义资源，用于描述 SUC 为在节点集上执行特定任务所需遵循的步骤。有关 SUC plan 外观的示例，请参阅上游储存库。

OS SUC plans 通过将 GitRepo 或 Bundle 资源部署到特定的 Fleet 工作区来分发到每个集群。Fleet 会检索已部署的 GitRepo/Bundle 并将其内容（即 OS SUC plans）部署到目标集群。

注意

GitRepo/Bundle 资源始终部署在 management cluster 上。是否使用 GitRepo 或 Bundle 资源取决于您的用例，请查看第 33.1.2 节 “确定您的用例” 以获取更多信息。

OS SUC plans 描述了以下工作流程：

在操作系统升级之前，请务必隔离节点。
请务必先升级 control-plane 节点，然后再升级 worker 节点。
请务必一次只升级一个 one 节点。

一旦部署了 OS SUC plans，工作流程如下所示：

SUC 会协调已部署的 OS SUC plans 并在 每个节点 上创建一个 Kubernetes Job。
Kubernetes Job 会为软件包升级或操作系统迁移创建一个 systemd.service (第 33.1.4.1.1 节 “systemd.service”)。
所创建的 systemd.service 会触发特定节点上的操作系统升级过程。
重要
一旦操作系统升级过程完成，相应的节点将被 rebooted 以应用系统更新。

您可以在下方找到上述描述的图示：

33.1.4.3 要求 #

常规：

SCC 注册机器 - 所有 downstream 集群节点都应注册到 https://scc.suse.com/，这是使相应的 systemd.service 能够成功连接到所需 RPM 储存库所必需的。
重要
对于需要操作系统版本迁移的 Edge 版本（例如 6.1 → 6.2），请确保您的 SCC 密钥支持迁移到新版本。
确保 SUC Plan 容忍度与节点容忍度匹配 - 如果您的 Kubernetes 集群节点具有自定义污点，请确保在 SUC Plans 中为这些污点添加容忍度。默认情况下，SUC Plans 仅具有针对 控制平面 节点的容忍度。默认容忍度包括：
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  注意
  任何额外的容忍度必须添加到每个计划的 .spec.tolerations 部分下。与操作系统升级相关的*SUC 计划*可以在`fleets/day2/system-upgrade-controller-plans/os-upgrade`下的suse-edge/fleet-examples储存库中找到。确保您使用来自有效存储库发布标签的计划。
  为*控制平面* 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来实现。

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

重要

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

Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - 可以通过从现有的 GitRepo/Bundle`目标配置中移除所需的集群，或者完全移除 `GitRepo/Bundle 资源来完成。
Reuse the existing GitRepo/Bundle resource - 可以通过将资源的修订版本指向包含所需 `suse-edge/fleet-examples`release 的正确 Fleet 的新标签来完成。

这样做是为了避免旧版 Edge 发行版本之间的`SUC Plans`冲突。

如果用户在 downstream 集群上存在现有的 SUC Plans 时尝试升级，他们将看到以下 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..

如第 33.1.4.2 节 “概述” 中所述，操作系统升级是通过以下方式之一将 SUC plans 部署到目标集群来完成的：

Fleet GitRepo 资源 - 第 33.1.4.4.1 节 “SUC 计划部署 - GitRepo 资源”。
Fleet Bundle 资源 - 第 33.1.4.4.2 节 “SUC 计划部署 - Bundle 资源”。

要确定应使用哪种资源，请参阅第 33.1.2 节 “确定您的用例”。

对于希望从第三方 GitOps 工具部署`OS SUC plans`的用例，请参阅第 33.1.4.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流”

33.1.4.4.1 SUC 计划部署 - GitRepo 资源 #

可以采用以下方式之一部署包含所需`OS SUC plans`的*GitRepo*资源：

通过 Rancher UI - 第 33.1.4.4.1.1 节 “GitRepo 创建 - Rancher UI”（当 Rancher 可用时）。
通过手动部署 (第 33.1.4.4.1.2 节 “GitRepo 创建 - 手动”) 资源到您的 management cluster。

部署完成后，要监控目标集群节点的操作系统升级过程，请参阅第 18.3 节 “监控 System Upgrade Controller 计划”。

33.1.4.4.1.1 GitRepo 创建 - Rancher UI #

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

Edge 团队维护着一个可直接使用的 Fleet。根据您的环境，此 Fleet 可以直接使用或作为模板使用。

重要

请务必使用来自有效 Edge 发布标签的此 Fleet。

对于不需要对 Fleet 附带的 SUC plans 进行任何自定义更改的用例，用户可以直接引用来自 suse-edge/fleet-examples 储存库的 os-upgrade Fleet。

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

关于如何配置 GitRepo 以使用来自 suse-edge/fleet-examples 储存库的 Fleet 的示例，可以在此处查看。

33.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.6.1/gitrepos/day2/os-upgrade-gitrepo.yaml

编辑 GitRepo 配置，在 spec.targets 下指定您所需的目标列表。默认情况下，来自 suse-edge/fleet-examples 的 GitRepo 资源不会映射到任何下游集群。
- 要匹配所有集群，请将默认 GitRepo 目标更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 或者，如果您需要更细粒度的集群选择，请参阅映射到下游集群
应用 GitRepo 资源到您的 management cluster：
```
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.6.1  0/0

33.1.4.4.2 SUC 计划部署 - Bundle 资源 #

一个 Bundle 资源（用于交付所需的 OS SUC Plans）可以通过以下方式之一进行部署：

通过 Rancher UI - 第 33.1.4.4.2.1 节 “Bundle 创建 - Rancher UI”（当 Rancher 可用时）。
通过手动部署 (第 33.1.4.4.2.2 节 “Bundle 创建 - 手动”) 资源到您的 management cluster。

部署完成后，要监控目标集群节点的操作系统升级过程，请参阅第 18.3 节 “监控 System Upgrade Controller 计划”。

33.1.4.4.2.1 Bundle 创建 - Rancher UI #

Edge 团队维护了一个可直接使用的 bundle，可用于以下步骤。

重要

请务必使用来自有效 Edge 发布标签的此 bundle。

通过 Rancher UI 创建 bundle：

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

33.1.4.4.2.2 Bundle 创建 - 手动 #

拉取 Bundle 资源：

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

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

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

在某些用例中，用户可能希望将 OS SUC plans 集成到他们自己的第三方 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 脚本的 Secret，该脚本负责创建 systemd.service (第 33.1.4.1.1 节 “systemd.service”)。
config-map.yaml 是一个 ConfigMap，其中保存了供 upgrade.sh 脚本使用的配置。

重要

这些 Plan 资源由 System Upgrade Controller 进行解释，并应部署在您希望升级的每个下游集群上。有关 SUC 部署信息，请参见第 18.2 节 “安装系统升级控制器”。

为了更好地了解如何使用 GitOps 工作流来部署用于操作系统升级的 SUC Plans，查看 overview (第 33.1.4.2 节 “概述”) 会有所帮助。

33.1.5 Kubernetes 版本升级 #

重要

本节涵盖了 未通过 Rancher (第 4 章 “Rancher”) 实例创建的下游集群的 Kubernetes 升级。有关如何升级 Rancher 创建的集群的 Kubernetes 版本的信息，请参阅升级和回滚 Kubernetes。

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

本节涵盖以下主题：

第 33.1.5.1 节 “组件” - 升级过程中使用的其他组件。
第 33.1.5.2 节 “概述” - 升级过程概述。
第 33.1.5.3 节 “要求” - 升级过程的要求。
第 33.1.5.4 节 “K8s 升级 - SUC 计划部署” - 有关如何部署 SUC plans 的信息，它负责触发升级过程。

33.1.5.1 组件 #

本节涵盖了 K8s upgrade 过程在默认“Day 2”组件 (第 33.1.1 节 “组件”)之外使用的自定义组件。

33.1.5.1.1 rke2-upgrade #

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

通过 SUC 基于 SUC 计划 创建的 Pod 进行分发。该计划应位于每个需要 RKE2 升级的集群上。

有关 rke2-upgrade 镜像如何执行升级的更多信息，请参阅上游文档。

33.1.5.1.2 k3s-upgrade #

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

通过 SUC 基于 SUC 计划 创建的 Pod 进行分发。该计划应位于每个需要 K3s 升级的集群上。

有关 k3s-upgrade 镜像如何执行升级的更多信息，请参阅上游文档。

33.1.5.2 概述 #

downstream 集群节点的 Kubernetes 发行版升级是通过利用 Fleet 和 System Upgrade Controller (SUC) 完成的。

Fleet 用于将 SUC plans 部署并管理到目标集群上。

注意

SUC plans 是自定义资源，用于描述 SUC 为在特定节点集上执行特定任务所需遵循的步骤。有关 SUC plan 外观的示例，请参阅上游储存库。

K8s SUC plans 通过将 GitRepo 或 Bundle 资源部署到特定的 Fleet 工作区，从而在每个集群上进行交付。Fleet 获取已部署的 GitRepo/Bundle 并将其内容（即 K8s SUC plans）部署到一个或多个目标集群。

注意

GitRepo/Bundle 资源始终部署在 management cluster 上。是使用 GitRepo 还是 Bundle 资源取决于您的用例，请查看第 33.1.2 节 “确定您的用例” 以获取更多信息。

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

在 K8s 升级之前，请务必隔离节点。
请务必先升级 control-plane 节点，然后再升级 worker 节点。
请务必每次升级 control-plane 节点中的一个节点，以及 worker 节点中的两个节点。

一旦部署了 K8s SUC plans，工作流程如下所示：

SUC 会协调已部署的 K8s SUC plans 并在 每个节点 上创建一个 Kubernetes Job。
根据 Kubernetes 发行版的不同，该 Job 将创建一个运行 rke2-upgrade (第 33.1.5.1.1 节 “rke2-upgrade”) 或 k3s-upgrade (第 33.1.5.1.2 节 “k3s-upgrade”) 容器镜像的 Pod。
创建的 Pod 将经历以下工作流程：
1. 将节点上现有的 rke2/k3s 二进制文件替换为来自 rke2-upgrade/k3s-upgrade 镜像的文件。
2. 终止正在运行的 rke2/k3s 进程。
终止 rke2/k3s 进程会触发重启，启动一个运行更新后二进制文件的新进程，从而实现 Kubernetes 发行版版本的升级。

您可以在下方找到上述描述的图示：

33.1.5.3 要求 #

备份您的 Kubernetes 发行版：
1. 对于 RKE2 集群，请参阅 RKE2 备份与恢复文档。
2. 对于 K3s 集群，请参阅 K3s 备份与恢复文档。
确保 SUC Plan 容忍度与节点容忍度匹配 - 如果您的 Kubernetes 集群节点具有自定义污点，请确保在 SUC Plans 中为这些污点添加容忍度。默认情况下，SUC Plans 仅包含针对 控制平面 节点的容忍度。默认容忍度包括：
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  注意
  任何额外的容忍度必须添加到每个 Plan 的 .spec.tolerations 部分下。与 Kubernetes 版本升级相关的 SUC Plans 可以在 suse-edge/fleet-examples 储存库的以下位置找到：
  对于 RKE2 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade
  对于 K3s - fleets/day2/system-upgrade-controller-plans/k3s-upgrade
  请确保您使用的是来自有效储存库发布标签的 Plans。
  为 RKE2 控制平面 SUC Plan 定义自定义容忍度的示例如下：
  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" ...

33.1.5.4 K8s 升级 - SUC 计划部署 #

重要

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

Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - 可以通过从现有的 GitRepo/Bundle 目标配置中移除所需的集群，或直接移除 GitRepo/Bundle 资源来完成。
Reuse the existing GitRepo/Bundle resource - 可以通过将资源的修订版本指向包含所需 suse-edge/fleet-examples 发布正确 Fleet 的新标签来完成。

这样做是为了避免旧版 Edge 发行版本之间的 SUC Plans 冲突。

如果用户在 downstream 集群上存在现有 SUC Plans 的情况下尝试升级，他们将看到以下 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..

如第 33.1.5.2 节 “概述” 中所述，Kubernetes 升级是通过以下方式之一将 SUC plans 发送到目标集群来完成的：

Fleet GitRepo 资源 (第 33.1.5.4.1 节 “SUC 计划部署 - GitRepo 资源”)
Fleet Bundle 资源 (第 33.1.5.4.2 节 “SUC 计划部署 - Bundle 资源”)

要确定应使用哪种资源，请参阅第 33.1.2 节 “确定您的用例”。

对于希望从第三方 GitOps 工具部署 K8s SUC plans 的用例，请参阅第 33.1.5.4.3 节 “SUC 计划部署 - 第三方 GitOps 工作流”

33.1.5.4.1 SUC 计划部署 - GitRepo 资源 #

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

通过 Rancher UI - 第 33.1.5.4.1.1 节 “GitRepo 创建 - Rancher UI”（当 Rancher 可用时）。
通过手动部署 (第 33.1.5.4.1.2 节 “GitRepo 创建 - 手动”) 资源到您的 management cluster。

部署完成后，要监控目标集群节点的 Kubernetes 升级过程，请参阅第 18.3 节 “监控 System Upgrade Controller 计划”。

33.1.5.4.1.1 GitRepo 创建 - Rancher UI #

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

Edge 团队维护着适用于 rke2 和 k3s Kubernetes 发行版的现成 fleet。根据您的环境，此 fleet 可以直接使用或作为模板使用。

重要

请务必使用来自有效 Edge 发布标签的这些 fleet。

对于不需要对这些 fleet 所发送的 SUC plans 进行任何自定义更改的用例，用户可以直接引用 suse-edge/fleet-examples 储存库中的 fleet。

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

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

33.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.6.1/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.6.1/gitrepos/day2/k3s-upgrade-gitrepo.yaml

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

将 GitRepo 资源应用到您的 management cluster：

# 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

33.1.5.4.2 SUC 计划部署 - Bundle 资源 #

可以采用以下方式之一部署包含所需 Kubernetes upgrade SUC Plans 的 Bundle 资源：

通过 Rancher UI - 第 33.1.5.4.2.1 节 “Bundle 创建 - Rancher UI”（当 Rancher 可用时）。
通过手动部署 (第 33.1.5.4.2.2 节 “Bundle 创建 - 手动创建”) 资源到您的 management cluster。

部署完成后，要监控目标集群节点的 Kubernetes 升级过程，请参阅第 18.3 节 “监控 System Upgrade Controller 计划”。

33.1.5.4.2.1 Bundle 创建 - Rancher UI #

Edge 团队为 rke2 和 k3s Kubernetes 发行版维护了可直接使用的 bundle。根据您的环境，这些 bundle 可以直接使用或作为模板使用。

重要

请务必使用来自有效 Edge release 标签的 bundle。

通过 Rancher UI 创建 bundle：

在左上角，点击 ☰ → 持续交付
转到高级 > Bundles
选择 从 YAML 创建
在此处，您可以通过以下方式之一创建 Bundle：
注意
在某些用例中，您可能需要将自定义更改包含到 Bundle 附带的 SUC plans 中（例如，添加自定义容忍度）。请确保在通过以下步骤生成的 Bundle 中包含这些更改。
1. 通过手动将 RKE2 或 K3s 的 Bundle 内容从 suse-edge/fleet-examples 复制到 从 YAML 创建 页面。
2. 通过从所需的发布标签克隆 suse-edge/fleet-examples 储存库，并在 从 YAML 创建 页面中选择 从文件读取 选项。从那里，导航到您需要的 Bundle（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 创建 页面中的 Bundle 内容。
更改 Bundle 的目标集群：
- 要匹配所有下游集群，请将默认 Bundle .spec.targets 更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 有关更细粒度的下游集群映射，请参阅 Mapping to Downstream Clusters.
选择创建

33.1.5.4.2.2 Bundle 创建 - 手动创建 #

拉取 Bundle 资源：

对于 RKE2 集群：

curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/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.6.1/bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml

编辑 Bundle target 配置，在 spec.targets 下提供您所需的目标列表。默认情况下，来自 Bundle 的 suse-edge/fleet-examples 资源不会映射到任何下游集群。
- 要匹配所有集群，请将默认的 Bundle target 更改为：
```
spec:
  targets:
  - clusterSelector: {}
```
- 或者，如果您需要更细粒度的集群选择，请参阅 Mapping to Downstream Clusters

将 Bundle 资源应用到您的 management cluster：

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

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

在 fleet-default 命名空间下查看创建的 Bundle 资源：

# 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

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

在某些情况下，用户可能希望将 Kubernetes upgrade SUC plans 集成到他们自己的第三方 GitOps 工作流中（例如 Flux）。

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

之后，可以在以下位置找到这些资源：

针对 RKE2 集群升级：
- 针对 control-plane 节点 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-control-plane.yaml
- 针对 worker 节点 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-worker.yaml
针对 K3s 集群升级：
- 针对 control-plane 节点 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-control-plane.yaml
- 针对 worker 节点 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-worker.yaml

重要

这些 Plan 资源由 System Upgrade Controller 解析，并应部署在您希望升级的每个下游集群上。有关 SUC 部署信息，请参见第 18.2 节 “安装系统升级控制器”。

为了更好地了解如何使用您的 GitOps 工作流来部署用于 Kubernetes 版本升级的 SUC Plans，建议查看使用 Fleet 的更新流程的概览 (第 33.1.5.2 节 “概述”)。

33.1.6 Helm chart 升级 #

本节包含以下部分：

第 33.1.6.1 节 “针对隔离环境的准备工作” - 包含有关如何将 Edge 相关的 OCI chart 和镜像传输到您的私有镜像仓库的信息。
第 33.1.6.2 节 “升级过程” - 包含有关不同 Helm chart 升级用例及其升级过程的信息。

33.1.6.1 针对隔离环境的准备工作 #

33.1.6.1.1 确保您可以访问您的 Helm chart Fleet #

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

将您的 chart Fleet 资源托管在您的 management cluster 可访问的本地 Git 服务器上。
使用 Fleet 的 CLI 将 Helm chart 转换为 Bundle，这样您就可以直接使用它，而无需将其托管在其他地方。可以从 Fleet 的发布页面获取其 CLI，对于 Mac 用户，有一个 fleet-cli Homebrew 公式。

33.1.6.1.2 查找 Edge 发布版本所需的资产 #

转到“Day 2”发布页面，找到您要将 chart 升级到的 Edge 版本，然后点击资产。

从 “资产” 部分，下载以下文件：

发布文件	说明
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 版本相关的镜像列表。

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

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

33.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 选项下指定的镜像仓库。

33.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 安装说明，请参阅 Installing Helm。
```
./edge-load-oci-artefacts.sh --archive-directory edge-release-oci-tgz-<date> --registry <REGISTRY.YOURDOMAIN.COM:PORT> --source-registry registry.suse.com
```

33.1.6.1.7 在您的 Kubernetes 发行版中配置您的私有镜像仓库 #

对于 RKE2，请参阅 Private Registry Configuration

对于 K3s，请参阅 Private Registry Configuration

33.1.6.2 升级过程 #

本节重点介绍以下 Helm 升级过程用例：

重要

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

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

本节介绍如何：

33.1.6.2.1.1 为您的 chart 准备 fleet 资源 #

从您希望使用的 Edge release 标签中获取该 chart 的 Fleet 资源。
导航至 Helm chart fleet (fleets/day2/chart-templates/<chart>)
如果您打算使用 GitOps 工作流，请将 chart Fleet 目录复制到您将执行 GitOps 的 Git 储存库中。
可选，如果 Helm chart 需要对其 values 进行配置，请编辑已复制目录中 .helm.values 文件内的 fleet.yaml 配置。
可选，在某些用例中，您可能需要向 chart 的 fleet 添加额外资源，以便使其更好地适应您的环境。有关如何增强 Fleet 目录的信息，请参阅 Git Repository Contents。

注意

在某些情况下，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

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

defaultNamespace: longhorn-system

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

33.1.6.2.1.2 为您的 chart 部署 Fleet #

您可以通过使用 GitRepo (第 33.1.6.2.1.2.1 节 “GitRepo”) 或 Bundle (第 33.1.6.2.1.2.2 节 “捆绑包”) 为您的 chart 部署 Fleet。

注意

在部署 Fleet 时，如果您收到 Modified 消息，请确保在 Fleet 的 diff 部分中添加相应的 comparePatches 条目。有关更多信息，请参阅生成忽略已修改 GitRepo 的差异。

33.1.6.2.1.2.1 GitRepo #

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

GitRepo 资源可以通过 Rancher UI 部署，也可以通过将资源部署到 management cluster 来手动部署。

用于手动部署的 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: {}

33.1.6.2.1.2.2 捆绑包 #

Bundle 资源包含需要由 Fleet 部署的原始 Kubernetes 资源。通常建议使用 GitRepo 方法，但对于环境处于隔离状态且无法支持本地 Git 服务器的用例，Bundles 可以帮助您将 Helm chart Fleet 传播到目标集群。

Bundle 可以通过 Rancher UI (Continuous Delivery → Advanced → Bundles → Create from YAML) 部署，也可以通过在正确的 Fleet 名称空间中手动部署 Bundle 资源来部署。有关 Fleet 名称空间的信息，请参阅上游文档。

可以通过利用 Fleet 的将 Helm Chart 转换为 Bundle 方法来创建用于 Edge Helm chart 的 Bundles。

您可以在下方找到关于如何从 longhorn 和 longhorn-crd Helm chart fleet 模板创建 Bundle 资源，并将此 bundle 手动部署到您的 management cluster 的示例。

注意

为了说明工作流程，以下示例使用了 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 转换为 Bundle 资源。
注意
Fleet 的 CLI 可以从其发布资产页面 (fleet-linux-amd64) 获取。
对于 Mac 用户，有一个 fleet-cli Homebrew 配方。
```
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 转换为 Bundle 资源。

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 文件部署到您的 management cluster：
```
kubectl apply -f longhorn-crd-bundle.yaml
kubectl apply -f longhorn-bundle.yaml
```

遵循这些步骤将确保 SUSE Storage 被部署到所有指定的 downstream 集群上。

33.1.6.2.1.3 管理已部署的 Helm chart #

使用 Fleet 部署后，有关 Helm chart 升级的信息，请参阅第 33.1.6.2.2 节 “我想升级一个由 Fleet 管理的 Helm chart”。

33.1.6.2.2 我想升级一个由 Fleet 管理的 Helm chart #

确定您需要将 chart 升级到的版本，以便其与所需的 Edge 版本兼容。每个 Edge 版本的 Helm chart 版本可以在发行说明 (第 41 章 “发行说明”) 中查看。
在您由 Fleet 监控的 Git 储存库中，使用发行说明 (第 41 章 “发行说明”) 中的正确 chart 版本和 储存库 编辑 Helm chart 的 fleet.yaml 文件。
提交并推送更改到您的储存库后，这将触发所需 Helm chart 的升级

33.1.6.2.3 我想升级一个通过 EIB 部署的 Helm chart #

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

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

您可以在下方找到以下信息：

升级过程的常规概述 (第 33.1.6.2.3.1 节 “概述”)。
必要的升级步骤 (第 33.1.6.2.3.2 节 “升级步骤”)。
一个示例 (第 33.1.6.2.3.3 节 “示例”)，展示了使用所解释的方法进行Longhorn chart 升级。
如何将升级过程与不同的 GitOps 工具 (第 33.1.6.2.3.4 节 “使用第三方 GitOps 工具进行 Helm chart 升级”)结合使用。

33.1.6.2.3.1 概述 #

通过`EIB`部署的 Helm charts 将通过一个名为eib-charts-upgrader的`fleet`进行升级。

此`fleet`处理*用户提供*的数据，以*更新*特定的一组 HelmChart 资源。

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

用户仅需：

在本地拉取需要升级的每个 Helm chart 的归档文件。
将这些归档文件传递给generate-chart-upgrade-data.shgenerate-chart-upgrade-data.sh`脚本，该脚本会将这些归档文件中的数据包含到`eib-charts-upgrader fleet 中。
将`eib-charts-upgrader` fleet 部署到其`management cluster`。这可以通过`GitRepo`或`Bundle`资源来完成。

部署完成后，`eib-charts-upgrader`将在 Fleet 的帮助下，将其资源发送到目标downstream集群。

这些资源包括：

一组`Secrets`，其中包含*用户提供*的 Helm chart 数据。
一个`Kubernetes Job`，它将部署一个`Pod`，该组件将挂载前面提到的`Secrets`，并据此对相应的 HelmChart 资源应用补丁。

如前所述，这将触发`helm-controller`，它将执行实际的 Helm chart 升级。

您可以在下方找到上述描述的图示：

33.1.6.2.3.2 升级步骤 #

从正确的发布标签克隆`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 脚本：
```
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 Secret YAML 文件，并将其存储在由 --fleet-path 指定的 fleet 的 base/secrets 目录中。
generate-chart-upgrade-data.sh 脚本还会对 fleet 进行额外的修改，以确保生成的 Kubernetes Secret YAML 文件能被 fleet 部署的工作负载正确使用。
重要
用户不应在 generate-chart-upgrade-data.sh 脚本生成的内容之上进行任何更改。

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

对于支持 GitOps 的环境（例如：非隔离的，或隔离的但允许本地 Git 服务器支持）：
1. 将 fleets/day2/eib-charts-upgrader Fleet 复制到您将用于 GitOps 的储存库中。
  注意
  确保 Fleet 包含由 generate-chart-upgrade-data.sh 脚本所做的更改。
2. 配置一个 GitRepo 资源，该资源将用于交付 eib-charts-upgrader Fleet 的所有资源。
  1. 有关通过 Rancher UI 进行 GitRepo 配置和部署的信息，请参阅在 Rancher UI 中访问 Fleet。
  2. 有关 GitRepo 手动配置和部署的信息，请参阅创建部署。
对于不支持 GitOps 的环境（例如：为隔离的且不允许使用本地 Git 服务器）：
1. 从`rancher/fleet`release 页面下载 fleet-cli 二进制文件（适用于 fleet-linux-amd64 的 Linux）。对于 Mac 用户，可以使用 Homebrew 配方 - fleet-cli。
2. 导航至 eib-charts-upgrader Fleet：
```
cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
3. 创建一个 targets.yaml 文件，用于指示 Fleet 在何处部署您的资源：
```
cat > targets.yaml <<EOF
targets:
# To match all downstream clusters
- clusterSelector: {}
EOF
```
  有关如何映射目标集群的信息，请参阅上游文档。
4. 使用 fleet-cli 将 Fleet 转换为 Bundle 资源：
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
  这将创建一个 Bundle (bundle.yaml)，其中将包含来自 eib-charts-upgrader Fleet 的所有模板化资源。
  有关 fleet apply 命令的更多信息，请参阅 fleet apply。
  有关将 Fleet 转换为 Bundle 的更多信息，请参阅将 Helm Chart 转换为 Bundle。
5. 部署 Bundle。可以通过以下两种方式之一完成此操作：
  1. 通过 Rancher UI - 导航到 持续交付 → 高级 → Bundles → 从 YAML 创建，然后粘贴 bundle.yaml 内容，或者点击 Read from File 选项并传入文件本身。
  2. 手动 - 在您的 management cluster 中手动部署 bundle.yaml 文件。

执行这些步骤将成功部署 GitRepo/Bundle 资源。该资源将被 Fleet 获取，其内容将部署到用户在先前步骤中指定的目标集群上。有关该过程的概述，请参阅第 33.1.6.2.3.1 节 “概述”。

有关如何跟踪升级过程的信息，您可以参阅第 33.1.6.2.3.3 节 “示例”。

重要

一旦成功验证了 Chart 升级，请删除 Bundle/GitRepo 资源。

这将从您的 downstream 集群中删除不再需要的升级资源，以确保不会发生未来的版本冲突。

33.1.6.2.3.3 示例 #

注意

下面的示例演示了如何在 downstream 集群上将通过 EIB 部署的 Helm Chart 从一个版本升级到另一个版本。请注意，此示例中使用的版本不是建议版本。有关特定于 Edge 版本的版本建议，请参阅发行说明 (第 41 章 “发行说明”)。

适用场景：

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

该集群已通过 EIB 部署，使用了以下镜像定义 snippet：

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.6 版本兼容的版本。这意味着它需要升级到 1.11.2。
假设负责管理 doc-example 的 management cluster 是 *隔离的*环境，不支持本地 Git 服务器，并且拥有可正常工作的 Rancher 设置。

遵循升级步骤 (第 33.1.6.2.3.2 节 “升级步骤”)：

从 release-3.6.1 标签克隆 suse-edge/fleet-example 储存库。

git clone -b release-3.6.1 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.11.2 chart archive
helm pull oci://dp.apps.rancher.io/charts/suse-storage --version 1.11.2

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

目录设置应如下所示：

.
├── archives
│   └── longhorn-1.11.2.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-1.11.2.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 创建一个 Bundle：
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 转换为 Bundle：
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
4. 现在，将 bundle.yaml 传输到您的 management cluster 机器上。
通过 Rancher UI 部署 Bundle：
图 33.1︰通过 Rancher UI 部署 Bundle #

在此处，选择 从文件读取 并在您的系统上找到 bundle.yaml 文件。
这将自动填充 Rancher UI 中的 Bundle。
选择创建。
部署成功后，您的 Bundle 应如下所示：
图 33.2︰ Bundle 部署成功 #

Bundle 成功部署后，要监控升级过程：

验证 Upgrade Pod 的日志：
现在，验证由 helm-controller 为升级创建的 Pod 的日志：
1. Pod 名称将遵循以下模板 - helm-install-longhorn-<random-suffix>
2. Pod 将位于部署了 HelmChart 资源的名称空间中。在我们的案例中，这是 kube-system。
  图 33.3︰成功升级 Longhorn chart 的日志 #
通过导航到 Rancher 的 HelmCharts 部分 (More Resources → HelmCharts)，验证 HelmChart 版本是否已更新。选择部署 chart 的名称空间，在此示例中为 kube-system。
最后，检查 Longhorn Pod 是否正在运行。

完成上述验证后，可以确信 Longhorn Helm chart 已升级到 1.11.2 版本。

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

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

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

要了解此工作流的预期用途，查看第 33.1.6.2.3.1 节 “概述” 和第 33.1.6.2.3.2 节 “升级步骤” 会有所帮助。