Migrer des conteneurs vers Google Cloud : migrer depuis un environnement OpenShift vers GKE Enterprise

Ce document vous aide à planifier, concevoir et mettre en œuvre la migration depuis un environnement OpenShift vers GKE Enterprise. Sans une sérieuse préparation, le transfert de charges de travail d'un environnement à un autre peut s'avérer compliqué. C'est pourquoi vous devez planifier et exécuter votre migration avec soin.

Ce document fait partie d'une série d'articles sur la migration vers Google Cloud. Si vous êtes intéressé par une présentation de la série, consultez la section 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 depuis un environnement OpenShift déployé sur site, sur un hébergement privé ou chez un autre fournisseur cloud, vers GKE Enterprise. Ce document est également utile si vous évaluez l'opportunité d'effectuer une migration et si vous souhaitez découvrir à quoi elle pourrait ressembler. L'environnement cible peut être l'un des environnements suivants :

  • Un environnement hébergé entièrement sur Google Cloud
  • Un environnement hybride, dans lequel vous conservez une partie de vos charges de travail sur site ou dans un environnement d'hébergement privé, tout en migrant le reste vers Google Cloud

Pour déterminer quel environnement correspond à vos besoins, examinez vos exigences. Par exemple, migrer vers un environnement de cloud public et déléguer certaines responsabilités à Google vous permet de vous concentrer sur des tâches contribuant à accroître la valeur de votre entreprise plutôt que sur les questions d'infrastructure. Vous bénéficiez d'un modèle de consommation flexible pour optimiser à la fois vos dépenses et l'utilisation des ressources. Si vous avez des exigences particulières, par exemple conserver certaines de vos charges de travail en dehors de Google Cloud, vous pouvez envisager un environnement hybride. Cela peut être nécessaire, par exemple, si vous devez conserver une partie de vos charges de travail dans votre environnement actuel afin de répondre à des exigences réglementaires concernant l'emplacement des données. Vous pouvez également mettre en œuvre une stratégie de migration "improve and move" (améliorer et déplacer) : dans ce cadre, vous commencez par moderniser vos charges de travail, puis vous les migrez vers Google Cloud.

Quel que soit le type d'environnement que vous ciblez, l'objectif de cette migration est de pouvoir utiliser GKE Enterprise pour gérer vos charges de travail exécutées dans cet environnement. En adoptant GKE Enterprise, vous avez accès à toute une gamme de services, parmi lesquels :

  • la gestion multicluster pour vous aider, vous et votre organisation, à gérer depuis un emplacement unique des clusters, une infrastructure et des charges de travail, à la fois dans des environnements cloud et sur site ;
  • Config Sync et Policy Controller pour créer une configuration et des règles communes à l'ensemble de votre infrastructure, et les appliquer sur site aussi bien que dans dans le cloud.
  • Anthos Service Mesh pour adopter un maillage de services entièrement géré qui simplifie les services d'exploitation, la gestion du trafic, la télémétrie et la sécurisation des communications entre services ;
  • l'autorisation binaire, afin de garantir que les conteneurs que vous déployez dans vos environnements sont approuvés ;
  • Cloud Run for Anthos, afin de gérer vos charges de travail sans serveur dans votre environnement GKE Enterprise.

Nous vous recommandons d'évaluer ces services dès la phase de conception de votre processus de migration. Il est plus facile d'adopter ces services dès la migration que de devoir modifier ultérieurement vos processus et votre infrastructure. Vous pouvez commencer à utiliser ces services immédiatement ou dès que vous êtes prêt à moderniser vos charges de travail.

Pour cette migration, vous allez suivre le framework défini dans le document Migration vers Google Cloud : premiers pas. Le framework comporte quatre phases :

  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

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases

Ce document s'appuie sur les concepts abordés dans la documentation Migrer des conteneurs vers Google Cloud : migrer Kubernetes vers GKE. Pour tous les éléments qui le nécessitent, vous trouverez donc des liens vers cette documentation.

Évaluer et découvrir vos charges de travail

Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour la migration de vos charges de travail depuis un environnement OpenShift vers GKE Enterprise. Vous devez donc effectuer les tâches suivantes :

  1. Dresser un inventaire complet de vos processus et applications
  2. Cataloguer vos processus et applications en fonction de leurs propriétés et 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. Choisir les charges de travail que vous souhaitez migrer en premier

Les sections suivantes s'appuient sur la documentation Migration vers Google Cloud : évaluer et découvrir vos charges de travail, mais elles fournissent des informations spécifiques à l'évaluation des charges de travail que vous souhaitez migrer depuis un environnement OpenShift vers GKE Enterprise.

