Migrer depuis AWS vers Google Cloud : migrer depuis Amazon EKS vers GKE

Last reviewed 2024-08-02 UTC

Google Cloud fournit des outils, des produits, des conseils et des services professionnels pour migrer d'Amazon Elastic Kubernetes Service (Amazon EKS) vers Google Kubernetes Engine (GKE). Ce document vous aide à concevoir, implémenter et valider un plan de migration d'Amazon EKS vers GKE. Il fournit également des conseils si vous étudiez l'opportunité d'effectuer une migration et si vous souhaitez découvrir à quoi elle pourrait ressembler. Outre l'exécution sur Amazon Elastic Compute Cloud (Amazon EC2), Amazon EKS propose quelques autres options de déploiement, telles que Amazon EKS sur AWS Outposts et Amazon EKS Anywhere. Ce document se concentre sur Amazon EKS sur EC2.

Ce document fait partie d'une série d'articles sur la migration depuis AWS vers Google Cloud, qui comprend les documents suivants :

GKE est un service Kubernetes géré par Google que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées à grande échelle à l'aide de l'infrastructure de Google. Il fournit des fonctionnalités qui vous aident à gérer votre environnement Kubernetes, par exemple:

  • Deux éditions: GKE Standard et GKE Enterprise. Avec GKE Standard, vous bénéficiez d'un niveau standard de fonctionnalités de base. Avec GKE Enterprise, vous avez accès à toutes les fonctionnalités de GKE. Pour en savoir plus, consultez la page Éditions GKE.
  • Deux modes de fonctionnement: Standard et Autopilot. Avec Standard, vous gérez l'infrastructure sous-jacente et la configuration de chaque nœud de votre cluster GKE. Avec Autopilot, GKE gère l'infrastructure sous-jacente, comme la configuration des nœuds, l'autoscaling, les mises à niveau automatiques, la sécurité de référence et la configuration réseau. Pour en savoir plus sur les modes de fonctionnement de GKE, consultez la section Choisir un mode de fonctionnement GKE.
  • Contrat de niveau de service unique dans le secteur pour les pods lorsque vous utilisez Autopilot dans plusieurs zones.
  • Création et suppression automatiques des pools de nœuds avec le provisionnement automatique des nœuds.
  • La mise en réseau multicluster gérée par Google pour vous aider à concevoir et à implémenter des architectures distribuées disponibilité élevée pour vos charges de travail.

Pour en savoir plus sur GKE, consultez la présentation de GKE.

Pour cette migration vers Google Cloud, nous vous recommandons de suivre le framework décrit dans la section Migrer vers Google Cloud : premiers pas.

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases.

Vous pouvez migrer depuis votre environnement source vers Google Cloud dans une série d'itérations. Par exemple, vous pouvez commencer par migrer certaines charges de travail, et en migrer d'autres ultérieurement. Pour chaque itération de migration distincte, vous suivez les phases du framework de migration général :

  1. Évaluer et découvrir vos charges de travail et vos données
  2. Planifier et établir vos fondations sur Google Cloud
  3. Migrer vos charges de travail et vos données vers Google Cloud
  4. Optimiser votre environnement Google Cloud

Pour en savoir plus sur les phases de ce framework, consultez la page Migrer vers Google Cloud : premiers pas.

Pour concevoir un plan de migration efficace, nous vous recommandons de valider chaque étape du plan et de vous assurer de disposer d'une stratégie de rollback. Pour vous aider à valider votre plan de migration, consultez la page Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration.

Évaluer l'environnement source

Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour migrer votre environnement source vers Google Cloud.

La phase d’évaluation est cruciale pour la réussite de votre migration. Vous devez acquérir une connaissance approfondie des charges de travail que vous souhaitez migrer, de leurs exigences, de leurs dépendances et de votre environnement actuel. Vous devez comprendre votre point de départ pour planifier et exécuter avec succès une migration Google Cloud.

La phase d'évaluation comprend les tâches suivantes :

  1. Dresser un inventaire complet de vos applications
  2. Cataloguer vos charges de travail en fonction de leurs propriétés et de leurs dépendances
  3. Former et préparer vos équipes sur Google Cloud
  4. Créer des tests et des démonstrations de faisabilité sur Google Cloud
  5. Calculer le coût total de possession (TCO) de l'environnement cible
  6. Choisissez la stratégie de migration pour vos charges de travail.
  7. Choisissez vos outils de migration.
  8. Définissez le plan de migration et le calendrier.
  9. Validez votre plan de migration.

Pour en savoir plus sur la phase d'évaluation et ces tâches, consultez la page Migrer vers Google Cloud : évaluer et découvrir vos charges de travail. Les sections suivantes sont basées sur les informations de ce document.

Créer vos inventaires

Pour définir la portée de votre migration, vous devez créer deux inventaires:

  1. L'inventaire de vos clusters.
  2. L'inventaire de vos charges de travail déployées dans ces clusters.

