Bonnes pratiques de planification

Cette rubrique propose des conseils pour les migrations d'applications vers Google Kubernetes Engine (GKE) ou Anthos, sur la base de migrations d'applications réelles effectuées avec Migrate to Containers.

Migrate to Containers fournit un outil permettant de déterminer si la charge de travail de VM est adaptée à la migration vers un conteneur. Pour en savoir plus, consultez la page Utiliser l'outil d'évaluation de l'adéquation.

Charges de travail recommandées

Migrate to Containers est recommandé pour certains types de charges de travail Linux et Windows, détaillés ci-dessous.

Bonne adéquation

Linux

Les applications Linux adaptées à la migration avec Migrate to Containers incluent les architectures d'applications suivantes :

• Serveurs Web et serveurs d'applications
• Middleware logique métier (par exemple, Tomcat)
• VM multiples, piles multiniveaux (par exemple, LAMP)
• Bases de données de petite et moyenne taille (par exemple, MySQL et PostgreSQL)

En outre, les applications les mieux adaptées à la migration avec Migrate to Containers présentent les caractéristiques opérationnelles suivantes :

• Cycle d'utilisation faible et charges de travail en rafales
• Environnements des ateliers de développement, de test et de formation
• Services activés en permanence et à faible charge

En général, la plupart des charges de travail Linux sont compatibles avec la migration, à l'exception de celles explicitement répertoriées ci-dessous dans la section Applications inadaptées.

Windows

Les applications Windows qui sont adaptées à la migration à l'aide de Migrate to Containers incluent des charges de travail qui remplissent toutes les caractéristiques suivantes :

• IIS 7 ou version ultérieure, ASP.NET avec le framework .NET 3.5 ou version ultérieure
• Niveaux Web et logiques
• WS2008 R2 ou version supérieure

Systèmes d'exploitation compatibles

Migrate to Containers est compatible avec ces systèmes d'exploitation de VM.

Applications inadaptées

Linux

Pour Linux, les applications et les serveurs qui ne conviennent pas à la migration avec Migrate to Containers sont les suivants :

• Bases de données en mémoire hautes performances et volumineuses
• VM avec des pilotes de noyau spéciaux (par exemple, NFS en mode noyau)
• Dépendances vis-à-vis d'un matériel spécifique
• Logiciels avec des licences liées à l'enregistrement de certains identifiants de matériel

Windows

Pour Windows, les charges de travail sans serveur IIS 7 ou version ultérieure ne conviennent pas à la migration. Voici d'autres types d'applications inadaptées pour la migration :

• Applications avec des dépendances sur des GPU ou des TPU
• Applications réseau de bas niveau
• Applications de bureau, RDP et VDI
• Applications avec BYOL

Règles d'accès DNS et réseau

Avant de migrer vers GKE, assurez-vous de bien comprendre les ressources et services réseau utilisés par vos charges de travail migrées, et assurez-vous qu'elles sont accessibles et adressables depuis votre cloud privé virtuel.

Planifier les noms de services Kubernetes

Si vos charges de travail dépendent du DNS pour accéder aux services, vous devez planifier vos schémas d'espace de noms Kubernetes, les règles de réseau et les noms de service.

La spécification de déploiement générée par le processus de migration contient un objet sans adresse IP Service suggéré de type "ClusterIP". "ClusterIP" signifie qu'aucun équilibrage de charge n'est disponible, et qu'une adresse IP interne unique du cluster est accessible uniquement à partir du cluster. Le contrôleur de points de terminaison Kubernetes modifie la configuration DNS pour renvoyer les enregistrements (adresses) pointant vers les pods, qui sont dotés de l'étiquette "app": "app-name" dans le fichier deployment_spec.yaml.

Remarque : Les noms des services Kubernetes sont plus limités que les noms autorisés par le DNS.

Créer et appliquer des services pour les connexions aux pods et aux conteneurs

Après la migration d'une charge de travail, les noms d'hôte ne sont plus applicables. Pour autoriser les connexions à vos charges de travail, créez et appliquez des services.

Identifier et configurer les noms et adresses IP migrés

GKE gère le fichier /etc/hosts. Dans Migrate to Containers, l'adaptation du fichier d'hôtes de la VM source à GKE n'est pas encore automatisée. Les noms et les adresses IP du fichier d'hôtes sur la VM migrée doivent être identifiés et configurés en tant que hostAliases.

Placer les services co-dépendants dans le même espace de noms

Les services qui dépendent les uns des autres doivent se trouver dans le même espace de noms Kubernetes et utiliser des noms DNS courts (par exemple, app et db) pour communiquer. Cette configuration permet également de répliquer plusieurs environnements d'application, tels que la production, la préproduction et le test.

Contrôler la surface d'accès grâce à la mise en réseau GKE

GKE dispose de contrôles sophistiqués pour la mise en réseau. Les pods sont accessibles depuis différents réseaux, tels que l'Internet public, le réseau VPC ou le réseau de cluster interne. Cette solution offre la possibilité de contrôler davantage et de restreindre la surface d'accès à une charge de travail, sans complexité supplémentaire liée à la gestion des VLAN, des filtres ou des règles de routage.

Par exemple, une application classique à trois niveaux comporte des niveaux d'interface, d'application et de base de données. Lors de la migration vers Google Cloud, le service d'interface est configuré avec un LoadBalancer sur le réseau VPC. Les autres niveaux ne sont pas directement accessibles depuis l'extérieur du cluster GKE. Une règle d'accès réseau garantit que le service d'application n'est accessible que par les pods d'interface frontend à partir du réseau du cluster interne. Une autre règle garantit que les pods de base de données ne sont accessibles que par les pods d'applications.

