|Index|SUSE Edge Documentación|Operaciones del día 2|Migración edge 3.6
Applies to SUSE Edge 3.6

31 Migración edge 3.6

 

Esta sección explica cómo migrar sus clústeres management y downstream de SUSE Edge 3.5 a SUSE Edge 3.6.0.

Important
Important

Realice siempre las migraciones de clúster desde la latest Z-stream release de SUSE Edge 3.5.

Migre siempre a la SUSE Edge 3.6.0 release. Para actualizaciones posteriores a la migración, consulte las management (Chapter 32, Clúster de gestión) y clúster en sentido descendente (Chapter 33, Clústeres en sentido descendente) secciones.

La siguiente tabla enumera los diferentes tipos de clústeres y los métodos para actualizarlos:

Table 31.1: Clústeres y métodos para actualizar clústeres en sentido descendente
 
Tipo de clústerMétodo

Clústeres aprovisionados por EIB

Consulte el Section 31.1.3, “Fleet” para obtener más información.

Clústeres aprovisionados por Phone-home

Consulte Actualización de la versión de Kubernetes para la actualización de la versión de Kubernetes y Clústeres en sentido descendente (Chapter 33, Clústeres en sentido descendente) para SUC, el sistema operativo y otros componentes.

31.1 Clúster de gestión

 

Esta sección cubre los temas siguientes:

Section 31.1.1, “Requisitos previos” - pasos previos necesarios antes de comenzar la migración.

Section 31.1.2, “Upgrade Controller” - cómo realizar una migración de clúster management utilizando Chapter 19, Controlador de actualización.

Section 31.1.3, “Fleet” - cómo realizar una migración de clúster management utilizando Chapter 6, Fleet.

31.1.1 Requisitos previos

 

31.1.1.1 Migrar la configuración del certificado de CA de Metal3

 
Note
Note

Se aplica solo a las implementaciones de Metal3 que utilizan CA de confianza adicionales para servidores de medios externos con TLS.

El gráfico de Helm de Metal3 ha cambiado la forma en que se configuran los certificados de CA de confianza. Anteriormente, las CA adicionales se proporcionaban a través de un Secret (tls-ca-additional) con el indicador booleano additionalTrustedCAs. La nueva versión utiliza un ConfigMap que contiene el paquete de CA completo al que hace referencia el valor global.trustedCAs.

Si ha configurado CA de confianza adicionales para Metal3, debe migrar del enfoque basado en Secret al enfoque basado en ConfigMap:

  1. Cree un ConfigMap que contenga su paquete de CA a partir del Secret existente:

    Extraiga los certificados del Secret antiguo:

    kubectl get secret tls-ca-additional -n metal3-system -o jsonpath='{.data}' | \
  jq -r 'to_entries[] | .value' | base64 -d > ca-bundle.pem

    Opcional: incluya el paquete de CA del sistema: Si el despliegue de Metal3 también necesita confiar en CA públicas (por ejemplo, al acceder a recursos externos a través de HTTPS), debe incluir el paquete de CA del sistema además de sus CA personalizadas. Extraiga el paquete de CA del sistema de una imagen de contenedor y antepóngalo a sus CA personalizadas:

    # Extract system CAs from a container image (using podman or docker)
podman run --rm registry.suse.com/bci/bci-base:latest cat /etc/ssl/certs/ca-certificates.crt > system-cas.pem

# Combine system CAs with your custom CAs
cat system-cas.pem ca-bundle.pem > combined-ca-bundle.pem
mv combined-ca-bundle.pem ca-bundle.pem
    Important
    Important

    Si incluye el paquete de CA del sistema, es su responsabilidad mantenerlo actualizado. Los certificados de CA del sistema en la imagen de contenedor pueden quedar obsoletos con el tiempo a medida que los certificados de CA caducan o son revocados. Debe actualizar periódicamente el paquete de CA del sistema volviéndolo a extraer de una imagen de contenedor actualizada.

    Cree el ConfigMap con el paquete de CA final:

    kubectl create configmap tls-ca-bundle -n metal3-system --from-file=ca-bundle.pem=ca-bundle.pem

  2. Actualice los valores de Helm de Metal3 para utilizar la nueva referencia de ConfigMap:

    Cambie de:

    global:
  additionalTrustedCAs: true

    A:

    global:
  trustedCAs: tls-ca-bundle

  3. Tras actualizar el gráfico de Helm de Metal3 con la nueva configuración, puede eliminar el Secret antiguo:

    kubectl delete secret tls-ca-additional -n metal3-system

