Migrer des conteneurs vers Google Cloud : migrer vers un environnement GKE multicluster

Last reviewed 2023-05-08 UTC

Ce document vous aide à planifier, concevoir et mettre en œuvre votre migration d'un environnement Google Kubernetes Engine (GKE) vers un nouvel environnement GKE. Sans une sérieuse préparation, 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. Pour obtenir une présentation de la série, consultez la page Migration 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 GKE vers un autre environnement GKE. Ce document est également utile si vous évaluez l'opportunité d'effectuer une migration et si vous souhaitez découvrir à quoi elle pourrait ressembler.

Les raisons de migrer d'un environnement GKE vers un autre environnement GKE peuvent être les suivantes :

  • Activer les fonctionnalités de GKE disponibles uniquement lors de la création de clusters. GKE évolue constamment avec de nouvelles fonctionnalités et des correctifs de sécurité. Pour bénéficier de la plupart des nouvelles fonctionnalités et corrections, vous devrez peut-être mettre à niveau vos clusters et vos pools de nœuds GKE vers une version plus récente de GKE, par le biais d'une mise à niveau automatique ou manuelle.

    Certaines nouvelles fonctionnalités de GKE ne peuvent pas être activées sur les clusters existants. Vous devez donc créer des clusters GKE avec ces nouvelles fonctionnalités activées. Par exemple, vous pouvez activer la Mise en réseau de VPC natif dans GKE,Dataplane V2 ou Dissimuler des métadonnées uniquement lorsque vous créez des clusters. Vous ne pouvez pas mettre à jour la configuration des clusters existants pour activer ces fonctionnalités après leur création.

  • Mettre en œuvre un processus de provisionnement et de configuration automatisé pour votre infrastructure. Si vous provisionnez et configurez manuellement votre infrastructure, vous pouvez concevoir et mettre en œuvre un processus automatisé de provisionnement et de configuration de vos clusters GKE, plutôt que de recourir à des méthodes manuelles sujettes à erreurs.

Lorsque vous concevez l'architecture de votre nouvel environnement, nous vous recommandons d'envisager d'utiliser un environnement GKE multicluster. En provisionnant et en configurant plusieurs clusters GKE dans votre environnement, vous obtenez les avantages suivants :

  • Réduisez les risques d'introduction d'un point de défaillance unique dans votre architecture. Par exemple, si un cluster subit une panne, d'autres clusters peuvent prendre le relais.
  • Profitez d'une plus grande flexibilité offerte par un environnement multicluster. Par exemple, en appliquant des modifications à un sous-ensemble de vos clusters, vous pouvez limiter l'impact des problèmes causés par des modifications de configuration erronées. Vous pouvez ensuite valider les modifications avant de les appliquer à vos clusters restants.
  • Laissez vos charges de travail communiquer entre les clusters. Par exemple, les charges de travail déployées dans un cluster peuvent communiquer avec les charges de travail déployées dans un autre cluster.

Les instructions de ce document s'appliquent également à un environnement GKE à cluster unique. Lorsque vous effectuez une migration vers un environnement GKE à cluster unique, votre environnement est moins complexe à gérer qu'un environnement multicluster. Toutefois, un environnement à cluster unique ne bénéficie pas de la flexibilité, de la fiabilité et de la résilience accrues d'un environnement GKE multicluster.

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases

Le framework illustré dans le schéma précédent présente les phases suivantes, définies dans le document Migration 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

Suivez les phases précédentes à chaque étape de la migration. Ce document s'appuie également sur les concepts abordés dans la section Migrer des conteneurs vers Google Cloud : migration de Kubernetes vers GKE. Il comprend des liens, le cas échéant.

Évaluer votre environnement

Au cours de la phase d'évaluation, vous rassemblez des informations sur votre environnement source et sur les charges de travail que vous souhaitez migrer. Cette évaluation est cruciale pour votre migration et pour redimensionner les ressources dont vous avez besoin pour la migration et votre environnement cible. Lors de la phase d'évaluation, vous effectuez les opérations suivantes :

  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 la page Migration vers Google Cloud : évaluer et découvrir vos charges de travail. Cependant, elles fournissent des informations spécifiques à l'évaluation des charges de travail que vous souhaitez migrer vers de nouveaux clusters GKE.

