documentation.suse.com / Documentación de SUSE Edge / Operaciones de día 2 / Clúster de gestión

35 Clúster de gestión

 

Actualmente, hay dos formas de realizar operaciones de "día 2" en su clúster de gestión:

  1. Mediante Capítulo 23, Upgrade Controller: Sección 35.1, “Upgrade Controller”

  2. Mediante Capítulo 8, Fleet: Sección 35.2, “Fleet”

35.1 Upgrade Controller

 
Importante
Importante

Upgrade Controller actualmente solo admite operaciones de día 2 para clústeres en entornos no aislados.

En esta sección se explica cómo realizar las distintas operaciones de día 2 relacionadas con la actualización del clúster de gestión de una versión de la plataforma Edge a otra.

Las operaciones de día 2 se automatizan con Upgrade Controller (Capítulo 23, Upgrade Controller) e incluyen:

35.1.1 Requisitos previos

 

Antes de actualizar su clúster de gestión, deben cumplirse los siguientes requisitos previos:

  1. Nodos registrados en el SCC: asegúrese de que los sistemas operativos de los nodos del clúster estén registrados con una clave de suscripción que admita la versión del sistema operativo especificada en la versión de Edge (Sección 52.1, “Resumen”) a la que desea actualizar.

  2. Upgrade Controller: asegúrese de que Upgrade Controller se haya desplegado en su clúster de gestión. Para conocer los pasos de instalación, consulte la Sección 23.3, “Instalación de Upgrade Controller”.

35.1.2 Actualización

 

  1. Determine la versión de Edge (Sección 52.1, “Resumen”) a la que desea actualizar el clúster de gestión.

  2. En el clúster de gestión, despliegue un recurso UpgradePlan que especifique la versión deseada. UpgradePlan debe desplegarse en el espacio de nombres de Upgrade Controller.

    kubectl apply -n <upgrade_controller_namespace> -f - <<EOF
apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
spec:
  # Version retrieved from release notes
  releaseVersion: 3.X.Y
EOF
    Nota
    Nota

    Puede haber casos en los que desee realizar configuraciones adicionales sobre el recurso UpgradePlan. Para conocer todas las configuraciones posibles, consulte la Sección 23.5.1, “UpgradePlan”.

  3. El despliegue de UpgradePlan en el espacio de nombres de Upgrade Controller iniciará el proceso de actualización.

    Nota
    Nota

    Para obtener más información sobre el proceso de actualización real, consulte la Sección 23.4, “¿Cómo funciona Upgrade Controller?”.

    Para obtener más información sobre cómo hacer un seguimiento del proceso de actualización, consulte la Sección 23.6, “Seguimiento del proceso de actualización”.

35.2 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:

  1. Sección 35.2.1, “Componentes”: los componentes predeterminados usados para todas las operaciones de "día 2".

  2. Sección 35.2.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".

  3. Sección 35.2.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.

  4. Sección 35.2.4, “Actualización del sistema operativo”: describe cómo realizar actualizaciones del sistema operativo con Fleet.

  5. Sección 35.2.5, “Actualización de la versión de Kubernetes”: describe cómo realizar actualizaciones de la versión de Kubernetes con Fleet.

  6. Sección 35.2.6, “Actualización de charts de Helm”: describe cómo realizar actualizaciones de charts de Helm con Fleet.

35.2.1 Componentes

 

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

35.2.1.1 Rancher

 

(Opcional) Es el responsable de gestionar los clústeres descendentes y de desplegar System Upgrade Controller en su clúster de gestión.

Para obtener más información, consulte el Capítulo 5, Rancher.

35.2.1.2 System Upgrade Controller (SUC)

 

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.

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

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

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

35.2.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 de gestión a una versión específica de Edge.

  1. Actualización del sistema operativo (Sección 35.2.4, “Actualización del sistema operativo”)

  2. Actualización de la versión de Kubernetes (Sección 35.2.5, “Actualización de la versión de Kubernetes”)

  3. Actualización del chart de Helm (Sección 35.2.6, “Actualización de charts de Helm”)

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

  1. Sección 35.2.4.1, “Componentes”: componentes adicionales usados por el proceso de actualización.

  2. Sección 35.2.4.2, “Descripción general”: descripción general del proceso de actualización.

  3. Sección 35.2.4.3, “Requisitos”: requisitos del proceso de actualización.

  4. Sección 35.2.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.