Une fois ces inventaires créés, vous pouvez:

  1. Évaluer vos processus de déploiement et opérationnels pour votre environnement source.
  2. Évaluer les services d'assistance et les dépendances externes.

Créer l'inventaire de vos 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. Identifiez l'image du système d'exploitation que vous utilisez sur vos nœuds.
  • 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 de Kubernetes, 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.
  • Configuration du réseau Évaluez la configuration réseau de vos clusters, leur allocation d'adresses IP, la façon dont vous avez configuré leurs plug-ins réseau, la façon dont vous avez configuré leurs serveurs DNS et leurs fournisseurs de services DNS, si vous avez configuré une forme de NAT ou de SNAT pour ces clusters, et s'ils font partie d'un environnement multi-clusters.
  • Conformité: évaluez les exigences réglementaires et de conformité auxquelles vos clusters doivent répondre, et déterminez si vous y répondez.
  • Quotas et limites Évaluez comment vous avez configuré les quotas et les limites pour vos clusters. Par exemple, combien de pods chaque nœud peut-il exécuter ? Combien de nœuds un cluster peut-il avoir ?
  • Étiquettes et tags. Évaluez les métadonnées que vous avez appliquées aux clusters, aux pools de nœuds et aux nœuds, ainsi que la façon dont vous les utilisez. Par exemple, vous pouvez générer des rapports avec une attribution des coûts détaillée, basée sur des libellés.

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.
  • Compte 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.

Lorsque vous créez l'inventaire de vos clusters Kubernetes, vous pouvez constater que certains clusters doivent être mis hors service lors de votre migration. Assurez-vous que votre plan de migration inclut la suppression de ces ressources.

Créer l'inventaire de vos charges de travail Kubernetes

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 des limites de consommation des ressources de calcul. 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 CronJobs. 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 et l'autoscaler de pods verticaux fonctionnent 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, les objets Gateway 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.
  • 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.
  • Authentification: évaluez la façon dont vos charges de travail s'authentifient auprès des ressources de votre cluster et des ressources externes.

Évaluer les services d'assistance et les dépendances externes

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 provisionnés de manière statique. 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.
  • 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.
  • Sauvegarde Évaluez comment vous sauvegardez la configuration de vos clusters et les données de vos charges de travail avec état dans votre environnement source.

Évaluer vos processus de déploiement et opérationnels

Il est essentiel de bien comprendre leur fonctionnement. Ces processus font partie intégrante des pratiques qui préparent et gèrent votre environnement de production et les charges de travail qui y sont exécutées.

Vos processus de déploiement et opérationnels peuvent créer les artefacts dont vos charges de travail ont besoin pour fonctionner. Par conséquent, vous devez collecter des informations sur chaque type d'artefact. Par exemple, un artefact peut être un package du système d'exploitation, un package de déploiement d'application, une image du système d'exploitation, une image de conteneur ou autre.

Outre le type d'artefact, réfléchissez à la façon dont vous effectuez les tâches suivantes :

  • Développez vos charges de travail. Évaluez les processus mis en place par les équipes de développement pour créer vos charges de travail. Par exemple, comment vos équipes de développement conçoivent-elles, codent-elles et testent-elles vos charges de travail ?
  • Générez les artefacts que vous déployez dans votre environnement source. Pour déployer vos charges de travail dans votre environnement source, vous pouvez générer des artefacts déployables, tels que des images de conteneur ou des images de système d'exploitation, ou vous pouvez personnaliser des artefacts existants, tels que des images de système d'exploitation tiers en installant et en configurant des logiciels. La collecte d'informations sur la manière dont vous générez ces artefacts vous permet de vous assurer qu'ils sont adaptés au déploiement dans Google Cloud.

  • Stockez les artefacts. Si vous produisez des artefacts que vous stockez dans un registre d'artefacts dans votre environnement source, vous devez les rendre disponibles dans votre environnement Google Cloud. Pour ce faire, vous pouvez utiliser des stratégies telles que les suivantes :

    • Établir un canal de communication entre les environnements : rendez les artefacts de votre environnement source accessibles depuis l'environnement Google Cloud cible.
    • Refactoriser le processus de compilation des artefacts : effectuez une refactorisation mineure de votre environnement source afin de pouvoir stocker des artefacts à la fois dans l'environnement source et dans l'environnement cible. Cette approche traite votre migration en créant une infrastructure telle qu'un dépôt d'artefacts avant que vous ayez à implémenter des processus de compilation d'artefacts dans l'environnement Google Cloud cible. Vous pouvez mettre en œuvre cette approche directement ou vous appuyer sur l'approche précédente qui consiste à d'abord établir un canal de communication.

    Le fait de disposer d'artefacts disponibles dans les environnements source et cible vous permet de vous concentrer sur la migration sans avoir à implémenter de processus de compilation d'artefacts dans l'environnement Google Cloud cible dans le cadre de la migration.

  • Scanner et signer le code. Dans le cadre de vos processus de compilation d'artefacts, vous pouvez utiliser l'analyse de code pour vous protéger contre les failles courantes et l'exposition involontaire au réseau, et la signature de code pour vous assurer que seul le code approuvé s'exécute dans vos environnements.

  • Déployez des artefacts dans votre environnement source. Après avoir généré des artefacts déployables, vous pouvez les déployer dans votre environnement source. Nous vous recommandons d'évaluer chaque processus de déploiement. L'évaluation permet de s'assurer que vos processus de déploiement sont compatibles avec Google Cloud. Elle vous permet également de comprendre les efforts nécessaires pour refactoriser les processus à terme. Par exemple, si vos processus de déploiement ne fonctionnent qu'avec votre environnement source, vous devrez peut-être les refactoriser pour cibler votre environnement Google Cloud.

  • L'injection d'une configuration d'exécution. Vous pouvez injecter une configuration d'environnement d'exécution pour des clusters, des environnements d'exécution ou des déploiements de charges de travail spécifiques. La configuration peut initialiser des variables d'environnement et d'autres valeurs de configuration telles que des secrets, des identifiants et des clés. Pour vous assurer que vos processus d'injection de configuration d'environnement d'exécution fonctionnent sur Google Cloud, nous vous recommandons d'évaluer la façon dont vous configurez les charges de travail exécutées dans votre environnement source.

  • Journalisation, surveillance et profilage Évaluez les processus de journalisation, de surveillance et de profilage que vous avez mis en place pour surveiller l'état de votre environnement source, les métriques d'intérêt et la façon dont vous consommez les données fournies par ces processus.

  • Authentification Évaluez la façon dont vous vous authentifiez auprès de votre environnement source.

  • Provisionnez et configurez vos ressources. Pour préparer votre environnement source, vous avez peut-être conçu et implémenté des processus de provisionnement et de configuration des ressources. Par exemple, vous pouvez utiliser Terraform avec des outils de gestion de la configuration pour provisionner et configurer des ressources dans votre environnement source.

