Migrer des conteneurs vers Google Cloud : migrer Kubernetes vers GKE

Last reviewed 2023-05-22 UTC

Ce document vous aide à planifier, concevoir et mettre en œuvre votre migration d'un environnement Kubernetes autogéré vers Google Kubernetes Engine (GKE). Si vous ne le faites pas correctement, le transfert d'applications d'un environnement à un autre peut s'avérer compliqué. Vous devez donc planifier et exécuter votre migration avec soin.

Ce document fait partie d'une série d'articles sur la migration vers Google Cloud. Si vous êtes intéressé par une présentation de la série, consultez la section Migrer vers Google Cloud : choisir votre chemin de migration.

Ce document fait partie d'une série qui traite de la migration de conteneurs vers Google Cloud :

Ce document est utile si vous envisagez de migrer d'un environnement Kubernetes autogéré vers GKE. Votre environnement peut s'exécuter dans un environnement sur site, dans un environnement d'hébergement privé ou dans l'environnement d'un autre fournisseur de cloud. Ce document est également utile si vous évaluez l'opportunité d'effectuer une migration et si vous souhaitez découvrir à quoi elle pourrait ressembler.

En utilisant GKE, vous bénéficiez des avantages suivants :

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases

À chaque étape du processus de migration, vous suivez les phases définies dans l'article Migrer vers Google Cloud : premiers pas :

  1. Évaluer et découvrir vos charges de travail
  2. Planifier et établir les fondations
  3. Déployer vos charges de travail
  4. Optimiser votre environnement

Évaluer votre environnement

Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour la migration de votre environnement Kubernetes autogéré vers GKE :

  1. Dresser un inventaire complet de vos applications.
  2. Cataloguer vos applications en fonction de leurs propriétés et de leurs dépendances.
  3. Former et préparer vos équipes sur Google Cloud.
  4. Élaborer un test et une démonstration de faisabilité sur Google Cloud.
  5. Calculer le coût total de possession (TCO) de l'environnement cible.
  6. Choisir les charges de travail que vous souhaitez migrer en premier

Les sections suivantes s'appuient sur Migrer vers Google Cloud : évaluer et découvrir vos charges de travail.

Créer vos inventaires

Pour couvrir votre migration, vous devez comprendre votre environnement Kubernetes actuel. Vous commencez par recueillir des informations sur vos clusters, puis vous vous concentrez sur vos charges de travail déployées dans ces clusters et sur les dépendances des charges de travail. À la fin de la phase d'évaluation, vous disposez de deux inventaires : un pour vos clusters et un pour les charges de travail déployées dans ces clusters.

Pour créer l'inventaire de vos clusters, tenez compte des points suivants pour chaque cluster :

  • Nombre et type de nœuds. Lorsque vous connaissez le nombre de nœuds et les caractéristiques de chaque nœud dans votre environnement actuel, vous dimensionnez vos clusters lorsque vous passez à GKE. Les nœuds de votre nouvel environnement peuvent fonctionner avec une génération d'architecture matérielle différente de celle que vous utilisez dans votre environnement. Les performances de chaque génération d'architecture étant différentes, le nombre de nœuds dont vous avez besoin dans votre nouvel environnement peut différer de celui de votre environnement. Évaluez tous les types de matériel que vous utilisez dans vos nœuds, tels que les périphériques de stockage hautes performances, les GPU et les TPU.
  • Cluster interne ou externe. Évaluez les acteurs, internes ou externes à votre environnement, auxquels chaque cluster est exposé. Pour prendre en charge vos cas d'utilisation, cette évaluation inclut les charges de travail exécutées dans le cluster, ainsi que les interfaces qui interagissent avec vos clusters.
  • Architecture mutualisée. Si vous gérez des clusters mutualisés dans votre environnement, vérifiez leur bon fonctionnement dans votre nouvel environnement Google Cloud. Le moment est venu d'évaluer comment améliorer vos clusters mutualisés, car votre stratégie d'architecture mutualisée influence la façon dont vous développez votre infrastructure de base sur Google Cloud.
  • Version de Kubernetes. Recueillez des informations sur la version Kubernetes de vos clusters pour vérifier la compatibilité entre ces versions et celles disponibles dans GKE. Si vous exécutez une version plus ancienne ou plus récente, vous utilisez peut-être des fonctionnalités qui ne sont pas disponibles dans GKE. Les fonctionnalités peuvent être obsolètes, ou la version de Kubernetes qui les fournit peut ne pas être déjà disponible dans GKE.
  • Cycle de mise à niveau de Kubernetes. Pour maintenir la fiabilité d'un environnement, vous devez comprendre comment gérer les mises à niveau de Kubernetes et comment votre cycle de mise à niveau est lié aux mises à niveau de GKE.
  • Pools de nœuds. Si vous utilisez une forme de regroupement de nœuds, vous pouvez envisager de les mettre en correspondance avec le concept de pools de nœuds dans GKE, car vos critères de regroupement peuvent ne pas être adaptés à GKE.
  • Initialisation des nœuds. Évaluez la façon dont vous initialisez chaque nœud avant de le marquer comme disponible pour exécuter vos charges de travail, afin de pouvoir transférer ces procédures d'initialisation vers GKE.