35.2.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 35.2.1, “Componentes”).

35.2.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 anteriormente se envían a cada nodo a través de un plan de SUC, que debe estar ubicado en el clúster de gestión que necesita una actualización del sistema operativo.

35.2.4.2 Descripción general

 

La actualización del sistema operativo para los nodos del clúster de gestión 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
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
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 35.2.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:

  1. Use siempre el comando cordon en los nodos antes de las actualizaciones del sistema operativo.

  2. Actualice siempre los nodos control-plane antes que los nodos worker.

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

  1. SUC reconcilia los planes de SUC de sistema operativo desplegados y crea un trabajo de Kubernetes en cada nodo.

  2. El trabajo de Kubernetes crea un servicio systemd.service (Sección 35.2.4.1.1, “systemd.service”) para la actualización de paquetes o para la migración del sistema operativo.

  3. El servicio systemd.service creado activa el proceso de actualización del sistema operativo en el nodo específico.

    Importante
    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 de sistema operativo de gestión de día 2 con fleet

35.2.4.3 Requisitos

 

Generales:

  1. Equipo registrado en el Centro de servicios al cliente de SUSE. Todos los nodos del clúster de gestión deben estar registrados en https://scc.suse.com/. Esto es necesario para que el servicio systemd.service respectivo pueda conectarse correctamente al repositorio de RPM deseado.

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

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

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

35.2.4.4 Actualización del sistema operativo - Despliegue del plan de SUC

 
Importante
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 de gestión. Puede hacerlo eliminando el clúster deseado de la configuración de destino del GitRepo/Bundle 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 hay planes de SUC en el clúster de gestión, 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 35.2.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:

Para determinar qué recurso se debe usar, consulte la Sección 35.2.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 35.2.4.4.3, “Despliegue del plan de SUC - Flujo de trabajo de GitOps de terceros”.

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

  1. Mediante la interfaz de usuario de Rancher: Sección 35.2.4.4.1.1, “Creación de GitRepo - Interfaz de usuario de Rancher” (si Rancher está disponible).

  2. Desplegando manualmente (Sección 35.2.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”.

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

35.2.4.4.1.2 Creación de GitRepo - Manual
 

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

  2. Edite la configuración de GitRepo:

    • Elimine la sección spec.targets: solo se necesita para clústeres descendentes.

      # Example using sed
sed -i.bak '/^  targets:/,$d' os-upgrade-gitrepo.yaml && rm -f os-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i os-upgrade-gitrepo.yaml

    • Dirija el espacio de nombres de GitRepo al espacio de nombres fleet-local. Esto se hace para desplegar el recurso en el clúster de gestión.

      # Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' os-upgrade-gitrepo.yaml && rm -f os-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i os-upgrade-gitrepo.yaml

  3. Aplique el recurso GitRepo a su clúster de gestión:

    kubectl apply -f os-upgrade-gitrepo.yaml

  4. Compruebe que el recurso GitRepo creado se encuentra en el espacio de nombres fleet-local:

    kubectl get gitrepo os-upgrade -n fleet-local

# Example output
NAME            REPO                                              COMMIT         BUNDLEDEPLOYMENTS-READY   STATUS
os-upgrade      https://github.com/suse-edge/fleet-examples.git   release-3.3.0  0/0
35.2.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:

  1. Mediante la interfaz de usuario de Rancher: Sección 35.2.4.4.2.1, “Creación de Bundle - Interfaz de usuario de Rancher” (si Rancher está disponible).

  2. Desplegando manualmente (Sección 35.2.4.4.2.2, “Creación del Bundle - 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”.

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

  1. En la esquina superior izquierda, haga clic en ☰ → Continuous Delivery (☰ → Entrega continua).

  2. Diríjase a Advanced > Bundles (Avanzado > Bundles).

  3. Seleccione Create from YAML (Crear desde YAML).

  4. Desde aquí, puede crear el Bundle de las siguientes maneras:

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

  5. Edite el Bundle en la interfaz de usuario de Rancher:

    • Cambie el espacio de nombres del bundle para que dirija al espacio de nombres fleet-local.

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...

    • Cambie los clústeres de destino para que el bundle apunte a su clúster de gestión local:

      spec:
  targets:
  - clusterName: local
      Nota
      Nota

      Hay casos prácticos en los que el clúster local podría tener un nombre diferente.

      Para recuperar el nombre del clúster local, ejecute el siguiente comando:

      kubectl get clusters.fleet.cattle.io -n fleet-local

  6. Seleccione Create (Crear).

35.2.4.4.2.2 Creación del Bundle - Manual
 

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

  2. Edite la configuración del Bundle:

    • Cambie los clústeres de destino para que el bundle apunte a su clúster de gestión local:

      spec:
  targets:
  - clusterName: local
      Nota
      Nota

      Hay casos prácticos en los que el clúster local podría tener un nombre diferente.

      Para recuperar el nombre del clúster local, ejecute el siguiente comando:

      kubectl get clusters.fleet.cattle.io -n fleet-local

    • Cambie el espacio de nombres del bundle para que dirija al espacio de nombres fleet-local.

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...

  3. Aplique el recurso Bundle al clúster de gestión:

    kubectl apply -f os-upgrade-bundle.yaml

  4. Compruebe que el recurso Bundle se ha creado en el espacio de nombres fleet-local:

    kubectl get bundles -n fleet-local
35.2.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 35.2.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
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 35.2.4.2, “Descripción general”).

35.2.5 Actualización de la versió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:

  1. Sección 35.2.5.1, “Componentes”: componentes adicionales usados por el proceso de actualización.

  2. Sección 35.2.5.2, “Descripción general”: descripción general del proceso de actualización.

  3. Sección 35.2.5.3, “Requisitos”: requisitos del proceso de actualización.

  4. Sección 35.2.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.

35.2.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 35.2.1, “Componentes”).

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

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

35.2.5.2 Descripción general

 

La actualización de la distribución de Kubernetes para los nodos del clúster de gestión 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
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
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 35.2.2, “Determinación de su caso de uso” para obtener más información.

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

  1. Use siempre el comando cordon en los nodos antes de las actualizaciones de K8s.

  2. Actualice siempre los nodos control-plane antes que los nodos worker.

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

  1. SUC reconcilia los planes de SUC de K8s desplegados y crea un trabajo de Kubernetes en cada nodo.

  2. Dependiendo de la distribución de Kubernetes, el trabajo creará un pod que ejecutará la imagen de contenedor rke2-upgrade (Sección 35.2.5.1.1, “rke2-upgrade”) o k3s-upgrade (Sección 35.2.5.1.2, “k3s-upgrade”).

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

  4. 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 de k8s de gestión de día2 con fleet

35.2.5.3 Requisitos

 

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

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

35.2.5.4 Actualización de K8s - Despliegue del plan de SUC

 
Importante
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 de gestión. Puede hacerlo eliminando el clúster deseado de la configuración de destino del GitRepo/Bundle 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 hay planes de SUC en el clúster de gestión, 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 35.2.5.2, “Descripción general”, las actualizaciones de Kubernetes se realizan incluyendo planes de SUC en el clúster deseado de las siguientes formas:

Para determinar qué recurso se debe usar, consulte la Sección 35.2.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 35.2.5.4.3, “Despliegue del plan de SUC - Flujo de trabajo de GitOps de terceros”.

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

  1. Mediante la interfaz de usuario de Rancher: Sección 35.2.5.4.1.1, “Creación de GitRepo - Interfaz de usuario de Rancher” (si Rancher está disponible).

  2. Desplegando manualmente (Sección 35.2.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”.

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

35.2.5.4.1.2 Creación de GitRepo - Manual
 

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

  2. Edite la configuración de GitRepo:

    • Elimine la sección spec.targets: solo se necesita para clústeres descendentes.

      • Para RKE2:

        # Example using sed
sed -i.bak '/^  targets:/,$d' rke2-upgrade-gitrepo.yaml && rm -f rke2-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i rke2-upgrade-gitrepo.yaml

      • Para K3s:

        # Example using sed
sed -i.bak '/^  targets:/,$d' k3s-upgrade-gitrepo.yaml && rm -f k3s-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i k3s-upgrade-gitrepo.yaml

    • Dirija el espacio de nombres de GitRepo al espacio de nombres fleet-local. Esto se hace para desplegar el recurso en el clúster de gestión.

      • Para RKE2:

        # Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' rke2-upgrade-gitrepo.yaml && rm -f rke2-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i rke2-upgrade-gitrepo.yaml

      • Para K3s:

        # Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' k3s-upgrade-gitrepo.yaml && rm -f k3s-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i k3s-upgrade-gitrepo.yaml

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

  4. Compruebe que el recurso GitRepo creado se encuentra en el espacio de nombres fleet-local:

    # RKE2
kubectl get gitrepo rke2-upgrade -n fleet-local

# K3s
kubectl get gitrepo k3s-upgrade -n fleet-local

# Example output
NAME           REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    https://github.com/suse-edge/fleet-examples.git   fleet-local   0/0
rke2-upgrade   https://github.com/suse-edge/fleet-examples.git   fleet-local   0/0
35.2.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:

  1. Mediante la interfaz de usuario de Rancher: Sección 35.2.5.4.2.1, “Creación de Bundle - Interfaz de usuario de Rancher” (si Rancher está disponible).

  2. Desplegando manualmente (Sección 35.2.5.4.2.2, “Creación del Bundle - 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”.

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

  1. En la esquina superior izquierda, haga clic en ☰ → Continuous Delivery (☰ → Entrega continua).

  2. Diríjase a Advanced > Bundles (Avanzado > Bundles).

  3. Seleccione Create from YAML (Crear desde YAML).

  4. Desde aquí, puede crear el Bundle de las siguientes maneras:

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

  5. Edite el Bundle en la interfaz de usuario de Rancher:

    • Cambie el espacio de nombres del bundle para que dirija al espacio de nombres fleet-local.

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...

    • Cambie los clústeres de destino para que el bundle apunte a su clúster de gestión local:

      spec:
  targets:
  - clusterName: local
      Nota
      Nota

      Hay casos prácticos en los que el clúster local podría tener un nombre diferente.

      Para recuperar el nombre del clúster local, ejecute el siguiente comando:

      kubectl get clusters.fleet.cattle.io -n fleet-local

  6. Seleccione Create (Crear).

35.2.5.4.2.2 Creación del Bundle - Manual
 

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

  2. Edite la configuración del Bundle:

    • Cambie los clústeres de destino para que el bundle apunte a su clúster de gestión local:

      spec:
  targets:
  - clusterName: local
      Nota
      Nota

      Hay casos prácticos en los que el clúster local podría tener un nombre diferente.

      Para recuperar el nombre del clúster local, ejecute el siguiente comando:

      kubectl get clusters.fleet.cattle.io -n fleet-local

    • Cambie el espacio de nombres del bundle para que dirija al espacio de nombres fleet-local.

      # Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...

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

  4. Compruebe que el recurso Bundle se ha creado en el espacio de nombres fleet-local:

    # For RKE2
kubectl get bundles rke2-upgrade -n fleet-local

# For K3s
kubectl get bundles k3s-upgrade -n fleet-local

# Example output
NAME           BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    0/0
rke2-upgrade   0/0
35.2.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
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 la versión de Kubernetes, puede resultar útil echar un vistazo a la descripción general (Sección 35.2.5.2, “Descripción general”) del procedimiento de actualización mediante Fleet.

35.2.6 Actualización de charts de Helm

 

Esta sección cubre lo siguiente:

  1. Sección 35.2.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.

  2. Sección 35.2.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.

35.2.6.1 Preparación para entornos aislados

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

  1. Aloje los recursos de Fleet de su chart en un servidor Git local al que pueda acceder su clúster de gestión.

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

35.2.6.1.2 Busque los recursos necesarios para su versión de Edge
 

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

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

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

En un equipo con acceso a Internet:

  1. Permita que edge-save-images.sh se pueda ejecutar:

    chmod +x edge-save-images.sh

  2. Genere el archivo de imagen:

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

  3. Esto creará un archivo listo para cargar llamado edge-images.tar.gz.

    Nota
    Nota

    Si se especifica la opción -i|--images, el nombre del archivo puede ser diferente.

  4. Copie este archivo a su equipo aislado:

    scp edge-images.tar.gz <user>@<machine_ip>:/path
35.2.6.1.4 Cree el archivo de imágenes del chart OCI de Edge
 

En un equipo con acceso a Internet:

  1. Permita que edge-save-oci-artefacts.sh se pueda ejecutar:

    chmod +x edge-save-oci-artefacts.sh

  2. Genere el archivo de imagen del chart OCI:

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

  3. Esto creará un archivo denominado oci-artefacts.tar.gz.

    Nota
    Nota

    Si se especifica la opción -a|--archive, el nombre del archivo puede ser distinto.

  4. Copie este archivo a su equipo aislado:

    scp oci-artefacts.tar.gz <user>@<machine_ip>:/path
35.2.6.1.5 Cargue las imágenes de la versión de Edge en su equipo aislado
 

En su equipo aislado:

  1. Inicie sesión en su registro privado (si es necesario):

    podman login <REGISTRY.YOURDOMAIN.COM:PORT>

  2. Permita que edge-load-images.sh se pueda ejecutar:

    chmod +x edge-load-images.sh

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

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

En su equipo aislado:

  1. Inicie sesión en su registro privado (si es necesario):

    podman login <REGISTRY.YOURDOMAIN.COM:PORT>

  2. Permita que edge-load-oci-artefacts.sh se pueda ejecutar:

    chmod +x edge-load-oci-artefacts.sh

  3. Desempaquete el archivo oci-artefacts.tar.gz copiado:

    tar -xvf oci-artefacts.tar.gz

  4. Esto generará un directorio con el formato de nombre edge-release-oci-tgz-<fecha>.

  5. 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
    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
35.2.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)

35.2.6.2 Procedimiento de actualización

 

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

  1. Sección 35.2.6.2.1, “Tengo un nuevo clúster y me gustaría desplegar y gestionar un chart de Helm de Edge”

  2. Sección 35.2.6.2.2, “Quiero actualizar un chart de Helm gestionado por Fleet”

  3. Sección 35.2.6.2.3, “Quiero actualizar un chart de Helm desplegado mediante EIB”

Importante
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 35.2.6.2.1, “Tengo un nuevo clúster y me gustaría desplegar y gestionar un chart de Helm de Edge”.

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

  1. Sección 35.2.6.2.1.1, “Prepare los recursos de Fleet para su chart”.

  2. Sección 35.2.6.2.1.2, “Despliegue la flota en su chart”.

  3. Sección 35.2.6.2.1.3, “Gestione el chart de Helm desplegado”.

35.2.6.2.1.1 Prepare los recursos de Fleet para su chart
 

  1. Adquiera los recursos de Fleet del chart desde la etiqueta de versión de Edge que desee usar.

  2. Diríjase a la flota del chart de Helm (fleets/day2/chart-templates/<chart>).

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

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

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

35.2.6.2.1.2 Despliegue la flota en su chart
 

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

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

35.2.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-local
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
35.2.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
Nota

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

  1. Diríjase a la plantilla de flota de chart de longhorn:

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

  2. Cree un archivo targets.yaml que indicará a Fleet en qué clústeres debe desplegar el chart de Helm:

    cat > targets.yaml <<EOF
targets:
# Match your local (management) cluster
- clusterName: local
EOF
    Nota
    Nota

    Hay casos prácticos en los que el clúster local podría tener un nombre diferente.

    Para recuperar el nombre del clúster local, ejecute el siguiente comando:

    kubectl get clusters.fleet.cattle.io -n fleet-local

  3. Convierta la flota de chart de Helm de Longhorn en un recurso Bundle mediante fleet-cli.

    Nota
    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-local -o - longhorn-bundle > longhorn-bundle.yaml

  4. Diríjase a la plantilla de flota de chart longhorn-crd:

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

  5. Cree un archivo targets.yaml que indicará a Fleet en qué clústeres debe desplegar el chart de Helm:

    cat > targets.yaml <<EOF
targets:
# Match your local (management) cluster
- clusterName: local
EOF

  6. 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-local -o - longhorn-crd-bundle > longhorn-crd-bundle.yaml

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

Siga estos pasos para asegurarse de que SUSE Storage se despliega en todos los clústeres de gestión especificados.

35.2.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 35.2.6.2.2, “Quiero actualizar un chart de Helm gestionado por Fleet”.

35.2.6.2.2 Quiero actualizar un chart de Helm gestionado por Fleet
 

  1. 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”).

  2. 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”).

  3. Después de confirmar y enviar los cambios al repositorio, se activará una actualización del chart de Helm deseado.

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

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

  1. Extraigan localmente los archivos de cada chart de Helm que deba actualizarse.

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

  3. 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 la ayuda de Fleet, incluirá sus recursos en el clúster de gestión deseado.

