Applies to SUSE Edge 3.6

33 Clústeres en sentido descendente #

Esta sección cubre las posibles formas de realizar operaciones de "Día 2" para diferentes partes de su downstream clúster.

33.1 Fleet #

Esta sección ofrece información sobre cómo realizar operaciones de «Día 2» utilizando el componente Fleet (Chapter 6, Fleet).

Los siguientes temas se tratan como parte de esta sección:

Section 33.1.1, “Componentes” - componentes predeterminados utilizados para todas las operaciones de «Día 2».
Section 33.1.2, “Determinad vuestro caso de uso” - proporciona una visión general de los recursos personalizados de Fleet que se utilizarán y su idoneidad para diferentes casos de uso de operaciones de «Día 2».
Section 33.1.3, “Flujo de trabajo de Día 2” - proporciona una guía de flujo de trabajo para ejecutar operaciones de «Día 2» con Fleet.
Section 33.1.4, “Actualización del SO” - describe cómo realizar actualizaciones del SO utilizando Fleet.
Section 33.1.5, “Actualización de la versión de Kubernetes” - describe cómo realizar actualizaciones de la versión de Kubernetes utilizando Fleet.
Section 33.1.6, “Actualización de Helm chart” - describe cómo realizar actualizaciones de Helm charts utilizando Fleet.

33.1.1 Componentes #

A continuación, podéis encontrar una descripción de los componentes predeterminados que deben configurarse en vuestro clúster downstream para que podáis realizar con éxito operaciones de «Día 2» utilizando Fleet.

33.1.1.1 System Upgrade Controller (SUC) #

Note

Debe desplegarse en cada clúster descendente.

System Upgrade Controller es responsable de ejecutar tareas en nodos especificados basándose en los datos de configuración proporcionados a través de un recurso personalizado, llamado Plan.

SUC se utiliza activamente para actualizar el sistema operativo y la distribución de Kubernetes.

Para obtener más información sobre el componente SUC y cómo encaja en la pila Edge, consultad Chapter 18, Controlador de actualización del sistema.

Para obtener información sobre cómo desplegar SUC, primero determinad vuestro caso de uso (Section 33.1.2, “Determinad vuestro caso de uso”) y, a continuación, consultad Instalación del controlador de actualización del sistema - GitRepo (Section 18.2.1.1, “Instalación del controlador de actualización del sistema - GitRepo”) o Instalación del controlador de actualización del sistema - Bundle (Section 18.2.1.2, “Instalación del controlador de actualización del sistema - Bundle”).

33.1.2 Determinad vuestro caso de uso #

Fleet utiliza dos tipos de recursos personalizados para permitir la gestión de recursos de Kubernetes y Helm.

A continuación, podéis encontrar información sobre el propósito de estos recursos y los casos de uso para los que son más adecuados en el contexto de las operaciones de «Día 2».

33.1.2.1 GitRepo #

Un GitRepo es un recurso de Fleet (Chapter 6, Fleet) que representa un repositorio Git desde el cual Fleet puede crear Bundles. Cada Bundle se crea en función de las rutas de configuración definidas dentro del recurso GitRepo. Para obtener más información, consultad la documentación de GitRepo.

En el contexto de las operaciones de «Día 2», los recursos GitRepo se utilizan normalmente para desplegar SUC o SUC Plans en entornos no aislados que utilizan un enfoque de Fleet GitOps.

Alternativamente, los recursos GitRepo también pueden utilizarse para desplegar SUC o SUC Plans en entornos aislados, siempre que reflejéis la configuración de vuestro repositorio a través de un servidor git local.

33.1.2.2 Bundle #

Bundles contienen recursos de Kubernetes sin procesar que se implementarán en el clúster de destino. Normalmente se crean a partir de un recurso GitRepo, pero existen casos de uso en los que se pueden desplegar manualmente. Para obtener más información, consultad la documentación de Bundle.

En el contexto de las operaciones de "Día 2", los recursos Bundle se utilizan normalmente para desplegar SUC o SUC Plans en entornos aislados que no utilizan ningún tipo de procedimiento de GitOps local (por ejemplo, un servidor git local).

Alternativamente, si vuestro caso de uso no permite un flujo de trabajo GitOps (por ejemplo, mediante un repositorio Git), los recursos Bundle también podrían utilizarse para desplegar SUC o SUC Plans en entornos no aislados.

33.1.3 Flujo de trabajo de Día 2 #

A continuación se muestra un flujo de trabajo de «Día 2» que debe seguirse al actualizar la versión de un clúster downstream a una versión específica de Edge.

Actualización de versión del SO (Section 33.1.4, “Actualización del SO”)
Actualización de versión de Kubernetes (Section 33.1.5, “Actualización de la versión de Kubernetes”)
Actualización de versión de Helm charts (Section 33.1.6, “Actualización de Helm chart”)

33.1.4 Actualización del SO #

Esta sección describe cómo realizar una actualización del sistema operativo utilizando Chapter 6, Fleet y Chapter 18, Controlador de actualización del sistema.

Los siguientes temas se tratan como parte de esta sección:

Section 33.1.4.1, “Componentes” - componentes adicionales utilizados por el proceso de actualización.
Section 33.1.4.2, “Descripción general” - descripción general del proceso de actualización.
Section 33.1.4.3, “Requisitos” - requisitos del proceso de actualización.
Section 33.1.4.4, “Actualización del SO - Ampliación del plan SUC” - información sobre cómo desplegar SUC plans, responsable de activar el proceso de actualización.

33.1.4.1 Componentes #

Esta sección cubre los componentes personalizados que utiliza el proceso OS upgrade sobre los componentes predeterminados (Section 33.1.1, “Componentes”) de «Día 2».

33.1.4.1.1 systemd.service #

La actualización del SO en un nodo específico se gestiona mediante un systemd.service.

Se crea un servicio diferente dependiendo del tipo de actualización que requiera el SO de una versión de Edge a otra:

Para las versiones de Edge que requieren la misma versión de SO (p. ej., 6.1), se creará el os-pkg-update.service. Utiliza transactional-update para realizar una actualización normal de paquetes.
Para las versiones de Edge que requieren una migración de versión de SO (p. ej., 6.1 → 6.2), se creará el os-migration.service. Utiliza transactional-update para realizar:
1. Una actualización normal de paquetes que garantiza que todos los paquetes estén actualizados para mitigar cualquier fallo en la migración relacionado con versiones antiguas de paquetes.
2. Una migración de SO utilizando el comando zypper migration.

Los servicios mencionados anteriormente se envían a cada nodo a través de un SUC plan que debe estar ubicado en el clúster downstream que necesita una actualización del SO.

33.1.4.2 Descripción general #

La actualización del sistema operativo para los nodos del clúster downstream se realiza utilizando Fleet y el System Upgrade Controller (SUC).

Fleet se utiliza para desplegar y gestionar SUC plans en el clúster deseado.

Note

SUC plans son recursos personalizados que describen los pasos que SUC debe seguir para que se ejecute una tarea específica en un conjunto de nodos. Para ver un ejemplo de cómo es un SUC plan, consultad el repositorio upstream.