NFS

Définir les installations NFS en tant que volumes persistants

Lorsque vous créez le plan de migration, les installations de client NFS sur la VM source sont automatiquement détectées et ajoutées au plan généré.

Les installations sont ajoutées au plan, mais elles sont désactivées par défaut. Cela signifie que les définitions de PersistentVolume et PersistentVolumeClaim ne sont pas incluses dans le fichier deployment_spec.yaml lorsque vous générez des artefacts de migration. Si vous souhaitez que Migrate to Containers génère des définitions de PersistentVolume et de PersistentVolumeClaim, vous devez d'abord modifier le plan de migration pour activer l'installation du client NFS.

Pour en savoir plus, consultez la section Personnaliser des installations NFS.

Remarque : Migrate to Containers nécessite que les installations NFS soient accessibles à partir du cluster de déploiement hébergeant la charge de travail du conteneur migré. Cependant, Migrate to Containers ne valide pas cette connectivité. Un conteneur migré avec un problème de connectivité ne peut pas être démarré et vous devrez peut-être modifier le fichier deployment_spec.yaml pour le résoudre. Pour en savoir plus, consultez la section Accéder aux instances Filestore avec le pilote CSI Filestore.

Remarque : Utiliser NFS sur une liaison VPN peut réduire les performances en raison d'une latence accrue et d'une bande passante réduite.

Serveurs NFS en mode noyau

Les VM avec des serveurs NFS s'exécutant en mode noyau ne peuvent pas être migrées vers GKE avec Migrate to Containers. Ces VM doivent être migrées vers des VM sur Compute Engine. Vous pouvez également utiliser Filestore pour une solution NFS cloud native.

Migrer des données depuis des partages NFS sources

Si votre VM source utilise un montage de partage NFS, ces données ne peuvent pas être migrées automatiquement. Montez le partage sur le conteneur de la charge de travail migrée à l'aide d'un volume persistant NFS ou, si le partage NFS source est à distance, copiez les données dans un autre partage de fichiers qui offre un accès à plus faible latence au cluster.

Pour copier les données, vous pouvez utiliser les options suivantes :

1. Service de transfert de stockage ou Transfer Appliance.

2. Copier des données avec gsutil rsync (à partir du partage de fichiers source vers un bucket, puis d'un bucket vers un partage de fichiers dans le cloud).

3. Des solutions tierces, telles que NetApp SnapMirror vers NetApp Cloud Volumes.

4. Outils OSS tels que Rsync.

Vérifier que les bases de données sont accessibles

Si votre application repose sur une base de données, qui s'exécute localement sur la VM ou sur une machine externe, vous devez vous assurer que la base de données est toujours accessible à partir du nouveau pod migré. Vous devez vérifier que votre stratégie du pare-feu de réseau autorise l'accès à la base de données depuis le cluster.

Pour migrer la base de données vers Google Cloud, nous vous recommandons d'utiliser Database Migration Service.

Vous pouvez également exécuter la base de données dans le cluster. Pour en savoir plus, consultez la page Planifier des déploiements de bases de données sur GKE.

Vérifier que les métadonnées injectées sont disponibles

Si vos applications reposent sur des métadonnées injectées (par exemple, des variables d'environnement), vous devez vous assurer que ces métadonnées sont disponibles sur GKE. Si la même méthode d'injection de métadonnées n'est pas disponible, GKE propose des ConfigMaps et des Secrets.

Configurer les services nécessaires pour démarrer au niveau d'exécution 3

Les charges de travail Migrate to Containers n'atteignent que le niveau d'exécution 3. Les VM migrées vers GKE avec Migrate to Containers seront démarrées dans le conteneur au niveau d'exécution 3 de Linux. Certains services (par exemple, X11 ou XDM pour l'accès à l'IUG via VNC) sont configurés par défaut pour démarrer uniquement au niveau d'exécution 5. Tous les services nécessaires doivent être configurés pour démarrer au niveau d'exécution 3.

Désactiver les services inutiles

Migrate to Containers désactive automatiquement des services spécifiques au matériel ou à l'environnement, ainsi qu'un ensemble prédéfini de services supplémentaires exécutés sur des VM. Ces services ne sont plus nécessaires après la migration de vos charges de travail vers des conteneurs.

Par exemple, Migrate to Containers désactive automatiquement iptables, ip6tables et firewalld. Pour obtenir la liste complète des services désactivés par Migrate to Containers, téléchargez le fichier blocklist.yaml.

Personnaliser les services désactivés

Par défaut, Migrate to Containers désactive les services inutiles répertoriés ci-dessus. Vous pouvez également définir votre propre liste de services à désactiver dans un conteneur migré en personnalisant le plan de migration pour définir une liste de blocage. Avec une liste de blocage, vous pouvez spécifier un ou plusieurs services à désactiver dans un conteneur migré.

Gérer et mettre à jour les VM migrées

À l'aide des artefacts générés lors de la migration, vous pouvez appliquer des mises à jour logicielles d'applications et d'OS de mode utilisateur, des correctifs de sécurité, éditer des configurations intégrées, ajouter ou remplacer des fichiers et mettre à jour le logiciel d'exécution Migrate to Containers.

Pour en savoir plus, consultez la section Mettre à jour des images post-migration.