Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

11.3. Migration d’applications à l’aide de la ligne de commande

Vous pouvez migrer des applications avec l’API MTC en utilisant l’interface de ligne de commande (CLI) afin d’automatiser la migration.

11.3.1. Conditions préalables à la migration
Copier lien

  • Vous devez être connecté en tant qu’utilisateur avec les privilèges cluster-admin sur tous les clusters.

Migration directe des images

  • Vous devez vous assurer que le registre d'images OpenShift sécurisé du cluster source est exposé.
  • Vous devez créer une route vers le registre exposé.

Migration directe des volumes

  • Si vos clusters utilisent des proxies, vous devez configurer un proxy TCP Stunnel.

Images internes

  • Si votre application utilise des images internes de l’espace de nommage openshift, vous devez vous assurer que les versions requises des images sont présentes sur le cluster cible.

    Vous pouvez mettre à jour manuellement une balise de flux d'images afin d'utiliser une image OpenShift Container Platform 3 dépréciée sur un cluster OpenShift Container Platform 4.12.

Clusters

  • Le cluster source doit être mis à niveau vers la dernière version de MTC z-stream.
  • La version de MTC doit être la même sur tous les clusters.

Réseau

  • Les clusters disposent d’un accès réseau illimité entre eux et au référentiel de réplication.
  • Si vous copiez les volumes persistants avec move, les clusters doivent disposer d’un accès réseau illimité aux volumes distants.

  • Vous devez activer les ports suivants sur un cluster OpenShift Container Platform 3 :

    • 8443 (serveur d’API)
    • 443 (routes)
    • 53 (DNS)

  • Vous devez activer les ports suivants sur un cluster OpenShift Container Platform 4 :

    • 6443 (serveur d’API)
    • 443 (routes)
    • 53 (DNS)
  • Vous devez activer le port 443 sur le référentiel de réplication si vous utilisez le protocole TLS.

Volumes persistants (PV)

  • Les volumes persistants doivent être valides.
  • Les volumes persistants doivent être liés à des revendications de volumes persistants.

  • Si vous utilisez des clichés pour copier les PV, des conditions préalables supplémentaires s’appliquent :

    • Le fournisseur de services en nuage doit prendre en charge les instantanés.
    • Les PV doivent avoir le même fournisseur de cloud.
    • Les PV doivent se trouver dans la même région géographique.
    • Les PV doivent avoir la même classe de stockage.

Pour la migration directe d'images, vous devez créer une route vers le registre d'images OpenShift exposé sur tous les clusters distants.

Conditions préalables

  • Le registre d'images OpenShift doit être exposé au trafic externe sur tous les clusters distants.

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

    Le registre OpenShift Container Platform 3 doit être exposé manuellement.

Procédure

  • Pour créer une route vers un registre OpenShift Container Platform 3, exécutez la commande suivante : 

    $ oc create route passthrough --service=docker-registry -n default
    Copy to Clipboard Toggle word wrap

  • Pour créer une route vers un registre OpenShift Container Platform 4, exécutez la commande suivante : 

    $ oc create route passthrough --service=image-registry -n openshift-image-registry
    Copy to Clipboard Toggle word wrap

11.3.3. Configuration du proxy
Copier lien

Dans le cas d’OpenShift Container Platform 4.1 et versions antérieures, vous devez configurer les proxies dans le manifeste de la ressource personnalisée (CR) MigrationController après avoir installé l’opérateur Migration Toolkit for Containers, car ces versions ne prennent pas en charge un objet proxy à l’échelle du cluster.

Pour OpenShift Container Platform 4.2 à 4.12, le Migration Toolkit for Containers (MTC) hérite des paramètres de proxy à l'échelle du cluster. Vous pouvez modifier les paramètres du proxy si vous souhaitez remplacer les paramètres du proxy à l'échelle du cluster.

11.3.3.1. Migration directe des volumes
Copier lien

