Se aplica a SUSE Edge 3.6

32 Clúster de gestión #

Actualmente, existen dos formas de realizar operaciones de «Día 2» en su clúster management:

A través de Capítulo 19, Controlador de actualización - Sección 32.1, “Upgrade Controller”
A través de Capítulo 6, Fleet - Sección 32.2, “Fleet”

32.1 Upgrade Controller #

Importante

El Upgrade Controller actualmente solo admite operaciones Day 2 para clústeres de gestión sin entorno aislado.

Esta sección cubre cómo realizar las diversas operaciones de Day 2 relacionadas con la actualización de su clúster management de una versión de plataforma SUSE Edge a otra.

Las operaciones de Day 2 están automatizadas por el Upgrade Controller (Capítulo 19, Controlador de actualización) e incluyen:

Actualización del SO SUSE Linux Micro (Capítulo 7, SUSE Linux Micro)
Actualización de Kubernetes Capítulo 12, RKE2 o Capítulo 11, K3s
Actualización de componentes adicionales de SUSE (SUSE Rancher Prime, SUSE Security, etc.)

32.1.1 Requisitos previos #

Antes de actualizar su clúster management, se deben cumplir los siguientes requisitos previos:

SCC registered nodes - asegúrese de que el SO de los nodos de su clúster esté registrado con una clave de suscripción que admita la versión del SO especificada en la SUSE Edge release (Capítulo 41, Notas de la versión) a la que pretende actualizar.
Upgrade Controller - asegúrese de que el Upgrade Controller se haya desplegado en su clúster management. Para conocer los pasos de instalación, consulte Sección 19.3, “Instalación del Controlador de actualización”.

32.1.2 Actualización #

Determine la versión de SUSE Edge release (Capítulo 41, Notas de la versión) a la que desea actualizar su clúster management.
En el clúster management, despliegue un UpgradePlan que especifique la release version deseada. El UpgradePlan debe desplegarse en el espacio de nombres del 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
Puede haber casos de uso en los que desee realizar configuraciones adicionales sobre el UpgradePlan. Para todas las configuraciones posibles, consulte Sección 19.6.1, “UpgradePlan”.
El despliegue del UpgradePlan en el espacio de nombres Upgrade Controller’s iniciará el upgrade process.
Nota
Para obtener más información sobre el upgrade process real, consulte Sección 19.5, “¿Cómo funciona el Controlador de actualización?”.
Para obtener información sobre cómo realizar el seguimiento del upgrade process, consulte Sección 19.7, “Seguimiento del proceso de actualización”.

32.1.3 Pasos posteriores a la actualización #

Las actualizaciones de SUSE Edge desde la última versión z-stream de 3.5 a 3.6.0 pueden requerir algunos pasos manuales finales que deben realizarse después de que el Upgrade Controller haya completado el proceso de actualización. Estos están relacionados con la sustitución de Ingress-NGINX por Traefik como el único controlador de entrada admitido en SUSE Edge a partir de la versión 3.6.

Nota

El proveedor de entrada Traefik integrado en RKE2/K3s es el único controlador de entrada admitido en la versión SUSE Edge 3.6, siendo todavía posible ejecutar temporalmente Ingress-NGINX junto con Traefik para admitir escenarios complejos de migración de entrada, pero solo después de que los clústeres de gestión y/o sentido descendente SUSE Edge se hayan actualizado a la versión 3.6 y durante el tiempo necesario para realizar dicha migración.

La guía de RKE2 Migración de Ingress NGINX a Traefik proporciona detalles sobre las rutas de migración de entrada disponibles una vez que el controlador de entrada Traefik sustituya al Ingress-NGINX discontinuado.

En caso de que el clúster de gestión recién actualizado no estuviera ejecutando el controlador de entrada Traefik (sino el predeterminado Ingress-NGINX) antes de iniciar la actualización, ahora es necesario desplegar manualmente Traefik.

Primero vamos a asegurarnos de que la instancia de ingress-NGINX implementada esté configurada correctamente (por ejemplo, para evitar colisiones innecesarias de hostPort entre los pods de los dos controladores de entrada):

kubectl apply -f - <<- EOF
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-ingress-nginx
  namespace: kube-system
