Applies to SUSE Edge 3.6

33 下游集群 #

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

33.1 Fleet #

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

本节涵盖以下主题：

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

33.1.1 组件 #

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

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

Note

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

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

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

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

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

33.1.2 确定您的用例 #

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

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

33.1.2.1 GitRepo #

GitRepo 是一个 Fleet (Chapter 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”工作流。

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

33.1.4 操作系统升级 #

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

本节涵盖以下主题：

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

33.1.4.1 组件 #

本节涵盖 OS upgrade 过程在默认“第 2 天”组件 (Section 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。

Note

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

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

Note

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

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

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

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

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

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

33.1.4.3 要求 #

常规：

SCC 注册机器 - 所有 downstream 集群节点都应注册到 https://scc.suse.com/，这是使相应的 systemd.service 能够成功连接到所需 RPM 储存库所必需的。
Important
对于需要操作系统版本迁移的 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
  Note
  任何额外的容忍度必须添加到每个计划的 .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 计划部署 #

Important

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

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

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

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

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

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

33.1.4.4.1 SUC 计划部署 - GitRepo 资源 #

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

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

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

33.1.4.4.1.1 GitRepo 创建 - Rancher UI #

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

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

Important

请务必使用来自有效 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 - Section 33.1.4.4.2.1, “Bundle 创建 - Rancher UI”（当 Rancher 可用时）。
通过手动部署 (Section 33.1.4.4.2.2, “Bundle 创建 - 手动”) 资源到您的 management cluster。

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

33.1.4.4.2.1 Bundle 创建 - Rancher UI #

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

Important

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

通过 Rancher UI 创建 bundle：

在左上角，点击 ☰ → 持续交付
转到高级 > Bundles
选择 从 YAML 创建
在此处，您可以通过以下方式之一创建 Bundle：
Note
在某些用例中，您可能需要将自定义更改包含到 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 (Section 33.1.4.1.1, “systemd.service”)。
config-map.yaml 是一个 ConfigMap，其中保存了供 upgrade.sh 脚本使用的配置。

Important

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

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

33.1.5 Kubernetes 版本升级 #

Important

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

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

本节涵盖以下主题：

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

33.1.5.1 组件 #

本节涵盖了 K8s upgrade 过程在默认“Day 2”组件 (Section 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 部署并管理到目标集群上。

Note

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

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

Note

GitRepo/Bundle 资源始终部署在 management cluster 上。是使用 GitRepo 还是 Bundle 资源取决于您的用例，请查看 Section 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 (Section 33.1.5.1.1, “rke2-upgrade”) 或 k3s-upgrade (Section 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
  Note
  任何额外的容忍度必须添加到每个 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 计划部署 #

Important

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

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

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

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

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

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

33.1.5.4.1 SUC 计划部署 - GitRepo 资源 #

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

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

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

33.1.5.4.1.1 GitRepo 创建 - Rancher UI #

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

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

Important

请务必使用来自有效 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 - Section 33.1.5.4.2.1, “Bundle 创建 - Rancher UI”（当 Rancher 可用时）。
通过手动部署 (Section 33.1.5.4.2.2, “Bundle 创建 - 手动创建”) 资源到您的 management cluster。

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

33.1.5.4.2.1 Bundle 创建 - Rancher UI #

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

Important

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

通过 Rancher UI 创建 bundle：

在左上角，点击 ☰ → 持续交付
转到高级 > Bundles
选择 从 YAML 创建
在此处，您可以通过以下方式之一创建 Bundle：
Note
在某些用例中，您可能需要将自定义更改包含到 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

Important

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

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

33.1.6 Helm chart 升级 #

本节包含以下部分：

Section 33.1.6.1, “针对隔离环境的准备工作” - 包含有关如何将 Edge 相关的 OCI chart 和镜像传输到您的私有镜像仓库的信息。
Section 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 的待加载归档文件。
Note
如果指定了 -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 的归档文件。
Note
如果指定了 -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
```
Note
这将从 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 镜像加载到您的私有镜像仓库：
Note
此脚本假定 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 升级过程用例：

Important

手动部署的 Helm charts 无法可靠地升级。我们建议使用 Section 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。

Note

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

Note

这些仅是用于说明 longhorn chart 自定义配置的示例值。它们 *不*应被视为 longhorn chart 的部署指南。

33.1.6.2.1.2 为您的 chart 部署 Fleet #

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

Note

在部署 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 的示例。

Note

为了说明工作流程，以下示例使用了 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 资源。
Note
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 升级的信息，请参阅 Section 33.1.6.2.2, “我想升级一个由 Fleet 管理的 Helm chart”。

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

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

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

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

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

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

升级过程的常规概述 (Section 33.1.6.2.3.1, “概述”)。
必要的升级步骤 (Section 33.1.6.2.3.2, “升级步骤”)。
一个示例 (Section 33.1.6.2.3.3, “示例”)，展示了使用所解释的方法进行Longhorn chart 升级。
如何将升级过程与不同的 GitOps 工具 (Section 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 部署的工作负载正确使用。
Important
用户不应在 generate-chart-upgrade-data.sh 脚本生成的内容之上进行任何更改。

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

对于支持 GitOps 的环境（例如：非隔离的，或隔离的但允许本地 Git 服务器支持）：
1. 将 fleets/day2/eib-charts-upgrader Fleet 复制到您将用于 GitOps 的储存库中。
  Note
  确保 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 获取，其内容将部署到用户在先前步骤中指定的目标集群上。有关该过程的概述，请参阅 Section 33.1.6.2.3.1, “概述”。

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

Important

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

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

33.1.6.2.3.3 示例 #

Note

下面的示例演示了如何在 downstream 集群上将通过 EIB 部署的 Helm Chart 从一个版本升级到另一个版本。请注意，此示例中使用的版本不是建议版本。有关特定于 Edge 版本的版本建议，请参阅发行说明 (Chapter 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 设置。

遵循升级步骤 (Section 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：
Figure 33.1: 通过 Rancher UI 部署 Bundle #

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

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

验证 Upgrade Pod 的日志：
现在，验证由 helm-controller 为升级创建的 Pod 的日志：
1. Pod 名称将遵循以下模板 - helm-install-longhorn-<random-suffix>
2. Pod 将位于部署了 HelmChart 资源的名称空间中。在我们的案例中，这是 kube-system。
  Figure 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 中。有关如何操作的详细信息，请参见 Section 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 设置。

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