Chapitre 5. À propos de Migration Toolkit for Containers
Le Migration Toolkit for Containers (MTC) vous permet de migrer des charges de travail d'applications stateful d'OpenShift Container Platform 3 à 4.12 à la granularité d'un espace de noms.
Avant de commencer votre migration, assurez-vous de passer en revue les différences entre OpenShift Container Platform 3 et 4.
MTC fournit une console Web et une API, en fonction des ressources personnalisées de Kubernetes, pour vous aider à contrôler la migration et à minimiser les temps d’arrêt des applications.
La console MTC est installée par défaut sur le cluster cible. Vous pouvez configurer Migration Toolkit for Containers Operator de façon à installer la console sur un cluster source OpenShift Container Platform 3 ou sur un cluster distant.
MTC prend en charge les méthodes de copie des données de cliché et du système de fichiers pour faire migrer les données du cluster source vers le cluster cible. Vous pouvez choisir une méthode adaptée à votre environnement et prise en charge par votre fournisseur de stockage.
Le catalogue de services n’est plus utilisé dans OpenShift Container Platform 4. Vous pouvez faire migrer les ressources de charge de travail fournies avec le catalogue de services d’OpenShift Container Platform 3 vers la version 4, mais vous ne pouvez pas effectuer les actions du catalogue de services telles que le provisioning
, le deprovisioning
ou la mise à jour
sur ces charges de travail après la migration. La console MTC affiche un message si les ressources du catalogue de services ne peuvent pas faire l’objet d’une migration.
5.1. Terminologie
Terme | Définition |
---|---|
Cluster source | Cluster à partir duquel les applications sont migrées. |
Cluster de destination[1] | Cluster vers lequel les applications sont migrées. |
Un référentiel de réplication | Stockage d’objets utilisé pour la copie d’images, de volumes et d’objets Kubernetes pendant la migration indirecte ou pour des objets Kubernetes pendant la migration directe de volumes ou d’images. Le référentiel de réplication doit être accessible à tous les clusters. |
Cluster hôte |
Cluster sur lequel le pod Le cluster hôte n’a pas besoin d’une route de registre exposée pour la migration directe des images. |
Cluster distant | Un cluster distant est généralement le cluster source, mais ce n’est pas obligatoire.
Un cluster distant nécessite une ressource personnalisée Un cluster distant nécessite une route de registre sécurisée exposée pour la migration directe des images. |
Migration indirecte | Les images, volumes et objets Kubernetes sont copiés du cluster source vers le référentiel de réplication, puis du référentiel de réplication vers le cluster de destination. |
Migration directe des volumes | Les volumes persistants sont copiés directement du cluster source vers le cluster de destination. |
Migration directe des images | Les images sont copiées directement du cluster source vers le cluster de destination. |
Migration par étapes | Les données sont copiées vers le cluster de destination sans arrêter l’application. Le fait d’exécuter plusieurs fois une migration par étapes réduit la durée de la migration à basculement. |
Migration à basculement | L’application est arrêtée sur le cluster source et ses ressources sont migrées vers le cluster de destination. |
Migration d’état | L'état de l'application est migré en copiant les demandes de volumes persistants spécifiques vers le cluster de destination. |
Migration de retour | La migration de retour annule une migration terminée. |
1 Appelez le cluster cible dans la console Web MTC.