Les éléments suivants que vous évaluez dans votre inventaire sont axés sur la sécurité de votre infrastructure et des clusters Kubernetes :

  • Espaces de noms. Si vous utilisez des espaces de noms Kubernetes dans vos clusters pour séparer logiquement les ressources, identifiez les ressources présentes dans chaque espace de noms et déterminez pourquoi vous avez créé cette séparation. Par exemple, vous utilisez peut-être des espaces de noms dans le cadre de votre stratégie d'architecture mutualisée. Il se peut que des charges de travail déployées dans des espaces de noms soient réservées aux composants système Kubernetes et que vous n'ayez pas autant de contrôle dans GKE.
  • Contrôle d'accès basé sur les rôles (RBAC). Si vous utilisez une autorisation RBAC dans vos clusters, répertoriez une description de tous les objets ClusterRole et ClusterRoleBinding que vous avez configurés dans vos clusters.
  • Règles de réseau. Répertoriez toutes les règles de réseau que vous avez configurées dans vos clusters, et déterminez comment les règles de réseau fonctionnent dans GKE.
  • Contextes de sécurité des pods Collectez des informations sur les contextes de sécurité des pods que vous avez configurés dans vos clusters, et découvrez comment ils fonctionnent dans GKE.
  • Comptes de service. Si l'un des processus de votre cluster interagit avec le serveur d'API Kubernetes, capturez des informations sur les comptes de service qu'ils utilisent.