Outils permettant de dresser l'inventaire de votre environnement source

Pour créer l'inventaire de vos clusters Amazon EKS, nous vous recommandons d'utiliser le Centre de migration, la plate-forme unifiée de Google Cloud qui vous aide à accélérer votre transition vers le cloud de bout en bout, de votre environnement actuel vers Google Cloud. Migration Center vous permet d'importer des données depuis Amazon EKS et d'autres ressources AWS. Migration Center recommande ensuite des services Google Cloud pertinents vers lesquels migrer.

Affiner l'inventaire de vos clusters et charges de travail Amazon EKS

Les données fournies par le centre de migration ne couvrent peut-être pas entièrement les dimensions qui vous intéressent. Dans ce cas, vous pouvez intégrer ces données aux résultats d'autres mécanismes de collecte de données que vous créez et qui sont basés sur les API AWS, les outils pour les développeurs AWS et l'interface de ligne de commande AWS.

En plus des données obtenues à partir du centre de migration, tenez compte des points de données suivants pour chaque cluster Amazon EKS que vous souhaitez migrer :

  • Examinez les aspects et les fonctionnalités spécifiques à chaque cluster Amazon EKS, y compris les suivants :
    • Clusters privés
    • Contrôle des accès au point de terminaison du cluster
    • Chiffrement de secrets
    • Groupes de nœuds gérés et nœuds autogérés
    • Tags sur les ressources Amazon EKS
    • AMI Amazon personnalisées dans EKS
    • Utilisation d'Amazon EKS Fargate
    • Utilisation d'Amazon EKS Managed Prometheus
    • Configuration de l'authentification OpenID Connect
  • Évaluez la façon dont vous vous authentifiez auprès des clusters Amazon EKS et la manière dont vous avez configuré AWS Identity and Access Management (IAM) pour Amazon EKS.
  • Évaluez la configuration réseau de vos clusters Amazon EKS.

Planifier et établir vos fondations

Au cours de la phase de planification et de compilation, vous provisionnez et configurez l'infrastructure pour effectuer les opérations suivantes :

  • Exécuter vos charges de travail dans votre environnement Google Cloud
  • Se connecter à votre environnement source et à votre environnement Google Cloud pour effectuer la migration

La phase de planification et de compilation est composée des tâches suivantes :

  1. Créez une hiérarchie de ressources.
  2. Configurer Identity and Access Management (IAM) de Google Cloud
  3. Configurer la facturation
  4. Configurez la connectivité réseau.
  5. Renforcez votre sécurité.
  6. Configurer la journalisation, la surveillance et les alertes

Pour en savoir plus sur chacune de ces tâches, consultez la section Migrer vers Google Cloud: planifier et créer vos fondations.

Les sections suivantes intègrent les considérations de la page "Migrer vers Google Cloud: planifier et établir les fondations".

Planifier l'architecture mutualisée