Los OS SUC plans se envían a cada clúster desplegando un recurso GitRepo o Bundle en un espacio de trabajo de Fleet específico. Fleet recupera el GitRepo/Bundle desplegado y despliega su contenido (el OS SUC plans) en el clúster o clústeres deseados.

Note

Los recursos GitRepo/Bundle siempre se despliegan en el management cluster. Si utilizar un recurso GitRepo o Bundle depende de vuestro caso de uso, consultad Section 33.1.2, “Determinad vuestro caso de uso” para obtener más información.

OS SUC plans describe el siguiente flujo de trabajo:

Acordonad siempre los nodos antes de las actualizaciones del SO.
Actualizad siempre los nodos control-plane antes que los nodos worker.
Actualizad siempre el clúster uno a uno.

Una vez que los OS SUC plans se hayan desplegado, el flujo de trabajo tiene este aspecto:

SUC reconcilia los OS SUC plans desplegados y crea un Kubernetes Job en cada nodo.
El Kubernetes Job crea un systemd.service (Section 33.1.4.1.1, “systemd.service”) para la actualización de paquetes o la migración del SO.
El systemd.service creado activa el proceso de actualización del SO en el nodo específico.
Important
Una vez que finalice el proceso de actualización del SO, el nodo correspondiente se rebooted para aplicar las actualizaciones en el sistema.

A continuación podéis encontrar un diagrama de la descripción anterior:

33.1.4.3 Requisitos #

General:

Máquina registrada en SCC - Todos los downstream nodos del clúster deben estar registrados en https://scc.suse.com/, lo cual es necesario para que el systemd.service correspondiente pueda conectarse correctamente al repositorio RPM deseado.
Important
Para las versiones Edge que requieran una migración de la versión del SO (p. ej., 6.1 → 6.2), aseguraos de que vuestra clave SCC admita la migración a la nueva versión.
Aseguraos de que las tolerancias del plan SUC coincidan con las tolerancias de los nodos - Si los nodos de vuestro clúster de Kubernetes tienen taints personalizados, aseguraos de añadir tolerancias para esas taints en los planes SUC. Por defecto, los planes SUC solo tienen tolerancias para los nodos del plano de control. Las tolerancias por defecto incluyen:
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  Note
  Cualquier tolerancia adicional debe añadirse bajo la sección .spec.tolerations de cada plan. Los planes SUC relacionados con la actualización del SO se pueden encontrar en el repositorio suse-edge/fleet-examples bajo fleets/day2/system-upgrade-controller-plans/os-upgrade. Aseguraos de utilizar los planes de una etiqueta de versión de repositorio válida.
  Un ejemplo de cómo definir tolerancias personalizadas para el plan SUC de plano de control sería el siguiente:
  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" ...

Entorno aislado:

Duplicar repositorios RPM de SUSE - Los repositorios RPM del SO deben estar duplicados localmente para que el systemd.service pueda tener acceso a ellos. Esto se puede lograr utilizando RMT o SUMA.

33.1.4.4 Actualización del SO - Ampliación del plan SUC #

Important

Para los entornos actualizados previamente mediante este procedimiento, los usuarios deben asegurarse de que se complete uno de los siguientes pasos:

Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - se puede realizar eliminando el clúster deseado de la GitRepo/Bundle configuración de destino existente, o eliminando el recurso GitRepo/Bundle por completo.
Reuse the existing GitRepo/Bundle resource - se puede realizar apuntando la revisión del recurso a una nueva etiqueta que contenga las flotas correctas para la suse-edge/fleet-examples release deseada.

Esto se hace para evitar conflictos entre SUC Plans para versiones de release de Edge anteriores.

Si los usuarios intentan actualizar mientras existen SUC Plans en el clúster downstream, verán el siguiente error de 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..

Como se menciona en Section 33.1.4.2, “Descripción general”, las actualizaciones del SO se realizan enviando SUC plans al clúster deseado a través de una de las siguientes formas:

Recurso GitRepo de Fleet - Section 33.1.4.4.1, “Ampliación del plan SUC - Recurso GitRepo”.
Recurso Bundle de Fleet - Section 33.1.4.4.2, “Despliegue del plan SUC - Recurso Bundle”.

Para determinar qué recurso debéis utilizar, consultad Section 33.1.2, “Determinad vuestro caso de uso”.

Para casos de uso en los que deseéis desplegar el OS SUC plans desde una herramienta GitOps de terceros, consultad Section 33.1.4.4.3, “Despliegue del plan SUC: flujo de trabajo GitOps de terceros”

33.1.4.4.1 Ampliación del plan SUC - Recurso GitRepo #

Un recurso GitRepo, que envía el OS SUC plans necesario, puede desplegarse de una de las siguientes formas:

A través del Rancher UI - Section 33.1.4.4.1.1, “Creación de GitRepo - Interfaz de usuario de Rancher” (cuando Rancher esté disponible).
Mediante desplegar manualmente (Section 33.1.4.4.1.2, “Creación de GitRepo - manual”) el recurso en vuestro management cluster.

Una vez desplegado, para supervisar el proceso de actualización del SO de los nodos de vuestro clúster de destino, consultad Section 18.3, “Monitorización de los planes del controlador de actualización del sistema”.

33.1.4.4.1.1 Creación de GitRepo - Interfaz de usuario de Rancher #

Para crear un recurso GitRepo a través de la interfaz de usuario de Rancher, seguid su documentación oficial.

El equipo de Edge mantiene un fleet listo para usar. Dependiendo de vuestro entorno, este fleet podría utilizarse directamente o como plantilla.

Important

Utilizad siempre este fleet a partir de una etiqueta de release de Edge válida.

Para casos de uso en los que no sea necesario incluir cambios personalizados en el SUC plans que distribuye el fleet, referenciad directamente el fleet os-upgrade desde el repositorio suse-edge/fleet-examples.

En los casos en los que se necesiten cambios personalizados (por ejemplo, para añadir tolerancias personalizadas), referenciad el fleet os-upgrade desde un repositorio independiente, lo que os permite añadir los cambios a los planes SUC según sea necesario.

Podéis ver un ejemplo de cómo se puede configurar un GitRepo para utilizar el fleet del repositorio suse-edge/fleet-examples aquí.

33.1.4.4.1.2 Creación de GitRepo - manual #

Extraed el recurso 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

Editad la configuración de GitRepo, bajo spec.targets especificad vuestra lista de destino deseada. Por defecto, los recursos GitRepo del suse-edge/fleet-examples NO están asignados a ningún clúster en sentido descendente.
- Para hacer coincidir todos los clústeres, cambiad el GitRepo target por defecto a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Alternativamente, si deseas una selección de clústeres más granular, consulta Mapeo a clústeres en sentido descendente
Aplica el recurso GitRepo en tu management cluster:
```
kubectl apply -f os-upgrade-gitrepo.yaml
```