Créer vos inventaires

Pour créer l'inventaire des composants de votre environnement, tenez compte des éléments suivants :

  • Modèle de diffusion des services et de gestion de la plate-forme
  • Projets OpenShift
  • Processus de compilation et de déploiement
  • Charges de travail, exigences et dépendances
  • Configuration des clusters OpenShift

Modèle de diffusion des services et de gestion de la plate-forme

Pour migrer efficacement vos charges de travail depuis OpenShift vers GKE Enterprise, vous devez tout d'abord évaluer le modèle actuel de diffusion des services et de gestion de la plate-forme utilisé dans votre environnement OpenShift. Ce modèle reflète probablement votre structure organisationnelle et vos besoins actuels. Si vous vous rendez compte que ce modèle ne répond pas aux besoins de l'organisation, vous pouvez tirer parti de cette migration pour l'améliorer.

Pour commencer, collectez des informations sur les équipes responsables des aspects suivants :

  • Développement et déploiement d'applications, y compris tous les utilisateurs OpenShift : il s'agit généralement des équipes de développement ou de publication des charges de travail.
  • Gestion de la plate-forme OpenShift, y compris la création de projets OpenShift, l'attribution de rôles aux utilisateurs, la configuration des contextes de sécurité et la configuration des pipelines CI/CD.
  • Installation et gestion des clusters OpenShift, y compris l'installation et la mise à niveau d'OpenShift, le scaling de clusters et la gestion de la capacité.
  • Gestion des infrastructures : ces équipes gèrent les serveurs physiques, le stockage, la mise en réseau, la plate-forme de virtualisation et les systèmes d'exploitation.

Un modèle de diffusion des services et de la gestion de plate-forme peut être constitué des équipes suivantes :

  • L'équipe de développement. Il s'agit de l'équipe qui développe les charges de travail et les déploie sur OpenShift. Dans les environnements de production complexes, l'équipe qui déploie les charges de travail peut être différente de l'équipe de développement. Dans ce document, pour plus de simplicité, nous considérons que cette équipe fait partie de l'équipe de développement. Dans les environnements de libre-service, l'équipe de développement est également chargée de la création des projets OpenShift.
  • L'équipe de gestion de la plate-forme. Il s'agit de l'équipe responsable de la gestion de la plate-forme OpenShift, généralement composée des "administrateurs de cluster OpenShift". Cette équipe configure les modèles de projet OpenShift pour les différentes équipes de développement et, dans des environnements dotés d'une gestion plus stricte, crée les projets OpenShift. Cette équipe attribue également les rôles et autorisations, configure les contextes de sécurité et le contrôle des accès basé sur les rôles (RBAC), définit des quotas pour les ressources et objets de calcul, et définit des stratégies de compilation et de déploiement. Elle est parfois désignée par l'appellation équipe DevOps, ou équipe middleware si elle gère les configurations du middleware et des serveurs d'applications pour le compte des développeurs. L'équipe chargée de la plate-forme et l'équipe chargée de l'infrastructure peuvent également être impliquées dans des activités de gestion de cluster OpenShift de bas niveau, telles que l'installation et la mise à niveau des logiciels, le scaling des clusters et la gestion de la capacité.
  • L'équipe chargée de l'infrastructure. Il s'agit de l'équipe gérant l'infrastructure sous-jacente à l'environnement OpenShift. Ses membres sont par exemple responsables des serveurs, du stockage, de la mise en réseau, de la plate-forme de virtualisation et du système d'exploitation de base. Cette équipe est parfois également appelée équipe du centre de données ou équipe en charge des opérations. Si OpenShift est déployé dans un environnement cloud public, cette équipe est responsable des services d'infrastructure en tant que service (IaaS) proposés par le fournisseur de cloud public.

Il est également important d'évaluer si vous disposez de clusters OpenShift dédiés pour différents environnements. Par exemple, vous pouvez avoir des environnements différents pour le développement, le contrôle qualité et la production, ou encore pour séparer différentes zones de réseau et de sécurité, telles que des zones internes et des zones démilitarisées.

Projets OpenShift

