36 Clústeres descendentes #

Importante

Los pasos siguientes no se aplican a clústeres descendentes gestionados por SUSE Edge for Telco (Capítulo 37, SUSE Edge for Telco). Para obtener información sobre cómo actualizar estos clústeres, consulte la Sección 43.2, “Actualización de clústeres descendentes”.

Esta sección describe las formas posibles de realizar operaciones de "día 2" para diferentes partes de su clúster descendente.

36.1 Fleet #

Esta sección ofrece información sobre cómo realizar operaciones de "día 2" utilizando el componente Fleet (Capítulo 8, Fleet).

En esta sección se tratan los siguientes temas:

Sección 36.1.1, “Componentes”: los componentes predeterminados usados para todas las operaciones de "día 2".
Sección 36.1.2, “Determinación de su caso de uso”: proporciona una descripción general de los recursos personalizados de Fleet que se usarán y su idoneidad para diferentes casos de uso de operaciones de "día 2".
Sección 36.1.3, “Flujo de trabajo de día 2”: proporciona una guía del flujo de trabajo para ejecutar operaciones de "día 2" con Fleet.
Sección 36.1.4, “Actualización del sistema operativo”: describe cómo realizar actualizaciones del sistema operativo con Fleet.
Sección 36.1.5, “Actualización de la versión de Kubernetes”: describe cómo realizar actualizaciones de la versión de Kubernetes con Fleet.
Sección 36.1.6, “Actualización de charts de Helm”: describe cómo realizar actualizaciones de charts de Helm con Fleet.

36.1.1 Componentes #

A continuación, encontrará una descripción de los componentes predeterminados que deben configurarse en el clúster descendente para poder realizar correctamente operaciones de "día 2" con Fleet.

36.1.1.1 System Upgrade Controller (SUC) #

Nota

Debe desplegarse en cada clúster descendente.

System Upgrade Controller es responsable de ejecutar tareas en nodos específicos según los datos de configuración proporcionados mediante un recurso personalizado, denominado 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 de Edge, consulte el Capítulo 22, System Upgrade Controller.

Para obtener información sobre cómo desplegar SUC, determine primero su caso práctico Sección 36.1.2, “Determinación de su caso de uso”) y, a continuación, consulte las secciones Instalación de System Upgrade Controller - GitRepo (Sección 22.2.1.1, “Instalación de System Upgrade Controller - GitRepo”) o Instalación de System Upgrade Controller - Bundle (Sección 22.2.1.2, “Instalación de System Upgrade Controller - Bundle”).

36.1.2 Determinación de su caso de uso #

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

A continuación, encontrará información sobre la finalidad 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".

36.1.2.1 GitRepo #

Un GitRepo es un recurso de Fleet (Capítulo 8, Fleet) que representa un repositorio Git desde el que 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, consulte la documentación de GitRepo.

En el contexto de las operaciones de "día 2", los recursos GitRepo se suelen usar para desplegar SUC o planes de SUC en entornos no aislados que emplean un enfoque de GitOps de Fleet.

Como alternativa, los recursos GitRepo también se pueden utilizar para desplegar SUC o planes de SUC en entornos aislados, siempre que se refleje la configuración del repositorio a través de un servidor Git local.

36.1.2.2 Bundle #

Los Bundles contienen recursos sin procesar de Kubernetes que se desplegarán en el clúster de destino. Por lo general, se crean a partir de un recurso GitRepo, pero hay casos en los que se pueden desplegar manualmente. Para obtener más información, consulte la documentación de Bundle.

En el contexto de las operaciones de "día 2", los recursos Bundle se suelen usar para desplegar SUC o planes de SUC en entornos aislados que no utilizan algún tipo de procedimiento GitOps local (por ejemplo, un servidor Git local).

Alternativamente, si su caso de uso no permite un flujo de trabajo GitOps (por ejemplo, porque use un repositorio Git), también se pueden utilizar recursos Bundle para desplegar SUC o planes de SUC en entornos no aislados.

36.1.3 Flujo de trabajo de día 2 #

A continuación, se describe el flujo de trabajo de "día 2" que se debe seguir al actualizar un clúster descendente a una versión específica de Edge.

Actualización del sistema operativo (Sección 36.1.4, “Actualización del sistema operativo”)
Actualización de la versión de Kubernetes (Sección 36.1.5, “Actualización de la versión de Kubernetes”)
Actualización del chart de Helm (Sección 36.1.6, “Actualización de charts de Helm”)

36.1.4 Actualización del sistema operativo #

En esta sección se describe cómo realizar una actualización del sistema operativo utilizando Capítulo 8, Fleet y Capítulo 22, System Upgrade Controller.

En esta sección se tratan los siguientes temas:

Sección 36.1.4.1, “Componentes”: componentes adicionales usados por el proceso de actualización.
Sección 36.1.4.2, “Descripción general”: descripción general del proceso de actualización.
Sección 36.1.4.3, “Requisitos”: requisitos del proceso de actualización.
Sección 36.1.4.4, “Actualización del sistema operativo - Despliegue del plan de SUC”: información sobre cómo desplegar planes de SUC, responsables de iniciar el proceso de actualización.

36.1.4.1 Componentes #

Esta sección trata sobre los componentes personalizados que el proceso de actualización del sistema operativo usa en lugar de los componentes predeterminados de "día 2" (Sección 36.1.1, “Componentes”).

36.1.4.1.1 systemd.service #

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

En función del tipo de actualización que requiera el sistema operativo de una versión de Edge a otra, se creará un servicio diferente:

Para las versiones de Edge que requieren la misma versión del sistema operativo (por ejemplo, la 6.0), se creará el servicio os-pkg-update.service. Use transactional-update para realizar una actualización normal del paquete.
Para las versiones de Edge que requieran una migración de la versión del sistema operativo (por ejemplo, de la 6.0 a la 6.1), se creará el servicio os-migration.service. Use transactional-update para realizar:
1. Una actualización normal del paquete que garantice que todos los paquetes estén actualizados para mitigar cualquier fallo en la migración relacionado con versiones antiguas del paquete.
2. Una migración del sistema operativo mediante el comando zypper migration.

Los servicios mencionados se incluyen a cada nodo mediante un plan de SUC que debe estar ubicado en el clúster descendente que necesita una actualización del sistema operativo.

36.1.4.2 Descripción general #

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

Fleet se usa para desplegar y gestionar planes de SUC en el clúster deseado.

Nota