Lors de la migration de Kubernetes vers GKE, la section Évaluer votre environnement décrit comment évaluer les clusters et les ressources Kubernetes, tels que les objets ServiceAccount et PersistentVolume. Les informations s'appliquent également à l'évaluation de votre environnement GKE.

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.

Sur la page "Migration de Kubernetes vers GKE", la section Construire vos inventaires explique comment créer les inventaires de vos clusters et charges de travail Kubernetes. Elle est également applicable à la création des inventaires de vos environnements GKE. Avant de passer à ce document, suivez ces instructions pour créer l'inventaire de vos clusters Kubernetes.

Après avoir suivi les conseils de migration de Kubernetes vers GKE pour créer vos inventaires, vous pouvez affiner les inventaires. Pour terminer l'inventaire de vos clusters et pools de nœuds GKE, tenez compte des aspects et des fonctionnalités spécifiques à GKE pour chaque cluster et pool de nœuds, y compris les suivants :

Lorsque vous créez votre inventaire, vous pouvez constater que certains clusters GKE doivent être mis hors service dans le cadre de votre migration. Certaines ressources Google Cloud ne sont pas supprimées lorsque vous supprimez les clusters GKE qui les ont créées. Assurez-vous que votre plan de migration inclut la suppression de ces ressources.

Pour en savoir plus sur les autres fonctionnalités et aspects spécifiques à GKE, consultez la documentation GKE.

Terminer l'évaluation

Après avoir créé les inventaires liés à vos charges de travail et clusters GKE, effectuez les autres étapes de la phase d'évaluation décrites dans la page Migrer des conteneurs vers Google Cloud : migrer Kubernetes vers GKE.

Planifier et créer votre infrastructure de base

Au cours de la phase de planification, vous provisionnez et configurez les fondations, l'infrastructure cloud et les services compatibles avec vos charges de travail sur Google Cloud. Au cours de la phase de planification, vous effectuez les opérations suivantes :

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

Lorsque vous configurez la connectivité réseau, assurez-vous que vous disposez d'assez d'adresses IP dans vos sous-réseaux pour allouer des nœuds, des pods et des services. Lorsque vous configurez la mise en réseau de vos clusters, planifiez soigneusement les allocations d'adresses IP. Par exemple, vous pouvez configurer des adresses IP publiques utilisées en mode privé pour GKE. Les plages d'adresses IP secondaires que vous définissez pour les pods et les services de vos clusters ne peuvent pas être modifiées après leur attribution. Soyez particulièrement vigilant si vous allouez un pod ou une plage de services de /22 (1 024 adresses) ou moins. Sinon, vous risquez de manquer d'adresses IP pour les pods et les services au fur et à mesure de la croissance de votre cluster. Pour plus d'informations, consultez la section Planifier des plages d'adresses IP.

Nous vous recommandons d'utiliser un sous-réseau partagé distinct pour les équilibreurs de charge internes que vous créez pour votre environnement GKE. Lorsque vous utilisez un service Kubernetes de type: LoadBalancer, vous pouvez spécifier un sous-réseau d'équilibreur de charge. Lorsque vous configurez des équilibreurs de charge HTTP(S) internes, vous devez configurer un sous-réseau proxy uniquement.

Pour créer l'infrastructure de base de votre environnement GKE, effectuez les activités de la phase de planification et de création décrites dans la section Migrer des conteneurs vers Google Cloud : migration de Kubernetes vers GKE.

Déployer vos charges de travail

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

  1. Provisionnez et configurez l'environnement cible.
  2. Migrez les données de votre environnement source vers l'environnement cible.
  3. Déployez vos charges de travail dans l'environnement cible.

Cette section fournit des informations spécifiques au déploiement de charges de travail sur GKE. Elle s'appuie sur les informations de la section Migration de Kubernetes vers GKE : déployer vos charges de travail.