spec:
  valuesContent: |-
    controller:
      hostPort:
        enabled: false  # not needed when exposing through a type:LoadBalancer service
      config:
        use-forwarded-headers: "true"
        enable-real-ip: "true"
      publishService:
        enabled: true
      service:
        enabled: true
        type: LoadBalancer
        externalTrafficPolicy: Local
EOF

Ahora podemos proceder con el despliegue de Traefik, mediante la instalación de los gráficos de Helm rke2-traefik-crd y rke2-traefik.

Nota

Despliegue estos gráficos de Helm a través de manifiestos HelmChart, como se muestra a continuación, para asegurar que Upgrade Controller se encargue también de actualizar estos gráficos de Helm en futuras actualizaciones del clúster de gestión.

kubectl apply -f - <<- EOF
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: rke2-traefik-crd
  namespace: kube-system
spec:
  chart: rke2-traefik-crd
  version: {rke2-traefik-crd Helm chart version}
  repo: https://rke2-charts.rancher.io
  bootstrap: false
  failurePolicy: reinstall
  backOffLimit: 20
  targetNamespace: kube-system
  set:
    global.cattle.systemDefaultRegistry: registry.rancher.com
    global.rke2DataDir: /var/lib/rancher/rke2
    global.systemDefaultRegistry: registry.rancher.com
---
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: rke2-traefik
  namespace: kube-system
spec:
  chart: rke2-traefik
  version: {rke2-traefik Helm chart version}
  repo: https://rke2-charts.rancher.io
  bootstrap: false
  failurePolicy: reinstall
  backOffLimit: 20
  targetNamespace: kube-system
  set:
    global.cattle.systemDefaultRegistry: registry.rancher.com
    global.rke2DataDir: /var/lib/rancher/rke2
    global.systemDefaultRegistry: registry.rancher.com
  valuesContent: |-
    ingressClass:
      isDefaultClass: false  # if traefik deployed alongside ingress-nginx
    ports:
      web:
        hostPort: null    # disallow hostPort
        exposedPort: 80
      websecure:
        hostPort: null    # disallow hostPort
        exposedPort: 443
    service:
      enabled: true
      type: LoadBalancer
      spec:
        externalTrafficPolicy: Local
        allocateLoadBalancerNodePorts: false  # k8s GA from 1.24; supported by MetalLB
    providers:
      kubernetesIngressNginx:  # this provider allows traefik to "understand" most of the ingress-nginx annotations
        enabled: true
        ingressClass: "rke2-ingress-nginx-migration"
        controllerClass: "rke2.cattle.io/ingress-nginx-migration"
EOF

El {rke2-traefik-crd Helm chart version} y el {rke2-traefik-crd Helm chart version} son los dictados por la versión de RKE2/k3s a la que hemos actualizado.

En el último paso, creamos finalmente los objetos necesarios de MetalLB para exponer el servicio Traefik a través de un servicio de tipo LoadBalancer:

kubectl apply -f - <<- EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ingress-ippool-traefik
  namespace: metallb-system
spec:
  addresses:
  - {EXTERNAL_IP_FOR_TRAEFIK_SERVICE}/32
  serviceAllocation:
    priority: 100
    serviceSelectors:
    - matchExpressions:
      - {key: app.kubernetes.io/name, operator: In, values: [rke2-traefik]}
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: ingress-l2-adv-traefik
  namespace: metallb-system
spec:
  ipAddressPools:
  - ingress-ippool-traefik
EOF

Ahora tanto Traefik como Ingress-NGINX se ejecutan simultáneamente, lo que le permite realizar de forma segura la migración necesaria de sus ingresses de uno a otro.

Importante

Una vez que todos los ingresses se hayan migrado y ya no necesite Ingress-NGINX, asegúrese de desinstalarlo y limpiar todos los recursos relacionados para evitar cualquier consumo innecesario de recursos en su clúster.

32.2 Fleet #

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

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

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

32.2.1 Componentes #

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

32.2.1.1 Rancher #

Opcional; responsable de gestionar downstream clusters y desplegar System Upgrade Controller en vuestro management cluster.

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

32.2.1.2 System Upgrade Controller (SUC) #

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

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

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

32.2.2 Determinad vuestro caso de uso #

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

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

32.2.2.1 GitRepo #

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

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

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