Un projet OpenShift est un espace de noms Kubernetes comportant des annotations supplémentaires qui permettent aux développeurs de gérer les ressources indépendamment des autres équipes, afin d'assurer une séparation logique. Pour créer l'inventaire de vos projets OpenShift, tenez compte des points suivants pour chaque projet :

  • Rôles de cluster et rôles locaux. OpenShift accepte aussi bien les rôles locaux pour un projet OpenShift que les rôles à l'échelle du cluster. Évaluez si vous avez créé des rôles de cluster et des rôles locaux permettant un mécanisme de contrôle d'accès efficace dans l'environnement cible.
  • Liaisons de rôles, à la fois pour les rôles de cluster et les rôles locaux. Les utilisateurs et les groupes reçoivent les autorisations nécessaires pour effectuer des opérations sur des projets OpenShift via l'attribution de liaisons de rôles. Les rôles peuvent être définis au niveau du cluster ou au niveau local. Les liaisons de rôles locaux concernent souvent des rôles de cluster prédéfinis. Par exemple, la liaison de rôle d'administrateur de projet OpenShift par défaut peut être liée au rôle d'administrateur de cluster par défaut.
  • Quotas de ressources. Pour limiter la consommation globale des ressources, OpenShift vous permet de définir à la fois des quotas au niveau d'un projet OpenShift et des quotas sur plusieurs projets OpenShift. Évaluez leur correspondance avec les quotas de ressources Kubernetes et renseignez une liste de tous les objets ResourceQuota que vous avez provisionnés et configurés dans votre environnement OpenShift.

La section Évaluer votre environnement décrit comment évaluer les ressources Kubernetes, telles que les objets ServiceAccount et PersistentVolume.

Processus de compilation et de déploiement

Une fois que vous avez recueilli des informations sur le modèle de diffusion des services et de gestion de la plate-forme, ainsi que sur les projets OpenShift, évaluez la manière dont vous créez vos charges de travail et les déployez dans votre environnement.

Dans votre environnement OpenShift existant, il est possible que vous utilisiez le même processus de création et de déploiement pour toutes vos charges de travail, ou au contraire que vous disposiez de différents processus à évaluer. Les artefacts du processus de création d'une charge de travail en conteneur sont des images de conteneurs. Dans un environnement OpenShift, vous pouvez compiler des images de conteneurs, les stocker et les déployer de différentes manières :

Une fois chaque image de conteneur compilée, vous la stockez dans un registre de conteneurs que vous pouvez déployer ultérieurement. Votre registre de conteneurs peut être hébergé soit sur OpenShift, soit en dehors de votre environnement OpenShift. Évaluez bien cet aspect, car vous pourriez avoir besoin d'un système similaire dans votre environnement cible.

Charges de travail, exigences et dépendances

Chaque application OpenShift contient les composants suivants :

  • Un objet OpenShift DeploymentConfig ou un objet Kubernetes Deployment. Pour en savoir plus sur les différences entre ces objets, consultez la page Comparing Deployments and DeploymentConfigs (Comparer les objets Deployment et DeploymentConfig).
  • Un service Kubernetes qui rend votre application accessible aux clients et une route OpenShift permettant la connexion à ce service Kubernetes depuis l'extérieur du cluster.
  • Un objet OpenShift ImageStream qui fournit une abstraction permettant de référencer des images de conteneurs. Un objet OpenShift ImageStream inclut une ou plusieurs images de conteneurs, chacune étant identifiée par des tags, et présente une vue abstraite unique des images associées, semblable à un dépôt d'images de conteneurs.
  • Un objet OpenShift BuildConfig pour créer les images de conteneurs de cette application OpenShift dans OpenShift.

Suivant la raison d'être de l'application, vous pouvez utiliser d'autres objets que des objets Deployment ou DeploymentConfig pour définir l'application :

  • Vous définissez des applications par lots à l'aide de tâches (objets Job) ou de tâches cron.
  • Vous définissez des applications avec état à l'aide d'objets StatefulSets.
  • Si vous avez des charges de travail liées aux opérations qui doivent s'exécuter sur chaque nœud ou être associées à des nœuds spécifiques, vous pouvez les définir à l'aide d'objets DaemonSets.

Le tableau suivant liste les spécifications et paramètres essentiels à collecter à partir des ressources OpenShift afin de migrer les applications vers l'environnement GKE Enterprise cible.

Fichier manifeste de la ressource OpenShift source Spécifications et paramètres essentiels
Objet Deployment, DeploymentConfig, StatefulSet, Job, tâche cron Image et dépôt du conteneur, port du conteneur, nombre de pods dupliqués, objets ConfigMap, Secret, PersistentVolumeClaim, demandes de ressources et limites, stratégie de mise à jour, nom de service StatefulSet, planification de tâche cron
Objet ImageStream Image de conteneur, stratégie d'extraction d'images, dépôt d'images de conteneurs
Autoscaler horizontal de pods Critères d'autoscaling
Service Nom d'hôte utilisé pour se connecter à l'application à partir du cluster, adresse IP et port sur lesquels le service est exposé, points de terminaison créés pour les ressources externes
Route Nom d'hôte et chemin de ressource utilisés pour se connecter à l'application depuis l'extérieur du cluster, règles de routage, chiffrement, informations sur la chaîne de certificats