Évaluer votre plate-forme et vos environnements d'exécution

Pour disposer d'une infrastructure plus flexible, fiable et facile à gérer, nous vous recommandons de concevoir et de mettre en œuvre une architecture multicluster. Dans une architecture multicluster, vous disposez de plusieurs clusters GKE de production dans votre environnement. Par exemple, si vous provisionnez plusieurs clusters GKE dans votre environnement, vous pouvez implémenter des stratégies de cycle de vie de cluster avancées, telles que les mises à niveau progressives ou les mises à niveau bleu-vert. Pour plus d'informations sur les conceptions d'architecture GKE multicluster et leurs avantages, consultez la page Mises à niveau GKE multicluster avec une entrée multicluster.

Lorsque vous exécutez votre environnement sur plusieurs clusters, vous devez prendre en compte d'autres défis, tels que les suivants :

  • Vous devez adapter la gestion de la configuration, la détection et la communication des services, les déploiements d'applications et l'équilibrage de charge pour le trafic entrant.
  • Vous devrez probablement exécuter des logiciels supplémentaires sur votre cluster, ainsi qu'une automatisation et une infrastructure supplémentaires.

Pour résoudre ces problèmes, vous aurez peut-être besoin d'utiliser des pipelines d'intégration continue/de déploiement continu (CI/CD) pour mettre à jour la configuration des clusters de manière séquentielle afin de minimiser l'impact des erreurs. Vous aurez peut-être également besoin d'équilibreurs de charge pour répartir le trafic d'un cluster vers d'autres.

La gestion manuelle de votre infrastructure est sujette aux erreurs et vous expose à des problèmes liés à une mauvaise configuration et à l'absence de documentation interne sur l'état actuel de votre infrastructure. Pour atténuer les risques liés à ces problèmes, nous vous recommandons d'appliquer le modèle Infrastructure en tant que code. Lorsque vous appliquez ce modèle, vous traitez le provisionnement de votre infrastructure de la même manière que vous gérez le code source de vos charges de travail.

Il existe plusieurs options d'architecture pour votre environnement GKE multicluster, décrites plus loin dans cette section. Le choix d'une option plutôt qu'une autre dépend de plusieurs facteurs, et aucune n'est intrinsèquement plus efficace que les autres. Chaque option possède ses propres avantages et inconvénients. Pour choisir un type d'architecture, procédez comme suit :

  1. Établissez un ensemble de critères permettant d'évaluer les types d'architectures des environnements GKE multicluster.
  2. Évaluez chaque option en fonction des critères d'évaluation.
  3. Choisissez l'option qui correspond le mieux à vos besoins.

Pour établir les critères permettant d'évaluer les types d'architecture des environnements GKE multiclusters, utilisez l'évaluation de l'environnement que vous avez effectuée pour identifier les fonctionnalités dont vous avez besoin. Classez les caractéristiques en fonction de leur importance. Par exemple, après avoir évalué vos charges de travail et votre environnement, vous pouvez prendre en compte les critères d'évaluation suivants, répertoriés par ordre potentiel d'importance :

  1. Solution gérée par Google. Préférez-vous des services et produits autogérés ou gérés par Google ?
  2. Interfaces permettant d'interagir avec l'architecture. Est-il possible d'interagir avec une interface lisible par une machine ? L'interface est-elle définie comme une norme ouverte ? L'interface est-elle compatible avec les directives déclaratives, les directives impératives ou les deux ?
  3. Exposez les services en dehors de l'environnement GKE. L'architecture vous permet-elle d'exposer vos charges de travail en dehors du cluster GKE dans lequel elles sont déployées ?
  4. Communication entre clusters. L'architecture est-elle compatible avec les canaux de communication entre les clusters ? Vos charges de travail sont-elles compatibles avec une architecture distribuée ? Ce critère est important pour prendre en charge les charges de travail avec une conception distribuée, telle que Jenkins.
  5. Gestion du trafic L'architecture est-elle compatible avec des fonctionnalités de gestion avancée du trafic, telles que l'injection de pannes, le transfert de trafic, les délais avant expiration de requête, les nouvelles tentatives, les disjoncteurs et la mise en miroir du trafic ? Ces fonctionnalités sont-elles prêtes à être utilisées ou devez-vous les mettre en œuvre vous-même ?
  6. Provisionner et configurer des outils supplémentaires. Avez-vous besoin de configurer et de configurer des composants matériels ou logiciels supplémentaires ?