La migration directe des volumes (DVM) a été introduite dans MTC 1.4.2. DVM ne prend en charge qu'un seul proxy. Le cluster source ne peut pas accéder à la route du cluster cible si ce dernier se trouve également derrière un proxy.

Si vous souhaitez effectuer un DVM à partir d'un cluster source situé derrière un proxy, vous devez configurer un proxy TCP qui fonctionne au niveau de la couche transport et transmet les connexions SSL de manière transparente sans les décrypter et les recrypter à l'aide de leurs propres certificats SSL. Un proxy Stunnel est un exemple de ce type de proxy.

11.3.3.1.1. Configuration du proxy TCP pour le DVM
Copier lien

Vous pouvez établir une connexion directe entre le cluster source et le cluster cible via un proxy TCP et configurer la variable stunnel_tcp_proxy dans le CR MigrationController pour utiliser le proxy : 

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  stunnel_tcp_proxy: http://username:password@ip:port
Copy to Clipboard Toggle word wrap

La migration directe de volume (DVM) ne prend en charge que l'authentification de base pour le proxy. En outre, la DVM ne fonctionne que derrière des proxys qui peuvent tunneliser une connexion TCP de manière transparente. Les mandataires HTTP/HTTPS en mode man-in-the-middle ne fonctionnent pas. Les proxys existants à l'échelle du cluster peuvent ne pas prendre en charge ce comportement. Par conséquent, les paramètres du proxy pour DVM sont intentionnellement différents de la configuration habituelle du proxy dans MTC.

Vous pouvez activer DVM en exécutant Rsync entre le cluster source et le cluster cible via une route OpenShift. Le trafic est chiffré à l'aide de Stunnel, un proxy TCP. Le Stunnel fonctionnant sur le cluster source initie une connexion TLS avec le Stunnel cible et transfère les données sur un canal crypté.

Les proxys HTTP/HTTPS à l'échelle du cluster dans OpenShift sont généralement configurés en mode man-in-the-middle où ils négocient leur propre session TLS avec les serveurs extérieurs. Cependant, cela ne fonctionne pas avec Stunnel. Stunnel exige que sa session TLS ne soit pas modifiée par le proxy, faisant essentiellement du proxy un tunnel transparent qui transmet simplement la connexion TCP telle quelle. Vous devez donc utiliser un proxy TCP.

11.3.3.1.3. Problème connu
Copier lien

La migration échoue avec l'erreur Upgrade request required

Le contrôleur de migration utilise le protocole SPDY pour exécuter des commandes dans des modules distants. Si le cluster distant se trouve derrière un proxy ou un pare-feu qui ne prend pas en charge le protocole SPDY, le contrôleur de migration ne parvient pas à exécuter les commandes à distance. La migration échoue avec le message d'erreur Upgrade request required. Solution : Utilisez un proxy qui prend en charge le protocole SPDY.

Outre la prise en charge du protocole SPDY, le proxy ou le pare-feu doit également transmettre l'en-tête HTTP Upgrade au serveur API. Le client utilise cet en-tête pour ouvrir une connexion websocket avec le serveur API. Si l'en-tête Upgrade est bloqué par le proxy ou le pare-feu, la migration échoue avec le message d'erreur Upgrade request required. Solution : Assurez-vous que le proxy transmet l'en-tête Upgrade.

OpenShift prend en charge la restriction du trafic vers ou depuis les pods à l'aide de NetworkPolicy ou EgressFirewalls en fonction du plugin réseau utilisé par le cluster. Si l'un des espaces de noms source impliqués dans une migration utilise de tels mécanismes pour restreindre le trafic réseau vers les pods, les restrictions peuvent par inadvertance arrêter le trafic vers les pods Rsync pendant la migration.

Les pods Rsync fonctionnant sur les clusters source et cible doivent se connecter l'un à l'autre via une route OpenShift. Les objets NetworkPolicy ou EgressNetworkPolicy existants peuvent être configurés pour exempter automatiquement les pods Rsync de ces restrictions de trafic.