Los planes de SUC son recursos personalizados que describen los pasos que debe seguir SUC para ejecutar una tarea específica en un conjunto de nodos. Para ver un ejemplo de cómo es un plan de SUC, consulte el repositorio original.

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

Nota

Los recursos GitRepo/Bundle siempre se despliegan en el clúster de gestión. Que se use un recurso GitRepo o Bundle depende del caso de uso. Consulte la Sección 36.1.2, “Determinación de su caso de uso” para obtener más información.

Los planes de SUC de sistema operativo describen el siguiente flujo de trabajo:

Use siempre el comando cordon en los nodos antes de las actualizaciones del sistema operativo.
Actualice siempre los nodos control-plane antes que los nodos worker.
Actualice siempre el clúster en un único nodo cada vez.

Una vez desplegados los planes de SUC de sistema operativo, el flujo de trabajo es el siguiente:

SUC reconcilia los planes de SUC de sistema operativo desplegados y crea un trabajo de Kubernetes en cada nodo.
El trabajo de Kubernetes crea un servicio systemd.service (Sección 36.1.4.1.1, “systemd.service”) para la actualización de paquetes o para la migración del sistema operativo.
El servicio systemd.service creado activa el proceso de actualización del sistema operativo en el nodo específico.
Importante
Cuando finaliza el proceso de actualización del sistema operativo, el nodo correspondiente se rearranca para aplicar las actualizaciones en el sistema.

A continuación, encontrará un diagrama de la descripción anterior:

actualización del sistema operativo descendente día 2 fleet

36.1.4.3 Requisitos #

Generales:

Equipo registrado en el Centro de servicios al cliente de SUSE: todos los nodos del clúster descendentes deben estar registrados en https://scc.suse.com/. Es necesario para que el servicio systemd.service respectivo pueda conectarse correctamente al repositorio RPM deseado.
Importante
Para las versiones de Edge que requieren una migración de la versión del sistema operativo (por ejemplo, de la 6.0 a la 6.1), asegúrese de que su clave del Centro de servicios al cliente de SUSE admita la migración a la nueva versión.
Asegúrese de que las tolerancias del plan de SUC coincidan con las tolerancias de los nodos. Si los nodos de su clúster de Kubernetes tienen intolerancias (taints) personalizadas, asegúrese de añadir tolerancias (tolerations) para ellas en los planes de SUC. De forma predeterminada, los planes de SUC solo tienen tolerancias para los nodos de plano de control. Las tolerancias predeterminadas son:
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  Nota
  Cualquier tolerancia adicional debe añadirse en la sección .spec.tolerations de cada plan. Los planes de SUC relacionados con la actualización del sistema operativo se pueden encontrar en el repositorio suse-edge/fleet-examples en fleets/day2/system-upgrade-controller-plans/os-upgrade. Asegúrese de usar planes que tengan una etiqueta de versión de repositorio válida.
  Esto es un ejemplo de definición de tolerancias personalizadas para el plan de SUC de plano de control:
  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" ...

En entornos aislados:

Duplique los repositorios RPM de SUSE. Los repositorios RPM del sistema operativo deben duplicarse y guardarse de forma local para que el servicio systemd.service pueda acceder a ellos. Para ello, utilice RMT o SUMA.

36.1.4.4 Actualización del sistema operativo - Despliegue del plan de SUC #

Importante

En entornos que se hayan actualizado previamente mediante este procedimiento, los usuarios deben asegurarse de que se haya completado uno de los pasos siguientes:

Elimine cualquier plan de SUC desplegado anteriormente relacionado con versiones anteriores de Edge del clúster descendente. Esto se puede hacer eliminando el clúster deseado de la configuración de destino de GitRepo/Bundle existente o eliminando por completo el recurso GitRepo/Bundle.
Reutilice el recurso GitRepo/Bundle existente. Puede hacerlo haciendo que la revisión del recurso apunte a una nueva etiqueta que contenga los recursos de Fleet correctos para la versión deseada de suse-edge/fleet-examples.

Esto se hace con el fin de evitar conflictos entre los planes de SUC para versiones anteriores de Edge.

Si los usuarios intentan actualizar, mientras haya planes de SUC existentes en el clúster descendente, 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 la Sección 36.1.4.2, “Descripción general”, las actualizaciones del sistema operativo se realizan incluyendo planes de SUC en el clúster deseado de las siguientes formas:

Recurso GitRepo de Fleet: Sección 36.1.4.4.1, “Despliegue del plan de SUC - Recurso GitRepo”.
Recurso Bundle de Fleet: Sección 36.1.4.4.2, “Despliegue del plan de SUC - Recurso Bundle”.

Para determinar qué recurso se debe usar, consulte la Sección 36.1.2, “Determinación de su caso de uso”.

Si desea desplegar los planes de SUC de sistema operativo desde una herramienta GitOps de terceros, consulte la Sección 36.1.4.4.3, “Despliegue del plan de SUC - Flujo de trabajo de GitOps de terceros”.

36.1.4.4.1 Despliegue del plan de SUC - Recurso GitRepo #

Es posible desplegar un recurso GitRepo, que incluye los planes de SUC de sistema operativo, de estas formas:

Mediante la interfaz de usuario de Rancher: Sección 36.1.4.4.1.1, “Creación de GitRepo - Interfaz de usuario de Rancher” (si Rancher está disponible).
Desplegando manualmente (Sección 36.1.4.4.1.2, “Creación de GitRepo - Manual”) el recurso en el clúster de gestión.

Una vez desplegado, para supervisar el proceso de actualización del sistema operativo de los nodos de su clúster de destino, consulte la Sección 22.3, “Supervisión de planes de System Upgrade Controller”.

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

Para crear un recurso GitRepo con la interfaz de usuario de Rancher, siga la documentación oficial.

El equipo de Edge mantiene una flota (fleet) lista para usar. Dependiendo de su entorno, se puede utilizar directamente o como plantilla.

Importante

Use siempre esta flota desde una etiqueta de versión de Edge válida.

Para los casos prácticos en los que no es necesario incluir cambios personalizados en los planes de SUC que incluye la flota, los usuarios pueden usar directamente la flota os-upgrade desde el repositorio suse-edge/fleet-examples.

Si fuera necesario realizar cambios personalizados (por ejemplo, para añadir tolerancias personalizadas), los usuarios deben usar la flota os-upgrade desde un repositorio independiente, lo que les permitirá añadir los cambios a los planes de SUC según sea necesario.