31.1.2 Upgrade Controller

 
Important
Important

Upgrade Controller actualmente solo admite migraciones de versiones de SUSE Edge para clústeres de gestión no en entorno aislado.

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

Section 31.1.2.1, “Requisitos previos”: requisitos previos específicos para Upgrade Controller.

Section 31.1.2.2, “Pasos de migración”: pasos para migrar un clúster management a una nueva versión de SUSE Edge utilizando Upgrade Controller.

31.1.2.1 Requisitos previos

 
31.1.2.1.1 SUSE Edge 3.6 Upgrade Controller
 

Antes de utilizar Upgrade Controller, debe asegurarse primero de que está ejecutando una versión capaz de migrar a la versión de SUSE Edge deseada.

Para realizar esta operación:

  1. Si ya tiene Upgrade Controller desplegado desde una versión de SUSE Edge anterior, actualice su gráfico:

    helm upgrade upgrade-controller -n upgrade-controller-system oci://registry.suse.com/edge/charts/upgrade-controller --version 306.0.4+up0.1.3

  2. Si no tiene Upgrade Controller desplegado, siga Section 19.3, “Instalación del Controlador de actualización”.

31.1.2.2 Pasos de migración

 

Realizar una migración de clúster management con Upgrade Controller es fundamentalmente similar a ejecutar una actualización.

La única diferencia es que su UpgradePlan debe especificar la versión de lanzamiento 3.6.0:

apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
  # Change to the namespace of your Upgrade Controller
  namespace: CHANGE_ME
spec:
  releaseVersion: 3.6.0

Para obtener información sobre cómo utilizar el UpgradePlan anterior para realizar una migración, consulte el proceso de actualización del Upgrade Controller (Section 32.1, “Upgrade Controller”).

31.1.3 Fleet

 
Note
Note

Siempre que sea posible, utilice Section 31.1.2, “Upgrade Controller” para la migración.

Consulte esta sección solo para casos de uso no cubiertos por Upgrade Controller.

Realizar una migración de clúster management con Fleet es fundamentalmente similar a ejecutar una actualización.

Las diferencias clave son que:

  1. Las flotas deben utilizarse desde la versión release-3.6.0 del repositorio suse-edge/fleet-examples.

  2. Los gráficos programados para una actualización deben actualizarse a versiones compatibles con la versión SUSE Edge 3.6.0. Para obtener una lista de los componentes SUSE Edge 3.6.0, consulte Section 41.4, “Versión 3.6.0”.

Important
Important

Para garantizar una migración SUSE Edge 3.6.0 correcta, es importante que los usuarios cumplan los puntos indicados anteriormente.

Teniendo en cuenta los puntos anteriores, los usuarios pueden seguir la documentación de Fleet (Section 32.2, “Fleet”) del management clúster para obtener una guía completa sobre los pasos necesarios para realizar una migración.

31.2 Clústeres descendentes

 

Section 31.2.1, “Fleet” - cómo realizar una migración de clúster downstream utilizando Chapter 6, Fleet.

31.2.1 Fleet

 

Realizar una migración de clúster downstream con Fleet es fundamentalmente similar a ejecutar una actualización.

Las diferencias clave son que:

  1. Las flotas deben utilizarse desde la versión release-3.6.0 del repositorio suse-edge/fleet-examples.

  2. Los gráficos programados para una actualización deben actualizarse a versiones compatibles con la versión SUSE Edge 3.6.0. Para obtener una lista de los componentes SUSE Edge 3.6.0, consulte Section 41.4, “Versión 3.6.0”.

Important
Important

Para garantizar una migración SUSE Edge 3.6.0 correcta, es importante que los usuarios cumplan los puntos indicados anteriormente.

Teniendo en cuenta los puntos anteriores, los usuarios pueden seguir la documentación de Fleet (Section 33.1, “Fleet”) del downstream clúster para obtener una guía completa sobre los pasos necesarios para realizar una migración.