11.3.3.2.1. Configuration de la politique de réseau
Copier lien
11.3.3.2.1.1. Trafic de sortie des pods Rsync
Copier lien

Vous pouvez utiliser les étiquettes uniques des modules Rsync pour autoriser le trafic sortant de ces modules si la configuration de NetworkPolicy dans les espaces de noms source ou destination bloque ce type de trafic. La stratégie suivante autorise le trafic de sortie all à partir des modules Rsync dans l'espace de noms : 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress-from-rsync-pods
spec:
  podSelector:
    matchLabels:
      owner: directvolumemigration
      app: directvolumemigration-rsync-transfer
  egress:
  - {}
  policyTypes:
  - Egress
Copy to Clipboard Toggle word wrap
11.3.3.2.1.2. Trafic entrant vers les pods Rsync
Copier lien
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress-from-rsync-pods
spec:
  podSelector:
    matchLabels:
      owner: directvolumemigration
      app: directvolumemigration-rsync-transfer
  ingress:
  - {}
  policyTypes:
  - Ingress
Copy to Clipboard Toggle word wrap

L'objet EgressNetworkPolicy ou Egress Firewalls sont des constructions OpenShift conçues pour bloquer le trafic de sortie du cluster.

Contrairement à l'objet NetworkPolicy, le pare-feu Egress fonctionne au niveau du projet car il s'applique à tous les modules de l'espace de noms. Par conséquent, les étiquettes uniques des pods Rsync n'exemptent pas uniquement les pods Rsync des restrictions. Cependant, vous pouvez ajouter les plages CIDR du cluster source ou cible à la règle Allow de la politique afin qu'une connexion directe puisse être établie entre deux clusters.

En fonction du cluster dans lequel le pare-feu de sortie est présent, vous pouvez ajouter la plage CIDR de l'autre cluster pour autoriser le trafic de sortie entre les deux : 

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: test-egress-policy
  namespace: <namespace>
spec:
  egress:
  - to:
      cidrSelector: <cidr_of_source_or_target_cluster>
    type: Deny
Copy to Clipboard Toggle word wrap

Par défaut, DVM utilise une route OpenShift Container Platform comme point final pour transférer les données PV vers les clusters de destination. Vous pouvez choisir un autre type de point d'extrémité pris en charge, si les topologies de cluster le permettent.

Pour chaque cluster, vous pouvez configurer un point de terminaison en définissant la variable rsync_endpoint_type sur le cluster destination approprié dans votre MigrationController CR : 

apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  rsync_endpoint_type: [NodePort|ClusterIP|Route]
Copy to Clipboard Toggle word wrap

Lorsque vos PVC utilisent un stockage partagé, vous pouvez configurer l'accès à ce stockage en ajoutant des groupes supplémentaires aux définitions de pods Rsync afin que les pods autorisent l'accès :

Expand
Tableau 11.2. Groupes supplémentaires pour les pods Rsync
VariableTypeDéfautDescription

src_supplemental_groups

chaîne de caractères

Non défini

Liste séparée par des virgules des groupes supplémentaires pour les pods Rsync source

target_supplemental_groups

chaîne de caractères

Non défini

Liste de groupes supplémentaires séparés par des virgules pour les pods Rsync cibles

Exemple d'utilisation

Le CR MigrationController peut être mis à jour pour définir les valeurs de ces groupes supplémentaires : 

spec:
  src_supplemental_groups: "1000,2000"
  target_supplemental_groups: "2000,3000"
Copy to Clipboard Toggle word wrap

11.3.3.3. Configuration des proxies
Copier lien

Conditions préalables

  • Vous devez être connecté en tant qu’utilisateur avec les privilèges cluster-admin sur tous les clusters.

Procédure

  1. Procurez-vous le manifeste du CR MigrationController : 

    $ oc get migrationcontroller <migration_controller> -n openshift-migration
    Copy to Clipboard Toggle word wrap

  2. Mettez à jour les paramètres du proxy : 

    apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: <migration_controller>
  namespace: openshift-migration