Pour concevoir une hiérarchie de ressources efficace, réfléchissez à la façon dont vos structures métier et organisationnelles correspondent à Google Cloud. 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. Pour plus d'informations, consultez la page Architecture de cluster mutualisée.

Configurer la gestion de l'authentification et des accès

GKE accepte plusieurs options de gestion de l'accès aux ressources de votre projet Google Cloud et de ses clusters par le biais du contrôle des accès basé sur les rôles (RBAC). Pour plus d'informations, consultez la section Contrôle des accès.

Configurer la mise en réseau GKE

La configuration réseau est un aspect essentiel de votre environnement. Avant de provisionner et de configurer un cluster, nous vous recommandons d'évaluer le modèle de réseau GKE, les bonnes pratiques pour la mise en réseau GKE et la façon de planifier les adresses IP lors de la migration vers GKE.

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, la surveillance et le profilage de vos clusters GKE et charges de travail au sein de ces clusters.

Migrer vos données et déployer des 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. Refactorisez vos charges de travail.
  4. Refactorisez les processus de déploiement et opérationnels
  5. Migrez des données de votre environnement source vers Google Cloud.
  6. Déployez vos charges de travail dans l'environnement GKE.
  7. Validez vos charges de travail et votre environnement GKE.
  8. Exposez des charges de travail exécutées sur GKE.
  9. Basculez le trafic de l'environnement source vers l'environnement GKE.
  10. Mettez hors service l'environnement source.

Provisionnez et configurez votre environnement Google Cloud

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

GKE permet d'activer certaines fonctionnalités sur des clusters existants, mais il est possible que certaines fonctionnalités ne puissent être activées qu'au moment de la création du cluster. Pour éviter toute perturbation et simplifier la migration, nous vous recommandons d'activer les fonctionnalités de cluster dont vous avez besoin au moment de la création du cluster. Sinon, vous devrez peut-être détruire et recréer vos clusters si les fonctionnalités de cluster dont vous avez besoin ne peuvent pas être activées après la création d'un cluster.

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. Pour provisionner vos clusters, tenez compte des points suivants:

  • Le nombre de clusters, le nombre de nœuds par cluster, les types de clusters, la configuration de chaque cluster et de 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 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é de chaque cluster.
  • Les fonctionnalités GKE supplémentaires dont vous avez besoin, telles que Cloud 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 :

Gestion de parc

Lorsque vous provisionnez vos clusters GKE, vous pouvez vous rendre compte que vous en avez besoin d'un grand nombre pour prendre en charge tous les cas d'utilisation de votre environnement. Par exemple, vous devrez peut-être séparer les environnements de production et hors production, ou les services entre les équipes ou les zones géographiques. Pour en savoir plus, consultez la section Cas d'utilisation multicluster.

À mesure que le nombre de clusters augmente, votre environnement GKE peut devenir plus difficile à gérer, car la gestion d'un grand nombre de clusters pose des défis d'évolutivité et d'exploitation importants. GKE fournit des outils et des fonctionnalités pour vous aider à gérer les parcs, qui sont des regroupements logiques de clusters Kubernetes. Pour en savoir plus, consultez la section Gestion de parc.

Mise en réseau multicluster

Pour vous aider à améliorer la fiabilité de votre environnement GKE et à répartir vos charges de travail sur plusieurs clusters GKE, vous pouvez utiliser les éléments suivants:

Pour en savoir plus sur la migration d'un environnement GKE à cluster unique vers un environnement GKE multicluster, consultez la section Passer à la mise en réseau multicluster.

Configurez vos clusters GKE.

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. Évaluez si les objets des clusters Kubernetes de votre environnement source sont compatibles avec GKE et comment les implémentations qui les sous-tendent diffèrent de l'environnement source et de GKE.
  3. Refactorisez tout objet incompatible pour le rendre compatible avec GKE ou supprimez-le.
  4. Créez ces objets dans vos clusters GKE.
  5. Configurez tous les objets supplémentaires dont vous avez besoin dans vos clusters GKE.

Config Sync

Pour vous aider à adopter les bonnes pratiques GitOps afin de gérer la configuration de vos clusters GKE à mesure que votre environnement GKE évolue, nous vous recommandons d'utiliser Config Sync, un service GitOps qui permet de déployer des configurations à partir d'une source de vérité. Par exemple, vous pouvez stocker la configuration de vos clusters GKE dans un dépôt Git et utiliser Config Sync pour appliquer cette configuration.

Pour en savoir plus, consultez la section Architecture de Config Sync.

Policy Controller

Policy Controller vous aide à appliquer et à faire respecter des règles programmables pour vous assurer que vos clusters et charges de travail GKE s'exécutent de manière sécurisée et conforme. À mesure que votre environnement GKE évolue, vous pouvez utiliser Policy Controller pour appliquer automatiquement des règles, des bundles de règles et des contraintes à tous vos clusters GKE. Par exemple, vous pouvez limiter les dépôts à partir desquels des images de conteneur peuvent être extraites, ou vous pouvez exiger que chaque espace de noms dispose d'au moins un libellé pour vous aider à assurer un suivi précis de la consommation de ressources.