Google Cloud offre les options suivantes pour concevoir l'architecture d'un environnement GKE multicluster. Pour choisir l'option la plus adaptée à vos charges de travail, vous devez d'abord les évaluer par rapport aux critères d'évaluation précédemment établis. Utilisez une échelle ordonnée et arbitraire pour attribuer à chaque option de conception un score par rapport à chaque critère d'évaluation. Par exemple, vous pouvez attribuer à chaque environnement un score compris entre 1 et 10 par rapport à chaque critère d'évaluation. Les options suivantes sont présentées dans l'ordre croissant des efforts nécessaires pour gérer le nouvel environnement GKE multicluster.

  1. Multi Cluster Ingress et détection de services multiclusters
  2. Entrée multicluster et Cloud Service Mesh
  3. Cloud Service Mesh
  4. Mises à jour des enregistrements DNS autogérés et Kubernetes

Les sections suivantes décrivent ces options en détail et incluent une liste de critères permettant d'évaluer chaque option. Aidez-vous de la documentation du produit pour attribuer des scores selon certains critères. Par exemple, en lisant la documentation, vous pouvez évaluer Cloud Service Mesh en fonction de certains des critères d'évaluation que vous avez définis précédemment. Toutefois, pour attribuer des scores selon d'autres critères, vous devrez peut-être concevoir et exécuter des analyses comparatives et des simulations plus approfondies. Par exemple, vous devrez peut-être comparer les performances de différentes architectures GKE multiclusters pour déterminer si elles conviennent à vos charges de travail.

Multi Cluster Ingress et détection de services multiclusters

L'entrée multi-cluster est un service géré par Google qui vous permet d'exposer des charges de travail, quel que soit le cluster GKE sur lequel elles sont déployées. Elle vous permet également de configurer des équilibreurs de charge partagés entre les clusters GKE et entre les régions. Pour plus d'informations sur l'utilisation de l'entrée multicluster dans un environnement GKE multicluster, consultez les sections Mises à niveau GKE multicluster à l'aide de l'entrée multicluster et Faciliter votre migration avec l'expansion du réseau maillé Istio.

La détection de services multiclusters est un mécanisme de détection et de connectivité de services multiclusters Kubernetes natif pour GKE. La détection de services multiclusters s'appuie sur la ressource Service de Kubernetes pour aider les applications à se découvrir les unes les autres et à se connecter entre elles au-delà des limites des clusters. Pour évaluer Multi Cluster Ingress et la détection de services multiclusters par rapport aux critères que vous avez définis précédemment, utilisez la liste suivante, numérotée par ordre d'importance relative :

  1. Solution gérée par Google. La détection de services multiclusters est une fonctionnalité entièrement gérée de GKE. Elle configure les ressources (zones et enregistrements Cloud DNS, règles de pare-feu et Cloud Service Mesh) afin que vous n'ayez pas à les gérer.
  2. Interfaces permettant d'interagir avec l'architecture. Les services sont exportés vers d'autres clusters à l'aide d'une ressource déclarative Kubernetes appelée ServiceExport.
  3. Exposez les services en dehors de l'environnement GKE. Lorsque vous utilisez Multi Cluster Ingress et la détection de services multiclusters, vous pouvez exposer vos charges de travail en dehors de vos clusters GKE, quel que soit l'endroit où vous les avez déployés.
  4. Communication entre clusters. Vous exportez des services existants vers d'autres clusters GKE en déclarant un objet ServiceExport. Les clusters GKE situés dans le même parc importent automatiquement les services que vous exportez à l'aide d'objets ServiceExport. La détection de services multiclusters configure une adresse IP virtuelle pour chaque service exporté. La détection de services multiclusters configure automatiquement les ressources Cloud Service Mesh, Cloud DNS ainsi que les règles de pare-feu pour détecter et connecter les services à l'aide d'une simple variante de la convention DNS de Kubernetes. Par exemple, pour accéder au service my-svc, vous pouvez utiliser le nom my-svc.my-ns.svc.clusterset.local.
  5. Gestion du trafic La détection de services multiclusters configure une connectivité simple de couche 3/4 et s'appuie sur DNS pour la détection de services. Elle ne fournit aucune fonctionnalité de gestion du trafic.
  6. Provisionner et configurer des outils supplémentaires. Vous pouvez configurer la détection de services multiclusters en activant les API Google. Aucune installation d'outils supplémentaires n'est nécessaire. Pour plus d'informations, consultez la section Migrer des conteneurs vers Google Cloud : migrer vers un environnement GKE multicluster avec Multi Cluster Ingress et la détection de services multiclusters.