Visualiza el recurso GitRepo creado bajo el espacio de nombres fleet-default:

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 Despliegue del plan SUC - Recurso Bundle #

Un recurso Bundle, que incluye los OS SUC Plans necesarios, puede desplegarse de una de las siguientes maneras:

A través del Rancher UI - Section 33.1.4.4.2.1, “Creación de Bundle - Interfaz de usuario de Rancher” (cuando Rancher esté disponible).
Mediante el despliegue manual (Section 33.1.4.4.2.2, “Creación de bundle - manual”) del recurso en tu management cluster.

Una vez desplegado, para supervisar el proceso de actualización del SO de los nodos de tu clúster de destino, consulta Section 18.3, “Monitorización de los planes del controlador de actualización del sistema”.

33.1.4.4.2.1 Creación de Bundle - Interfaz de usuario de Rancher #

El equipo de Edge mantiene un bundle listo para usar que puede utilizarse en los pasos siguientes.

Important

Utiliza siempre este bundle a partir de una etiqueta de release de Edge válida.

Para crear un bundle a través de la interfaz de usuario de Rancher:

En la esquina superior izquierda, haz clic en ☰ → Continuous Delivery
Ve a Avanzado > Bundles
Selecciona Crear a partir de YAML
Desde aquí puedes crear el Bundle de una de las siguientes maneras:
Note
Puede haber casos de uso en los que necesites incluir cambios personalizados en el SUC plans que incorpora el bundle (por ejemplo, para añadir tolerancias personalizadas). Asegúrate de incluir esos cambios en el bundle que se generará mediante los pasos siguientes.
1. Copiando manualmente el contenido del bundle desde suse-edge/fleet-examples a la página Crear a partir de YAML.
2. Clonando el repositorio suse-edge/fleet-examples desde la etiqueta de release deseada y seleccionando la opción Leer desde archivo en la página Crear a partir de YAML. Desde ahí, navega a la ubicación del bundle (bundles/day2/system-upgrade-controller-plans/os-upgrade) y selecciona el archivo del bundle. Esto rellenará automáticamente la página Crear a partir de YAML con el contenido del bundle.
Cambia los clústeres target para el Bundle:
- Para que coincida con todos los clústeres descendentes, cambia el .spec.targets del bundle predeterminado a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Para obtener asignaciones de clústeres en sentido descendente más granulares, consulta Mapeo a clústeres en sentido descendente.
Selecciona Crear

33.1.4.4.2.2 Creación de bundle - manual #

Obtén el recurso 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

Edita las configuraciones target del Bundle, y en spec.targets proporciona la lista de destinos deseada. Por defecto, los recursos Bundle del suse-edge/fleet-examples NO están asignados a ningún clúster descendente.
- Para hacer coincidir todos los clústeres, cambia el Bundle target por defecto a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Alternativamente, si deseas una selección de clústeres más granular, consulta Mapping to Downstream Clusters
Aplica el recurso Bundle a tu management cluster:
```
kubectl apply -f os-upgrade-bundle.yaml
```
Visualiza el recurso Bundle creado en el espacio de nombres fleet-default:
```
kubectl get bundles -n fleet-default
```

33.1.4.4.3 Despliegue del plan SUC: flujo de trabajo GitOps de terceros #

Puede haber casos de uso en los que desees incorporar el OS SUC plans a tu propio flujo de trabajo GitOps de terceros (p. ej., Flux).

Para obtener los recursos de actualización del SO que necesitas, primero determina la etiqueta de release de Edge del repositorio suse-edge/fleet-examples que desees utilizar.

Después de eso, los recursos se pueden encontrar en fleets/day2/system-upgrade-controller-plans/os-upgrade, donde:

plan-control-plane.yaml es un recurso de plan SUC para nodos de control-plane.
plan-worker.yaml es un recurso de plan SUC para nodos worker.
secret.yaml es un Secret que contiene el script upgrade.sh, el cual es responsable de crear el systemd.service (Section 33.1.4.1.1, “systemd.service”).
config-map.yaml es un ConfigMap que contiene la configuración que consume el script upgrade.sh.

Important

Estos recursos Plan son interpretados por el System Upgrade Controller y deben desplegarse en cada clúster descendente que desees actualizar. Para obtener información sobre el despliegue de SUC, consulta Section 18.2, “Instalación del controlador de actualización del sistema”.

Para comprender mejor cómo puede utilizar tu flujo de trabajo GitOps para desplegar los SUC Plans para la actualización del SO, puede resultar útil echar un vistazo a visión general (Section 33.1.4.2, “Descripción general”).

33.1.5 Actualización de la versión de Kubernetes #

Important

Esta sección cubre las actualizaciones de Kubernetes para clústeres descendentes que NO se han creado a través de una instancia de Rancher (Chapter 4, Rancher). Para obtener información sobre cómo actualizar la versión de Kubernetes de los clústeres creados por Rancher, consultad Actualización y reversión de Kubernetes.

Esta sección describe cómo realizar una actualización de Kubernetes utilizando Chapter 6, Fleet y Chapter 18, Controlador de actualización del sistema.

Los siguientes temas se tratan como parte de esta sección:

Section 33.1.5.1, “Componentes” - componentes adicionales utilizados por el proceso de actualización.
Section 33.1.5.2, “Descripción general” - visión general del proceso de actualización.
Section 33.1.5.3, “Requisitos” - requisitos del proceso de actualización.
Section 33.1.5.4, “Actualización de K8s - Ampliación del plan SUC” - información sobre cómo desplegar SUC plans, responsable de activar el proceso de actualización.

33.1.5.1 Componentes #

Esta sección cubre los componentes personalizados que utiliza el proceso K8s upgrade sobre los componentes (Section 33.1.1, “Componentes”) predeterminados del "Día 2".

33.1.5.1.1 rke2-upgrade #

Imagen de contenedor responsable de actualizar la versión de RKE2 de un nodo específico.

Distribuida a través de un Pod creado por SUC basado en un Plan SUC. El Plan debe estar ubicado en cada clúster que necesite una actualización de RKE2.

Para obtener más información sobre cómo la imagen rke2-upgrade realiza la actualización, consultad la documentación de sentido ascendente.

33.1.5.1.2 k3s-upgrade #

Imagen de contenedor responsable de actualizar la versión de K3s de un nodo específico.

Distribuida a través de un Pod creado por SUC basado en un Plan SUC. El Plan debe estar ubicado en cada clúster que necesite una actualización de K3s.

Para obtener más información sobre cómo la imagen k3s-upgrade realiza la actualización, consultad la documentación de sentido ascendente.

33.1.5.2 Descripción general #

La actualización de la distribución de Kubernetes para los nodos del clúster downstream se realiza utilizando Fleet y System Upgrade Controller (SUC).

Fleet se utiliza para desplegar y gestionar SUC plans en el clúster deseado.

Note

SUC plans son recursos personalizados que describen los pasos que SUC debe seguir para que se ejecute una tarea específica en un conjunto de nodos. Para ver un ejemplo de cómo es un SUC plan, consultad el repositorio de sentido ascendente.