Pour en savoir plus, consultez la section Policy Controller.

Refactoriser vos charges de travail

Une bonne pratique pour concevoir des charges de travail conteneurisées consiste à éviter les dépendances sur la plate-forme d'orchestration de conteneurs. En pratique, cela n'est pas toujours possible en raison des exigences et de la conception de vos charges de travail. Par exemple, vos charges de travail peuvent dépendre de fonctionnalités spécifiques à l'environnement qui ne sont disponibles que dans votre environnement source, telles que les modules complémentaires, les extensions et les intégrations.

Bien que vous puissiez migrer la plupart des charges de travail telles quelles vers GKE, vous devrez peut-être déployer des efforts supplémentaires pour refactoriser les charges de travail qui dépendent de fonctionnalités spécifiques à l'environnement afin de minimiser ces dépendances, et passer éventuellement à des alternatives disponibles sur GKE.

Pour refactoriser vos charges de travail avant de les migrer vers GKE, procédez comme suit:

  1. Examinez les fonctionnalités spécifiques à l'environnement source, telles que les modules complémentaires, les extensions et les intégrations.
  2. Adoptez des solutions GKE alternatives appropriées.
  3. Refactorisez vos charges de travail.

Examiner les fonctionnalités spécifiques à l'environnement source

Si vous utilisez des fonctionnalités spécifiques à l'environnement source et que vos charges de travail en dépendent, vous devez:

  1. Trouvez des solutions GKE alternatives appropriées.
  2. Refactoriser vos charges de travail afin de pouvoir utiliser les solutions GKE alternatives.

Pour ce faire, nous vous recommandons d'effectuer les opérations suivantes:

  • Déterminez si vous pouvez abandonner l'une de ces fonctionnalités spécifiques à l'environnement source.
  • Évaluez l'importance d'une fonctionnalité spécifique à l'environnement source pour la réussite de la migration.

Adoptez des solutions GKE alternatives appropriées

Après avoir examiné les fonctionnalités spécifiques à votre environnement source et les avoir mappées à des solutions GKE alternatives appropriées, vous adoptez ces solutions dans votre environnement GKE. Pour réduire la complexité de votre migration, nous vous recommandons de procéder comme suit:

  • Évitez d'adopter des solutions GKE alternatives pour les fonctionnalités spécifiques à l'environnement source que vous souhaitez abandonner.
  • Concentrez-vous sur l'adoption de solutions GKE alternatives pour les fonctionnalités les plus critiques spécifiques à l'environnement source, et planifiez des projets de migration dédiés pour le reste.

Refactoriser vos charges de travail

Bien que la plupart de vos charges de travail puissent fonctionner telles quelles dans GKE, vous devrez peut-être en refactoriser certaines, en particulier si elles dépendaient de fonctionnalités spécifiques à l'environnement source pour lesquelles vous avez adopté des solutions GKE alternatives.

Ce refactoring peut impliquer les éléments suivants:

  • Les descripteurs d'objets Kubernetes, tels que les déploiements et les services, exprimés au format YAML.
  • Déscripteurs d'images de conteneur, tels que les fichiers Dockerfile et Containerfile.
  • Code source des charges de travail

Pour simplifier l'effort de refactoring, nous vous recommandons de vous concentrer sur l'application du moins de modifications possible pour adapter vos charges de travail à GKE et pour corriger les bugs critiques. Vous pouvez planifier d'autres améliorations et modifications dans le cadre de futurs projets.

Refactoriser les processus de déploiement et opérationnels

Après avoir refactorisé vos charges de travail, vous devez refactoriser vos processus de déploiement et d'exploitation pour effectuer les opérations suivantes:

  • Provisionnez et configurez des ressources dans votre environnement Google Cloud au lieu de le faire dans votre environnement source.
  • Créez et configurez des charges de travail, puis déployez-les dans Google Cloud au lieu de les déployer dans votre environnement source.

Vous avez recueilli des informations sur ces processus lors de la phase d'évaluation plus tôt dans ce processus.

Le type de refactoring que vous devez envisager pour ces processus dépend de la façon dont vous les avez conçus et implémentés. La refactorisation dépend également de l'état final que vous souhaitez pour chaque processus. Nous vous conseillons, par exemple, de suivre les recommandations suivantes :

  • Vous avez peut-être mis en œuvre ces processus dans votre environnement source, et vous avez l'intention de concevoir et de mettre en œuvre des processus équivalents dans Google Cloud. Par exemple, vous pouvez refactoriser ces processus pour utiliser Cloud Build, Cloud Deploy et Infrastructure Manager.
  • Vous avez peut-être implémenté ces processus dans un autre environnement tiers en dehors de votre environnement source. Dans ce cas, vous devez refactoriser ces processus pour cibler votre environnement Google Cloud au lieu de votre environnement source.
  • Une combinaison des approches précédentes.