32.2.2.2 Bundle #

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

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

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

32.2.3 Flujo de trabajo de Día 2 #

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

Actualización de versión del SO (Sección 32.2.4, “Actualización del SO”)
Actualización de versión de Kubernetes (Sección 32.2.5, “Actualización de la versión de Kubernetes”)
Actualización de versión de Helm charts (Sección 32.2.6, “Actualización de Helm chart”)

32.2.4 Actualización del SO #

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

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

Sección 32.2.4.1, “Componentes” - componentes adicionales utilizados por el proceso de actualización.
Sección 32.2.4.2, “Descripción general” - descripción general del proceso de actualización.
Sección 32.2.4.3, “Requisitos” - requisitos del proceso de actualización.
Sección 32.2.4.4, “Actualización del SO - Ampliación del plan SUC” - información sobre cómo desplegar SUC plans, responsable de activar el proceso de actualización.

32.2.4.1 Componentes #

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

32.2.4.1.1 systemd.service #

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

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

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

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

32.2.4.2 Descripción general #

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

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

Nota

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

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

Nota

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

OS SUC plans describe el siguiente flujo de trabajo:

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

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

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

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

32.2.4.3 Requisitos #

General:

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

Entorno aislado:

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

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

Importante

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

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

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

Si los usuarios intentan actualizar mientras existen SUC Plans en el clúster management, 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 Sección 32.2.4.2, “Descripción general”, las actualizaciones del SO se realizan enviando SUC plans al clúster deseado a través de una de las siguientes formas:

Recurso GitRepo de Fleet - Sección 32.2.4.4.1, “Ampliación del plan SUC - Recurso GitRepo”.
Recurso Bundle de Fleet - Sección 32.2.4.4.2, “Despliegue del plan SUC - Recurso Bundle”.

Para determinar qué recurso debéis utilizar, consultad Sección 32.2.2, “Determinad vuestro caso de uso”.

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

32.2.4.4.1 Ampliación del plan SUC - Recurso GitRepo #

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

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

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

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

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

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

Importante

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

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

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

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

32.2.4.4.1.2 Creación de GitRepo - manual #

Extraed el recurso GitRepo:

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

Edita la configuración de GitRepo:

Elimina la sección spec.targets: solo es necesaria para los clústeres en sentido descendente.

# 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

Apunta el espacio de nombres del GitRepo al espacio de nombres fleet-local: 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

Aplica el recurso GitRepo en tu management cluster:
```
kubectl apply -f os-upgrade-gitrepo.yaml
```

Visualiza el recurso GitRepo creado bajo el espacio de nombres fleet-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.6.1  0/0

32.2.4.4.2 Despliegue del plan SUC - Recurso Bundle #

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

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

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

32.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 utilizarse en los pasos siguientes.

Importante

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

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

En la esquina superior izquierda, haz clic en ☰ → Continuous Delivery
Ve a Avanzado > Bundles
Selecciona Crear a partir de YAML
Desde aquí puedes crear el Bundle de una de las siguientes maneras:
Nota
Puede haber casos de uso en los que necesites incluir cambios personalizados en el SUC plans que incorpora el bundle (por ejemplo, para añadir tolerancias personalizadas). Asegúrate de incluir esos cambios en el bundle que se generará mediante los pasos siguientes.
1. Copiando manualmente el contenido del bundle desde suse-edge/fleet-examples a la página Crear a partir de YAML.
2. Clonando el repositorio suse-edge/fleet-examples desde la etiqueta de release deseada y seleccionando la opción Leer desde archivo en la página Crear a partir de YAML. Desde ahí, navega a la ubicación del bundle (bundles/day2/system-upgrade-controller-plans/os-upgrade) y selecciona el archivo del bundle. Esto rellenará automáticamente la página Crear a partir de YAML con el contenido del bundle.
Edita el bundle en la interfaz de usuario de Rancher:
- Cambia el espacio de nombres del Bundle para que apunte al espacio de nombres fleet-local.
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...
```
- Cambia los clústeres target del Bundle para que apunten a tu clúster local (gestión):
```
spec:
  targets:
  - clusterName: local