Après avoir terminé l'inventaire des clusters Kubernetes et évalué la sécurité de votre environnement, créez l'inventaire des charges de travail déployées dans ces clusters. Lorsque vous évaluez vos charges de travail, collectez des informations sur les aspects suivants :

  • Pods et contrôleurs. Pour dimensionner les clusters dans votre nouvel environnement, évaluez le nombre d'instances de chaque charge de travail déployée puis, si vous utilisez des quotas de ressources et calculez les limites de consommation des ressources. Collectez des informations sur les charges de travail exécutées sur les nœuds du plan de contrôle de chaque cluster et sur les contrôleurs utilisés par chaque charge de travail. Par exemple, combien de déploiements utilisez-vous ? Combien de DaemonSets utilisez-vous ?
  • Tâches standards et tâches Cron. Vos clusters et vos charges de travail devront peut-être exécuter des tâches standards ou des tâches Cron dans le cadre de leurs procédures d'initialisation ou d'exploitation. Évaluez le nombre d'instances de tâches standards et Cron que vous avez déployées, ainsi que les responsabilités et critères d'achèvement de chaque instance.
  • Autoscalers Kubernetes. Pour migrer vos règles d'autoscaling dans le nouvel environnement, découvrez comment l'autoscaler horizontal des pods, l'autoscaler de pods verticaux et l'autoscaler de pods multirégionaux fonctionne sur GKE.
  • Charges de travail sans état et avec état. Les charges de travail sans état ne stockent pas de données ni d'état dans le cluster ni dans un stockage persistant. Les applications avec état enregistrent des données pour une utilisation ultérieure. Pour chaque charge de travail, évaluez les composants sans état et avec état, car la migration des charges de travail avec état est généralement plus compliquée que la migration des charges de travail sans état.
  • Fonctionnalités de Kubernetes. L'inventaire des clusters vous permet de savoir quelle version de Kubernetes est exécutée par chaque cluster. Consultez les notes de version de chaque version de Kubernetes pour connaître les fonctionnalités fournies et celles qui sont obsolètes. Ensuite, évaluez vos charges de travail par rapport aux fonctionnalités Kubernetes dont vous avez besoin. L'objectif de cette tâche est de savoir si vous utilisez des fonctionnalités obsolètes ou qui ne sont pas encore disponibles dans GKE. Si vous trouvez des fonctionnalités indisponibles, supprimez les fonctionnalités obsolètes et adoptez les nouvelles lorsqu'elles seront disponibles dans GKE.
  • Stockage. Pour les charges de travail avec état, déterminez si elles utilisent PersistenceVolumeClaims. Répertoriez toutes les exigences de stockage, telles que la taille et le mode d'accès, ainsi que la façon dont ces PersistenceVolumeClaims mappent les PersistenceVolumes. Pour tenir compte de la croissance future, déterminez si vous devez développer un PersistenceVolumeClaim.
  • Injection de fichiers de configuration et de secrets. Pour éviter de recréer vos artefacts déployables chaque fois que la configuration de votre environnement change, injectez des fichiers de configuration et de secrets dans les pods à l'aide de ConfigMaps et de Secrets. Pour chaque charge de travail, déterminez quels ConfigMaps et Secrets sont utilisés par cette charge de travail, ainsi que la manière dont vous renseignez ces objets.
  • Dépendances. Vos charges de travail ne travaillent probablement pas isolément. Elles peuvent disposer de dépendances internes au cluster ou de systèmes externes. Pour chaque charge de travail, identifiez les dépendances, et déterminez si vos charges de travail ont une certaine tolérance lorsque les dépendances ne sont pas disponibles. Par exemple, les dépendances courantes incluent les systèmes de fichiers distribués, les bases de données, les plates-formes de distribution de secrets, les systèmes de gestion de l'authentification et des accès, les mécanismes de détection de services et tout autre système externe.
  • Services Kubernetes. Pour exposer vos charges de travail à des clients internes et externes, utilisez Services. Pour chaque service, vous devez connaître son type. Pour les services exposés en externe, évaluez l'interaction de ce service avec le reste de votre infrastructure. Par exemple, de quelle manière votre infrastructure est-elle compatible avec les services LoadBalancer et les objets Ingress ? Quels contrôleurs d'entrée avez-vous déployés dans vos clusters ?
  • Maillage de services. Si vous utilisez un maillage de services dans votre environnement, vous devez évaluer sa configuration. Vous devez également connaître le nombre de clusters que le maillage couvre, les services qui en font partie et la façon dont vous modifiez sa topologie. Par exemple, utilisez-vous une injection side-car automatique pour ajouter automatiquement des side-cars aux pods Kubernetes ?
  • Rejets et tolérances et affinité et anti-affinité. Pour chaque pod et nœud, déterminez si vous avez configuré des rejets de nœuds, des tolérances de pods ou des affinités pour personnaliser la planification des pods dans vos clusters Kubernetes. Ces propriétés peuvent également vous donner des indications sur les configurations de nœuds ou de pods non homogènes et peuvent signifier que les pods, les nœuds ou les deux doivent être évalués avec une attention particulière. Par exemple, si vous avez configuré un ensemble particulier de pods pour qu'ils ne soient programmés que sur certains nœuds de votre cluster Kubernetes, cela peut signifier que les pods ont besoin de ressources spécialisées qui ne sont disponibles que sur ces nœuds.

Après avoir évalué vos clusters et leurs charges de travail, évaluez les autres services et aspects d'assistance de votre infrastructure, tels que les suivants :

  • StorageClasses et PersistentVolumes. Évaluez la manière dont votre infrastructure sauvegarde PersistanceVolumeClaims en répertoriant StorageClasses pour le provisionnement dynamique ainsi que les PersistentVolumes statiquement provisionnés. Pour chaque PersistentVolume, tenez compte des éléments suivants : capacité, mode de volume, mode d'accès, classe, règle de récupération, options d'installation et affinité de nœud.
  • VolumeSnapshots et VolumeSnapshotContents. Pour chaque PersistentVolume, vérifiez si vous avez configuré un VolumeSnapshot, et si vous devez migrer un VolumeSnapshotContent existant.
  • Pilotes CSI (Container Storage Interface). S'ils sont déployés dans vos clusters, déterminez si ces pilotes sont compatibles avec GKE et si vous devez adapter la configuration de vos volumes pour qu'elle fonctionne avec des pilotes CSI compatibles avec GKE.
  • Stockage de données. Si vous dépendez de systèmes externes pour provisionner des PersistentVolumes, fournissez un moyen aux charges de travail de votre environnement GKE d'utiliser ces systèmes. La localisation des données a un impact sur les performances des charges de travail avec état, car la latence entre vos systèmes externes et votre environnement GKE est proportionnelle à la distance entre eux. Pour chaque système de stockage de données externe, tenez compte de son type (volumes de blocs, stockage de fichiers ou stockage d'objets) ainsi que des exigences de performances et de disponibilité qu'il doit satisfaire.
  • Journalisation, surveillance et traçage. Relevez des informations sur vos systèmes de surveillance, de journalisation et de traçage. Vous pouvez intégrer vos systèmes à Google Cloud Observability ou utiliser Google Cloud Observability comme seul outil de surveillance, de journalisation et de traçage. Par exemple, vous pouvez intégrer Google Cloud Observability à d'autres services, configurer des interfaces de journalisation pour vos langages de programmation préférés et utiliser l'agent Cloud Logging sur vos VM. GKE s'intègre à Google Cloud Observability et aux journaux d'audit Cloud. Vous pouvez également personnaliser les journaux Cloud Logging pour GKE avec Fluentd, puis traiter les journaux à grande échelle à l'aide de Dataflow.
  • Ressources personnalisées et modules complémentaires Kubernetes. Collectez des informations sur toutes les ressources Kubernetes personnalisées et tous les modules complémentaires Kubernetes que vous pouvez avoir déployés dans vos clusters, car ils peuvent ne pas fonctionner dans GKE, ou vous devrez peut-être les modifier. Par exemple, si une ressource personnalisée interagit avec un système externe, vous déterminez si cela s'applique à votre environnement Google Cloud.