Hay un ejemplo de cómo se puede configurar un recurso GitRepo para utilizar la flota del repositorio suse-edge/fleet-examples aquí.

36.1.4.4.1.2 Creación de GitRepo - Manual #

Extraiga el recurso GitRepo:

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

Edite la configuración de GitRepo. En spec.targets, especifique la lista de destinos que desee. De forma predeterminada, los recursos GitRepo de suse-edge/fleet-examples NO están asignados a ningún clúster descendente.
- Para que coincidan todos los clústeres, cambie el destino predeterminado de GitRepo a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Como alternativa, si desea una selección de clústeres más detallada, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).
Aplique el recurso GitRepo a su clúster de gestión:
```
kubectl apply -f os-upgrade-gitrepo.yaml
```

Consulte el recurso GitRepo creado en 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.3.0  0/0

36.1.4.4.2 Despliegue del plan de SUC - Recurso Bundle #

Es posible desplegar un recurso Bundle, que incluye los planes de SUC de sistema operativo válidos, de estas formas:

Mediante la interfaz de usuario de Rancher: Sección 36.1.4.4.2.1, “Creación de Bundle - Interfaz de usuario de Rancher” (si Rancher está disponible).
Desplegando manualmente (Sección 36.1.4.4.2.2, “Creación del Bundle - Manual”) el recurso en el clúster de gestión.

36.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 emplear en los pasos que se indican a continuación.

Importante

Use siempre este bundle desde una etiqueta de versión válida de Edge.

Para crear un bundle con la interfaz de usuario de Rancher:

En la esquina superior izquierda, haga clic en ☰ → Continuous Delivery (☰ → Entrega continua).
Diríjase a Advanced > Bundles (Avanzado > Bundles).
Seleccione Create from YAML (Crear desde YAML).
Desde aquí, puede crear el Bundle de las siguientes maneras:
Nota
Puede haber casos en los que sea necesario incluir cambios personalizados en los planes de SUC que incluye el Bundle (por ejemplo, para añadir tolerancias personalizadas). Asegúrese de incluir esos cambios en el Bundle que se generará con los pasos siguientes.
1. Copiando manualmente el contenido del Bundle desde suse-edge/fleet-examples a la página Create from YAML (Crear desde YAML).
2. Clonando el repositorio suse-edge/fleet-examples desde la etiqueta de versión deseada y seleccionando la opciónRead from File (Leer desde archivo) en la página Create from YAML (Crear desde YAML). Desde ahí, diríjase a la ubicación del Bundle (bundles/day2/system-upgrade-controller-plans/os-upgrade) y seleccione el archivo del Bundle. Esto rellenará automáticamente la página Create from YAML (Crear desde YAML) con el contenido del Bundle.
Cambie los clústeres de destino para el Bundle:
- Para que coincidan todos los clústeres descendentes, cambie el valor .spec.targets predeterminado del Bundle a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Para obtener asignaciones de clústeres descendentes más detalladas, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).
Seleccione Create (Crear).

36.1.4.4.2.2 Creación del Bundle - Manual #

Extraiga el recurso Bundle:

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

Edite las configuraciones de destino del Bundle. En spec.targets, proporcione la lista de objetivos que desee. De forma predeterminada, los recursos Bundle de suse-edge/fleet-examples NO están asignados a ningún clúster descendente.
- Para que coincidan con todos los clústeres descendentes, cambie el valor de destino predeterminado del Bundle a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Como alternativa, si desea una selección de clústeres más detallada, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).
Aplique el recurso Bundle al clúster de gestión:
```
kubectl apply -f os-upgrade-bundle.yaml
```
Consulte el recurso Bundle creado en el espacio de nombres fleet-default:
```
kubectl get bundles -n fleet-default
```

36.1.4.4.3 Despliegue del plan de SUC - Flujo de trabajo de GitOps de terceros #

Puede haber casos prácticos en los que los usuarios deseen incorporar los planes de SUC de sistema operativo a su propio flujo de trabajo de GitOps de terceros (por ejemplo, Flux).

Para obtener los recursos de actualización del sistema operativo que necesita, determine primero la etiqueta de versión de Edge del repositorio suse-edge/fleet-examples que desea utilizar.

Después, los recursos se encuentran en fleets/day2/system-upgrade-controller-plans/os-upgrade, donde:

plan-control-plane.yaml es un recurso de plan de SUC para los nodos de plano de control.
plan-worker.yaml es un recurso de plan de SUC para los nodos de trabajador.
secret.yaml es un secreto que contiene el guion upgrade.sh, que se encarga de crear el servicio systemd.service (Sección 36.1.4.1.1, “systemd.service”).
config-map.yaml es un mapa de configuración que contiene las configuraciones que utiliza el guion upgrade.sh.

Importante

Estos recursos de plan son interpretados por System Upgrade Controller y se deben desplegar en cada clúster descendente que desee actualizar. Para obtener información sobre el despliegue de SUC, consulte la Sección 22.2, “Instalación de System Upgrade Controller”.

Para comprender mejor cómo usar su flujo de trabajo de GitOps para desplegar los planes de SUC para actualizar el sistema operativo, puede resultar útil echar un vistazo a la descripción general (Sección 36.1.4.2, “Descripción general”).

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

Importante

Esta sección trata sobre las actualizaciones de Kubernetes para clústeres descendentes que NO se hayan creado mediante una instancia de Rancher (Capítulo 5, Rancher). Para obtener información sobre cómo actualizar la versión de Kubernetes de los clústeres creados con Rancher, consulte Upgrading and Rolling Back Kubernetes (Actualización y reversión de Kubernetes).

En esta sección se describe cómo realizar una actualización de Kubernetes utilizando Capítulo 8, Fleet y Capítulo 22, System Upgrade Controller.

En esta sección se tratan los siguientes temas:

Sección 36.1.5.1, “Componentes”: componentes adicionales usados por el proceso de actualización.
Sección 36.1.5.2, “Descripción general”: descripción general del proceso de actualización.
Sección 36.1.5.3, “Requisitos”: requisitos del proceso de actualización.
Sección 36.1.5.4, “Actualización de K8s - Despliegue del plan de SUC”: información sobre cómo desplegar planes de SUC, responsables de iniciar el proceso de actualización.

36.1.5.1 Componentes #

Esta sección trata sobre los componentes personalizados que el proceso de actualización de K8s usa en lugar de los componentes predeterminados de "día 2" (Sección 36.1.1, “Componentes”).

36.1.5.1.1 rke2-upgrade #

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