...
spec:
  stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port>
    1 
    
  noProxy: example.com
    2
    Copy to Clipboard Toggle word wrap
    1
    URL du proxy Stunnel pour la migration directe des volumes.
    2
    Liste, séparée par des virgules, de noms de domaines de destination, de domaines, d’adresses IP ou d’autres CIDR de réseau à exclure de la mise en proxy.

    Faites précéder un domaine du signe . pour ne faire correspondre que les sous-domaines. Par exemple, .y.com correspond à x.y.com, mais pas à y.com. Utilisez * pour ignorer le proxy pour toutes les destinations. Si vous mettez à l’échelle des workers qui ne sont pas inclus dans le réseau défini par le champ networking.machineNetwork[].cidr à partir de la configuration d’installation, vous devez les ajouter à cette liste pour éviter les problèmes de connexion.

    Ce champ est ignoré si ni le champ httpProxy ni le champ httpsProxy ne sont définis.

  3. Enregistrez le manifeste en tant que migration-controller.yaml.

  4. Appliquez le manifeste mis à jour : 

    $ oc replace -f migration-controller.yaml -n openshift-migration
    Copy to Clipboard Toggle word wrap

Vous pouvez migrer une application à partir de la ligne de commande en utilisant l’API Migration Toolkit for Containers (MTC).

Procédure

  1. Créez un manifeste de CR MigCluster pour le cluster hôte : 

    $ cat << EOF | oc apply -f -
apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  name: <host_cluster>
  namespace: openshift-migration
spec:
  isHostCluster: true
EOF
    Copy to Clipboard Toggle word wrap

  2. Créez un manifeste d’objets Secret pour chaque cluster distant : 

    $ cat << EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: <cluster_secret>
  namespace: openshift-config
type: Opaque
data:
  saToken: <sa_token>
    1 
    
EOF
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le token de compte de service (SA) migration-controller codé en base64 du cluster distant. Vous pouvez obtenir le token en exécutant la commande suivante : 
    $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0
    Copy to Clipboard Toggle word wrap

  3. Créez un manifeste de CR MigCluster pour chaque cluster distant : 

    $ cat << EOF | oc apply -f -
apiVersion: migration.openshift.io/v1alpha1
kind: MigCluster
metadata:
  name: <remote_cluster>
    1 
    
  namespace: openshift-migration
spec:
  exposedRegistryPath: <exposed_registry_route>
    2 
    
  insecure: false
    3 
    
  isHostCluster: false
  serviceAccountSecretRef:
    name: <remote_cluster_secret>
    4 
    
    namespace: openshift-config
  url: <remote_cluster_url>
    5 
    
EOF
    Copy to Clipboard Toggle word wrap
    1
    Indiquez la ressource personnalisée Cluster du cluster distant.
    2
    Facultatif : pour la migration directe d’images, indiquez la route de registre exposée.
    3
    La vérification SSL est activée si la valeur est définie sur false. Les certificats CA ne sont pas requis ni vérifiés si la valeur est définie sur true.
    4
    Indiquez l’objet Secret du cluster distant.
    5
    Indiquez l’URL du cluster distant.

  4. Vérifiez que tous les clusters sont dans l’état Ready : 

    $ oc describe cluster <cluster>
    Copy to Clipboard Toggle word wrap

  5. Créez un manifeste d’objets Secret pour le référentiel de réplication : 

    $ cat << EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  namespace: openshift-config
  name: <migstorage_creds>
type: Opaque
data:
  aws-access-key-id: <key_id_base64>
    1 
    
  aws-secret-access-key: <secret_key_base64>
    2 
    