La section Évaluer votre environnement décrit comment évaluer les ressources Kubernetes telles que :

OpenShift 4 a introduit le framework des opérateurs. Si vous utilisez cette version d'OpenShift, vous avez peut-être déployé certaines applications à l'aide des opérateurs installés. Dans ce cas, récupérez la liste des opérateurs installés et collectez pour chacun d'entre eux des informations concernant les instances d'opérateur déployées. Ces instances sont des ressources personnalisées définies par l'opérateur, qui déploient certaines des ressources Kubernetes répertoriées précédemment.

En plus d'évaluer ces ressources, évaluez les éléments suivants :

  • Exigences de connectivité réseau de l'application. Par exemple, vos services ou pods doivent-ils être exposés à un réseau spécifique ? Doivent-ils accéder à des systèmes backend spécifiques ?
  • Contraintes d'exécution des charges de travail dans un emplacement spécifique. Par exemple, les charges de travail ou les ensembles de données doivent-ils rester sur site pour répondre à des exigences telles que la latence de communication avec d'autres charges de travail, la réglementation concernant l'emplacement des données, ou encore la proximité avec les utilisateurs ?

Configuration des clusters OpenShift

Vous devez ensuite évaluer vos clusters OpenShift. Pour effectuer cette tâche, vous devez collecter les informations suivantes :

  • Version d'OpenShift. Les principales versions d'OpenShift couvertes par ce document sont OpenShift 3 et OpenShift 4. Différentes versions d'OpenShift peuvent présenter des fonctionnalités différentes. Évaluez la version d'OpenShift que vous utilisez pour déterminer si vous utilisez des fonctionnalités spécifiques à cette version.
  • Fournisseur d'identité utilisé pour l'authentification. Pour l'authentification, il se peut que vous utilisiez le serveur OAuth intégré et un ou plusieurs fournisseurs d'identité.
  • Contraintes de contexte de sécurité. Évaluez les contraintes de contexte de sécurité OpenShift que vous avez définies dans vos clusters, leur configuration, ainsi que les utilisateurs, groupes et comptes de service qui leur sont associés.
  • Règles et isolation du réseau. Évaluez les règles NetworkPolicy, la manière dont vous avez configuré l'isolation réseau des pods et le mode SDN OpenShift que vous avez configuré dans vos clusters.
  • Surveillance. Évaluez vos besoins actuels en matière de surveillance, ainsi que la manière dont vous avez provisionné et configuré votre système de surveillance actuel. Cela vous permettra de décider comment concevoir et mettre en œuvre une solution de surveillance dans l'environnement cible. Cette évaluation peut vous aider à déterminer si vous devez faire appel à une nouvelle solution de surveillance ou si vous pouvez continuer à utiliser la solution existante. De nombreuses versions d'OpenShift incluent une pile de surveillance basée sur Prometheus pour surveiller les composants du système. Cette pile peut également être utilisée pour la surveillance des applications. Lorsque vous concevez votre solution cible, tenez compte des éléments suivants :

    • La solution de surveillance que vous utilisez actuellement dans votre environnement OpenShift, par exemple une solution Prometheus hébergée par OpenShift, une pile Prometheus - Grafana indépendante, Zabbix, InfluxData ou Nagios
    • La manière dont les métriques sont produites et collectées, par exemple par un mécanisme d'extraction (pull) ou d'envoi (push)
    • Les dépendances à tout composant déployé dans vos clusters OpenShift
    • L'emplacement de votre système de surveillance déployé, par exemple, dans un environnement cloud ou sur site
    • Les métriques que vous collectez actuellement pour vos charges de travail
    • Toutes les alertes relatives aux métriques que vous avez configurées dans votre système de surveillance actuel
  • Journalisation. Évaluez vos besoins actuels en matière de journalisation, ainsi que la manière dont vous avez provisionné et configuré votre système de journalisation actuel. Cela vous permettra de décider comment concevoir et mettre en œuvre une solution de journalisation dans l'environnement cible. Cette évaluation peut vous aider à déterminer si vous devez faire appel à une nouvelle solution de journalisation ou si vous pouvez continuer à utiliser la solution existante. De nombreuses versions d'OpenShift sont fournies avec une solution de journalisation basée sur une pile Elasticsearch, Fluentd et Kibana (pile EFK) qui permet de collecter les journaux des composants système. Cette solution peut également être utilisée pour la journalisation des applications. Lorsque vous concevez votre solution cible, tenez compte des éléments suivants :

    • Le système de journalisation que vous utilisez actuellement dans votre environnement OpenShift, par exemple, une pile EFK hébergée par OpenShift, une pile EFK indépendante ou une solution Splunk
    • Les dépendances à tout composant déployé dans vos clusters OpenShift
    • L'architecture et la capacité des composants de stockage des journaux
    • L'emplacement de votre système de journalisation déployé, par exemple, dans un environnement cloud ou sur site
    • Les règles de conservation des journaux et la configuration associée

