Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

10.4. Préoccupations et problèmes courants

Cette section décrit les préoccupations et problèmes courants qui peuvent entraîner des problèmes au cours de la migration.

10.4.1. La migration directe des volumes ne se termine pas
Copier lien

Si la migration directe des volumes ne se termine pas, il se peut que le cluster cible n’ait pas les mêmes annotations node-selector que le cluster source.

Migration Toolkit for Containers (MTC) fait migrer les espaces de nommage avec toutes les annotations afin de conserver les contraintes du contexte de sécurité et les exigences en termes de planification. Pendant la migration directe des volumes, MTC crée des pods de transfert Rsync sur le cluster cible dans les espaces de nommage qui ont été migrés depuis le cluster source. Si un espace de nommage de cluster cible ne possède pas les mêmes annotations que l’espace de nommage de cluster source, les pods de transfert Rsync ne peuvent pas être planifiés. Les pods Rsync restent dans l’état Pending.

Vous pouvez identifier et corriger ce problème en procédant comme suit.

Procédure

  1. Vérifiez l’état de la CR MigMigration : 

    $ oc describe migmigration <pod> -n openshift-migration

    La sortie comprend le message d’état suivant :

    Exemple de sortie

    Some or all transfer pods are not running for more than 10 mins on destination cluster

  2. Sur le cluster source, procurez-vous les détails d’un espace de nommage migré : 

    $ oc get namespace <namespace> -o yaml
    1
    1
    Indiquez l’espace de nommage migré.

  3. Sur le cluster cible, modifiez l’espace de nommage migré : 

    $ oc edit namespace <namespace>

  4. Ajoutez les annotations openshift.io/node-selector manquantes à l’espace de nommage migré comme dans l’exemple suivant : 

    apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: "region=east"
...
  5. Exécutez à nouveau le plan de migration.

10.4.2. Messages d’erreur et résolutions
Copier lien

Cette section décrit les messages d’erreur courants que vous pouvez rencontrer avec Migration Toolkit for Containers (MTC), ainsi que la façon de résoudre les causes sous-jacentes.

Si un message CA certificate error s’affiche la première fois que vous essayez d’accéder à la console MTC, cela est probablement dû à l’utilisation de certificats CA auto-signés dans l’un des clusters.

Pour résoudre ce problème, accédez à l’URL oauth-authorization-server affichée dans le message d’erreur et acceptez le certificat. Pour résoudre ce problème de façon permanente, ajoutez le certificat au magasin de confiance de votre navigateur Web.

Si un message Unauthorized s’affiche après l’acceptation du certificat, accédez à la console MTC et actualisez la page Web.

10.4.2.2. Erreur de timeout OAuth dans la console MTC
Copier lien

Si un message connection has timed out s’affiche dans la console MTC après l’acceptation d’un certificat auto-signé, les causes sont probablement les suivantes :

  • Interruption de l’accès réseau au serveur OAuth
  • Interruption de l’accès réseau à la console OpenShift Container Platform
  • Configuration du proxy qui bloque l’accès à l’URL oauth-authorization-server. Pour plus d’informations, reportez-vous à l’article MTC console inaccessible because of OAuth timeout error (Console MTC inaccessible en raison d’une erreur de timeout OAuth).

Pour déterminer la cause du timeout :

  • Examinez la page Web de la console MTC à l’aide de l’inspecteur Web d’un navigateur.
  • Recherchez des erreurs dans le journal du pod Migration UI.

Si vous utilisez un certificat auto-signé pour sécuriser un cluster ou un référentiel de réplication pour Migration Toolkit for Containers (MTC), il se peut que la vérification du certificat échoue avec le message d’erreur suivant : Certificate signed by unknown authority.

Vous pouvez créer un fichier de regroupement de certificats CA personnalisé et l’envoyer dans la console Web MTC lorsque vous ajoutez un cluster ou un référentiel de réplication.

Procédure

Téléchargez un certificat CA à partir d’un point d’accès distant et enregistrez-le en tant que fichier de regroupement CA : 

$ echo -n | openssl s_client -connect <host_FQDN>:<port> \
1 

  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert>
2
1
Indiquez le nom de domaine complet (FQDN) de l’hôte et le port du point d’accès ; api.mon-cluster.example.com:6443, par exemple.
2
Indiquez le nom du fichier de regroupement CA.

Si une ressource personnalisée Velero Backup contient une référence à un emplacement de stockage de sauvegarde qui n’existe pas, il se peut que le journal du pod Velero affiche les messages d’erreur suivants : 

$ oc logs <Velero_Pod> -n openshift-migration

Exemple de sortie