```
  Nota
  Existen algunos casos de uso en los que tu clúster local podría tener un nombre diferente.
  Para recuperar el nombre de tu clúster local, ejecuta el comando siguiente:
  kubectl get clusters.fleet.cattle.io -n fleet-local
Selecciona Crear

32.2.4.4.2.2 Creación de bundle - manual #

Obtén el recurso Bundle:

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

Editad la configuración del Bundle:
- Cambia los clústeres target del Bundle para que apunten a tu clúster local (gestión):
```
spec:
  targets:
  - clusterName: local
```
  Nota
  Existen algunos casos de uso en los que tu clúster local podría tener un nombre diferente.
  Para recuperar el nombre de tu clúster local, ejecuta el comando siguiente:
  kubectl get clusters.fleet.cattle.io -n fleet-local
- Cambia el espacio de nombres del Bundle para que apunte al espacio de nombres fleet-local.
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...
```
Aplica el recurso Bundle a tu management cluster:
```
kubectl apply -f os-upgrade-bundle.yaml
```
Visualiza el recurso Bundle creado en el espacio de nombres fleet-local:
```
kubectl get bundles -n fleet-local
```

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

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

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

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

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

Importante

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

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

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

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

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

Sección 32.2.5.1, “Componentes” - componentes adicionales utilizados por el proceso de actualización.
Sección 32.2.5.2, “Descripción general” - visión general del proceso de actualización.
Sección 32.2.5.3, “Requisitos” - requisitos del proceso de actualización.
Sección 32.2.5.4, “Actualización de K8s - Ampliación del plan SUC” - información sobre cómo desplegar SUC plans, responsable de activar el proceso de actualización.

32.2.5.1 Componentes #

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

32.2.5.1.1 rke2-upgrade #

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

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

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

32.2.5.1.2 k3s-upgrade #

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

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

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

32.2.5.2 Descripción general #

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

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

Nota

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

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

Nota

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

K8s SUC plans describen el siguiente flujo de trabajo:

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

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

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

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

32.2.5.3 Requisitos #

Haced una copia de seguridad de vuestra distribución de Kubernetes:
1. Para clústeres RKE2, consultad la documentación de copia de seguridad y restauración de RKE2.
2. Para clústeres K3s, consultad la documentación de copia de seguridad y restauración de K3s.
Aseguraos de que las tolerancias del Plan SUC coincidan con las tolerancias del nodo - Si los nodos de vuestro clúster de Kubernetes tienen taints personalizados, aseguraos de añadir tolerancias para esas taints en los Planes SUC. Por defecto, los Planes SUC solo tienen tolerancias para los nodos del plano de control. Las tolerancias predeterminadas incluyen:
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  Nota
  Cualquier tolerancia adicional debe añadirse en la sección .spec.tolerations de cada Plan. Los Planes SUC relacionados con la actualización de versión de Kubernetes se pueden encontrar en el repositorio suse-edge/fleet-examples en:
  Para RKE2 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade
  Para K3s - fleets/day2/system-upgrade-controller-plans/k3s-upgrade
  Aseguraos de utilizar los Planes de una etiqueta de versión de repositorio válida.
  Un ejemplo de cómo definir tolerancias personalizadas para el Plan SUC del plano de control de RKE2 tendría este aspecto:
  apiVersion: upgrade.cattle.io/v1 kind: Plan metadata: name: rke2-upgrade-control-plane spec: ... tolerations: # default tolerations - key: "CriticalAddonsOnly" operator: "Equal" value: "true" effect: "NoExecute" - key: "node-role.kubernetes.io/control-plane" operator: "Equal" effect: "NoSchedule" - key: "node-role.kubernetes.io/etcd" operator: "Equal" effect: "NoExecute" # custom toleration - key: "foo" operator: "Equal" value: "bar" effect: "NoSchedule" ...

32.2.5.4 Actualización de K8s - Ampliación del plan SUC #

Importante

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

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

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

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

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

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

Recurso de flota GitRepo (Sección 32.2.5.4.1, “Ampliación del plan SUC - recurso GitRepo”)
Recurso de flota Bundle (Sección 32.2.5.4.2, “Ampliación del plan SUC - Recurso Bundle”)

Para determinar qué recurso debéis utilizar, consultad Sección 32.2.2, “Determinad vuestro caso de uso”.

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

32.2.5.4.1 Ampliación del plan SUC - recurso GitRepo #

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

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

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

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

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

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