La section Évaluer votre environnement décrit comment évaluer les éléments suivants :

  • Nombre de clusters
  • Nombre et type de nœuds (par cluster)
  • Considérations complémentaires sur la journalisation, la surveillance et le traçage
  • Ressources Kubernetes personnalisées

Terminer l'évaluation

Une fois que vous avez fait l'inventaire des informations concernant vos processus et vos charges de travail OpenShift, effectuez les activités restantes de la phase d'évaluation décrite dans la documentation Migration vers Google Cloud : évaluer et découvrir vos charges de travail.

Planifier et créer votre infrastructure de base

Au cours de la phase de planification et de création, vous provisionnez et configurez l'infrastructure et les services sous-jacents à vos charges de travail :

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

Cette section fournit des informations spécifiques à la création de vos fondations sur GKE Enterprise, en s'appuyant sur les informations de la section Migration vers Google Cloud : établir les fondations.

Avant de créer l'infrastructure de base dans Google Cloud, lisez la présentation technique de GKE Enterprise pour bien comprendre le fonctionnement de GKE Enterprise et identifier les composants dont vous pourriez avoir besoin. Selon les exigences de la charge de travail et de la localité des données recueillies lors de la phase d'évaluation, le déploiement de vos charges de travail va s'effectuer sur GKE sur VMware, sur des clusters GKE sur Google Cloud ou sur GKE sur AWS. Vos clusters peuvent être répartis entre différents environnements. Pour en savoir plus sur la création des fondations pour GKE sur Google Cloud, consultez la page Planifier et créer votre infrastructure de base.

Pour créer l'infrastructure de base pour GKE sur VMware, prenez connaissance des concepts clés associés, puis tenez compte des points suivants lors de l'installation de GKE sur VM ware :

Pour créer l'infrastructure de base pour GKE sur AWS, prenez connaissance des concepts clés associés, tels que GKE sur une architecture AWS et GKE sur un stockage AWS. Tenez compte des points suivants lors de l'installation de GKE sur AWS :

Déployer vos charges de travail

Lors de la phase de déploiement, vous allez déployer vos charges de travail sur GKE Enterprise :

  1. Provisionnez et configurez votre plate-forme et vos environnements d'exécution.
  2. Migrez les données de votre ancien environnement vers le nouvel environnement.
  3. Déployer vos charges de travail.

Les sections suivantes fournissent des informations spécifiques au déploiement de charges de travail sur GKE Enterprise, en s'appuyant sur les informations des documentations Migration vers Google Cloud : transférer vos ensembles de données volumineux, Migration vers Google Cloud : déployer vos charges de travail et Migration vers Google Cloud : passer des déploiements manuels aux déploiements automatisés en conteneurs.

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

Avant de pouvoir déployer une charge de travail, vous devez provisionner et configurer les clusters GKE Enterprise requis.

Vous pouvez provisionner des clusters GKE sur Google Cloud, des clusters GKE sur VMware ou des clusters GKE sur AWS. Par exemple, pour une charge de travail que vous devez déployer sur site, provisionnez un ou plusieurs clusters GKE sur VMware. Si vos charges de travail ne sont soumises à aucune contrainte d'emplacement, vous pouvez provisionner des clusters GKE sur Google Cloud. Dans les deux cas, vous utilisez GKE Enterprise pour gérer et surveiller vos clusters. Si vous avez des exigences multicloud, provisionnez des clusters GKE sur AWS conjointement à d'autres clusters GKE Enterprise.