Estos recursos incluyen:

  1. Un conjunto de secretos que guardan los datos del chart de Helm proporcionados por el usuario.

  2. 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 del helm de gestión de día 2 de fleet
35.2.6.2.3.2 Pasos para la actualización
 

  1. Clone el repositorio suse-edge/fleet-examples de la etiqueta de versión correcta.

  2. Cree un directorio en el que almacenarán los archivos de los charts de Helm extraídos.

    mkdir archives

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

  4. En la página Assets (Recursos) de la etiqueta de versión deseada, descargue el guion generate-chart-upgrade-data.sh.

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

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

  2. 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 map the local(management) cluster
- clusterName: local
EOF
      Nota
      Nota

      Hay casos prácticos en los que el clúster local podría tener un nombre diferente.

      Para recuperar el nombre del clúster local, ejecute el siguiente comando:

      kubectl get clusters.fleet.cattle.io -n fleet-local

    4. Utilice fleet-cli para convertir la flota en un recurso Bundle:

      fleet apply --compress --targets-file=targets.yaml -n fleet-local -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 35.2.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 35.2.6.2.3.3, “Ejemplo”.

Importante
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 del clúster de gestión, lo que garantizará que no se produzcan conflictos entre versiones en el futuro.

35.2.6.2.3.3 Ejemplo
 