level=error msg="Error checking repository for stale locks" error="error getting backup storage location: BackupStorageLocation.velero.io \"ts-dpa-1\" not found" error.file="/remote-source/src/github.com/vmware-tanzu/velero/pkg/restic/repository_manager.go:259"

Vous pouvez ignorer ces messages d’erreur. Un emplacement de stockage de sauvegarde manquant ne peut pas faire échouer une migration.

Si une migration échoue en raison d’un timeout de Restic, l’erreur suivante est affichée dans le journal du pod Velero. 

level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete" error.file="/go/src/github.com/heptio/velero/pkg/restic/backupper.go:165" error.function="github.com/heptio/velero/pkg/restic.(*backupper).BackupPodVolumes" group=v1

La valeur par défaut de restic_timeout est d’une heure. Vous pouvez augmenter ce paramètre pour les migrations de grande envergure, en gardant à l’esprit qu’une valeur plus élevée peut retarder le renvoi de messages d’erreur.

Procédure

  1. Dans la console Web OpenShift Container Platform, accédez à Operators Installed Operators.
  2. Cliquez sur Migration Toolkit for Containers Operator.
  3. Dans l’onglet MigrationController, cliquez sur migration-controller.

  4. Dans l’onglet YAML, mettez à jour la valeur du paramètre suivant : 

    spec:
  restic_timeout: 1h
    1
    1
    Les unités valides sont h (heures), m (minutes) et s (secondes) ; 3h30m15s, par exemple.
  5. Cliquez sur Save.

Si la vérification des données échoue lors de la migration d’un volume persistant avec la méthode de copie des données du système de fichiers, l’erreur suivante s’affiche dans la CR MigMigration.

Exemple de sortie

status:
  conditions:
  - category: Warn
    durable: true
    lastTransitionTime: 2020-04-16T20:35:16Z
    message: There were verify errors found in 1 Restic volume restores. See restore `<registry-example-migration-rvwcm>`
      for details
1 

    status: "True"
    type: ResticVerifyErrors
2

1
Le message d’erreur identifie le nom de la CR Restore.
2
ResticVerifyErrors est un type d’avertissement d’erreur général qui inclut les erreurs de vérification.
Note

Une erreur de vérification des données n’entraîne pas l’échec du processus de migration.

Vous pouvez vérifier la CR Restore pour identifier la source de l’erreur de vérification des données.

Procédure

  1. Connectez-vous au cluster cible.

  2. Visualisez la CR Restore : 

    $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

    La sortie identifie le volume persistant avec des erreurs PodVolumeRestore.

    Exemple de sortie

    status:
  phase: Completed
  podVolumeRestoreErrors:
  - kind: PodVolumeRestore
    name: <registry-example-migration-rvwcm-98t49>
    namespace: openshift-migration
  podVolumeRestoreResticErrors:
  - kind: PodVolumeRestore
    name: <registry-example-migration-rvwcm-98t49>
    namespace: openshift-migration

  3. Affichez la CR PodVolumeRestore : 

    $ oc describe <migration-example-rvwcm-98t49>

    La sortie identifie le pod Restic qui a enregistré les erreurs.

    Exemple de sortie

      completionTimestamp: 2020-05-01T20:49:12Z
  errors: 1
  resticErrors: 1
  ...
  resticPod: <restic-nr2v5>

  4. Consultez le journal du pod Restic pour localiser les erreurs : 

    $ oc logs -f <restic-nr2v5>

Si vous migrez des données à partir d’un stockage NFS et que la fonction root_squash est activée, Restic est mappé sur nfsnobody et n’a pas l’autorisation d’effectuer la migration. L’erreur suivante est affichée dans le journal du pod Restic.

Exemple de sortie

backup=openshift-migration/<backup_id> controller=pod-volume-backup error="fork/exec /usr/bin/restic: permission denied" error.file="/go/src/github.com/vmware-tanzu/velero/pkg/controller/pod_volume_backup_controller.go:280" error.function="github.com/vmware-tanzu/velero/pkg/controller.(*podVolumeBackupController).processBackup" logSource="pkg/controller/pod_volume_backup_controller.go:280" name=<backup_id> namespace=openshift-migration

Vous pouvez résoudre ce problème en créant un groupe supplémentaire pour Restic et en ajoutant l’ID du groupe au manifeste de CR MigrationController.

Procédure

  1. Créez un groupe supplémentaire pour Restic sur le stockage NFS.
  2. Définissez le bit setgid sur les répertoires NFS afin que la propriété du groupe soit héritée.

  3. Ajoutez le paramètre restic_supplemental_groups au manifeste de CR MigrationController sur les clusters source et cible : 

    spec:
  restic_supplemental_groups: <group_id>
    1
    1
    Indiquez l’ID du groupe supplémentaire.
  4. Attendez que les pods Restic redémarrent pour que les modifications soient appliquées.
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début