Se incluye a través de un pod creado por SUC basado en un plan de 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, consulte la documentación original.

36.1.5.1.2 k3s-upgrade #

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

Se incluye a través de un pod creado por SUC basado en un plan de 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 realiza la imagen k3s-upgrade la actualización, consulte la documentación original.

36.1.5.2 Descripción general #

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

Fleet se usa para desplegar y gestionar planes de SUC en el clúster deseado.

Nota

Los planes de SUC son recursos personalizados que describen los pasos que debe seguir SUC para ejecutar una tarea específica en un conjunto de nodos. Para ver un ejemplo de un plan de SUC, consulte el repositorio original.

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

Nota

Los planes de SUC de K8s describen el siguiente flujo de trabajo:

Use siempre el comando cordon en los nodos antes de las actualizaciones de K8s.
Actualice siempre los nodos control-plane antes que los nodos worker.
Actualice siempre los nodos de control-plane (plano de control) de uno en uno y los nodos worker (trabajador) de dos en dos.

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

SUC reconcilia los planes de SUC de K8s desplegados y crea un trabajo de Kubernetes en cada nodo.
Dependiendo de la distribución de Kubernetes, el trabajo creará un pod que ejecutará la imagen de contenedor rke2-upgrade (Sección 36.1.5.1.1, “rke2-upgrade”) o k3s-upgrade (Sección 36.1.5.1.2, “k3s-upgrade”).
El pod creado seguirá el siguiente flujo de trabajo:
1. Sustituye el binario rke2/k3s existente en el nodo por el de la imagen rke2-upgrade/k3s-upgrade.
2. Detiene el proceso rke2/k3s en ejecución.
Al detener el proceso rke2/k3s, se activa un reinicio y se lanza un nuevo proceso que ejecuta el binario actualizado, lo que da como resultado una versión actualizada de la distribución de Kubernetes.

A continuación, encontrará un diagrama de la descripción anterior:

actualización k8s descendente de día 2 con fleet

36.1.5.3 Requisitos #

Haga una copia de seguridad de su distribución de Kubernetes:
1. Para los clústeres RKE2, consulte RKE2 Backup and Restore (Copia de seguridad y restauración de RKE2).
2. Para los clústeres K3s, consulte K3s Backup and Restore (Copia de seguridad y restauración de K3s).
Asegúrese de que las tolerancias del plan de SUC coincidan con las tolerancias de los nodos. Si los nodos del clúster de Kubernetes tienen intolerancias (taints) personalizadas, asegúrese de añadir tolerancias (tolerations) para ellas en los planes de SUC. Por defecto, los planes de SUC solo tienen tolerancias para los nodos de plano de control. Las tolerancias predeterminadas son:
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  Nota
  Cualquier tolerancia adicional debe añadirse en la sección .spec.tolerations de cada plan. Los planes de SUC relacionados con la actualización de la versión de Kubernetes se encuentran 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
  Asegúrese de usar los planes de una etiqueta de versión del repositorio válida.
  Este es un ejemplo de definición de tolerancias personalizadas para el plan de SUC de plano de control de RKE2:
  apiVersion: upgrade.cattle.io/v1 kind: Plan metadata: name: rke2-upgrade-control-plane spec: ... tolerations: # default tolerations - key: "CriticalAddonsOnly" operator: "Equal" value: "true" effect: "NoExecute" - key: "node-role.kubernetes.io/control-plane" operator: "Equal" effect: "NoSchedule" - key: "node-role.kubernetes.io/etcd" operator: "Equal" effect: "NoExecute" # custom toleration - key: "foo" operator: "Equal" value: "bar" effect: "NoSchedule" ...

36.1.5.4 Actualización de K8s - Despliegue del plan de SUC #

Importante

En entornos que se hayan actualizado previamente mediante este procedimiento, los usuarios deben asegurarse de que se haya completado uno de los pasos siguientes:

Elimine cualquier plan de SUC desplegado anteriormente relacionado con versiones anteriores de Edge del clúster descendente. Esto se puede hacer eliminando el clúster deseado de la configuración de destino de GitRepo/Bundle existente o eliminando por completo el recurso GitRepo/Bundle.
Reutilice el recurso GitRepo/Bundle existente. Puede hacerlo haciendo que la revisión del recurso apunte a una nueva etiqueta que contenga los recursos de Fleet correctos para la versión deseada de suse-edge/fleet-examples.

Esto se hace con el fin de evitar conflictos entre los planes de SUC para versiones anteriores de Edge.

Si los usuarios intentan actualizar, mientras haya planes de SUC existentes en el clúster descendente, 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 la Sección 36.1.5.2, “Descripción general”, las actualizaciones de Kubernetes se realizan incluyendo planes de SUC en el clúster deseado de las siguientes formas:

Recurso GitRepo de Fleet (Sección 36.1.5.4.1, “Despliegue del plan de SUC - Recurso GitRepo”)
Recurso Bundle de Fleet (Sección 36.1.5.4.2, “Despliegue del plan de SUC - Recurso Bundle”)

Para determinar qué recurso se debe usar, consulte la Sección 36.1.2, “Determinación de su caso de uso”.

Si desea desplegar los planes de SUC de K8s desde una herramienta GitOps de terceros, consulte la Sección 36.1.5.4.3, “Despliegue del plan de SUC - Flujo de trabajo de GitOps de terceros”.

36.1.5.4.1 Despliegue del plan de SUC - Recurso GitRepo #

Es posible desplegar un recurso GitRepo, que incluye los planes de SUC de K8s necesarios, de las siguientes formas:

Mediante la interfaz de usuario de Rancher: Sección 36.1.5.4.1.1, “Creación de GitRepo - Interfaz de usuario de Rancher” (si Rancher está disponible).
Desplegando manualmente (Sección 36.1.5.4.1.2, “Creación de GitRepo - Manual”) el recurso en el clúster de gestión.

Una vez desplegado, para supervisar el proceso de actualización de Kubernetes de los nodos del clúster de destino, consulte la Sección 22.3, “Supervisión de planes de System Upgrade Controller”.

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

Para crear un recurso GitRepo con la interfaz de usuario de Rancher, siga la documentación oficial.

El equipo de Edge mantiene flotas listas para usar para las distribuciones de Kubernetes rke2 y k3s. Según su entorno, estas flotas se pueden usar directamente o como plantilla.

Importante

Utilice siempre estas flotas desde una etiqueta de versión de Edge válida.