Entrée multicluster et Cloud Service Mesh

Un maillage de services est un modèle architectural permettant de résoudre les problèmes réseau liés aux applications distribuées. Ces défis incluent la détection de services, l'équilibrage de charge, la tolérance aux pannes, le contrôle du trafic, l'observabilité, l'authentification, l'autorisation et le chiffrement en transit. Les implémentations de maillage de services classiques consistent en un plan de données et un plan de contrôle. Le plan de données est responsable de la gestion directe du trafic et de son transfert vers les charges de travail de destination, généralement à l'aide de proxys side-car. Le plan de contrôle fait référence aux composants qui configurent le plan de données.

Lorsque vous implémentez le modèle de maillage de services dans votre infrastructure, vous pouvez choisir entre deux produits Google Cloud : Cloud Service Mesh et Cloud Service Mesh. Ces deux produits fournissent un plan de contrôle pour configurer la mise en réseau de la couche d'application (L7) sur plusieurs clusters GKE. Cloud Service Mesh est basé sur Istio et propose des API Open Source déclaratives. Cloud Service Mesh est basé sur une combinaison de fonctionnalités d'équilibrage de charge Google, de technologies Open Source et d'API Google impératives.

Cloud Service Mesh est une suite gérée par Google d'outils qui vous permet de connecter, de gérer, de sécuriser et de surveiller vos charges de travail, quel que soit le cluster GKE sur lequel elles sont déployées et sans modifier le code de votre application. Pour en savoir plus sur l'utilisation de Cloud Service Mesh pour configurer un maillage couvrant plusieurs clusters GKE, consultez la page Ajouter des clusters GKE à Cloud Service Mesh. Pour évaluer l'entrée multicluster et Cloud Service Mesh en fonction des critères que vous avez définis précédemment, utilisez la liste suivante, numérotée par ordre d'importance relative :

  1. Solution gérée par Google. Multi Cluster Ingress et Cloud Service Mesh sont des produits entièrement gérés. Vous n'avez pas besoin de provisionner ces produits, car Google les gère pour vous.
  2. Interfaces permettant d'interagir avec l'architecture. Cloud Service Mesh utilise Istio au cœur de son infrastructure. L'API Cloud Service Mesh est compatible avec la configuration déclarative basée sur le modèle de ressources Kubernetes.
  3. Exposez les services en dehors de l'environnement GKE. Les passerelles d'entrée de l'entrée multicluster et de Cloud Service Mesh vous permettent d'exposer vos charges de travail en dehors de vos clusters GKE.
  4. Communication entre clusters. Cloud Service Mesh configure des canaux de communication sécurisés directement entre les pods, quel que soit le cluster dans lequel ils s'exécutent. Cette configuration vous permet d'éviter des efforts supplémentaires pour provisionner et configurer ces canaux de communication. Cloud Service Mesh utilise le concept de parcs et d'uniformité des services pour étendre la détection de services GKE à plusieurs clusters. Par conséquent, vous n'avez pas besoin de modifier vos charges de travail pour détecter les charges de travail s'exécutant sur d'autres clusters du maillage.
  5. Gestion du trafic Cloud Service Mesh fournit des fonctionnalités avancées de gestion du trafic que vous pouvez utiliser pour contrôler la manière dont le trafic entrant est sécurisé et acheminé vers les charges de travail. Par exemple, Cloud Service Mesh est compatible avec toutes les fonctionnalités de gestion du trafic Istio, telles que l'injection de pannes, les délais d'expiration de requête et les nouvelles tentatives, les disjoncteurs, la mise en miroir du trafic et la répartition du trafic. Vous pouvez également utiliser ces fonctionnalités de gestion du trafic pour simplifier votre migration vers un nouvel environnement GKE. Par exemple, vous pouvez migrer progressivement le trafic de votre ancien environnement vers le nouveau.
  6. Provisionner et configurer des outils supplémentaires. Pour utiliser Multi Cluster Ingress, vous devez remplir les conditions préalables à la détection de services multiclusters, mais vous n'avez pas besoin d'installer des outils supplémentaires dans vos clusters GKE. Pour utiliser Cloud Service Mesh, vous devez l'installer dans vos clusters.