Importante

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

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

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

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

32.2.5.4.1.2 Creación de GitRepo - manual #

Obtened el recurso GitRepo:

Para clústeres RKE2:

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

Para clústeres K3s:

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

Editad la configuración del GitRepo:

Eliminad la sección spec.targets, solo es necesaria para los clústeres de sentido descendente.

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

Apuntad el espacio de nombres del 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

Aplicad los recursos GitRepo a vuestro management cluster:

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

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

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

32.2.5.4.2 Ampliación del plan SUC - Recurso Bundle #

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

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

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

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

Importante

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

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

En la esquina superior izquierda, haced clic en ☰ → Entrega Continua
Id a Advanced > Bundles
Seleccionad Create from YAML
Desde aquí podéis crear el Bundle de una de las siguientes maneras:
Nota
Puede haber casos de uso en los que necesitéis incluir cambios personalizados en los SUC plans que el bundle incluye (p. ej., para añadir tolerancias personalizadas). Aseguraos de incluir esos cambios en el bundle que se generará mediante los siguientes pasos.
1. Copiando manualmente el contenido del bundle para RKE2 o K3s desde suse-edge/fleet-examples a la página Create from YAML.
2. Clonando el repositorio suse-edge/fleet-examples desde la release deseada y seleccionando la opción Read from File en la página Create from YAML. Desde allí, navegad hasta el bundle que necesitéis (bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml para RKE2 y bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml para K3s). Esto rellenará automáticamente la página Create from YAML con el contenido del bundle.
Editad el Bundle en la interfaz de usuario de Rancher:
- Cambiad el espacio de nombres del Bundle para que apunte al espacio de nombres fleet-local.
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...
```
- Cambiad los clústeres target del Bundle para que apunten a vuestro clúster local (gestión):
```
spec:
  targets:
  - clusterName: local
```
  Nota
  Existen algunos casos de uso en los que vuestro clúster local podría tener un nombre diferente.
  Para recuperar el nombre de vuestro clúster local, ejecutad el siguiente comando:
  kubectl get clusters.fleet.cattle.io -n fleet-local
Seleccionad Crear

32.2.5.4.2.2 Creación de bundle - manual #

Obtened los recursos del Bundle:

Para clústeres RKE2:

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

Para clústeres K3s:

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

Editad la configuración del Bundle:
- Cambiad los clústeres target del Bundle para que apunten a vuestro clúster local (gestión):
```
spec:
  targets:
  - clusterName: local
```
  Nota
  Existen algunos casos de uso en los que vuestro clúster local podría tener un nombre diferente.
  Para recuperar el nombre de vuestro clúster local, ejecutad el siguiente comando:
  kubectl get clusters.fleet.cattle.io -n fleet-local
- Cambiad el espacio de nombres del Bundle para que apunte al espacio de nombres fleet-local.
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...
```

Aplicad los recursos del Bundle a vuestro management cluster:

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

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

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

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

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

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

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

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

Importante

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

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

32.2.6 Actualización de Helm chart #

Esta sección trata las siguientes partes:

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

32.2.6.1 Preparación para entornos aislados #

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

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

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

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

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

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

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

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

En una máquina con acceso a internet:

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

Generad el archivo de imagen:

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

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

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

En una máquina con acceso a internet:

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

Generad el archivo de imagen de gráfico OCI:

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

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

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

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

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

En vuestra máquina en entorno aislado:

Iniciad sesión en vuestro registro privado (si es necesario):
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
Haced que edge-load-images.sh sea ejecutable:
```
chmod +x edge-load-images.sh
```
Ejecutad el script, pasando el archivo edge-images.tar.gz que fue copiado anteriormente:
```
./edge-load-images.sh --source-registry registry.suse.com --registry <REGISTRY.YOURDOMAIN.COM:PORT> --images edge-images.tar.gz
```
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.

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

En vuestra máquina en entorno aislado:

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

32.2.6.1.7 Configurad vuestro registro privado en vuestra distribución de Kubernetes #

Para RKE2, consultad Configuración de registro privado.

Para K3s, consultad Configuración de registro privado.

32.2.6.2 Procedimiento de actualización #

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

Importante

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

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

Esta sección cubre cómo:

32.2.6.2.1.1 Preparad los recursos de Fleet para vuestro Helm chart #

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

Nota

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

failed pre-install: context deadline exceeded

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

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

Estructura del repositorio Git del usuario:

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

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

defaultNamespace: longhorn-system

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

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

Nota

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

32.2.6.2.1.2 Desplegad la flota para vuestro Helm chart #

Podéis desplegar la flota para vuestro Helm chart utilizando un GitRepo (Sección 32.2.6.2.1.2.1, “GitRepo”) o un Bundle (Sección 32.2.6.2.1.2.2, “Bundle”).

Nota

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

32.2.6.2.1.2.1 GitRepo #

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

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

Ejemplo de recurso Longhorn GitRepo para despliegue manual:

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: longhorn-git-repo
  namespace: fleet-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

32.2.6.2.1.2.2 Bundle #

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

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

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

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

Nota

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

Navegad hasta la plantilla de Fleet del Helm chart longhorn:
```
cd fleets/day2/chart-templates/longhorn/longhorn
```
Cread un archivo targets.yaml que indique a Fleet en qué clústeres debe desplegar el Helm chart:
```
cat > targets.yaml <<EOF
targets:
# Match your local (management) cluster
- clusterName: local
EOF
```
Nota
Existen algunos casos de uso en los que vuestro clúster local podría tener un nombre diferente.
Para recuperar el nombre de su clúster local, ejecute el siguiente comando:
```
kubectl get clusters.fleet.cattle.io -n fleet-local
```
Convierta el recurso Fleet del gráfico de Helm Longhorn en un recurso Bundle utilizando la fleet-cli.
Nota
La CLI de Fleet se puede obtener desde su página de lanzamientos Assets (fleet-linux-amd64).
Para los usuarios de Mac, existe una fórmula de Homebrew para fleet-cli.
```
fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - longhorn-bundle > longhorn-bundle.yaml
```
Navegue hasta la plantilla de Fleet del gráfico longhorn-crd:
```
cd fleets/day2/chart-templates/longhorn/longhorn-crd
```
Cree un archivo targets.yaml que indique a Fleet en qué clústeres debe desplegar el gráfico de Helm:
```
cat > targets.yaml <<EOF
targets:
# Match your local (management) cluster
- clusterName: local
EOF
```

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

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

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

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

32.2.6.2.1.3 Gestionar el gráfico de Helm desplegado #

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

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

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

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

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

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

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

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

32.2.6.2.3.1 Descripción general #

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

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

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

Solo se espera que el usuario:

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

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

Estos recursos incluyen:

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

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

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

32.2.6.2.3.2 Pasos de actualización #

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

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

cd archives
helm pull [chart URL | repo/chartname]

# Alternatively if you want to pull a specific version:
# helm pull [chart URL | repo/chartname] --version 0.0.0

Desde Assets de la etiqueta de versión deseada, descargad el script generate-chart-upgrade-data.sh.
Ejecutad el script generate-chart-upgrade-data.sh:
```
chmod +x ./generate-chart-upgrade-data.sh

./generate-chart-upgrade-data.sh --archive-dir /foo/bar/archives/ --fleet-path /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
Para cada archivo de gráfico en el directorio --archive-dir, el script genera un archivo Kubernetes Secret YAML que contiene los datos de actualización del gráfico y los almacena en el directorio base/secrets de la flota especificada por --fleet-path.
El script generate-chart-upgrade-data.sh también aplica modificaciones adicionales a la flota para garantizar que los archivos Kubernetes Secret YAML generados sean utilizados correctamente por la carga de trabajo desplegada por la flota.
Importante
Los usuarios no deben realizar cambios sobre lo que genera el script generate-chart-upgrade-data.sh.

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

Para un entorno que admita GitOps (por ejemplo, que no esté aislado o que esté aislado, pero permita el soporte de un servidor Git local):
1. Copiad la flota fleets/day2/eib-charts-upgrader al repositorio que utilizaréis para GitOps.
  Nota
  Aseguraos de que la flota incluya los cambios realizados por el script generate-chart-upgrade-data.sh.
2. Configurad un recurso GitRepo que se utilizará para enviar todos los recursos de la flota eib-charts-upgrader.
  1. Para la configuración y el despliegue de GitRepo a través de la interfaz de usuario de Rancher, consultad Acceso a Fleet en la interfaz de usuario de Rancher.
  2. Para la configuración y el despliegue manual de GitRepo, consultad Creación de un despliegue.
Para un entorno que no admita GitOps (por ejemplo, que sea un entorno aislado y no permita el uso de un servidor Git local):
1. Descargad el binario fleet-cli desde la página rancher/fleet release (fleet-linux-amd64 para Linux). Para los usuarios de Mac, existe una fórmula de Homebrew que se puede utilizar: fleet-cli.
2. Navegad a eib-charts-upgrader Fleet:
```
cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
3. Cread un archivo targets.yaml que indique a Fleet dónde desplegar vuestros recursos:
```
cat > targets.yaml <<EOF
targets:
# To map the local(management) cluster
- clusterName: local
EOF
```
  Nota
  Existen algunos casos de uso en los que vuestro clúster local podría tener un nombre diferente.
  Para recuperar el nombre de vuestro clúster local, ejecutad el siguiente comando:
  kubectl get clusters.fleet.cattle.io -n fleet-local