Cuando no sea necesario incluir cambios personalizados en los planes de SUC que incluyen estas flotas, los usuarios pueden consultar directamente las flotas en el repositorio suse-edge/fleet-examples.

Si fuera necesario realizar cambios personalizados (por ejemplo, para añadir tolerancias personalizadas), los usuarios deben consultar las flotas desde un repositorio independiente, lo que les permitirá 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:

36.1.5.4.1.2 Creación de GitRepo - Manual #

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

Edite la configuración de GitRepo. En spec.targets, especifique la lista de destinos que desee. De forma predeterminada, los recursos GitRepo de suse-edge/fleet-examples NO están asignados a ningún clúster descendente.
- Para que coincidan todos los clústeres, cambie el destino predeterminado de GitRepo a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Como alternativa, si desea una selección de clústeres más detallada, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).

Aplique los recursos GitRepo a su clúster de gestión:

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

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

Consulte 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

36.1.5.4.2 Despliegue del plan de SUC - Recurso Bundle #

Es posible desplegar un recurso Bundle, que incluye los planes de SUC de actualización de Kubernetes necesarios, de una de estas formas:

Mediante la interfaz de usuario de Rancher: Sección 36.1.5.4.2.1, “Creación de Bundle - Interfaz de usuario de Rancher” (si Rancher está disponible).
Desplegando manualmente (Sección 36.1.5.4.2.2, “Creación del Bundle - Manual”) el recurso en el clúster de gestión.

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

El equipo de Edge mantiene bundles listos para usar para las distribuciones de Kubernetes rke2 y k3s. Dependiendo de su entorno, estos bundles se pueden utilizar directamente o como plantilla.

Importante

Use siempre este bundle desde una etiqueta de versión válida de Edge.

Para crear un bundle con la interfaz de usuario de Rancher:

En la esquina superior izquierda, haga clic en ☰ → Continuous Delivery (☰ → Entrega continua).
Diríjase a Advanced > Bundles (Avanzado > Bundles).
Seleccione Create from YAML (Crear desde YAML).
Desde aquí, puede crear el Bundle de las siguientes maneras:
Nota
Puede haber casos en los que sea necesario incluir cambios personalizados en los planes de SUC que incluye el Bundle (por ejemplo, para añadir tolerancias personalizadas). Asegúrese de incluir esos cambios en el Bundle que se generará con los pasos siguientes.
1. Copie manualmente el contenido del Bundle para RKE2 o K3s desde suse-edge/fleet-examples en la página Create from YAML (Crear desde YAML).
2. Clone el repositorio suse-edge/fleet-examples desde la etiqueta de versión deseada y seleccione la opción Read from File (Leer desde archivo) en la página Create from YAML (Crear desde YAML). Desde ahí, diríjase al Bundle que necesita (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). La página Create from YAML (Crear desde YAML) se rellenará automáticamente con el contenido del paquete.
Cambie los clústeres de destino para el Bundle:
- Para que coincidan todos los clústeres descendentes, cambie el valor .spec.targets predeterminado del Bundle a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Para obtener asignaciones de clústeres descendentes más detalladas, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).
Seleccione Create (Crear).

36.1.5.4.2.2 Creación del Bundle - Manual #

Extraiga los recursos Bundle:

Para clústeres RKE2:

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

Para clústeres K3s:

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

Edite las configuraciones de destino del Bundle. En spec.targets, proporcione la lista de objetivos que desee. De forma predeterminada, los recursos Bundle de suse-edge/fleet-examples NO están asignados a ningún clúster descendente.
- Para que coincidan con todos los clústeres descendentes, cambie el valor de destino predeterminado del Bundle a:
```
spec:
  targets:
  - clusterSelector: {}
```
- Como alternativa, si desea una selección de clústeres más detallada, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).

Aplique los recursos Bundle al clúster de gestión:

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

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

Consulte 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

36.1.5.4.3 Despliegue del plan de SUC - Flujo de trabajo de GitOps de terceros #

Puede haber casos prácticos en los que los usuarios deseen incorporar los planes de SUC de actualización de Kubernetes a su propio flujo de trabajo de GitOps de terceros (por ejemplo, Flux).

Para obtener los recursos de actualización de K8s que necesita, primero determine la etiqueta de versión de Edge del repositorio suse-edge/fleet-examples que desea utilizar.

Después, los recursos se encuentran en:

Para actualizar un 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 actualizar un 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

Importante

Para comprender mejor cómo usar su flujo de trabajo de GitOps para desplegar los planes de SUC para actualizar la versión de Kubernetes, puede resultar útil echar un vistazo a la descripción general (Sección 36.1.5.2, “Descripción general”) del procedimiento de actualización utilizando Fleet.

36.1.6 Actualización de charts de Helm #

Esta sección cubre lo siguiente:

Sección 36.1.6.1, “Preparación para entornos aislados”: contiene información sobre cómo incluir charts e imágenes OCI relacionados con Edge en su registro privado.
Sección 36.1.6.2, “Procedimiento de actualización”: contiene información sobre diferentes casos de actualización de charts de Helm y su procedimiento de actualización.

36.1.6.1 Preparación para entornos aislados #

36.1.6.1.1 Asegúrese de tener acceso a los recursos de Fleect del chart de Helm #

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

Aloje los recursos de Fleet de su chart en un servidor Git local al que pueda acceder su clúster de gestión.
Use la interfaz de línea de comandos de Fleet para convertir un chart de Helm en un Bundle que podrá utilizar directamente sin necesidad de alojarlo en ningún sitio. Puede descargar la interfaz de línea de comandos de la página de la versión. Para los usuarios de Mac, hay una versión propia de fleet-cli.

36.1.6.1.2 Busque los recursos necesarios para su versión de Edge #

Vaya a la página de la versión de "día 2", busque la versión de Edge a la que desea actualizar su chart y haga clic en Assets (Recursos).

En la sección Assets (Recursos), descargue los archivos siguientes:

Archivo de versión	Descripción
edge-save-images.sh	Extrae las imágenes especificadas en el archivo `edge-release-images.txt` y las empaqueta en un archivo ".tar.gz".
edge-save-oci-artefacts.sh	Extrae las imágenes del chart OCI relacionadas con la versión específica de Edge y las empaqueta en 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 charts OCI ".tgz" de Edge y los carga en un registro privado.
edge-release-helm-oci-artefacts.txt	Contiene una lista de imágenes de charts 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.

36.1.6.1.3 Cree el archivo de imágenes de la versión de Edge #

En un equipo con acceso a Internet:

Permita que edge-save-images.sh se pueda ejecutar:
```
chmod +x edge-save-images.sh
```

Genere 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.
Nota
Si se especifica la opción -i|--images, el nombre del archivo puede ser diferente.

Copie este archivo a su equipo aislado:

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

36.1.6.1.4 Cree el archivo de imágenes del chart OCI de Edge #

En un equipo con acceso a Internet:

Permita que edge-save-oci-artefacts.sh se pueda ejecutar:
```
chmod +x edge-save-oci-artefacts.sh
```

Genere el archivo de imagen del chart OCI:

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

Esto creará un archivo denominado oci-artefacts.tar.gz.
Nota
Si se especifica la opción -a|--archive, el nombre del archivo puede ser distinto.

Copie este archivo a su equipo aislado:

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

36.1.6.1.5 Cargue las imágenes de la versión de Edge en su equipo aislado #

En su equipo aislado:

Inicie sesión en su registro privado (si es necesario):
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
Permita que edge-load-images.sh se pueda ejecutar:
```
chmod +x edge-load-images.sh
```
Ejecute el guion pasando el archivo edge-images.tar.gz copiado anteriormente:
```
./edge-load-images.sh --source-registry registry.suse.com --registry <REGISTRY.YOURDOMAIN.COM:PORT> --images edge-images.tar.gz
```
Nota
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.

36.1.6.1.6 Cargue las imágenes del chart OCI de Edge en su equipo aislado #

En su equipo aislado:

Inicie sesión en su registro privado (si es necesario):
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
Permita que edge-load-oci-artefacts.sh se pueda ejecutar:
```
chmod +x edge-load-oci-artefacts.sh
```
Desempaquete el archivo oci-artefacts.tar.gz copiado:
```
tar -xvf oci-artefacts.tar.gz
```
Esto generará un directorio con el formato de nombre edge-release-oci-tgz-<fecha>.
Pase este directorio al guion edge-load-oci-artefacts.sh para cargar las imágenes del chart OCI de Edge a su registro privado:
Nota
Este guion presupone que la interfaz de línea de comandos de Helm ya está preinstalada en su entorno. Para obtener instrucciones sobre la instalación de Helm, consulte Installing Helm (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
```

36.1.6.1.7 Configure el registro privado en su distribución de Kubernetes #

Para RKE2, consulte Private Registry Configuration (Configuración del registro privado)

Para K3s, consulte Private Registry Configuration (Configuración del registro privado)

36.1.6.2 Procedimiento de actualización #

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

Importante

Los charts de Helm desplegados manualmente no se pueden actualizar de forma fiable. Recomendamos volver a desplegar el chart de Helm utilizando el método Sección 36.1.6.2.1, “Tengo un nuevo clúster y me gustaría desplegar y gestionar un chart de Helm de Edge”.

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

En esta sección se trata lo siguiente:

36.1.6.2.1.1 Prepare los recursos de Fleet para su chart #

Adquiera los recursos de Fleet del chart desde la etiqueta de versión de Edge que desee usar.
Diríjase a la flota del chart de Helm (fleets/day2/chart-templates/<chart>).
Si tiene intención de utilizar un flujo de trabajo de GitOps, copie el directorio Fleet del chart en el repositorio Git desde donde realizará la operación de GitOps.
Opcionalmente, si el chart de Helm requiere que se configuren sus valores, edite la configuración de .helm.values dentro del archivo fleet.yaml del directorio copiado.
Opcionalmente, puede haber casos en los que sea necesario añadir recursos adicionales a la flota de su chart para que se adapte mejor a su entorno. Para obtener información sobre cómo mejorar su directorio de Fleet, consulte Git Repository Contents (Contenido del repositorio Git).

Nota

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

failed pre-install: context deadline exceeded

Si fuera el caso, añada la propiedad timeoutSeconds en la configuración de helm de su archivo fleet.yaml.

Esto es un ejemplo del aspecto que tendría el chart de Helm de longhorn:

Estructura del repositorio Git del usuario:

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

Contenido de fleet.yaml con datos de Longhorn del usuario:

defaultNamespace: longhorn-system

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

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

Nota

Estos son solo valores de ejemplo que se utilizan para mostrar configuraciones personalizadas en el chart de longhorn. NO deben considerarse directrices de despliegue para el chart de longhorn.

36.1.6.2.1.2 Despliegue la flota en su chart #

Puede desplegar la flota de su chart usando GitRepo (Sección 36.1.6.2.1.2.1, “GitRepo”) o Bundle (Sección 36.1.6.2.1.2.2, “Bundle”).

Nota

Al desplegar su flota, si recibe un mensaje con la indicación Modified (Modificado), asegúrese de añadir la entrada comparePatches correspondiente a la sección diff del Fleet. Para obtener más información, consulte Generating Diffs to Ignore Modified GitRepos (Generación de diffs para ignorar recursos GitRepo modificados).

36.1.6.2.1.2.1 GitRepo #

El recurso GitRepo de Fleet incluye información sobre cómo acceder a los recursos de Fleet de su chart y a qué clústeres deben aplicarse esos recursos.

El recurso GitRepo se puede desplegar mediante la interfaz de usuario de Rancher o, manualmente, desplegando el recurso en el clúster de gestión.

Recurso GitRepo de Longhorn de ejemplo para el 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: {}

36.1.6.2.1.2.2 Bundle #

Los recursos Bundle contienen los recursos sin procesar de Kubernetes que debe desplegar Fleet. Normalmente, se recomienda utilizar el enfoque de GitRepo, pero en entornos aislados o que no admitan un servidor Git local, los Bundles pueden ayudarle a propagar su chart de Helm de Fleet a los clústeres de destino.

Es posible desplegar un Bundle mediante la interfaz de usuario de Rancher seleccionando Continuous Delivery → Advanced → Bundles → Create from YAML (Entrega continua → Avanzado → Bundles → Crear desde 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.

Es posible crear Bundles para los charts de Helm de Edge convirtiendo un chart de Helm en un Bundle de Fleet.

A continuación, hay un ejemplo de cómo crear un recurso Bundle a partir de plantillas de flota de un chart de Helm de longhorn y longhorn-crd y cómo desplegar manualmente este Bundle en su clúster de gestión.

Nota

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

Diríjase a la plantilla de flota de chart de longhorn:
```
cd fleets/day2/chart-templates/longhorn/longhorn
```
Cree un archivo targets.yaml que indicará a Fleet en qué clústeres debe desplegar el chart de Helm:
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```
Para una selección más detallada de clústeres descendentes, consulte Mapping to Downstream Clusters (Asignación a clústeres descendentes).
Convierta la flota de chart de Helm de Longhorn en un recurso Bundle mediante fleet-cli.
Nota
Puede obtener la interfaz de línea de comandos de Fleet (fleet-linux-amd64) de la página Assets (Recursos) de su versión.
Para usuarios de Mac, hay una versión propia de fleet-cli.
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-bundle > longhorn-bundle.yaml
```
Diríjase a la plantilla de flota de chart longhorn-crd:
```
cd fleets/day2/chart-templates/longhorn/longhorn-crd
```
Cree un archivo targets.yaml que indicará a Fleet en qué clústeres debe desplegar el chart de Helm:
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```

Convierta la flota de chart de Helm de la CRD de Longhorn en un recurso Bundle mediante 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 clúster de gestión:
```
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 clústeres descendentes especificados.

36.1.6.2.1.3 Gestione el chart de Helm desplegado #

Cuando se complete el despliegue con Fleet, para actualizaciones de charts de Helm, consulte la Sección 36.1.6.2.2, “Quiero actualizar un chart de Helm gestionado por Fleet”.

36.1.6.2.2 Quiero actualizar un chart de Helm gestionado por Fleet #

Determine la versión a la que debe actualizar su chart para que sea compatible con la versión deseada de Edge. Puede consultar la versión del chart de Helm para cada versión de Edge en las notas de la versión (Sección 52.1, “Resumen”).
En su repositorio Git supervisado por Fleet, edite el archivo fleet.yaml del chart de Helm con la versión y el repositorio correctos del chart, tal y como se indica en las notas de la versión (Sección 52.1, “Resumen”).
Después de confirmar y enviar los cambios al repositorio, se activará una actualización del chart de Helm deseado.

36.1.6.2.3 Quiero actualizar un chart de Helm desplegado mediante EIB #

Capítulo 11, Edge Image Builder despliega charts de Helm creando un recurso HelmChart y usando el helm-controller introducido por la función de integración de Helm RKE2/K3s.

Para garantizar que un chart de Helm desplegado mediante EIB se actualice correctamente, los usuarios deben realizar una actualización de los recursos HelmChart correspondientes.

A continuación, encontrará más información:

La descripción general (Sección 36.1.6.2.3.1, “Descripción general”) del proceso de actualización.
Los pasos necesarios para la actualización (Sección 36.1.6.2.3.2, “Pasos para la actualización”).
Un ejemplo (Sección 36.1.6.2.3.3, “Ejemplo”) que muestra la actualización de un chart de Longhorn usando el método explicado.
Cómo usar el proceso de actualización con una herramienta GitOps diferente (Sección 36.1.6.2.3.4, “Actualización del chart de Helm con una herramienta GitOps de terceros”).

36.1.6.2.3.1 Descripción general #

Los charts de Helm que se despliegan mediante EIB se actualizan usando una flota llamada eib-charts-upgrader.

Esta flota procesa los datos proporcionados por el usuario para actualizar un conjunto específico de recursos HelmChart.

Al actualizar estos recursos se activa helm-controller, que actualiza los charts de Helm asociados con los recursos HelmChart modificados.

Solo se espera de los usuarios que:

Extraigan localmente los archivos de cada chart de Helm que deba actualizarse.
Pasen estos archivos al guion generate-chart-upgrade-data.sh generate-chart-upgrade-data.sh, que incluirá los datos de estos archivos en la flota eib-charts-upgrader.
Desplieguen la flota eib-charts-upgrader a su clúster de gestión. Esto se hace con un recurso GitRepo o Bundle.

Una vez desplegado, eib-charts-upgrader, con ayuda de Fleet, incluirá sus recursos en el clúster descendente deseado.

Estos recursos incluyen:

Un conjunto de secretos que guardan los datos del chart de Helm proporcionados por el usuario.
Un trabajo de Kubernetes que desplegará un pod que montará los secretos mencionados anteriormente y, basándose en ellos, parcheará los recursos HelmChart correspondientes.

Como se mencionó anteriormente, esto activará helm-controller, que llevará a cabo la actualización real del chart de Helm.

A continuación, encontrará un diagrama de la descripción anterior:

actualización eib de helm descendente de día 2 con fleet

36.1.6.2.3.2 Pasos para la actualización #

Clone el repositorio suse-edge/fleet-examples de la etiqueta de versión correcta.
Cree un directorio en el que almacenarán los archivos de los charts de Helm extraídos.
```
mkdir archives
```

En el directorio recién creado, extraiga los archivos de los charts de Helm que desea 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

En la página Assets (Recursos) de la etiqueta de versión deseada, descargue el guion generate-chart-upgrade-data.sh.
Ejecute el guion 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 chart del directorio --archive-dir, el guion genera un archivo Kubernetes Secret YAML que contiene los datos de actualización de chart y lo guardar en el directorio base/secrets de la flota especificada por --fleet-path.
El guion generate-chart-upgrade-data.sh también aplica modificaciones adicionales a la flota para garantizar que la carga de trabajo desplegada por la flota utilice correctamente los archivos Kubernetes Secret YAML generados.
Importante
Los usuarios no deben cambiar nada de lo que genera el guion generate-chart-upgrade-data.sh.

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

En un entorno que admita GitOps (por ejemplo, que no esté aislado, o que esté aislado pero permita la asistencia de un servidor Git local):
1. Copie la flota fleets/day2/eib-charts-upgrader en el repositorio que usará para GitOps.
  Nota
  Asegúrese de que la flota incluye los cambios realizados por el guion generate-chart-upgrade-data.sh.
2. Configure un recurso GitRepo que se usará para incluir todos los recursos de la flota eib-charts-upgrader.
  1. Para la configuración y el despliegue de GitRepo mediante la interfaz de usuario de Rancher, consulte Accessing Fleet in the Rancher UI (Acceso a Fleet en la interfaz de usuario de Rancher).
  2. Para la configuración y el despliegue manuales de GitRepo, consulte Creating a Deployment (Creación de un despliegue).
En un entorno que no admita GitOps (por ejemplo, un entorno aislado que no permita el uso de un servidor Git local):
1. Descargue el binario de fleet-cli de la página de versión de rancher/fleet (fleet-linux-amd64 para Linux). Los usuarios de Mac pueden usar una versión propia: fleet-cli.
2. Diríjase a la flota eib-charts-upgrader:
```
cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
3. Cree un archivo targets.yaml que indicará a Fleet dónde debe desplegar los 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, consulte la documentación original.
4. Utilice fleet-cli para convertir la flota 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 de plantilla de la flota eib-charts-upgrader.
  Para obtener más información sobre el comando fleet apply, consulte fleet apply.
  Para obtener más información sobre cómo convertir flotas en Bundles, consulte Convert a Helm Chart into a Bundle (Conversión de un chart de Helm en un Bundle).
5. Despliegue el Bundle. Puede hacerlo de dos formas:
  1. Mediante la interfaz de usuario de Rancher: seleccione Continuous Delivery → Advanced → Bundles → Create from YAML (Entrega continua → Avanzado → Bundles → Crear desde YAML) y pegue el contenido de bundle.yaml o haga clic en la opción Read from File (Leer desde archivo) y pase el archivo.
  2. Manualmente: despliegue el archivo bundle.yaml manualmente dentro de su clúster de gestión.

Al ejecutar estos pasos, se desplegará correctamente el recurso GitRepo/Bundle. Fleet recogerá el recurso y su contenido se desplegará en los clústeres de destino que el usuario haya especificado en los pasos anteriores. Para obtener una descripción general del proceso, consulte la Sección 36.1.6.2.3.1, “Descripción general”.

Para obtener información sobre cómo realizar un seguimiento del proceso de actualización, consulte la Sección 36.1.6.2.3.3, “Ejemplo”.

Importante

Cuando haya verificado que el chart se ha actualizado correctamente, elimine el recurso Bundle/GitRepo.

Esto eliminará los recursos de actualización que ya no son necesarios de su clúster descendente, lo que garantizará que no se produzcan conflictos entre versiones en el futuro.

36.1.6.2.3.3 Ejemplo #

Nota

El siguiente ejemplo muestra cómo actualizar un chart de Helm desplegado con EIB de una versión a otra en un clúster descendente. Tenga en cuenta que las versiones utilizadas en este ejemplo no son recomendaciones. Para obtener recomendaciones de versiones específicas para una versión de Edge, consulte las notas de la versión (Sección 52.1, “Resumen”).

Caso práctico:

Un clúster denominado doc-example ejecuta una versión anterior de Longhorn.

El clúster se ha desplegado mediante EIB, utilizando el siguiente fragmento de definición de imagen:

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 debe actualizarse a una versión compatible con la versión Edge 3.3.1. Esto significa que debe actualizarse a 106.2.0+up1.8.1.
Se sobrentiende que el clúster de gestión encargado de gestionar doc-example está aislado, sin asistencia para un servidor Git local y con una configuración de Rancher operativa.

Siga los pasos de actualización (Sección 36.1.6.2.3.2, “Pasos para la actualización”):

Clone el repositorio suse-edge/fleet-example desde la etiqueta release-3.3.0.

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

Cree un directorio donde se almacenará el archivo de actualización de Longhorn.
```
mkdir archives
```

Extraiga la versión del archivo de chart de Longhorn deseada:

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

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

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

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

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

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

Ejecute el guion 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 tras la ejecución del guion debería ser similar a esto:

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

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

Cree un Bundle para la flota eib-charts-upgrader:
1. En primer lugar, diríjase a la flota:
```
cd ./fleet-examples/fleets/day2/eib-charts-upgrader
```
2. A continuación, cree un archivo targets.yaml:
```
cat > targets.yaml <<EOF
targets:
- clusterName: doc-example
EOF
```
3. Después, use el binario de fleet-cli para convertir la flota en un Bundle:
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
4. Ahora, transfiera bundle.yaml a su equipo del clúster de gestión.
Despliegue el Bundle mediante la interfaz de usuario de Rancher:
Figura 36.1: Despliegue del Bundle mediante la interfaz de Rancher #

Ahora, seleccione Read from File (Leer desde archivo) y busque el archivo bundle.yaml en su sistema.
El Bundle se rellenará automáticamente en la interfaz de usuario de Rancher.
Seleccione Create (Crear).
Cuando haya finalizado el despliegue correctamente, el Bundle deberá tener un aspecto similar al siguiente:
Figura 36.2: Bundle desplegado correctamente #

Cuando haya finalizado el despliegue del Bundle correctamente, para supervisar el proceso de actualización:

Verifique los registros del pod de actualización:
Ahora, verifique los registros del pod creado para la actualización por helm-controller:
1. El nombre del pod tendrá este formato: helm-install-longhorn-<sufijo aleatorio>
2. El pod estará en el espacio de nombres donde se desplegó el recurso HelmChart. En nuestro caso, kube-system.
  Figura 36.3: Registros de chart de Longhorn actualizado correctamente #
Compruebe que la versión de HelmChart se ha actualizado. Para ello, diríjase a la sección HelmCharts de Rancher seleccionando More Resources → HelmCharts (Más recursos → HelmCharts). Seleccione el espacio de nombres donde se desplegó el chart; en este ejemplo, sería kube-system.
Por último, compruebe que los pods de Longhorn se estén ejecutando.

Después de realizar las validaciones anteriores, se puede entender con seguridad que el chart de Helm de Longhorn se ha actualizado a la versión 106.2.0+up1.8.1.

36.1.6.2.3.4 Actualización del chart de Helm con una herramienta GitOps de terceros #

Puede darse el caso de que los usuarios deseen utilizar este procedimiento de actualización con un flujo de trabajo de GitOps que no sea Fleet (por ejemplo, Flux).

Para generar los recursos necesarios para el procedimiento de actualización, puede usar el guion generate-chart-upgrade-data.sh para rellenar la flota eib-charts-upgrader con los datos proporcionados por el usuario. Para obtener más información sobre cómo hacerlo, consulte la Sección 36.1.6.2.3.2, “Pasos para la actualización”.

Cuando haya completado la configuración, puede utilizar kustomize para generar una solución totalmente funcional que puede desplegar en su clúster:

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

kustomize build .

Si desea incluir la solución en su flujo de trabajo de GitOps, puede eliminar el archivo fleet.yaml y usar lo que queda como una configuración válida de Kustomize. No olvide ejecutar primero el guion generate-chart-upgrade-data.sh, para poder rellenar la configuración de Kustomize con los datos de los charts de Helm a los que desea actualizar.

Para comprender cómo se pretende usar este flujo de trabajo, puede resultar útil consultar la Sección 36.1.6.2.3.1, “Descripción general” y la Sección 36.1.6.2.3.2, “Pasos para la actualización”.