Cloud Service Mesh

Cloud Service Mesh est un plan de contrôle géré pour la mise en réseau des applications. Il vous permet de provisionner et de configurer des topologies de maillage de services enrichies, avec des fonctionnalités avancées de gestion du trafic et d'observabilité. Pour en savoir plus sur Cloud Service Mesh, consultez la présentation de Cloud Service Mesh et les fonctionnalités de Cloud Service Mesh. Pour provisionner et configurer un maillage de services couvrant plusieurs clusters GKE, vous pouvez utiliser une configuration Cloud Service Mesh multicluster ou multienvironnement. Pour évaluer Cloud Service Mesh par rapport aux critères que vous avez définis précédemment, utilisez la liste suivante, numérotée par ordre d'importance relative :

  1. Solution gérée par Google. Cloud Service Mesh est un produit entièrement géré. Vous n'avez pas besoin de provisionner ces produits, car Google les gère pour vous.
  2. Interfaces permettant d'interagir avec l'architecture. Vous pouvez configurer Cloud Service Mesh à l'aide de la console Google Cloud, de Google Cloud CLI, de l'API Traffic Director ou d'outils tels que Terraform. Cloud Service Mesh est compatible avec un modèle de configuration impératif et est basé sur des produits et des technologies Open Source, tels que xDS et gRPC.
  3. Exposez les services en dehors de l'environnement GKE. Vous pouvez utiliser Cloud Load Balancing pour envoyer du trafic entrant provenant de l'extérieur vers les services du réseau de services.
  4. Communication entre clusters. Le plan de contrôle de Cloud Service Mesh propose des API qui vous permettent de regrouper des points de terminaison (tels que des pods GKE sur plusieurs clusters) en backends de service. Ces backends peuvent ensuite être routés depuis d'autres clients du maillage. Cloud Service Mesh n'est pas directement intégré à la détection de services GKE, mais vous pouvez éventuellement automatiser l'intégration à l'aide d'un contrôleur Open Source comme gke-autoneg-controller. Vous pouvez également utiliser la détection de services multiclusters pour étendre la détection de services GKE à plusieurs clusters.
  5. Gestion du trafic Cloud Service Mesh fournit des fonctionnalités avancées de gestion du trafic que vous pouvez utiliser pour simplifier votre migration vers un nouvel environnement GKE et améliorer la fiabilité de votre architecture. Pour en savoir plus sur la configuration de fonctionnalités telles que le routage du trafic ultraprécis, la répartition du trafic en fonction d'une pondération, la mise en miroir du trafic et l'équilibrage de charge affiné, consultez la pageConfigurer la gestion avancée du trafic.
  6. Provisionner et configurer des outils supplémentaires. Cloud Service Mesh ne s'exécute pas dans vos clusters GKE. Pour en savoir plus sur le provisionnement et la configuration de Cloud Service Mesh, consultez la page Préparer la configuration de Cloud Service Mesh. Pour configurer les pods side-car dont Cloud Service Mesh a besoin pour inclure vos charges de travail dans le réseau de service, consultez Déployer Cloud Service Mesh avec Envoy sur des pods GKE.