Pour commencer, définissez le nombre et le type de clusters GKE Enterprise dont vous avez besoin. Ces exigences dépendent en grande partie des déductions faites à partir des informations recueillies lors de la phase d'évaluation, telles que le modèle de service que vous souhaitez mettre en œuvre et la façon dont vous souhaitez isoler les différents environnements. Si plusieurs équipes de développement partagent actuellement vos clusters OpenShift, vous devez mettre en œuvre un modèle mutualisé sur GKE Enterprise :

  • Utilisation d'espaces de noms Kubernetes différents. L'équipe de gestion de la plate-forme crée un espace de noms Kubernetes pour chaque projet OpenShift et met en œuvre un modèle d'architecture de cluster mutualisée. Ce modèle suit assez fidèlement celui que vous avez sans doute adopté dans votre environnement OpenShift. Il nécessite donc autant de clusters GKE Enterprise que pour OpenShift. Si nécessaire, vous pouvez toujours disposer de clusters dédiés pour différents environnements.
  • Utilisation de clusters GKE Enterprise différents. L'équipe responsable de l'infrastructure fournit un cluster GKE Enterprise à chaque équipe de développement, et l'équipe plate-forme gère alors chacun de ces clusters. Ce modèle peut nécessiter un nombre de clusters GKE Enterprise supérieur au nombre de clusters OpenShift, car il offre davantage de flexibilité et d'isolation pour vos équipes de développement.
  • Utilisation de projets Google Cloud différents. L'équipe responsable de l'infrastructure crée un projet Google Cloud pour chaque équipe de développement et provisionne les clusters GKE Enterprise au sein de ce projet Google Cloud. L'équipe de gestion de la plate-forme administre ensuite ces clusters. Ce modèle peut nécessiter un nombre de clusters GKE Enterprise supérieur au nombre de clusters OpenShift, car il offre une flexibilité et une isolation maximales pour vos équipes de développement.

Après avoir déterminé le nombre de clusters dont vous avez besoin et l'environnement dans lequel les provisionner, définissez la taille, la configuration et les types de nœuds de ces clusters. Provisionnez ensuite vos clusters et vos pools de nœuds en fonction des exigences des charges de travail, que vous avez répertoriées lors de la phase d'évaluation. Par exemple, vos charges de travail peuvent exiger certaines garanties de performances et d'évolutivité, ainsi que d'autres critères tels que des besoins en GPU et en TPU.

Pour plus d'informations sur le provisionnement et la configuration des clusters, consultez les pages suivantes :

Après avoir créé vos clusters et avant de déployer une charge de travail, vous devez configurer les composants suivants afin de répondre aux exigences que vous avez répertoriées lors de la phase d'évaluation des projet et des clusters OpenShift :

Grâce à Config Sync, vous pouvez définir la configuration des ressources suivantes de manière centralisée, dans un dépôt commun compatible avec Git, et l'appliquer à l'ensemble des clusters, qu'ils soient sur site ou dans le cloud :

Pour installer Config Sync, consultez la section Installer Config Sync. Pour installer Policy Controller, consultez la page Installer Policy Controller.

Migrer les données depuis votre ancien environnement

Vous pouvez désormais transférer les données de votre environnement source vers l'environnement cible.

Si vos applications OpenShift avec état hébergent des données sur des volumes persistants Kubernetes, il existe différentes stratégies pour migrer les données vers l'environnement cible. La stratégie optimale dépend de divers facteurs, tels que vos fournisseurs d'espace de stockage backend source et cible ainsi que les emplacements de déploiement :

  • Appuyez-vous sur les fonctionnalités de clonage, d'exportation et d'importation de volumes proposées par votre fournisseur de stockage. Si vous utilisez des volumes VMware vSphere dans votre environnement sur site et que vous migrez vers GKE sur VMware, clonez les disques persistants PersistentVolume sous-jacents aux disques virtuels VMDK et installez-les en tant que volumes dans votre environnement cible. Si vous migrez vers GKE, importez vos disques virtuels en tant que disques persistants Compute Engine, puis utilisez-les en tant que volumes persistants.
  • Sauvegardez vos données à partir de votre environnement source à l'aide des outils du système d'exploitation ou de base de données. Hébergez ces données dans un emplacement temporaire accessible à partir des deux environnements, puis restaurez les données dans votre environnement cible.
  • Utilisez un outil de copie distante, tel que rsync, pour copier des données de l'environnement source vers l'environnement cible.
  • Utilisez une solution de sauvegarde indépendante du stockage, telle que Velero et son intégration restic.

Pour en savoir plus, consultez la page Migration vers Google Cloud : transférer des ensembles de données volumineux.

Pour en savoir plus sur la migration de données et les stratégies de gestion du stockage dans GKE, consultez la page Effectuer la migration des données de votre ancien environnement vers votre nouvel environnement et les documents GKE concernant la configuration du stockage.

Avec GKE sur VMware, vous pouvez choisir parmi différentes options d'intégration avec des systèmes de stockage externes, par exemple via le stockage VMware vSphere, les plug-ins Kubernetes de volume "in-tree", ou encore les pilotes CSI (Container Storage Interface). Votre choix dépend du système de stockage externe avec lequel vous devez réaliser l'intégration, des modes d'accès compatibles et de votre besoin éventuel de gestion dynamique des volumes.