EOF
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’ID de la clé au format base64.
    2
    Indiquez la clé secrète au format base64.

    Les informations d’identification AWS sont codées en base64 par défaut. Pour les autres fournisseurs de stockage, vous devez coder vos informations d’identification en exécutant la commande suivante avec chaque clé : 

    $ echo -n "<key>" | base64 -w 0
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’ID de la clé ou la clé secrète. Les deux clés doivent être codées en base64.

  6. Créez un manifeste de CR MigStorage pour le référentiel de réplication : 

    $ cat << EOF | oc apply -f -
apiVersion: migration.openshift.io/v1alpha1
kind: MigStorage
metadata:
  name: <migstorage>
  namespace: openshift-migration
spec:
  backupStorageConfig:
    awsBucketName: <bucket>
    1 
    
    credsSecretRef:
      name: <storage_secret>
    2 
    
      namespace: openshift-config
  backupStorageProvider: <storage_provider>
    3 
    
  volumeSnapshotConfig:
    credsSecretRef:
      name: <storage_secret>
    4 
    
      namespace: openshift-config
  volumeSnapshotProvider: <storage_provider>
    5 
    
EOF
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le nom du compartiment.
    2
    Indiquez la ressource personnalisée Secrets du stockage d’objets. Vous devez vous assurer que les informations d’identification stockées dans la ressource personnalisée Secrets du stockage d’objets sont correctes.
    3
    Indiquez le fournisseur de stockage.
    4
    Facultatif : si vous copiez des données en utilisant des clichés, indiquez la ressource personnalisée Secrets du stockage d’objets. Vous devez vous assurer que les informations d’identification stockées dans la ressource personnalisée Secrets du stockage d’objets sont correctes.
    5
    Facultatif : si vous copiez des données en utilisant des clichés, indiquez le fournisseur de stockage.

  7. Vérifiez que la ressource personnalisée MigStorage se trouve dans l’état Ready : 

    $ oc describe migstorage <migstorage>
    Copy to Clipboard Toggle word wrap

  8. Créez un manifeste de CR MigPlan : 

    $ cat << EOF | oc apply -f -
apiVersion: migration.openshift.io/v1alpha1
kind: MigPlan
metadata:
  name: <migplan>
  namespace: openshift-migration
spec:
  destMigClusterRef:
    name: <host_cluster>
    namespace: openshift-migration
  indirectImageMigration: true
    1 
    
  indirectVolumeMigration: true
    2 
    
  migStorageRef:
    name: <migstorage>
    3 
    
    namespace: openshift-migration
  namespaces:
    - <source_namespace_1>
    4 
    
    - <source_namespace_2>
    - <source_namespace_3>:<destination_namespace>
    5 
    
  srcMigClusterRef:
    name: <remote_cluster>
    6 
    
    namespace: openshift-migration
EOF
    Copy to Clipboard Toggle word wrap
    1
    La migration directe des images est activée si la valeur est définie sur false.
    2
    La migration directe des volumes est activée si la valeur est définie sur false.
    3
    Indiquez le nom de l’instance CR MigStorage.
    4
    Indiquez un ou plusieurs espaces de nommage sources. Par défaut, l’espace de nommage de destination porte le même nom.
    5
    Indiquez un espace de nommage de destination s’il est différent de l’espace de nommage source.
    6
    Indiquez le nom de l’instance MigCluster du cluster source.

  9. Vérifiez que l’instance MigPlan se trouve dans l’état Ready : 

    $ oc describe migplan <migplan> -n openshift-migration
    Copy to Clipboard Toggle word wrap

  10. Créez un manifeste de CR MigMigration pour lancer la migration définie dans l’instance MigPlan : 

    $ cat << EOF | oc apply -f -
apiVersion: migration.openshift.io/v1alpha1
kind: MigMigration
metadata:
  name: <migmigration>
  namespace: openshift-migration
spec:
  migPlanRef:
    name: <migplan>
    1 
    
    namespace: openshift-migration
  quiescePods: true
    2 
    
  stage: false
    3 
    
  rollback: false
    4 
    