Los K8s SUC plans se distribuyen en cada clúster desplegando un recurso GitRepo o Bundle en un espacio de trabajo de Fleet específico. Fleet recupera el GitRepo/Bundle desplegado y despliega su contenido (el K8s SUC plans) en el clúster o clústeres deseados.

Note

Los recursos GitRepo/Bundle se despliegan siempre en el management cluster. El uso de un recurso GitRepo o Bundle depende de su caso de uso; consulte Section 33.1.2, “Determinad vuestro caso de uso” para obtener más información.

K8s SUC plans describen el siguiente flujo de trabajo:

Acordonad siempre los nodos antes de actualizar la versión de K8s.
Actualizad siempre los nodos control-plane antes que los nodos worker.
Actualizad siempre los nodos control-plane de uno en uno y los nodos worker de dos en dos.

Una vez desplegados los K8s SUC plans, el flujo de trabajo es el siguiente:

SUC reconcilia el K8s SUC plans desplegado y crea un Kubernetes Job en cada nodo.
Dependiendo de la distribución de Kubernetes, el Job creará un Pod que ejecute la imagen de contenedor rke2-upgrade (Section 33.1.5.1.1, “rke2-upgrade”) o k3s-upgrade (Section 33.1.5.1.2, “k3s-upgrade”).
El Pod creado seguirá el siguiente flujo de trabajo:
1. Reemplazad el binario rke2/k3s existente en el nodo por el de la imagen rke2-upgrade/k3s-upgrade.
2. Matad el proceso rke2/k3s en ejecución.
Matar el proceso rke2/k3s provoca un reinicio, lo que lanza un nuevo proceso que ejecuta el binario actualizado, dando lugar a una versión de distribución de Kubernetes actualizada.

A continuación podéis encontrar un diagrama de la descripción anterior:

33.1.5.3 Requisitos #

Haced una copia de seguridad de vuestra distribución de Kubernetes:
1. Para clústeres RKE2, consultad la documentación de copia de seguridad y restauración de RKE2.
2. Para clústeres K3s, consultad la documentación de copia de seguridad y restauración de K3s.
Aseguraos de que las tolerancias del Plan SUC coincidan con las tolerancias del nodo - Si los nodos de vuestro clúster de Kubernetes tienen taints personalizados, aseguraos de añadir tolerancias para esas taints en los Planes SUC. Por defecto, los Planes SUC solo tienen tolerancias para los nodos del plano de control. Las tolerancias predeterminadas incluyen:
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  Note
  Cualquier tolerancia adicional debe añadirse en la sección .spec.tolerations de cada Plan. Los Planes SUC relacionados con la actualización de versión de Kubernetes se pueden encontrar en el repositorio suse-edge/fleet-examples en:
  Para RKE2 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade
  Para K3s - fleets/day2/system-upgrade-controller-plans/k3s-upgrade
  Aseguraos de utilizar los Planes de una etiqueta de versión de repositorio válida.
  Un ejemplo de cómo definir tolerancias personalizadas para el Plan SUC del plano de control de RKE2 tendría este aspecto:
  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 Actualización de K8s - Ampliación del plan SUC #

Important

Para entornos actualizados previamente mediante este procedimiento, los usuarios deben asegurarse de que se completa uno de los siguientes pasos:

Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - se puede hacer eliminando el clúster deseado de la GitRepo/Bundle configuración de destino existente, o eliminando el recurso GitRepo/Bundle por completo.
Reuse the existing GitRepo/Bundle resource - se puede hacer apuntando la revisión del recurso a una nueva etiqueta que contenga las flotas correctas para la suse-edge/fleet-examples versión deseada.

Esto se hace para evitar conflictos entre SUC Plans para versiones de lanzamiento de Edge más antiguas.

Si los usuarios intentan actualizar mientras existen SUC Plans en el clúster downstream, verán el siguiente error de flota:

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

Como se menciona en Section 33.1.5.2, “Descripción general”, las actualizaciones de Kubernetes se realizan enviando SUC plans al clúster deseado a través de una de las siguientes formas:

Recurso de flota GitRepo (Section 33.1.5.4.1, “Ampliación del plan SUC - recurso GitRepo”)
Recurso de flota Bundle (Section 33.1.5.4.2, “Ampliación del plan SUC - Recurso Bundle”)

Para determinar qué recurso debéis utilizar, consultad Section 33.1.2, “Determinad vuestro caso de uso”.

Para casos de uso en los que deseéis desplegar el K8s SUC plans desde una herramienta GitOps de terceros, consultad Section 33.1.5.4.3, “Ampliación del plan SUC: flujo de trabajo GitOps de terceros”

33.1.5.4.1 Ampliación del plan SUC - recurso GitRepo #

Se puede desplegar un recurso GitRepo, que envía los K8s SUC plans necesarios, de una de las siguientes maneras:

A través de Rancher UI - Section 33.1.5.4.1.1, “Creación de GitRepo - Interfaz de usuario de Rancher” (cuando Rancher esté disponible).
Mediante el despliegue manual (Section 33.1.5.4.1.2, “Creación de GitRepo - manual”) del recurso en vuestro management cluster.

Una vez desplegado, para supervisar el proceso de actualización de Kubernetes de los nodos de vuestro clúster de destino, consultad Section 18.3, “Monitorización de los planes del controlador de actualización del sistema”.

33.1.5.4.1.1 Creación de GitRepo - Interfaz de usuario de Rancher #

Para crear un recurso GitRepo a través de la interfaz de usuario de Rancher, seguid su documentación oficial.

El equipo de Edge mantiene flotas listas para usar tanto para las distribuciones de Kubernetes rke2 como k3s. Dependiendo de vuestro entorno, esta flota podría utilizarse directamente o como plantilla.

Important

Utilizad siempre estas flotas a partir de una etiqueta de versión de Edge válida.

Para casos de uso en los que no sea necesario incluir cambios personalizados en los SUC plans que envían estas flotas, los usuarios pueden referenciar directamente las flotas desde el repositorio suse-edge/fleet-examples.

En los casos en los que se necesiten cambios personalizados (p. ej., para añadir tolerancias personalizadas), los usuarios deben referenciar las flotas desde un repositorio independiente, lo que les permite añadir los cambios a los planes de SUC según sea necesario.

Ejemplos de configuración para un recurso GitRepo utilizando las flotas del repositorio suse-edge/fleet-examples:

33.1.5.4.1.2 Creación de GitRepo - manual #

Obtened el recurso GitRepo:

Para clústeres 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

Para clústeres 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

Editad la configuración del GitRepo y, en spec.targets, especificad vuestra lista de destino deseada. Por defecto, los recursos GitRepo del suse-edge/fleet-examples NO están asignados a ningún clúster de sentido descendente.
- Para hacer coincidir todos los clústeres, cambiad el GitRepo target por defecto a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Alternativamente, si deseáis una selección de clústeres más granular, consultad Mapping to Downstream Clusters

Aplicad los recursos GitRepo a vuestro management cluster:

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

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