4. Utilizad fleet-cli para convertir Fleet 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 con plantilla del Fleet eib-charts-upgrader.
  Para obtener más información sobre el comando fleet apply, consultad fleet apply.
  Para obtener más información sobre la conversión de Fleets a Bundles, consultad Convertir un gráfico de Helm en un Bundle.
5. Desplegad Bundle. Esto se puede hacer de dos formas:
  1. A través de la interfaz de usuario de Rancher: navegad a Continuous Delivery → Advanced → Bundles → Create from YAML y pegad el contenido de bundle.yaml o haced clic en la opción Read from File y enviad el archivo directamente.
  2. Manualmente: desplegad el archivo bundle.yaml manualmente dentro de vuestro management cluster.

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

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

Importante

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

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

32.2.6.2.3.3 Ejemplo #

Nota

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

Caso práctico:

Un clúster management está ejecutando una versión anterior de Longhorn.

El clúster se ha desplegado a través de EIB, utilizando la siguiente definición de imagen snippet:

kubernetes:
  helm:
    charts:
    - name: longhorn-crd
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    - name: longhorn
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    repositories:
    - name: rancher-charts
      url: https://charts.rancher.io/
...

SUSE Storage necesita ser actualizado a una versión que sea compatible con la versión 3.6 de Edge. Lo que significa que debe actualizarse a 1.11.2.
Se asume que el management cluster está en un entorno aislado, sin soporte para un servidor Git local y tiene una configuración de Rancher en funcionamiento.

Seguid los Pasos de actualización (Sección 32.2.6.2.3.2, “Pasos de actualización”):

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

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

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

# Pull the Longhorn 1.11.2 chart archive
helm pull oci://dp.apps.rancher.io/charts/suse-storage --version 1.11.2

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

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

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

Ejecutad el script generate-chart-upgrade-data.sh:

# First make the script executable
chmod +x ./generate-chart-upgrade-data.sh

# Then execute the script
./generate-chart-upgrade-data.sh --archive-dir ./archives --fleet-path ./fleet-examples/fleets/day2/eib-charts-upgrader

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

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

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

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   fleets/day2/eib-charts-upgrader/base/patches/job-patch.yaml
    modified:   fleets/day2/eib-charts-upgrader/base/secrets/kustomization.yaml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-VERSION.yaml
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-crd-VERSION.yaml

Cread un Bundle para el Fleet eib-charts-upgrader:

Primero, navegad hasta el Fleet:

cd ./fleet-examples/fleets/day2/eib-charts-upgrader

A continuación, cread un archivo targets.yaml:

cat > targets.yaml <<EOF
targets:
- clusterName: local
EOF

Después, utilizad el binario fleet-cli para convertir el Fleet en un Bundle:

fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yaml

Desplegad el Bundle a través de la interfaz de usuario de Rancher:
Figura 32.1: Desplegad el Bundle a través de la interfaz de usuario de Rancher #

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

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

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

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

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

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

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

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

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

kustomize build .

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

Para entender cómo se pretende utilizar este flujo de trabajo, consultad Sección 32.2.6.2.3.1, “Descripción general” y Sección 32.2.6.2.3.2, “Pasos de actualización”.