Nota
Nota

El siguiente ejemplo muestra cómo actualizar un chart de Helm desplegado mediante EIB de una versión a otra en un clúster de gestión. 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:

  • Se ejecuta un clúster de gestión en 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 entiende que el clúster de gestión 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 35.2.6.2.3.2, “Pasos para la actualización”):

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

  2. Cree un directorio donde se almacenará el archivo de actualización de Longhorn.

    mkdir archives

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

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

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

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

  7. 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: local
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-local -o - eib-charts-upgrade > bundle.yaml

  8. Despliegue el Bundle mediante la interfaz de usuario de Rancher:

    ejemplo 1 de actualización del chart de helm de día 2
    Figura 35.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).

  9. Cuando haya finalizado el despliegue correctamente, el Bundle deberá tener un aspecto similar al siguiente:

    ejemplo 2 de actualización de chart del helm de día 2
    Figura 35.2: Bundle desplegado correctamente
     

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

  1. Verifique los registros del pod de actualización:

    ejemplo 3 de actualización de chart de helm de día 2 gestión

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

      ejemplo 4 de actualización de chart de helm de día 2 gestión
      Figura 35.3: Registros de chart de Longhorn actualizado correctamente
       

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

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

35.2.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 35.2.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 35.2.6.2.3.1, “Descripción general” y la Sección 35.2.6.2.3.2, “Pasos para la actualización”.