Visualizad el recurso GitRepo creado en el espacio de nombres fleet-default:

# 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 Ampliación del plan SUC - Recurso Bundle #

Un recurso Bundle, que incluye los Kubernetes upgrade SUC Plans necesarios, puede desplegarse de una de las siguientes maneras:

A través de Rancher UI - Section 33.1.5.4.2.1, “Creación de Bundle - Interfaz de usuario de Rancher” (cuando Rancher esté disponible).
Mediante el despliegue manual (Section 33.1.5.4.2.2, “Creación de bundle - manual”) del recurso en vuestro management cluster.

33.1.5.4.2.1 Creación de Bundle - Interfaz de usuario de Rancher #

El equipo de Edge mantiene bundles listos para usar tanto para las distribuciones de Kubernetes rke2 como k3s. Dependiendo de vuestro entorno, estos bundles podrían utilizarse directamente o como plantilla.

Important

Utilizad siempre este bundle a partir de una etiqueta de release de Edge válida.

Para crear un bundle a través de la interfaz de usuario de Rancher:

En la esquina superior izquierda, haced clic en ☰ → Entrega Continua
Id a Advanced > Bundles
Seleccionad Create from YAML
Desde aquí podéis crear el Bundle de una de las siguientes maneras:
Note
Puede haber casos de uso en los que necesitéis incluir cambios personalizados en los SUC plans que el bundle incluye (p. ej., para añadir tolerancias personalizadas). Aseguraos de incluir esos cambios en el bundle que se generará mediante los siguientes pasos.
1. Copiando manualmente el contenido del bundle para RKE2 o K3s desde suse-edge/fleet-examples a la página Create from YAML.
2. Clonando el repositorio suse-edge/fleet-examples desde la release deseada y seleccionando la opción Read from File en la página Create from YAML. Desde allí, navegad hasta el bundle que necesitéis (bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml para RKE2 y bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml para K3s). Esto rellenará automáticamente la página Create from YAML con el contenido del bundle.
Cambiad los clústeres target para el Bundle:
- Para que coincida con todos los clústeres de sentido descendente, cambiad el .spec.targets del Bundle predeterminado a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Para asignaciones de clústeres de sentido descendente más granulares, consultad Mapping to Downstream Clusters.
Seleccionad Crear

33.1.5.4.2.2 Creación de bundle - manual #

Obtened los recursos del Bundle:

Para clústeres 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

Para clústeres 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

Editad las configuraciones Bundle target, bajo spec.targets proporcionad vuestra lista de destino deseada. Por defecto, los recursos Bundle del suse-edge/fleet-examples NO están asignados a ningún clúster de sentido descendente.
- Para hacer coincidir todos los clústeres, cambiad el Bundle target por defecto a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Alternativamente, si deseáis una selección de clústeres más granular, consultad Mapping to Downstream Clusters

Aplicad los recursos del Bundle a vuestro management cluster:

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

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

Visualizad el recurso Bundle creado en el espacio de nombres 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

33.1.5.4.3 Ampliación del plan SUC: flujo de trabajo GitOps de terceros #

Puede haber casos de uso en los que los usuarios deseen incorporar el Kubernetes upgrade SUC plans a su propio flujo de trabajo GitOps de terceros (p. ej., Flux).

Para obtener los recursos de actualización de K8s que necesitáis, determinad primero la etiqueta de release de Edge del repositorio suse-edge/fleet-examples que deseáis utilizar.

Después de eso, los recursos se pueden encontrar en:

Para una actualización de clúster RKE2:
- Para nodos control-plane - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-control-plane.yaml
- Para nodos worker - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-worker.yaml
Para una actualización de clúster K3s:
- Para nodos control-plane - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-control-plane.yaml
- Para nodos worker - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-worker.yaml

Important

Estos recursos Plan son interpretados por el System Upgrade Controller y deben desplegarse en cada clúster de sentido descendente que deseéis actualizar. Para obtener información sobre la ampliación de SUC, consultad Section 18.2, “Instalación del controlador de actualización del sistema”.

Para comprender mejor cómo podéis utilizar vuestro flujo de trabajo de GitOps para implementar los planes de SUC para la actualización de la versión de Kubernetes, puede resultar útil echar un vistazo a la descripción general (Section 33.1.5.2, “Descripción general”) del procedimiento de actualización utilizando Fleet.

33.1.6 Actualización de Helm chart #

Esta sección trata las siguientes partes:

Section 33.1.6.1, “Preparación para entornos aislados” - contiene información sobre cómo enviar gráficos e imágenes OCI relacionados con Edge a su registro privado.
Section 33.1.6.2, “Procedimiento de actualización” - contiene información sobre diferentes casos de uso de actualización de gráficos de Helm y su procedimiento de actualización.

33.1.6.1 Preparación para entornos aislados #

33.1.6.1.1 Asegúrese de tener acceso a su Fleet de gráficos de Helm #

Dependiendo de lo que admita su entorno, puede elegir una de las siguientes opciones:

Aloje los recursos de Fleet de su gráfico en un servidor Git local al que pueda acceder su management cluster.
Utilizad la CLI de Fleet para convertir un Helm chart en un Bundle que podáis usar directamente sin necesidad de alojarlo en otro sitio. La CLI de Fleet se puede obtener en su página de lanzamientos; para usuarios de Mac, existe una fleet-cli Homebrew Formulae.

33.1.6.1.2 Busque los activos necesarios para su versión de lanzamiento de Edge #

Vaya a la página de lanzamiento de «Día 2», busque el lanzamiento de Edge al que desea actualizar su gráfico y haga clic en Activos.

Desde la sección «Activos», descargue los siguientes archivos:

Archivo de lanzamiento	Descripción
edge-save-images.sh	Extrae las imágenes especificadas en el archivo `edge-release-images.txt` y las empaqueta dentro de un archivo '.tar.gz'.
edge-save-oci-artefacts.sh	Extrae las imágenes de gráfico OCI relacionadas con la versión específica de Edge y las empaqueta dentro de un archivo '.tar.gz'.
edge-load-images.sh	Carga imágenes desde un archivo '.tar.gz', las vuelve a etiquetar y las envía a un registro privado.
edge-load-oci-artefacts.sh	Toma un directorio que contiene paquetes de gráfico OCI '.tgz' de Edge y los carga en un registro privado.
edge-release-helm-oci-artefacts.txt	Contiene una lista de imágenes de gráfico OCI relacionadas con una versión específica de Edge.
edge-release-images.txt	Contiene una lista de imágenes relacionadas con una versión específica de Edge.

33.1.6.1.3 Cread el archivo de imágenes de la versión de Edge #

En una máquina con acceso a internet:

Haced que edge-save-images.sh sea ejecutable:
```
chmod +x edge-save-images.sh
```

Generad el archivo de imagen:

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

Esto creará un archivo listo para cargar llamado edge-images.tar.gz.
Note
Si se especifica la opción -i|--images, el nombre del archivo puede variar.
Copiad este archivo a vuestra máquina air-gapped:
```
scp edge-images.tar.gz <user>@<machine_ip>:/path
```