Terminer l'évaluation

Après avoir créé les inventaires liés à vos charges de travail et clusters Kubernetes, accomplissez les autres étapes de la phase d'évaluation décrites dans la page Migration vers Google Cloud : évaluer et découvrir vos charges de travail.

Planifier et établir vos fondations

Au cours de la phase de planification et de création, vous provisionnez et configurez l'infrastructure et les services cloud compatibles avec vos charges de travail sur Google Cloud :

  1. Créez une hiérarchie de ressources.
  2. Configurez la gestion des identités et des accès.
  3. Configurez la facturation.
  4. Configurez la connectivité réseau.
  5. Renforcez votre sécurité.
  6. Configurez la surveillance et les alertes.

Si vous avez déjà adopté infrastructure-as-code pour gérer les charges de travail dans votre environnement Kubernetes, vous pouvez appliquer le même processus à votre environnement Google Cloud. Vous analysez vos descripteurs Kubernetes, car certaines ressources Google Cloud provisionnées automatiquement par GKE sont configurables à l'aide de libellés et d'annotations Kubernetes. Par exemple, vous pouvez provisionner un équilibreur de charge interne plutôt qu'externe en ajoutant une annotation à un service LoadBalancer.

Les sections suivantes s'appuient sur la page Migrer vers Google Cloud : établir les fondations.

Créer une hiérarchie de ressources

Pour concevoir une hiérarchie de ressources efficace, réfléchissez à la façon dont vos structures métier et organisationnelles correspondent à Google Cloud, comme indiqué dans la section Migration vers Google Cloud : établir les fondations.

Par exemple, si vous avez besoin d'un environnement mutualisé sur GKE, vous avez le choix entre les options suivantes :

  • Créer un projet Google Cloud pour chaque locataire.
  • Partager un projet entre différents locataires et provisionner plusieurs clusters GKE.
  • Utiliser des espaces de noms Kubernetes.

Votre choix dépend de vos besoins en matière d'isolement, de complexité et d'évolutivité. Par exemple, avoir un projet par locataire permet d'isoler les locataires les uns des autres, mais la hiérarchie des ressources devient alors plus complexe à gérer en raison du nombre élevé de projets. Cependant, bien que la gestion des espaces de noms Kubernetes soit relativement plus simple qu'une hiérarchie de ressources complexe, cette option ne garantit pas un tel degré d'isolement. Par exemple, le plan de contrôle peut être partagé entre locataires.

Configurer la gestion des identités et des accès

La gestion de l'authentification et des accès fournit les outils permettant de configurer de manière centralisée et précise le contrôle des accès aux ressources cloud. Pour en savoir plus, consultez la section Gestion de l'authentification et des accès.

Découvrez comment Kubernetes RBAC interagit avec la gestion de l'authentification et des accès dans Google Cloud, puis configurez-le en fonction des exigences que vous avez recueillies lors de la phase d'évaluation.

Configurer la facturation

Avant de provisionner des ressources Google Cloud, configurez Cloud Billing et comprenez le fonctionnement du modèle de tarification de GKE. Pour en savoir plus, consultez la section Facturation.

Configurer la connectivité réseau