Mises à jour des enregistrements DNS autogérés et Kubernetes

Si vous ne souhaitez pas installer de logiciels supplémentaires sur votre cluster et que vous n'avez pas besoin des fonctionnalités fournies par un maillage de services, vous pouvez choisir l'option de mise à jour des enregistrements DNS autogérés et de Kubernetes.

Bien que vous puissiez configurer la découverte et la connectivité interclusters à l'aide de cette option, nous vous recommandons de choisir l'une des autres options décrites dans ce document. Les efforts nécessaires pour exploiter une solution autogérée dépassent largement les avantages que vous pourriez obtenir en retour. Tenez également compte des limitations importantes suivantes :

Lorsque vous créez un service de type: LoadBalancer ou un objet Entrée dans un cluster GKE, GKE crée automatiquement des équilibreurs de charge réseau et des équilibreurs de charge HTTP(S) pour exposer ce service à l'aide de l'adresse IP de l'équilibreur de charge. Vous pouvez utiliser les adresses IP des équilibreurs de charge pour communiquer avec vos services. Toutefois, nous vous recommandons d'éviter de dépendre des adresses IP en mappant ces adresses IP sur les enregistrements DNS à l'aide de Cloud DNS ou sur des points de terminaison de l'annuaire des services que vous pouvez interroger à l'aide de DNS, et de configurer vos clients pour qu'ils utilisent ces enregistrements DNS. Vous pouvez déployer plusieurs instances du service et mapper toutes les adresses IP d'équilibreur de charge obtenues sur l'enregistrement DNS ou le point de terminaison de l'annuaire des services associé.

Pour supprimer une instance d'un service, commencez par supprimer l'adresse IP de l'équilibreur de charge associée de l'enregistrement DNS approprié ou du point de terminaison de l'annuaire des services. Ensuite, assurez-vous que le cache DNS des clients est mis à jour, puis supprimez le service.

Vous pouvez configurer vos charges de travail pour qu'elles puissent communiquer entre elles sur différents clusters GKE. Pour ce faire, vous devez d'abord exposer vos services en dehors du cluster à l'aide des équilibreurs de charge TCP/UDP internes ou des équilibreurs de charge HTTP(S) internes. Vous mappez ensuite les adresses IP des équilibreurs de charge aux enregistrements DNS ou aux points de terminaison de l'annuaire des services. Enfin, vous créez des services de type: ExternalName qui pointent vers ces enregistrements DNS ou ces points de terminaison de l'annuaire des services dans chaque cluster.

Vous pouvez également utiliser un contrôleur d'entrée supplémentaire pour partager un équilibreur de charge unique et un enregistrement Cloud DNS ou un point de terminaison de l'annuaire des services avec plusieurs charges de travail. Par exemple, si vous provisionnez un contrôleur d'entrée dans un cluster, vous pouvez le configurer pour rediriger les requêtes adressées à l'équilibreur de charge que GKE crée pour ce contrôleur d'entrée vers plusieurs services. L'utilisation d'un contrôleur d'entrée supplémentaire vous permet de réduire le nombre d'enregistrements DNS ou de points de terminaison de l'annuaire des services que vous devez gérer.