33.1.6.1.4 Cread el archivo de imágenes de gráfico OCI de Edge #

En una máquina con acceso a internet:

Haced que edge-save-oci-artefacts.sh sea ejecutable:
```
chmod +x edge-save-oci-artefacts.sh
```

Generad el archivo de imagen de gráfico OCI:

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

Esto creará un archivo llamado oci-artefacts.tar.gz.
Note
Si se especifica la opción -a|--archive, el nombre del archivo puede variar.

Copiad este archivo a vuestra máquina air-gapped:

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

33.1.6.1.5 Cargad las imágenes de la versión de Edge en vuestra máquina en entorno aislado. #

En vuestra máquina en entorno aislado:

Iniciad sesión en vuestro registro privado (si es necesario):
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
Haced que edge-load-images.sh sea ejecutable:
```
chmod +x edge-load-images.sh
```
Ejecutad el script, pasando el archivo edge-images.tar.gz que fue copiado anteriormente:
```
./edge-load-images.sh --source-registry registry.suse.com --registry <REGISTRY.YOURDOMAIN.COM:PORT> --images edge-images.tar.gz
```
Note
Esto cargará todas las imágenes desde edge-images.tar.gz, las volverá a etiquetar y las enviará al registro especificado en la opción --registry.

33.1.6.1.6 Cargad las imágenes del gráfico Edge OCI en vuestra máquina en entorno aislado. #

En vuestra máquina en entorno aislado:

Iniciad sesión en vuestro registro privado (si es necesario):
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
Haced que edge-load-oci-artefacts.sh sea ejecutable:
```
chmod +x edge-load-oci-artefacts.sh
```
Desempaquetad el archivo oci-artefacts.tar.gz copiado:
```
tar -xvf oci-artefacts.tar.gz
```
Esto producirá un directorio con la plantilla de nomenclatura edge-release-oci-tgz-<date>
Pasad este directorio al script edge-load-oci-artefacts.sh para cargar las imágenes del gráfico Edge OCI en vuestro registro privado:
Note
Este script asume que la CLI de helm ha sido preinstalada en vuestro entorno. Para obtener instrucciones sobre la instalación de Helm, consultad Instalación de 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 Configurad vuestro registro privado en vuestra distribución de Kubernetes #

Para RKE2, consultad Configuración de registro privado.

Para K3s, consultad Configuración de registro privado.

33.1.6.2 Procedimiento de actualización #

Esta sección se centra en los siguientes casos de uso del procedimiento de actualización de Helm:

Important

Los gráficos de Helm desplegados manualmente no se pueden actualizar de forma fiable. Sugerimos volver a desplegar el gráfico de Helm utilizando el método Section 33.1.6.2.1, “Tengo un nuevo clúster y me gustaría desplegar y gestionar un Helm chart de Edge”.

33.1.6.2.1 Tengo un nuevo clúster y me gustaría desplegar y gestionar un Helm chart de Edge #

Esta sección cubre cómo:

33.1.6.2.1.1 Preparad los recursos de Fleet para vuestro Helm chart #

Adquirid los recursos de Fleet de vuestro Helm chart desde la etiqueta de lanzamiento de Edge que deseéis utilizar.
Navegad hasta el Fleet de vuestro Helm chart (fleets/day2/chart-templates/<chart>)
Si tenéis la intención de utilizar un flujo de trabajo GitOps, copiad el directorio Fleet del Helm chart al repositorio Git desde donde realizaréis GitOps.
Opcionalmente, si el Helm chart requiere configuraciones en sus valores, editad la configuración .helm.values dentro del archivo fleet.yaml del directorio copiado.
Opcionalmente, puede haber casos de uso en los que necesitéis añadir recursos adicionales a la flota de vuestro gráfico para que se adapte mejor a vuestro entorno. Para obtener información sobre cómo mejorar vuestro directorio de Fleet, consultad Contenido del repositorio Git.

Note

En algunos casos, el tiempo de espera predeterminado que utiliza Fleet para las operaciones de Helm puede ser insuficiente, lo que da lugar al siguiente error:

failed pre-install: context deadline exceeded

En tales casos, añadid la propiedad timeoutSeconds bajo la configuración helm de vuestro archivo fleet.yaml.

Un ejemplo para el Helm chart longhorn sería así:

Estructura del repositorio Git del usuario:

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

Contenido de fleet.yaml poblado con datos de usuario 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

Estos son solo valores de ejemplo que se utilizan para ilustrar configuraciones personalizadas sobre el Helm chart longhorn. NO deben tratarse como directrices de despliegue para el Helm chart longhorn.

33.1.6.2.1.2 Desplegad la flota para vuestro Helm chart #

Podéis desplegar la flota para vuestro Helm chart utilizando un GitRepo (Section 33.1.6.2.1.2.1, “GitRepo”) o un Bundle (Section 33.1.6.2.1.2.2, “Bundle”).

Note

Al desplegar vuestra flota, si recibís un mensaje de Modified, aseguraos de añadir la entrada comparePatches correspondiente a la sección diff de la flota. Para más información, consultad Generación de diferencias para ignorar GitRepos modificados.

33.1.6.2.1.2.1 GitRepo #

El recurso GitRepo de Fleet contiene información sobre cómo acceder a los recursos de flota de vuestro Helm chart y a qué clústeres debe aplicar dichos recursos.

El recurso GitRepo puede desplegarse a través de la interfaz de usuario de Rancher, o manualmente, desplegando el recurso en management cluster.

Ejemplo de recurso Longhorn GitRepo para despliegue manual:

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 #

Los recursos Bundle contienen los recursos brutos de Kubernetes que deben ser desplegados por Fleet. Normalmente se recomienda utilizar el enfoque GitRepo, pero para casos de uso en los que el entorno sea aislado y no pueda admitir un servidor Git local, Bundles puede ayudaros a propagar vuestro Helm chart con Fleet a vuestros clústeres de destino.

Un Bundle puede desplegarse a través de la interfaz de usuario de Rancher (Continuous Delivery → Advanced → Bundles → Create from YAML) o desplegando manualmente el recurso Bundle en el espacio de nombres de Fleet correcto. Para obtener información sobre los espacios de nombres de Fleet, consulte la documentación original.

Se pueden crear Bundles para los Helm charts de Edge utilizando el enfoque Convertir un Helm chart en un Bundle de Fleet.

A continuación, podéis encontrar un ejemplo sobre cómo crear un recurso Bundle a partir de las plantillas de Fleet de los Helm charts longhorn y longhorn-crd, y desplegad manualmente este Bundle en vuestro management cluster.

Note

Para ilustrar el flujo de trabajo, el siguiente ejemplo utiliza la estructura de directorio suse-edge/fleet-examples.

