|Index|SUSE Edge Documentação|Operações do Dia 2|Migração Edge 3.6
Applies to SUSE Edge 3.6

31 Migração Edge 3.6

 

Esta seção explica como migrar seus clusters management e downstream de SUSE Edge 3.5 para SUSE Edge 3.6.0.

Important
Important

Sempre realize migrações de cluster a partir da latest Z-stream release do SUSE Edge 3.5.

Sempre migre para a SUSE Edge 3.6.0 release. Para upgrades pós-migração subsequentes, consulte as management (Chapter 32, Cluster de gerenciamento) e cluster downstream (Chapter 33, Downstream clusters) seções.

A tabela a seguir lista os diferentes tipos de clusters e os métodos para fazer upgrade dos clusters:

Table 31.1: Clusters e métodos para fazer upgrade de clusters downstream
 
Tipo de clusterMétodo

Clusters provisionados por EIB

Consulte Section 31.1.3, “Fleet” para obter os detalhes.

Clusters provisionados por phone-home

Consulte Atualizando a versão do Kubernetes para fazer upgrade da versão do Kubernetes e Clusters downstream (Chapter 33, Downstream clusters) para SUC, sistema operacional e outros componentes.

31.1 Cluster de gerenciamento

 

Esta seção abrange os seguintes tópicos:

Section 31.1.1, “Pré-requisitos” - etapas de pré-requisito a serem concluídas antes de iniciar a migração.

Section 31.1.2, “Upgrade Controller” - como fazer uma migração de cluster management usando o Chapter 19, Upgrade Controller.

Section 31.1.3, “Fleet” - como fazer uma migração de cluster management usando Chapter 6, Fleet.

31.1.1 Pré-requisitos

 

31.1.1.1 Migrar a configuração do certificado de CA do Metal3

 
Note
Note

Aplica-se apenas a implantações do Metal3 que usam CAs confiáveis adicionais para servidores de mídia externos com TLS.

O gráfico Helm do Metal3 mudou a forma como os certificados de CA confiáveis são configurados. Anteriormente, as CAs adicionais eram fornecidas por meio de um Secret (tls-ca-additional) com o sinalizador booleano additionalTrustedCAs. A nova versão usa um ConfigMap contendo o pacote de CA completo referenciado pelo valor global.trustedCAs.

Se você configurou CAs confiáveis adicionais para o Metal3, você precisa migrar da abordagem baseada em Secret para a abordagem baseada em ConfigMap:

  1. Crie um ConfigMap contendo seu pacote de CA a partir do Secret existente:

    Extraia os certificados do Secret antigo:

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

    Opcional - Inclua o pacote de CA do sistema: Se sua implantação do Metal3 também precisar confiar em CAs públicas (por exemplo, ao acessar recursos externos via HTTPS), você precisará incluir o pacote de CA do sistema além de suas CAs personalizadas. Extraia o pacote de CA do sistema de uma imagem de contêiner e adicione-o antes de suas CAs 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

    Se você incluir o pacote de CA do sistema, torna-se sua responsabilidade mantê-lo atualizado. As CAs do sistema na imagem do contêiner podem ficar obsoletas com o tempo, à medida que os certificados de CA expiram ou são revogados. Você deve atualizar periodicamente o pacote de CA do sistema extraindo-o novamente de uma imagem de contêiner atualizada.

    Crie o ConfigMap com o pacote de CA final:

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

  2. Atualize seus valores de Helm do Metal3 para usar a nova referência do ConfigMap:

    Altere de:

    global:
  additionalTrustedCAs: true

    Para:

    global:
  trustedCAs: tls-ca-bundle

  3. Após atualizar o gráfico Helm do Metal3 com a nova configuração, você pode excluir o Secret antigo:

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

31.1.2 Upgrade Controller

 
Important
Important

O Upgrade Controller atualmente suporta migrações de versão SUSE Edge apenas para clusters de gerenciamento que não são air-gapped.

Os tópicos a seguir são abordados como parte desta seção:

Section 31.1.2.1, “Pré-requisitos” - pré-requisitos específicos para o Upgrade Controller.

Section 31.1.2.2, “Etapas de migração” - etapas para migrar um cluster management para uma nova versão SUSE Edge usando o Upgrade Controller.

31.1.2.1 Pré-requisitos

 
31.1.2.1.1 SUSE Edge 3.6 Upgrade Controller
 

Antes de usar o Upgrade Controller, você deve primeiro garantir que ele esteja executando uma versão capaz de migrar para a versão SUSE Edge desejada.

Para fazer isso:

  1. Se você já tiver o Upgrade Controller implantado a partir de uma versão SUSE Edge anterior, atualize seu 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. Se você não tiver Upgrade Controller implantado, siga Section 19.3, “Instalando o Upgrade Controller”.

31.1.2.2 Etapas de migração

 

Realizar uma migração de cluster management com o Upgrade Controller é fundamentalmente semelhante à execução de um upgrade.

A única diferença é que seu UpgradePlan deve especificar a versão de lançamento 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 obter informações sobre como usar o UpgradePlan acima para realizar uma migração, consulte processo de upgrade do Upgrade Controller (Section 32.1, “Upgrade Controller”).

31.1.3 Fleet

 
Note
Note

Sempre que possível, use o Section 31.1.2, “Upgrade Controller” para migração.

Consulte esta seção apenas para casos de uso não cobertos pelo Upgrade Controller.

Realizar uma migração de cluster management com Fleet é fundamentalmente semelhante à execução de um upgrade.

As principais diferenças são:

  1. As frotas devem ser usadas a partir da versão release-3.6.0 do repositório suse-edge/fleet-examples.

  2. Os gráficos agendados para um upgrade devem ser atualizados para versões compatíveis com a versão SUSE Edge 3.6.0. Para obter uma lista dos componentes SUSE Edge 3.6.0, consulte Section 41.4, “Release 3.6.0”.

Important
Important

Para garantir uma migração SUSE Edge 3.6.0 bem-sucedida, é importante que os usuários cumpram os pontos descritos acima.

Considerando os pontos acima, os usuários podem seguir a documentação do Fleet (Section 32.2, “Fleet”) do cluster management para obter um guia abrangente sobre as etapas necessárias para realizar uma migração.

31.2 Clusters downstream

 

Section 31.2.1, “Fleet” - como fazer uma migração de cluster downstream usando Chapter 6, Fleet.

31.2.1 Fleet

 

Realizar uma migração de cluster downstream com Fleet é fundamentalmente semelhante à execução de um upgrade.

As principais diferenças são:

  1. As Fleet devem ser usadas a partir da versão release-3.6.0 do repositório suse-edge/fleet-examples.

  2. Os gráficos agendados para um upgrade devem ser atualizados para versões compatíveis com a versão SUSE Edge 3.6.0. Para obter uma lista dos componentes SUSE Edge 3.6.0, consulte Section 41.4, “Release 3.6.0”.

Important
Important

Para garantir uma migração SUSE Edge 3.6.0 bem-sucedida, é importante que os usuários cumpram os pontos descritos acima.

Considerando os pontos acima, os usuários podem seguir a documentação do Fleet (Section 33.1, “Fleet”) do cluster downstream para obter um guia abrangente sobre as etapas necessárias para realizar uma migração.