La configuration réseau est un aspect essentiel de votre environnement. Évaluez le modèle de réseau GKE et les exigences de connectivité de vos charges de travail. Vous pouvez ensuite commencer à planifier la configuration de votre réseau. Pour en savoir plus, consultez la section Connectivité et mise en réseau.

Renforcer votre sécurité

Il est essentiel de comprendre les différences entre le modèle de sécurité de votre environnement et le modèle Google Cloud, et comment renforcer la sécurité de vos clusters GKE pour protéger vos éléments critiques. Pour en savoir plus, consultez la section Sécurité.

Configurer la surveillance et les alertes

Il est indispensable d'avoir une idée claire des performances de votre infrastructure et de vos charges de travail pour identifier les points à améliorer. GKE offre des intégrations approfondies avec Google Cloud Observability. Vous obtenez ainsi des informations sur la journalisation et la surveillance de vos clusters GKE et charges de travail au sein de ces clusters. Pour en savoir plus, consultez la section Surveillance et alertes.

Déployer vos charges de travail

Lors de la phase de déploiement, procédez comme suit :

  1. Provisionnez et configurez votre environnement GKE.
  2. Configurez vos clusters GKE.
  3. Migrez des données de votre environnement source vers Google Cloud.
  4. Déployez vos charges de travail dans l'environnement GKE.
  5. Validez vos charges de travail.
  6. Exposez des charges de travail exécutées sur GKE.
  7. Déplacez le trafic de l'environnement source vers l'environnement GKE.
  8. Mettez hors service l'environnement source.

Provisionner et configurer votre plate-forme et vos environnements d'exécution

Avant de déplacer une charge de travail vers votre nouvel environnement Google Cloud, provisionnez les clusters GKE.

Après la phase d'évaluation, vous savez maintenant comment provisionner les clusters GKE dans votre nouvel environnement Google Cloud afin de répondre à vos besoins. Vous pouvez provisionner les éléments suivants :

  • Le nombre de clusters, le nombre de nœuds par cluster, les types de clusters, la configuration de chaque cluster et chaque nœud, ainsi que les plans d'évolutivité de chaque cluster.
  • Mode de fonctionnement de chaque cluster. GKE propose deux modes de fonctionnement pour les clusters : GKE Autopilot et GKE Standard.
  • Le nombre de clusters privés.
  • Le choix entre la mise en réseau de VPC natif ou basée sur un routeur.
  • Les versions et canaux de publication de Kubernetes dont vous avez besoin dans vos clusters GKE.
  • Les pools de nœuds permettant de regrouper logiquement les nœuds dans vos clusters GKE et le cas échéant de créer automatiquement des pools de nœuds avec le provisionnement automatique des nœuds.
  • Les procédures d'initialisation que vous pouvez transférer de votre environnement vers l'environnement GKE, ainsi que les nouvelles procédures que vous pouvez mettre en œuvre. Par exemple, vous pouvez amorcer automatiquement les nœuds GKE en mettant en œuvre une ou plusieurs procédures d'initialisation, éventuellement privilégiées pour chaque nœud ou pool de nœuds de vos clusters.
  • Les plans d'évolutivité pour chaque cluster
  • Les fonctionnalités GKE supplémentaires dont vous avez besoin, telles qu'Anthos Service Mesh et les modules complémentaires GKE, tels que Sauvegarde pour GKE.

Pour en savoir plus sur le provisionnement des clusters GKE, consultez les pages suivantes :

Configurer vos clusters

Après avoir provisionné vos clusters GKE et avant de déployer une charge de travail ou de migrer des données, configurez les espaces de noms, RBAC, les règles de réseau, les quotas de ressources et autres objets Kubernetes et GKE pour chaque cluster GKE.

Pour configurer des objets Kubernetes et GKE dans vos clusters GKE, nous vous recommandons d'effectuer les opérations suivantes :

  1. Assurez-vous de disposer des identifiants et des autorisations nécessaires pour accéder aux clusters de votre environnement source et de votre environnement GKE.
  2. Déterminez si les objets des clusters Kubernetes dans votre environnement source sont compatibles avec GKE, et comment les mises en œuvre qui sauvegardent ces objets diffèrent de l'environnement source et de GKE.
  3. Refactorisez un objet incompatible pour le rendre compatible avec GKE ou supprimez-le.
  4. Migrez ces objets vers vos clusters GKE.
  5. Configurez tous les objets supplémentaires dont vous avez besoin dans vos clusters GKE.

Migrer la configuration du cluster