Navegad hasta la plantilla de Fleet del Helm chart longhorn:
```
cd fleets/day2/chart-templates/longhorn/longhorn
```
Cread un archivo targets.yaml que indique a Fleet en qué clústeres debe desplegar el Helm chart:
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```
Para una selección de clústeres en sentido descendente más granular, consultad Asignación a clústeres en sentido descendente.
Convierta el recurso Fleet del gráfico de Helm Longhorn en un recurso Bundle utilizando la fleet-cli.
Note
La CLI de Fleet se puede obtener desde su página de lanzamientos Assets (fleet-linux-amd64).
Para los usuarios de Mac, existe una fórmula de Homebrew para fleet-cli.
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-bundle > longhorn-bundle.yaml
```
Navegue hasta la plantilla de Fleet del gráfico longhorn-crd:
```
cd fleets/day2/chart-templates/longhorn/longhorn-crd
```
Cree un archivo targets.yaml que indique a Fleet en qué clústeres debe desplegar el gráfico de Helm:
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```

Convierta el recurso Fleet del gráfico de Helm Longhorn CRD en un recurso Bundle utilizando la fleet-cli.

fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-crd-bundle > longhorn-crd-bundle.yaml

Despliegue los archivos longhorn-bundle.yaml y longhorn-crd-bundle.yaml en su management cluster:
```
kubectl apply -f longhorn-crd-bundle.yaml
kubectl apply -f longhorn-bundle.yaml
```

Seguir estos pasos garantizará que SUSE Storage se despliegue en todos los downstream clústeres especificados.

33.1.6.2.1.3 Gestionar el gráfico de Helm desplegado #

Una vez desplegado con Fleet, para las actualizaciones del gráfico de Helm, consulte Section 33.1.6.2.2, “Me gustaría actualizar un gráfico de Helm gestionado por Fleet”.

33.1.6.2.2 Me gustaría actualizar un gráfico de Helm gestionado por Fleet #

Determine la versión a la que necesita actualizar su gráfico para que sea compatible con la versión de Edge deseada. La versión del gráfico de Helm por versión de Edge se puede consultar en las notas de la versión (Chapter 41, Notas de la versión).
En su repositorio Git supervisado por Fleet, edite el archivo fleet.yaml del gráfico de Helm con la versión y el repositorio correctos de las notas de la versión (Chapter 41, Notas de la versión).
Tras confirmar y enviar los cambios a su repositorio, esto activará una actualización del gráfico de Helm deseado.

33.1.6.2.3 Me gustaría actualizar un gráfico de Helm desplegado a través de EIB. #

Chapter 8, Edge Image Builder despliega gráficos de Helm creando un recurso HelmChart y utilizando el helm-controller introducido por la función de integración de Helm de RKE2/K3s.

Para garantizar que un gráfico de Helm desplegado a través de EIB se actualice correctamente, los usuarios deben realizar una actualización sobre los recursos HelmChart respectivos.

A continuación, puede encontrar información sobre:

La visión general (Section 33.1.6.2.3.1, “Descripción general”) del proceso de actualización.
Los pasos de actualización (Section 33.1.6.2.3.2, “Pasos de actualización”) necesarios.
Un ejemplo (Section 33.1.6.2.3.3, “Ejemplo”) que muestra una actualización del gráfico Longhorn utilizando el método explicado.
Cómo utilizar el proceso de actualización con una herramienta GitOps diferente (Section 33.1.6.2.3.4, “Actualización del chart de Helm mediante una herramienta GitOps de terceros”).

33.1.6.2.3.1 Descripción general #

Los gráficos de Helm que se despliegan a través de EIB se actualizan mediante un fleet llamado eib-charts-upgrader.

Este fleet procesa datos proporcionados por el usuario para actualizar un conjunto específico de recursos HelmChart.

La actualización de estos recursos activa el helm-controller, que actualiza la versión de los gráficos de Helm asociados con los recursos HelmChart modificados.

Solo se espera que el usuario:

Localmente, extraed los archivos comprimidos para cada gráfico de Helm que deba actualizarse.
Pasad estos archivos al script generate-chart-upgrade-data.sh generate-chart-upgrade-data.sh, que incluirá los datos de estos archivos en la flota eib-charts-upgrader.
Desplegad la flota eib-charts-upgrader en vuestro management cluster. Esto se realiza a través de un recurso GitRepo o Bundle.

Una vez desplegado, el eib-charts-upgrader, con la ayuda de Fleet, enviará sus recursos al clúster downstream deseado.

Estos recursos incluyen:

Un conjunto de Secrets que contiene los datos del gráfico de Helm proporcionados por el usuario.
Un Kubernetes Job que desplegará un Pod que montará los Secrets mencionados anteriormente y, basándose en ellos, parcheará los recursos de HelmChart correspondientes.

Como se mencionó anteriormente, esto activará el helm-controller que realizará la actualización real del gráfico de Helm.

A continuación podéis encontrar un diagrama de la descripción anterior:

33.1.6.2.3.2 Pasos de actualización #

Clonad el repositorio suse-edge/fleet-examples desde la etiqueta de la versión correcta.
Cread un directorio en el que almacenaréis el/los archivo(s) comprimido(s) del gráfico de Helm descargado(s).
```
mkdir archives
```

Dentro del directorio de archivos comprimidos recién creado, descargad el/los archivo(s) comprimido(s) para el/los gráfico(s) de Helm que deseéis actualizar:

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

Desde Assets de la etiqueta de versión deseada, descargad el script generate-chart-upgrade-data.sh.
Ejecutad el script 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
```
Para cada archivo de gráfico en el directorio --archive-dir, el script genera un archivo Kubernetes Secret YAML que contiene los datos de actualización del gráfico y los almacena en el directorio base/secrets de la flota especificada por --fleet-path.
El script generate-chart-upgrade-data.sh también aplica modificaciones adicionales a la flota para garantizar que los archivos Kubernetes Secret YAML generados sean utilizados correctamente por la carga de trabajo desplegada por la flota.
Important
Los usuarios no deben realizar cambios sobre lo que genera el script generate-chart-upgrade-data.sh.

Los pasos siguientes dependen del entorno en el que estéis ejecutando:

Para un entorno que admita GitOps (por ejemplo, que no esté aislado o que esté aislado, pero permita el soporte de un servidor Git local):
1. Copiad la flota fleets/day2/eib-charts-upgrader al repositorio que utilizaréis para GitOps.
  Note
  Aseguraos de que la flota incluya los cambios realizados por el script generate-chart-upgrade-data.sh.
2. Configurad un recurso GitRepo que se utilizará para enviar todos los recursos de la flota eib-charts-upgrader.
  1. Para la configuración y el despliegue de GitRepo a través de la interfaz de usuario de Rancher, consultad Acceso a Fleet en la interfaz de usuario de Rancher.
  2. Para la configuración y el despliegue manual de GitRepo, consultad Creación de un despliegue.