Pour évaluer les mises à jour des enregistrements DNS autogérés et Kubernetes en fonction des critères que vous avez définis précédemment, utilisez la liste suivante, numérotée par ordre d'importance relative :

  1. Solution gérée par Google. Vous gérez vous-même les objets Kubernetes qui font partie de cette solution. Cloud DNS, l'Annuaire des services et l'Équilibrage de charge sont des services gérés par Google.
  2. Interfaces permettant d'interagir avec l'architecture. Kubernetes est au cœur de GKE, qui prend en charge à la fois les modèles de configuration impératifs et déclaratifs.
  3. Exposez les services en dehors de l'environnement GKE. Vous pouvez utiliser des enregistrements DNS, des points de terminaison de l'annuaire des services et des équilibreurs de charge pour exposer des services auprès de clients en dehors de vos clusters GKE.
  4. Communication entre clusters. Les services de type: ExternalName vous permettent de définir des points de terminaison qui pointent vers des services déployés dans l'autre cluster GKE. Cette configuration permet aux services de communiquer entre eux comme s'ils étaient déployés dans le même cluster.
  5. Gestion du trafic La solution n'offre pas d'autres fonctionnalités de gestion du trafic que celles déjà proposées par Kubernetes et GKE. Par exemple, cette option n'est pas compatible avec le partitionnement du trafic entre différents clusters.
  6. Provisionner et configurer des outils supplémentaires. Cette option ne nécessite pas de logiciel supplémentaire pour être provisionnée et configurée dans vos clusters GKE. Vous pouvez éventuellement installer un contrôleur d'entrée.

Sélectionner une architecture

Après avoir attribué une valeur à chaque critère pour chaque option, vous calculez le score total de chaque option. Pour calculer le score total de chaque option, vous additionnez tous les scores obtenus par cette option de conception sur la base des critères retenus. Par exemple, si un environnement a obtenu un score de 10 par rapport à un critère, et de 6 pour un autre critère, le score total de cette option est de 16.

Vous pouvez également attribuer différentes pondérations au score pour chaque critère afin de représenter l'importance de chacun d'entre eux pour votre évaluation. Par exemple, si une solution gérée par Google est plus importante que la prise en charge d'une architecture de charge de travail distribuée dans votre évaluation, vous pouvez définir des multiplicateurs pour refléter ce qui suit : un multiplicateur de 1.0 pour la solution gérée par Google et un multiplicateur de 0,7 pour l'architecture de charge de travail distribuée. Vous utilisez ensuite ces coefficients pour calculer le score total d'une option.

Après avoir calculé le score total de chaque environnement évalué, vous organisez les environnements en fonction de leur score total, par ordre décroissant. Sélectionnez ensuite l'option ayant le score le plus élevé comme environnement de votre choix.

Il existe plusieurs façons de représenter ces données. Par exemple, vous pouvez utiliser un graphique approprié pour représenter les résultats comportant plusieurs dimensions, telles qu'un graphique à barres.

Effectuer la migration des données de votre ancien environnement vers votre nouvel environnement

Pour en savoir plus sur la migration des données de votre ancien environnement vers votre nouvel environnement, consultez la section Migration de Kubernetes vers GKE, Migrer des données de votre ancien environnement vers le nouvel environnement.

Déployer vos charges de travail

Pour obtenir des conseils sur la migration de données de votre ancien environnement vers votre nouvel environnement, consultez la section Déployer vos charges de travail.

Toutes les architectures proposées dans ce document vous permettent de migrer vos charges de travail d'un environnement GKE existant vers un nouvel environnement multicluster sans aucun temps d'arrêt ni intervalle de basculement. Pour migrer vos charges de travail sans temps d'arrêt, procédez comme suit :

  1. Intégrez temporairement vos anciens clusters GKE existants dans le nouvel environnement GKE multicluster.
  2. Déployez des instances de vos charges de travail dans votre nouvel environnement multicluster.
  3. Migrez progressivement le trafic de votre environnement existant afin de pouvoir migrer progressivement vos charges de travail vers les nouveaux clusters GKE, puis supprimez les anciens clusters GKE.

Terminer le déploiement

Après avoir provisionné et configuré votre plate-forme et vos environnements d'exécution, effectuez les activités décrites dans la section Migration de Kubernetes vers GKE, Déployer vos charges de travail.

Optimiser votre environnement

L'optimisation est la dernière phase de votre migration. Dans cette phase, vous améliorez l'efficacité de votre environnement. Pour optimiser votre environnement, effectuez plusieurs itérations de la boucle reproductible suivante jusqu'à ce que votre environnement réponde à vos exigences d'optimisation :

  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

Pour effectuer l'optimisation de votre environnement GKE, consultez la page Migration de Kubernetes vers GKE, Optimiser votre environnement.

Étape suivante