GKE sur AWS déploie automatiquement le pilote CSI pour Amazon Elastic Block Store (EBS), une classe StorageClass par défaut qui étaie les demandes PersistentVolumeClaims avec des volumes EBS et des classes StorageClass pour d'autres types de volumes EBS. Vous pouvez également installer des pilotes CSI supplémentaires et des classes StorageClass personnalisées. Si vous souhaitez importer un volume EBS dans GKE sur AWS, vous pouvez créer un objet PersistentVolume à partir de celui-ci.

Déployer vos charges de travail

Après avoir provisionné le cluster GKE Enterprise et migré les données, vous allez maintenant créer et déployer vos charges de travail. Vous disposez de différentes options, allant des déploiements manuels aux déploiements entièrement automatisés.

Si vous devez utiliser des opérateurs pour déployer des charges de travail qui exploitent cette méthode de déploiement dans votre environnement OpenShift, vous devez installer l'opérateur avant de déployer votre charge de travail. Vous pouvez vérifier la disponibilité des opérateurs dont vous avez besoin auprès des sources suivantes :

Déployer manuellement

Si vous déployez manuellement vos charges de travail dans votre environnement OpenShift, vous pouvez adapter ce processus de déploiement manuel à votre nouvel environnement GKE Enterprise. Par exemple, vous pouvez traduire manuellement les fichiers manifestes des ressources OpenShift que vous avez évaluées dans la phase concernant les charges de travail, exigences et dépendances en fichiers manifestes pour les ressources GKE Enterprise correspondantes.

Le tableau suivant étend le tableau figurant dans la section Charges de travail, exigences et dépendances de ce document et ajoute des informations sur les ressources GKE Enterprise cibles dans lesquelles vous pouvez les utiliser.

Fichier manifeste de la ressource OpenShift source Spécifications et paramètres essentiels Fichier manifeste de la ressource GKE Enterprise cible
Objet Deployment, DeploymentConfig, StatefulSet, Job, tâche cron Image et dépôt du conteneur, port du conteneur, nombre de pods dupliqués, objets ConfigMap, Secret, PersistentVolumeClaim, demandes de ressources et limites, stratégie de mise à jour, nom de service StatefulSet, planification de tâche cron Objets Deployment, StatefulSet, Job, tâche cron
Objet ImageStream Image de conteneur, stratégie d'extraction d'images, dépôt d'images de conteneurs Déploiement
Autoscaler horizontal de pods Critères d'autoscaling Autoscaler horizontal de pods
Service Nom d'hôte utilisé pour se connecter à l'application à partir du cluster, adresse IP et port sur lesquels le service est exposé, points de terminaison créés pour les ressources externes Service
Route Nom d'hôte et chemin de ressource utilisés pour se connecter à l'application depuis l'extérieur du cluster, règles de routage Entrée

Concevoir et mettre en œuvre un processus de déploiement automatisé

Pour créer et déployer automatiquement vos charges de travail, vous devez concevoir et mettre en œuvre des processus de compilation et de déploiement, ou adapter les processus existants pour les rendre compatibles avec votre nouvel environnement. Si vous devez déployer vos charges de travail dans un environnement hybride, vos processus de déploiement doivent être compatibles à la fois avec GKE sur Google Cloud et avec GKE sur VMware.

Pour mettre en œuvre vos processus de compilation et de déploiement, vous pouvez exploiter Cloud Build. Si vous souhaitez automatiser vos processus de compilation et de déploiement, vous pouvez configurer des déclencheurs de compilation ou des déclencheurs d'application GitHub, ou vous pouvez configurer des déploiements automatisés depuis la console Google Cloud. Si vous utilisez des contraintes Policy Controller, vous pouvez comparer vos descripteurs Kubernetes et GKE Enterprise avec les règles de vos jobs Cloud Build afin de fournir des commentaires aux développeurs.

Si vous devez exécuter des tâches de compilation ou stocker du code source sur site, vous pouvez utiliser GitLab. GitLab propose des dépôts de code source, une plate-forme de collaboration, des fonctionnalités CI/CD, ainsi qu'un registre d'images de conteneurs. Vous pouvez déployer GitLab sur vos clusters GKE Enterprise directement depuis Cloud Marketplace ou bien utiliser l'une des autres options d'installation disponibles.