Pour migrer la configuration de vos clusters Kubernetes de l'environnement source vers vos clusters GKE, vous pouvez utiliser l'approche suivante :

  • Si vous avez adopté des processus infrastructure en tant que code pour configurer des objets dans les clusters Kubernetes de votre environnement source, vous pouvez :

    1. Migrer des objets compatibles avec GKE ne nécessitant que des modifications de métadonnées mineures, tels que les noms d'objets, l'emplacement ou l'espace de noms, à l'aide des outils Kubernetes (kubectl) ou de services gérés (Config Sync).
    2. Refactoriser ou supprimer des objets qui ne sont pas compatibles avec GKE.

  • Si vous n'avez pas adopté de processus de type "Infrastructure as Code", vous pouvez :

    • Migrer la configuration des objets Kubernetes de votre environnement source vers votre environnement GKE à l'aide d'outils tiers, tels que Crane et Velero.

Migrer les données

Pour migrer les données dont vos charges de travail avec état ont besoin de votre environnement source vers votre environnement GKE, nous vous recommandons de concevoir un plan de migration de données en suivant les instructions de la section Migrer vers Google Cloud : transférer des ensembles de données importants.

Vous provisionnez toute l'infrastructure de stockage nécessaire avant de déplacer vos données. Si vous utilisez des approvisionneurs StorageClass, configurez-les dans les nouveaux clusters.

Pour en savoir plus sur les options de stockage de données disponibles sur GKE, consultez la section Configuration de l'espace de stockage. Par exemple, vous pouvez utiliser des disques persistants Compute Engine, zonaux ou répliqués sur une région, ou Filestore.

Après avoir provisionné les ressources StorageClass, vous provisionnez tous les PersistentVolumes nécessaires pour stocker les données à migrer. Ensuite, migrez les données de l'environnement source vers ces PersistentVolumes. Les spécificités de cette migration de données dépendent des caractéristiques de l'environnement source. Par exemple, vous pouvez :

  1. Provisionner une instance Compute Engine.
  2. Associer un disque persistant à l'instance Compute Engine.
  3. Copier les données de l'environnement source vers le disque persistant.
  4. Arrêter l'instance Compute Engine.
  5. Dissocier le disque persistant de l'instance Compute Engine.
  6. Configurer le disque persistant en tant que PersistentVolume de GKE.
  7. Mettre hors service l'instance Compute Engine.

Pour plus d'informations sur l'utilisation des disques persistants Compute Engine en tant que PersistentVolumes de GKE, consultez la page Utiliser des disques persistants préexistants en tant que PersistentVolumes.

Déployer vos charges de travail

Pour déployer vos charges de travail, nous vous recommandons l'une des approches suivantes :

  • Mettre en œuvre un processus de déploiement sur Google Cloud.
  • Refactoriser vos processus de déploiement existants pour déployer des charges de travail dans votre environnement GKE.

La phase de déploiement permet également de moderniser vos processus de déploiement et vos charges de travail. Par exemple, si vous utilisez des pods dans votre environnement, envisagez de migrer ces charges de travail vers des déploiements Kubernetes.

Pour en savoir plus sur la refactorisation des processus de déploiement, consultez la page Migrer vers Google Cloud : migrer des déploiements manuels vers des conteneurs et l'automatisation. Elle contient des conseils pour une transition des déploiements manuels aux outils d'orchestration de conteneurs ainsi qu'à l'automatisation.

Lorsque vos processus de déploiement sont prêts, vous pouvez déployer vos charges de travail sur GKE.

Mettre en œuvre un processus de déploiement sur Google Cloud

Pour mettre en œuvre vos processus de déploiement sur Google Cloud, utilisez l'évolutivité, les opérations gérées et la sécurité de la conception des produits Google Cloud.

Pour en savoir plus sur la mise en œuvre de vos processus de déploiement sur Google Cloud, consultez les pages suivantes :

Refactoriser vos processus de déploiement existants

Bien que cela ne soit pas strictement nécessaire pour un résultat réussi, vous pouvez également refactoriser vos processus de déploiement pendant la migration. Par exemple, vous pouvez moderniser et automatiser vos processus de déploiement existants, et les mettre en œuvre sur Google Cloud.

La migration de vos processus de déploiement vers Google Cloud en même temps que la migration des charges de travail peut s'avérer complexe et augmenter le risque d'échec de la migration. Pour les migrations particulièrement complexes, vous pouvez également envisager de migrer votre processus de déploiement en une seconde fois, puis de continuer à utiliser vos charges de travail actuelles pour déployer des charges de travail dans votre environnement GKE. Cette approche vous permet de réduire la complexité de la migration. En continuant à utiliser vos processus de déploiement existants, vous pouvez simplifier le processus de migration.