EOF
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le nom de la ressource personnalisée MigPlan.
    2
    Les pods sur le cluster source sont arrêtés avant la migration si la valeur est définie sur true.
    3
    Une migration par étapes, qui copie la plupart des données sans arrêter l’application, est effectuée si la valeur est définie sur true.
    4
    Une migration terminée est annulée si la valeur est définie sur true.

  11. Vérifiez la migration en observant la progression de la ressource personnalisée MigMigration : 

    $ oc watch migmigration <migmigration> -n openshift-migration
    Copy to Clipboard Toggle word wrap

    La sortie se présente comme suit :

    Exemple de sortie

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
Namespace:    openshift-migration
Labels:       migration.openshift.io/migplan-name=django
Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
API Version:  migration.openshift.io/v1alpha1
Kind:         MigMigration
...
Spec:
  Mig Plan Ref:
    Name:       migplan
    Namespace:  openshift-migration
  Stage:        false
Status:
  Conditions:
    Category:              Advisory
    Last Transition Time:  2021-02-02T15:04:09Z
    Message:               Step: 19/47
    Reason:                InitialBackupCreated
    Status:                True
    Type:                  Running
    Category:              Required
    Last Transition Time:  2021-02-02T15:03:19Z
    Message:               The migration is ready.
    Status:                True
    Type:                  Ready
    Category:              Required
    Durable:               true
    Last Transition Time:  2021-02-02T15:04:05Z
    Message:               The migration registries are healthy.
    Status:                True
    Type:                  RegistriesHealthy
  Itinerary:               Final
  Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
  Phase:                   InitialBackupCreated
  Pipeline:
    Completed:  2021-02-02T15:04:07Z
    Message:    Completed
    Name:       Prepare
    Started:    2021-02-02T15:03:18Z
    Message:    Waiting for initial Velero backup to complete.
    Name:       Backup
    Phase:      InitialBackupCreated
    Progress:
      Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
    Started:        2021-02-02T15:04:07Z
    Message:        Not started
    Name:           StageBackup
    Message:        Not started
    Name:           StageRestore
    Message:        Not started
    Name:           DirectImage
    Message:        Not started
    Name:           DirectVolume
    Message:        Not started
    Name:           Restore
    Message:        Not started
    Name:           Cleanup
  Start Timestamp:  2021-02-02T15:03:18Z
Events:
  Type    Reason   Age                 From                     Message
  ----    ------   ----                ----                     -------
  Normal  Running  57s                 migmigration_controller  Step: 2/47
  Normal  Running  57s                 migmigration_controller  Step: 3/47
  Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
  Normal  Running  54s                 migmigration_controller  Step: 5/47
  Normal  Running  54s                 migmigration_controller  Step: 6/47
  Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
  Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
  Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
  Normal  Running  50s                 migmigration_controller  Step: 9/47
  Normal  Running  50s                 migmigration_controller  Step: 10/47
    Copy to Clipboard Toggle word wrap

11.3.5. Migration d’état
Copier lien

Vous pouvez effectuer des migrations répétables, uniquement d'état, en utilisant Migration Toolkit for Containers (MTC) pour migrer les réclamations de volumes persistants (PVC) qui constituent l'état d'une application. Vous migrez des PVC spécifiés en excluant d'autres PVC du plan de migration. Vous pouvez mapper les PVC pour vous assurer que les PVC source et cible sont synchronisés. Les données des volumes persistants (PV) sont copiées sur le cluster cible. Les références PV ne sont pas déplacées et les pods d'application continuent de fonctionner sur le cluster source.

La migration d'état est spécifiquement conçue pour être utilisée en conjonction avec des mécanismes de CD externes, tels que OpenShift Gitops. Vous pouvez migrer les manifestes d'application à l'aide de GitOps tout en migrant l'état à l'aide de MTC.

Si vous disposez d’un pipeline CI/CD, vous pouvez migrer les composants sans état en les déployant sur le cluster cible. Ensuite, vous pouvez migrer les composants avec état en utilisant MTC.