La refactorisation des processus de déploiement et opérationnels peut être complexe et nécessiter un effort considérable. Si vous essayez d'effectuer ces tâches lors de la migration de votre charge de travail, celle-ci peut devenir plus complexe et vous exposer à des risques. Après avoir évalué vos processus de déploiement et opérationnels, vous comprenez probablement leur conception et leur complexité. Si vous estimez que vous avez besoin d'un effort considérable pour refactoriser vos processus de déploiement et opérationnels, nous vous recommandons de refactoriser ces processus au cours d'un projet distinct dédié.

Pour en savoir plus sur la conception et la mise en œuvre des processus de déploiement sur Google Cloud, consultez les ressources suivantes:

Ce document se concentre sur les processus de déploiement qui produisent les artefacts à déployer et les déploient dans l'environnement d'exécution cible. La stratégie de refactoring dépend fortement de la complexité de ces processus. La liste suivante décrit une stratégie de refactoring générale possible:

  1. Provisionnez des dépôts d'artefacts sur Google Cloud. Par exemple, vous pouvez utiliser Artifact Registry pour stocker des artefacts et créer des dépendances.
  2. Refactorisez vos processus de compilation pour stocker des artefacts à la fois dans votre environnement source et dans Artifact Registry.
  3. Refactorisez vos processus de déploiement pour déployer vos charges de travail dans votre environnement Google Cloud cible. Par exemple, vous pouvez commencer par déployer un petit sous-ensemble de vos charges de travail dans Google Cloud, à l'aide d'artefacts stockés dans Artifact Registry. Vous augmentez ensuite progressivement le nombre de charges de travail déployées dans Google Cloud, jusqu'à ce que toutes les charges de travail à migrer s'exécutent sur Google Cloud.
  4. Refactorisez vos processus de compilation pour stocker les artefacts dans Artifact Registry uniquement.
  5. Si nécessaire, migrez les versions antérieures des artefacts à déployer depuis les dépôts de votre environnement source vers Artifact Registry. Par exemple, vous pouvez copier des images de conteneur dans Artifact Registry.
  6. Mettez hors service les dépôts de votre environnement source lorsque vous n'en avez plus besoin.

Pour faciliter les éventuels rollbacks en raison de problèmes imprévus lors de la migration, vous pouvez stocker des images de conteneurs à la fois dans vos dépôts d'artefacts actuels dans Google Cloud pendant la migration vers Google Cloud. Enfin, dans le cadre du décommissionnement de votre environnement source, vous pouvez refactoriser vos processus de création d'images de conteneur pour stocker des artefacts uniquement dans Google Cloud.

Bien que cela ne soit pas essentiel à la réussite d'une migration, vous devrez peut-être migrer vos versions antérieures d'artefacts depuis votre environnement source vers vos dépôts d'artefacts sur Google Cloud. Par exemple, pour permettre le rollback de vos charges de travail à des moments arbitraires, vous devrez peut-être migrer les versions antérieures de vos artefacts vers Artifact Registry. Pour en savoir plus, consultez la page Migrer des images à partir d'un registre tiers.

Si vous utilisez Artifact Registry pour stocker vos artefacts, nous vous recommandons de configurer des contrôles pour vous aider à sécuriser vos dépôts d'artefacts, tels que le contrôle des accès, la prévention de l'exfiltration de données, l'analyse des failles et l'autorisation binaire. Pour en savoir plus, consultez la section Contrôler l'accès et protéger les artefacts.

Migrer les données

GKE est compatible avec plusieurs services de stockage de données, tels que le stockage de blocs, le stockage de blocs bruts, le stockage de fichiers et le stockage d'objets. Pour en savoir plus, consultez la présentation du stockage pour les clusters GKE.

Pour migrer des données vers votre environnement GKE, procédez comme suit:

  1. Provisionnez et configurez toute l'infrastructure de stockage nécessaire.
  2. Configurez des provisionneurs StorageClass dans vos clusters GKE. Tous les approvisionneurs StorageClass ne sont pas compatibles avec tous les environnements. Avant de déployer un provisionneur StorageClass, nous vous recommandons d'évaluer sa compatibilité avec GKE et ses dépendances.
  3. Configurez des StorageClasses.
  4. Configurez des PersistentVolumes et des PersistentVolumeClaims pour stocker les données à migrer.
  5. Migrez les données de votre environnement source vers ces PersistentVolumes. Les spécificités de cette migration de données dépendent des caractéristiques de l'environnement source.

Pour migrer des données de votre environnement source vers votre environnement Google Cloud, 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.

Migrer des données depuis EKS vers GKE

AWS propose plusieurs options de stockage de données pour Amazon EKS. Ce document se concentre sur les scénarios de migration de données suivants :

  • Migrer les données depuis des volumes Amazon EBS vers des ressources GKE PersistentVolume
  • Copier les données des volumes Amazon EBS vers Amazon S3 ou Cloud Storage, puis les migrer vers des ressources GKE PersistentVolume