Valider vos charges de travail

Après avoir déployé des charges de travail dans votre environnement GKE, mais avant de les exposer à vos utilisateurs, nous vous recommandons d'effectuer une validation et des tests étendus. Ces tests peuvent vous aider à vérifier que vos charges de travail se comportent comme prévu. Par exemple, vous pouvez :

  • Effectuer des tests d'intégration, des tests de charge, des tests de conformité, des tests de fiabilité et d'autres procédures de vérification qui vous aident à vérifier que vos charges de travail fonctionnent dans les paramètres attendus et conformément à leurs spécifications.
  • Examiner les journaux, les métriques et les rapports d'erreurs dans Google Cloud Observability pour identifier les problèmes potentiels et repérer les tendances pour anticiper les problèmes avant qu'ils ne surviennent.

Pour en savoir plus sur la validation des charges de travail, consultez la page Tests de fiabilité.

Exposer vos charges de travail

Une fois les tests de validation des charges de travail exécutés dans votre environnement GKE terminés, exposez vos charges de travail pour les rendre accessibles.

Pour exposer les charges de travail exécutées dans votre environnement GKE, vous pouvez utiliser les services Kubernetes et un maillage de services.

Pour plus d'informations sur la manière dont GKE est compatible avec les services Kubernetes, consultez la page Services.

Pour en savoir plus sur l'exposition de charges de travail exécutées dans GKE, consultez les pages suivantes :

Transférer le trafic vers votre environnement Google Cloud

Après avoir vérifié que les charges de travail s'exécutent dans votre environnement GKE et après les avoir exposées à des clients, vous transférez le trafic de votre environnement source vers votre environnement GKE. Pour vous aider à éviter les migrations à grande échelle et tous les risques associés, nous vous recommandons de déplacer progressivement le trafic de votre environnement source vers votre GKE.

Selon votre conception de l'environnement GKE, vous disposez de plusieurs options pour mettre en œuvre un mécanisme d'équilibrage de charge qui déplace progressivement le trafic de votre environnement source vers votre environnement cible. Par exemple, vous pouvez mettre en œuvre une règle de résolution DNS qui résout les enregistrements DNS en fonction d'une règle afin de résoudre un certain pourcentage de requêtes adressées aux adresses IP appartenant à votre environnement GKE. Vous pouvez également mettre en œuvre un mécanisme d'équilibrage de charge à l'aide d'adresses IP virtuelles et d'équilibreurs de charge réseau.

Une fois que vous avez commencé à basculer progressivement le trafic vers votre environnement GKE, nous vous recommandons de surveiller le comportement de vos charges de travail à mesure que leurs charges augmentent.

Enfin, vous effectuez un basculement, qui se produit lorsque vous déplacez tout le trafic de votre environnement source vers votre environnement GKE.

Pour en savoir plus sur l'équilibrage de charge, consultez la page Équilibrage de charge au niveau de l'interface.

Mettre hors service l'environnement source

Une fois que les charges de travail de votre environnement GKE diffusent correctement les requêtes, vous mettez hors service votre environnement source.

Avant de commencer la mise hors service des ressources dans votre environnement source, nous vous recommandons d'effectuer les opérations suivantes :

  • Sauvegardez toutes les données pour vous aider à restaurer les ressources dans votre environnement source.
  • Informez vos utilisateurs avant de mettre hors service l'environnement.

Pour mettre hors service votre environnement source, procédez comme suit :

  1. Mettez hors service les charges de travail exécutées dans les clusters de votre environnement source.
  2. Supprimez les clusters de votre environnement source.
  3. Supprimez les ressources associées à ces clusters, telles que les groupes de sécurité, les équilibreurs de charge et les réseaux virtuels.

Pour éviter de laisser des ressources orphelines, l'ordre dans lequel vous mettez les ressources hors service dans l'environnement source est important. Par exemple, certains fournisseurs exigent la mise hors service des services Kubernetes qui entraînent la création d'équilibreurs de charge avant de pouvoir mettre hors service les réseaux virtuels contenant ces équilibreurs de charge.

Optimiser votre environnement