Vous pouvez effectuer une migration d’état entre des clusters ou au sein d’un même cluster.

Important

La migration d’état ne fait migrer que les composants qui constituent l’état d’une application. Si vous souhaitez migrer un espace de nommage complet, utilisez la migration par étapes ou à basculement.

Conditions préalables

  • L'état de l'application sur le cluster source est conservé dans PersistentVolumes provisionné via PersistentVolumeClaims.
  • Les manifestes de l'application sont disponibles dans un référentiel central accessible à partir des clusters source et cible.

Procédure

  1. Migrer les données des volumes persistants du cluster source vers le cluster cible.

    Vous pouvez effectuer cette étape autant de fois que nécessaire. L'application source continue de fonctionner.

  2. Mettre en pause l'application source.

    Vous pouvez le faire en définissant les répliques des ressources de charge de travail à 0, soit directement sur le cluster source, soit en mettant à jour les manifestes dans GitHub et en resynchronisant l'application Argo CD.

  3. Cloner les manifestes de l'application sur le cluster cible.

    Vous pouvez utiliser Argo CD pour cloner les manifestes d'application sur le cluster cible.

  4. Migrer les données de volume restantes de la source vers le cluster cible.

    Migrer toutes les nouvelles données créées par l'application au cours du processus de migration des états en effectuant une migration finale des données.

  5. Si l'application clonée est en état d'arrêt, il faut l'arrêter.
  6. Basculer l'enregistrement DNS vers le cluster cible pour rediriger le trafic utilisateur vers l'application migrée.
Note

MTC 1.6 ne peut pas mettre les applications en veille automatiquement lors de la migration des états. Il ne peut migrer que les données PV. Par conséquent, vous devez utiliser vos mécanismes CD pour la mise en veille ou l'arrêt des applications.

MTC 1.7 introduit les flux explicites Stage et Cutover. Vous pouvez utiliser la mise en scène pour effectuer des transferts de données initiaux autant de fois que nécessaire. Vous pouvez ensuite procéder à un basculement, au cours duquel les applications sources sont mises en veille automatiquement.

Conditions préalables

  • L'état de l'application sur le cluster source est conservé dans PersistentVolumes provisionné via PersistentVolumeClaims.
  • Les manifestes de l'application sont disponibles dans un référentiel central accessible à partir des clusters source et cible.

Procédure

  1. Migrer les données des volumes persistants du cluster source vers le cluster cible.

    Vous pouvez effectuer cette étape autant de fois que nécessaire. L'application source continue de fonctionner.

  2. Mettre en pause l'application source.

    Vous pouvez le faire en définissant les répliques des ressources de charge de travail à 0, soit directement sur le cluster source, soit en mettant à jour les manifestes dans GitHub et en resynchronisant l'application Argo CD.

  3. Cloner les manifestes de l'application sur le cluster cible.

    Vous pouvez utiliser Argo CD pour cloner les manifestes d'application sur le cluster cible.

  4. Migrer les données de volume restantes de la source vers le cluster cible.

    Migrer toutes les nouvelles données créées par l'application au cours du processus de migration des états en effectuant une migration finale des données.

  5. Si l'application clonée est en état d'arrêt, il faut l'arrêter.
  6. Basculer l'enregistrement DNS vers le cluster cible pour rediriger le trafic utilisateur vers l'application migrée.
Note

MTC 1.6 ne peut pas mettre les applications en veille automatiquement lors de la migration des états. Il ne peut migrer que les données PV. Par conséquent, vous devez utiliser vos mécanismes CD pour la mise en veille ou l'arrêt des applications.

MTC 1.7 introduit les flux explicites Stage et Cutover. Vous pouvez utiliser la mise en scène pour effectuer des transferts de données initiaux autant de fois que nécessaire. Vous pouvez ensuite procéder à un basculement, au cours duquel les applications sources sont mises en veille automatiquement.

Ressources supplémentaires

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