Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

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

12.4.1. Mise à jour d’images internes obsolètes
Copier lien

Si votre application utilise des images de l’espace de nommage openshift, les versions requises des images doivent être présentes sur le cluster cible.

Si une image OpenShift Container Platform 3 est dépréciée dans OpenShift Container Platform 4.12, vous pouvez mettre à jour manuellement la balise de flux d'image en utilisant podman.

Conditions préalables

  • Il faut que podman soit installé.
  • Vous devez être connecté en tant qu’utilisateur avec les privilèges cluster-admin.
  • Si vous utilisez des registres non sécurisés, ajoutez vos valeurs d’hôte de registre à la section [registries.insecure] du fichier /etc/container/registries.conf pour vous assurer que podman ne rencontre pas d’erreur de vérification TLS.
  • Les registres internes doivent être exposés sur les clusters source et cible.

Procédure

  1. Assurez-vous que les registres internes sont exposés sur les clusters OpenShift Container Platform 3 et 4.

    Le registre d'images OpenShift est exposé par défaut sur OpenShift Container Platform 4.

  2. Si vous utilisez des registres non sécurisés, ajoutez vos valeurs d’hôte de registre à la section [registries.insecure] du fichier /etc/container/registries.conf pour vous assurer que podman ne rencontre pas d’erreur de vérification TLS.

  3. Connectez-vous au registre OpenShift Container Platform 3 : 

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
    Copy to Clipboard Toggle word wrap

  4. Connectez-vous au registre OpenShift Container Platform 4 : 

    $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <registry_url>:<port>
    Copy to Clipboard Toggle word wrap

  5. Extrayez l’image OpenShift Container Platform 3 : 

    $ podman pull <registry_url>:<port>/openshift/<image>
    Copy to Clipboard Toggle word wrap

  6. Balisez l’image OpenShift Container Platform 3 pour le registre OpenShift Container Platform 4 : 

    $ podman tag <registry_url>:<port>/openshift/<image> \
    1 
    
  <registry_url>:<port>/openshift/<image>
    2
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’URL et le port du registre pour le cluster OpenShift Container Platform 3.
    2
    Indiquez l’URL et le port du registre pour le cluster OpenShift Container Platform 4.

  7. Poussez l’image vers le registre OpenShift Container Platform 4 : 

    $ podman push <registry_url>:<port>/openshift/<image>
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le cluster OpenShift Container Platform 4.

  8. Vérifiez que le flux de l’image est valide : 

    $ oc get imagestream -n openshift | grep <image>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME      IMAGE REPOSITORY                                                      TAGS    UPDATED
my_image  image-registry.openshift-image-registry.svc:5000/openshift/my_image  latest  32 seconds ago
    Copy to Clipboard Toggle word wrap

12.4.2. 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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

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

    $ oc get namespace <namespace> -o yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’espace de nommage migré.

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

    $ oc edit namespace <namespace>
    Copy to Clipboard Toggle word wrap

  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"
...
    Copy to Clipboard Toggle word wrap
  5. Exécutez à nouveau le plan de migration.

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

12.4.3.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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
    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
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

  3. Affichez la CR PodVolumeRestore : 

    $ oc describe <migration-example-rvwcm-98t49>
    Copy to Clipboard Toggle word wrap

    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>
    Copy to Clipboard Toggle word wrap

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

    $ oc logs -f <restic-nr2v5>
    Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’ID du groupe supplémentaire.
  4. Attendez que les pods Restic redémarrent pour que les modifications soient appliquées.

12.4.4. Problèmes connus
Copier lien

Cette version présente les problèmes connus suivants :

  • Pendant la migration, Migration Toolkit for Containers (MTC) conserve les annotations d’espace de nommage suivantes :

    • openshift.io/sa.scc.mcs
    • openshift.io/sa.scc.supplemental-groups

    • openshift.io/sa.scc.uid-range

      Ces annotations conservent la plage d’UID. De cette façon, vous avez la garantie que les conteneurs conservent leurs autorisations de système de fichiers sur le cluster cible. Il existe un risque que les UID migrés fassent double emploi avec les UID d’un espace de nommage existant ou futur sur le cluster cible. (BZ#1748440)

  • La plupart des ressources délimitées par le cluster ne sont pas encore gérées par MTC. Si vos applications nécessitent des ressources de ce type, vous devrez peut-être les créer manuellement sur le cluster cible.
  • En cas d’échec d’une migration, le plan de migration ne conserve pas les paramètres de PV personnalisés pour les pods suspendus. Vous devez annuler manuellement la migration, supprimer le plan de migration et en créer un nouveau avec vos paramètres de PV. (BZ#1784899)
  • Si une migration de grande envergure échoue en raison d’un timeout de Restic, vous pouvez augmenter la valeur du paramètre restic_timeout (par défaut : 1h) dans le manifeste de la ressource personnalisée (CR) MigrationController.
  • Si vous sélectionnez l’option de vérification des données pour les volumes persistants (PV) qui sont migrés avec la méthode de copie du système de fichiers, vous constaterez une diminution sensible des performances.

  • 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. La migration échoue et une erreur d’autorisation est affichée dans le journal du pod Restic. (BZ#1873641)

    Vous pouvez résoudre ce problème en ajoutant des groupes supplémentaires pour Restic au manifeste de CR MigrationController: 

    spec:
...
  restic_supplemental_groups:
  - 5555
  - 6666
    Copy to Clipboard Toggle word wrap
  • Si vous effectuez une migration directe des volumes avec des nœuds qui se trouvent dans des zones ou des ensembles de disponibilité différents, la migration risque d’échouer, car les pods migrés ne peuvent pas accéder à la PVC. (BZ#1947487)
Retour au début
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 Hat