Migrer les données depuis des volumes Amazon EBS vers des ressources GKE PersistentVolumes

Vous pouvez migrer des données depuis des volumes Amazon EBS vers des ressources GKE PersistentVolume à l'aide de l'une des approches suivantes :

  • Copier directement les données des volumes Amazon EBS sur des disques persistants Compute Engine :
    1. Provisionnez des instances Amazon EC2 et associez les volumes Amazon EBS contenant les données à migrer.
    2. Provisionnez des instances Compute Engine avec des disques persistants vides disposant d'une capacité suffisante pour stocker les données à migrer.
    3. Exécutez un outil de synchronisation de données, tel que rsync, pour copier les données des volumes Amazon EBS sur les disques persistants Compute Engine.
    4. Dissociez les disques persistants des instances Compute Engine.
    5. Mettre hors service les instances Compute Engine.
    6. Configurez les disques persistants en tant que ressources GKE PersistentVolume.
  • Migrer des instances Amazon EC2 et des volumes Amazon EBS vers Compute Engine :
    1. Provisionnez des instances Amazon EC2 et associez les volumes Amazon EBS contenant les données à migrer.
    2. Migrez les instances Amazon EC2 et les volumes Amazon EBS vers Compute Engine avec Migrate to Virtual Machines.
    3. Dissociez les disques persistants des instances Compute Engine.
    4. Mettre hors service les instances Compute Engine.
    5. Configurez les disques persistants en tant que ressources GKE PersistentVolume.

Pour en savoir plus sur la migration d'instances Amazon EC2 vers Compute Engine, consultez la page Migrer depuis AWS vers Google Cloud : migrer depuis Amazon EC2 vers Compute Engine.

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

Copier les données de volumes Amazon EBS sur un support provisoire et les migrer vers des PersistentVolumes GKE

Au lieu d'effectuer la migration directement depuis des volumes Amazon EBS vers des ressources GKE PersistentVolume, vous pouvez utiliser un support provisoire comme un magasin d'objets :

  1. Importez les données des volumes Amazon EBS vers un support provisoire (par exemple, un bucket Amazon S3 ou Cloud Storage).
  2. Téléchargez les données du support provisoire sur vos ressources GKE PersistentVolume.

Dans certains cas, l'utilisation de plusieurs supports peut simplifier le transfert de données en fonction de vos configurations réseau et de sécurité. Vous pouvez par exemple importer les données dans un bucket S3, les copier depuis le bucket S3 vers un bucket Cloud Storage, puis les télécharger dans vos volumes persistants. Quelle que soit l'approche choisie, pour garantir une transition fluide tout en prenant en compte des considérations importantes, nous vous recommandons de consulter la page Migrer depuis AWS vers Google Cloud : migrer depuis Amazon S3 vers Cloud Storage.

Choisir une option de migration

L'option de migration la mieux adaptée dépend de vos besoins et de vos exigences spécifiques, y compris les suivants :

  • La quantité de données à migrer.
    • Si vous devez migrer une petite quantité de données, par exemple quelques fichiers de données, envisagez d'utiliser des outils tels que rsync pour copier les données directement sur des disques persistants Compute Engine. Cette option est relativement rapide, mais elle peut ne pas convenir pour une grande quantité de données.
    • Si vous devez migrer une grande quantité de données, envisagez d'utiliser Migrate to Virtual Machines pour migrer les données vers Compute Engine. Cette option est plus complexe que la copie directe des données, mais elle est plus fiable et évolutive.
  • Le type de données à migrer.
  • La connectivité réseau entre les environnements source et cible.
    • Si vous ne parvenez pas à établir une connectivité réseau directe entre vos instances AWS EC2 et Compute Engine, vous pouvez envisager d'utiliser Amazon S3 ou Cloud Storage pour stocker temporairement les données pendant leur migration vers Compute Engine. Cette option peut être moins coûteuse, car vous n'aurez pas à exécuter simultanément vos instances EC2 et Compute Engine.
  • Votre calendrier de migration.
    • Si votre bande passante réseau est limitée ou si vous disposez d'une grande quantité de données, et que votre calendrier n'est pas serré, vous pouvez également envisager d'utiliser Transfer Appliance pour déplacer vos données d'AWS vers Google Cloud.

Quelle que soit l'option choisie, il est important de tester votre migration avant de la publier. Les tests vous aideront à identifier les problèmes potentiels et à garantir la réussite de votre migration.

Déployer vos charges de travail

Lorsque vos processus de déploiement sont prêts, vous déployez vos charges de travail sur GKE. Pour en savoir plus, consultez la page Présentation du déploiement des charges de travail.

Pour préparer les charges de travail à déployer pour GKE, nous vous recommandons d'analyser vos descripteurs Kubernetes, car certaines ressources Google Cloud provisionnées automatiquement par GKE pour vous sont configurables à l'aide des libellés et des annotations Kubernetes, au lieu de devoir provisionner manuellement ces ressources. Par exemple, vous pouvez provisionner un équilibreur de charge interne plutôt qu'externe en ajoutant une annotation à un service LoadBalancer.