Para un entorno que no admita GitOps (por ejemplo, que sea un entorno aislado y no permita el uso de un servidor Git local):
1. Descargad el binario fleet-cli desde la página rancher/fleet release (fleet-linux-amd64 para Linux). Para los usuarios de Mac, existe una fórmula de Homebrew que se puede utilizar: fleet-cli.
2. Navegad a eib-charts-upgrader Fleet:
```
cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
3. Cread un archivo targets.yaml que indique a Fleet dónde desplegar vuestros recursos:
```
cat > targets.yaml <<EOF
targets:
# To match all downstream clusters
- clusterSelector: {}
EOF
```
  Para obtener información sobre cómo asignar clústeres de destino, consultad la documentación original.
4. Utilizad fleet-cli para convertir Fleet en un recurso Bundle:
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
  Esto creará un Bundle (bundle.yaml) que contendrá todos los recursos con plantilla del Fleet eib-charts-upgrader.
  Para obtener más información sobre el comando fleet apply, consultad fleet apply.
  Para obtener más información sobre la conversión de Fleets a Bundles, consultad Convertir un gráfico de Helm en un Bundle.
5. Desplegad Bundle. Esto se puede hacer de dos formas:
  1. A través de la interfaz de usuario de Rancher: navegad a Continuous Delivery → Advanced → Bundles → Create from YAML y pegad el contenido de bundle.yaml o haced clic en la opción Read from File y enviad el archivo directamente.
  2. Manualmente: desplegad el archivo bundle.yaml manualmente dentro de vuestro management cluster.

La ejecución de estos pasos dará como resultado un recurso GitRepo/Bundle desplegado correctamente. Fleet detectará el recurso y su contenido se desplegará en los clústeres de destino que hayáis especificado en los pasos anteriores. Para obtener una visión general del proceso, consultad Section 33.1.6.2.3.1, “Descripción general”.

Para obtener información sobre cómo realizar el seguimiento del proceso de actualización, podéis consultar Section 33.1.6.2.3.3, “Ejemplo”.

Important

Una vez que se haya verificado correctamente la actualización del gráfico, eliminad el recurso Bundle/GitRepo.

Esto eliminará los recursos de actualización que ya no son necesarios de vuestro clúster downstream, asegurando que no se produzcan conflictos de versiones en el futuro.

33.1.6.2.3.3 Ejemplo #

Note

El siguiente ejemplo demuestra cómo actualizar un gráfico de Helm desplegado mediante EIB de una versión a otra en un clúster downstream. Tened en cuenta que las versiones utilizadas en este ejemplo no son recomendaciones. Para obtener recomendaciones de versiones específicas de una versión Edge, consultad las notas de la versión (Chapter 41, Notas de la versión).

Caso práctico:

Un clúster llamado doc-example está ejecutando una versión anterior de Longhorn.

El clúster se ha desplegado a través de EIB, utilizando la siguiente definición de imagen 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 necesita ser actualizado a una versión que sea compatible con la versión 3.6 de Edge. Lo que significa que debe actualizarse a 1.11.2.
Se asume que el management cluster encargado de gestionar doc-example está en un entorno aislado, sin soporte para un servidor Git local y tiene una configuración de Rancher en funcionamiento.

Seguid los Pasos de actualización (Section 33.1.6.2.3.2, “Pasos de actualización”):

Clonad el repositorio suse-edge/fleet-example desde la etiqueta release-3.6.1.
```
git clone -b release-3.6.1 https://github.com/suse-edge/fleet-examples.git
```
Cread un directorio donde se almacenará el archivo de actualización de Longhorn.
```
mkdir archives
```

Descargad la versión del archivo del chart Longhorn deseada:

# 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

Fuera del directorio archives, descargad el script generate-chart-upgrade-data.sh desde la suse-edge/fleet-examples etiqueta de la versión.

La configuración del directorio debería ser similar a:

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

Ejecutad el script 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

La estructura del directorio después de la ejecución del script debería ser similar a:

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

Los archivos modificados en git deberían tener este aspecto:

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

Cread un Bundle para el Fleet eib-charts-upgrader:
1. Primero, navegad hasta el Fleet:
```
cd ./fleet-examples/fleets/day2/eib-charts-upgrader
```
2. A continuación, cread un archivo targets.yaml:
```
cat > targets.yaml <<EOF
targets:
- clusterName: doc-example
EOF
```
3. Después, utilizad el binario fleet-cli para convertir el Fleet en un Bundle:
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
4. Ahora, transferid el bundle.yaml en vuestra máquina management cluster.
Desplegad el Bundle a través de la interfaz de usuario de Rancher:
Figure 33.1: Desplegad el Bundle a través de la interfaz de usuario de Rancher #

Desde aquí, seleccionad Leer desde archivo y buscad el archivo bundle.yaml en vuestro sistema.
Esto rellenará automáticamente el Bundle dentro de la interfaz de usuario de Rancher.
Seleccionad Crear.
Tras un despliegue correcto, vuestro Bundle debería tener un aspecto similar a:
Figure 33.2: Bundle desplegado correctamente #

Tras el despliegue correcto del Bundle, para supervisar el proceso de actualización:

Verificad los registros del Upgrade Pod:
Ahora verificad los registros del Pod creado para la actualización por el helm-controller:
1. El nombre del Pod seguirá la siguiente plantilla: helm-install-longhorn-<random-suffix>
2. El Pod estará en el espacio de nombres donde se desplegó el recurso HelmChart. En nuestro caso, es kube-system.
  Figure 33.3: Registros de la actualización correcta del chart de Longhorn #
Verificad que la versión de HelmChart se ha actualizado navegando a la sección HelmCharts de Rancher (More Resources → HelmCharts). Seleccionad el espacio de nombres donde se desplegó el chart; para este ejemplo, sería kube-system.
Finalmente, comprobad que los Pods de Longhorn se están ejecutando.

Tras realizar las validaciones anteriores, es seguro asumir que el chart de Helm de Longhorn se ha actualizado a la versión 1.11.2.

33.1.6.2.3.4 Actualización del chart de Helm mediante una herramienta GitOps de terceros #

Puede haber casos de uso en los que los usuarios deseen utilizar este procedimiento de actualización con un flujo de trabajo GitOps distinto de Fleet (por ejemplo, Flux).

Para generar los recursos necesarios para el procedimiento de actualización, puede utilizar el script generate-chart-upgrade-data.sh para poblar el Fleet eib-charts-upgrader con los datos proporcionados por el usuario. Para obtener información sobre cómo hacerlo, consulte Section 33.1.6.2.3.2, “Pasos de actualización”.

Una vez que tengáis la configuración completa, podéis utilizar kustomize para generar una solución funcional completa que podáis desplegar en vuestro clúster:

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

kustomize build .

Si queréis incluir la solución en vuestro flujo de trabajo GitOps, podéis eliminar el archivo fleet.yaml y usar lo que queda como una configuración Kustomize válida. Simplemente, no olvidéis ejecutar primero el script generate-chart-upgrade-data.sh, para que pueda poblar la configuración Kustomize con los datos de los charts de Helm a los que queráis actualizar.

Para entender cómo se pretende utilizar este flujo de trabajo, consultad Section 33.1.6.2.3.1, “Descripción general” y Section 33.1.6.2.3.2, “Pasos de actualización”.