Si vous utilisez actuellement l'une des fonctionnalités OpenShift pour compiler ou déployer automatiquement vos charges de travail, vous pouvez adopter l'une des stratégies suivantes, en fonction de votre processus actuel :

  • Pipelines Jenkins. Si vous utilisez des pipelines Jenkins pour automatiser votre processus de compilation et de déploiement, vous pouvez transférer votre pipeline vers Cloud Build, utiliser votre environnement Jenkins existant ou déployer Jenkins dans Google Cloud.
  • Compilations et déploiements à partir d'un fichier Dockerfile et des artefacts requis. Vous pouvez utiliser Cloud Build pour créer des images de conteneurs à partir d'un fichier Dockerfile ou d'un fichier de configuration de compilation. Si vous souhaitez réaliser vos compilations dans un cluster sur site, vous pouvez utiliser GitLab.
  • Compilations "source-to-image". Dans Cloud Build, vous devez mettre en œuvre une étape préliminaire pour créer les artefacts requis par l'image de conteneur résultante. Si votre tâche "source-to-image" compile une application Python et génère une image de conteneur, vous devez configurer une étape de compilation personnalisée pour compiler l'application Python, puis générer l'image de conteneur. Cette approche nécessite également de fournir un fichier Dockerfile. Si vous ne souhaitez pas en fournir un, vous pouvez utiliser les buildpacks Google Cloud ou Jib pour les applications Java.
  • Compilations personnalisées. Vous pouvez créer des compilateurs Cloud Build personnalisés comme vous le faites actuellement dans OpenShift. Si vos compilateurs personnalisés n'utilisent aucune fonctionnalité spécifique à OpenShift, vous pouvez les utiliser tels quels dans Cloud Build.

Quelle que soit l'approche choisie pour créer vos images de conteneurs, vous devez les stocker dans un dépôt d'images de conteneurs. Vous disposez des options suivantes :

Quelle que soit la solution que vous retenez pour stocker vos images de conteneurs, vous devez provisionner et configurer des identifiants pour que vos clusters puissent accéder au dépôt d'images de conteneurs.

Si vous devez envoyer des notifications sur l'état de vos compilations et de vos images de conteneurs à des utilisateurs ou à des services tiers, vous pouvez utiliser Cloud Functions pour répondre à des événements générés par Cloud Build et Container Registry.

Résumé des correspondances de fonctionnalités entre OpenShift et GKE Enterprise

Le tableau suivant présente un récapitulatif des correspondances entre les fonctionnalités GKE Enterprise et les fonctionnalités que vous utilisiez sur OpenShift.

OpenShift GKE Enterprise
Projets OpenShift
  • Espaces de noms Kubernetes gérés de manière centralisée par Config Sync
  • Autorisations Kubernetes RBAC gérées de manière centralisée par Config Sync
  • Quotas de ressources Kubernetes gérés de manière centralisée par Config Sync
SDN OpenShift et isolation réseau
  • Règles de sécurité réseau Calico gérées de manière centralisée par Config Sync
Contraintes de contexte de sécurité OpenShift
  • Contraintes Policy Controller
Pipelines OpenShift
  • Cloud Build
  • Intégration de Jenkins à l'aide du plug-in Google Cloud Jenkins
  • GitLab
OpenShift Source-to-Image
  • Packs de création cloud natifs
  • Jib
Intégration de l'identité
  • Cloud Identity
  • Google Cloud Directory Sync
  • Intégration OIDC pour GKE sur VMware

Optimiser votre environnement

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

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

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

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

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

Définir vos exigences d'optimisation

Pour les exigences d'optimisation de GKE sur Google Cloud, consultez les éléments définis dans la section Optimiser votre environnement.

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

Terminer l'optimisation

Une fois que vous avez satisfait l'ensemble de vos exigences en matière d'optimisation, effectuez les activités restantes de la phase d'optimisation décrite dans la documentation Migration vers Google Cloud : optimiser votre environnement.

Obtenir de l'aide

Google Cloud vous propose différentes options et ressources pour vous aider à utiliser au mieux les services Google Cloud :

  • Ressources en libre-service. Si vous n'avez pas besoin d'une assistance dédiée, vous pouvez utiliser les diverses options proposées selon le rythme qui vous convient.
  • Partenaires technologiques. Google Cloud s'est associé à plusieurs entreprises qui peuvent vous aider à utiliser nos produits et services.
  • Services professionnels Google Cloud. Nos services professionnels peuvent vous aider à tirer le meilleur parti de votre investissement dans Google Cloud.

D'autres ressources pouvant vous aider dans la migration des charges de travail vers Google Cloud sont proposées dans le centre de migration Google Cloud.

Pour en savoir plus sur ces ressources, consultez la section Obtenir de l'aide du document Migration vers Google Cloud : premiers pas.

Étape suivante