Validez 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 approfondis. 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 que vous avez terminé les tests de validation des charges de travail exécutées dans votre environnement GKE, exposez-les pour les rendre accessibles.

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

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

Déplacer 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 aux 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 transférer progressivement le trafic de votre environnement source vers votre GKE.

En fonction de la conception de votre environnement GKE, vous disposez de plusieurs options pour implémenter un mécanisme d'équilibrage de charge qui transfère progressivement le trafic de votre environnement source vers votre environnement cible. Par exemple, vous pouvez implémenter une stratégie de résolution DNS qui résout les enregistrements DNS en fonction d'une stratégie pour résoudre un certain pourcentage de requêtes vers des adresses IP appartenant à votre environnement GKE. Vous pouvez également implémenter 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é à transférer progressivement le trafic vers votre environnement GKE, nous vous recommandons de surveiller le comportement de vos charges de travail à mesure que leur charge augmente.

Enfin, vous effectuez une transition, qui se produit lorsque vous transférez tout le trafic de votre environnement source vers votre environnement GKE.

Pour en savoir plus sur l'équilibrage de charge, consultez la section É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 répondent correctement aux 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. Décommissionnez 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 hors service les ressources dans votre environnement source est important. Par exemple, certains fournisseurs exigent que vous désinstalliez les services Kubernetes qui génèrent des équilibreurs de charge avant de pouvoir désinstaller les réseaux virtuels qui les contiennent.

Optimiser votre environnement Google Cloud

L'optimisation est la dernière phase de votre migration. Au cours de cette phase, vous effectuez des itérations sur les tâches d'optimisation jusqu'à ce que votre environnement réponde à vos exigences d'optimisation. Les étapes de chaque itération 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

Vous devez répéter cette séquence jusqu'à ce que vous ayez atteint vos objectifs d'optimisation.

Pour en savoir plus sur l'optimisation de votre environnement Google Cloud, consultez la section Migrer vers Google Cloud : optimiser votre environnement et Processus d'optimisation des performances.

Les sections suivantes intègrent les considérations de la page "Migrer vers Google Cloud: optimiser votre environnement".

Définir vos exigences d'optimisation

Les exigences d'optimisation vous aident à affiner le champ d'application de l'itération d'optimisation en cours. Pour en savoir plus sur les exigences et les objectifs d'optimisation, consultez la section Définir vos exigences et objectifs d'optimisation.

Pour définir vos exigences d'optimisation pour votre environnement GKE, commencez par examiner les aspects suivants:

  • Sécurité, confidentialité et conformité: vous aident à améliorer la stratégie de sécurité de votre environnement GKE.
  • Fiabilité: vous aide à améliorer la disponibilité, l'évolutivité et la résilience de votre environnement GKE.
  • Optimisation des coûts: vous aide à optimiser la consommation de ressources et les dépenses générées par votre environnement GKE.
  • Efficacité opérationnelle: vous aide à gérer et à exploiter efficacement votre environnement GKE.
  • Optimisation des performances: vous aide à optimiser les performances des charges de travail déployées dans votre environnement GKE.

Sécurité, confidentialité et conformité

Fiabilité

  • Améliorez la fiabilité de vos clusters. Pour vous aider à concevoir un GKE plus résilient aux pannes zonales peu probables, privilégiez les clusters régionaux aux clusters zonaux ou multizones.
  • Sauvegarde et restauration de la charge de travail Configurez un workflow de sauvegarde et de restauration des charges de travail avec Sauvegarde pour GKE.

Optimisation des coûts

Pour en savoir plus sur l'optimisation des coûts de votre environnement GKE, consultez les pages suivantes:

Efficacité opérationnelle

Pour vous aider à éviter les problèmes qui affectent votre environnement de production, nous vous recommandons de:

  • 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.
  • Surveillez les métriques qui vous intéressent. Assurez-vous que toutes les métriques d'intérêt concernant vos charges de travail et vos clusters sont correctement collectées. Vérifiez également que toutes les alertes pertinentes qui utilisent ces métriques comme entrées sont en place et fonctionnent.

Pour en savoir plus sur la configuration de la surveillance, de la journalisation et du profilage dans votre environnement GKE, consultez les pages suivantes:

Optimisation des performances

  • Configurez l'autoscaling de cluster et le provisionnement automatique des nœuds. Redimensionnez automatiquement votre cluster GKE en fonction de la demande à l'aide de l'autoscaling de cluster et du provisionnement automatique des nœuds.
  • Scaling automatique des charges de travail. GKE est compatible avec plusieurs mécanismes de scaling, par exemple :

Pour en savoir plus, consultez la section À propos de l'évolutivité de GKE.

Étape suivante

Contributeurs

Auteurs :