L'optimisation est la dernière phase de votre migration. Dans cette phase, vous améliorez l'efficacité de votre environnement. Vous exécutez ici plusieurs itérations d'une boucle reproductible jusqu'à ce que votre environnement réponde à vos exigences d'optimisation. Les étapes de cette boucle reproductible sont les suivantes :

  1. Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation.
  2. Définir vos exigences et vos objectifs d'optimisation
  3. Optimiser votre environnement et vos équipes
  4. Ajuster la boucle d'optimisation

Les sections suivantes s'appuient sur la page Migrer vers Google Cloud : optimiser votre environnement.

Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation

Tandis que la première évaluation porte sur la migration de votre environnement vers GKE, cette seconde évaluation est plutôt adaptée à la phase d'optimisation.

Définir vos exigences d'optimisation

Examinez les exigences d'optimisation suivantes pour votre environnement GKE :

  • Mettre en œuvre des processus de déploiement avancés. Des processus tels que les déploiements Canary ou les déploiements bleus-verts vous offrent davantage de flexibilité et peuvent améliorer la fiabilité de votre environnement, étendre la portée des tests et réduire l'impact des problèmes pour vos utilisateurs.
  • Configurer un maillage de services. En introduisant un maillage de services dans votre environnement, vous utilisez des fonctionnalités comme l'observabilité, la gestion du trafic et l'authentification mutuelle pour vos services, et vous réduisez la pression sur vos équipes DevOps. Vous pouvez déployer un maillage de services multicluster pour mieux segmenter vos charges de travail, ou un maillage de services étendu pour prendre en charge votre migration vers le nouvel environnement.
  • Configurer le scaling automatique. Vous disposez de différentes options pour effectuer un scaling automatique de votre environnement GKE. Vous pouvez faire un scaling automatique de vos clusters et des charges de travail dans chaque cluster. En configurant l'autoscaler de cluster, vous pouvez redimensionner automatiquement un cluster GKE en fonction des exigences de vos charges de travail, en ajoutant ou en supprimant des nœuds de calcul sur le cluster. Si vous souhaitez effectuer un scaling automatique de vos charges de travail, ajustez la demande et les limites de consommation de processeur et de mémoire avec l'autoscaler de pods verticaux. Lorsque vous utilisez l'autoscaler, vous n'avez pas à vous préoccuper des valeurs à spécifier pour les demandes de ressources de processeur et de mémoire de chaque conteneur. Vous pouvez également exporter les métriques fournies par l'autoscaler vers des charges de travail GKE de taille adaptée à grande échelle.
  • Réduire les coûts grâce aux machines virtuelles (VM) préemptives. Si certaines de vos charges de travail tolèrent les environnements d'exécution sans garantie de disponibilité, envisagez de les déployer dans un pool de nœuds composé de VM préemptives. Les VM préemptives sont moins coûteuses que les VM Compute Engine standards, ce qui vous permet de réduire les coûts de vos clusters.
  • Intégrer GKE à d'autres produits. Certains produits Google Cloud peuvent s'intégrer à GKE pour renforcer la sécurité de votre environnement. Par exemple, vous pouvez analyser les failles des conteneurs ou utiliser des images de base gérées dans Container Registry.
  • Concevoir des clusters GKE interchangeables. En tenant compte du caractère interchangeable de vos clusters et en automatisant leur provisionnement et leur configuration, vous pouvez optimiser et généraliser les processus opérationnels pour les gérer, et simplifier les futures migrations et mises à niveau des clusters GKE. Par exemple, si vous devez mettre à niveau un cluster GKE interchangeable vers une nouvelle version de GKE, vous pouvez provisionner et configurer automatiquement un nouveau cluster mis à niveau, déployer automatiquement les charges de travail dans le nouveau cluster et mettre hors service l'ancien cluster GKE obsolète.

  • Concevoir un environnement multicluster En mettant en œuvre un environnement multicluster sur GKE, vous obtenez les avantages suivants :

    • Réduisez les risques d'introduction de points de défaillance uniques dans votre architecture.
    • Profitez de la plus grande flexibilité dans la possibilité de tester les modifications de configuration sur un sous-ensemble de vos clusters GKE.
    • Répartissez les charges de travail sur les clusters GKE.

Bien que vous puissiez répondre à certaines de ces exigences d'optimisation dans un environnement Kubernetes, cela est plus facile dans GKE, car vous n'avez aucun effort à faire pour garantir l'exécution du cluster. Vous pouvez vous concentrer sur l'optimisation elle-même.

Terminer l'optimisation

Après avoir renseigné la liste de vos exigences d'optimisation, accomplissez les autres étapes de la phase d'optimisation.

Étape suivante