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 :
- Migrer des conteneurs vers Google Cloud : migrer Kubernetes vers Google Kubernetes Engine (GKE)
- Migrer des conteneurs vers Google Cloud : migrer depuis un environnement OpenShift vers GKE Enterprise (ce document)
- Migrer des conteneurs vers Google Cloud : migrer des projets OpenShift vers GKE Enterprise
- Migrer depuis OpenShift vers GKE Enterprise : migrer des contraintes de contexte de sécurité OpenShift vers des contraintes Policy Controller
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.
- Cloud 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 ;
- Knative serving, pour 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 :
- Évaluer et découvrir vos charges de travail
- Planifier et établir les fondations
- Déployer vos charges de travail
- Optimiser votre environnement
Le diagramme suivant illustre le parcours de votre migration.
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 :
- Dresser un inventaire complet de vos processus et applications
- Cataloguer vos processus et applications en fonction de leurs propriétés et dépendances
- Former et préparer vos équipes sur Google Cloud
- Créer des tests et des démonstrations de faisabilité sur Google Cloud
- Calculer le coût total de possession (TCO) de l'environnement cible
- 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, l'assurance 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 :
- Le processus de compilation d'image de conteneur s'exécute entièrement en dehors d'OpenShift. Le processus de compilation peut être basé sur des étapes manuelles ou sur un pipeline d'intégration et de déploiement continus (CI/CD), dont l'image de conteneur et les fichiers manifestes Kubernetes constituent le produit final.
- Le processus de compilation d'image de conteneur s'exécute au sein d'OpenShift. OpenShift accepte différentes options, par exemple fournir un fichier Dockerfile et tous les artefacts requis pour compiler une image de conteneur, configurer une compilation "source-to-image" (source vers image), configurer une compilation par pipeline ou configurer une compilation personnalisée. Ces stratégies de compilation créent une ressource BuildConfig qui définit le choix de compilation, l'emplacement des artefacts source, les images de conteneurs cibles et les événements pouvant déclencher le processus de compilation d'images de conteneurs.
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 :
- Autres contrôleurs Kubernetes
- Autoscalers horizontaux de pods
- Contextes de sécurité des pods
- Charges de travail avec et sans état
- Stockage
- Injection de fichiers de configuration et de secrets
- Entrées
- Journalisation et surveillance
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 :
- Créez une hiérarchie de ressources.
- Configurez la gestion de l'authentification et des accès.
- Configurez la facturation.
- Configurez la connectivité réseau.
- Renforcez votre sécurité.
- 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 :
- Assurez-vous que votre environnement sur site répond aux exigences d'Anthos GKE On-Prem. Vous devez fournir une capacité suffisante dans votre environnement VMware vSphere pour répondre aux exigences du cluster administrateur et des clusters utilisateur. Ces exigences dépendent de la quantité de requêtes de ressources nécessaires à vos charges de travail et du nombre de clusters dont vous avez besoin. Vous avez estimé ces deux aspects lors de la phase d'évaluation.
Configurez votre réseau. Vous devez configurer votre réseau sur site afin de répondre aux exigences de connectivité réseau des applications, que vous avez répertoriées lors de l'évaluation, en plus des exigences d'installation de GKE sur VMware. Tenez compte des besoins réseau suivants :
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 :
- Assurez-vous que vos environnements Amazon Web Services (AWS) et Google Cloud répondent aux exigences de GKE sur AWS. GKE sur AWS nécessite un compte (AWS) avec accès en ligne de commande et une clé AWS Key Management Service (KMS) pour chiffrer les codes secrets de la couche d'application dans les clusters. Vous avez besoin de Terraform et de kubectl.
- Configurez l'environnement AWS. Vous devez configurer votre environnement AWS, installer des outils tels que la CLI (interface de ligne de commande) AWS, configurer les identifiants IAM AWS et provisionner dans votre environnement AWS des ressources telles qu'une clé KMS AWS.
- Configurez l'environnement Google Cloud. Vous devez configurer votre environnement Google Cloud, créer les projets et comptes de service Google Cloud nécessaires, et configurer IAM.
Déployer vos charges de travail
Lors de la phase de déploiement, vous allez déployer vos charges de travail sur GKE Enterprise :
- Provisionnez et configurez votre plate-forme et vos environnements d'exécution.
- Migrez les données de votre ancien environnement vers le nouvel environnement.
- 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 :
- Provisionner et configurer votre plate-forme et vos environnements d'exécution pour des clusters GKE sur Google Cloud
- Créer des clusters d'administrateur et d'utilisateur pour les clusters GKE sur VMware.
- Installer le cluster de gestion et créer un cluster utilisateur pour des clusters GKE sur AWS
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 :
- Gestion de l'authentification et des accès. Vous pouvez configurer la gestion de l'authentification et des accès comme décrit dans la section Configurer la gestion de l'authentification et des accès. Vous pouvez migrer vers Cloud Identity comme fournisseur d'identité principal ou utiliser Google Cloud Directory Sync pour synchroniser Cloud Identity avec un serveur LDAP ou Active Directory existant. GKE sur VMware est compatible avec OIDC (OpenID Connect) pour l'authentification auprès des clusters d'utilisateur à l'aide de la ligne de commande. Suivez les instructions de la section Procéder à l'authentification à l'aide d'OIDC et de Google pour intégrer l'authentification depuis la ligne de commande avec Cloud Identity.
- Surveillance. Vous pouvez adapter votre solution de surveillance actuelle à l'environnement GKE Enterprise cible en fonction de vos contraintes et de vos exigences. Si votre solution actuelle est hébergée sur OpenShift, vous pouvez implémenter Cloud Monitoring (comme décrit dans la section Établir les fondations) ou Prometheus et Grafana avec GKE sur VMware.
- Journalisation. Vous pouvez adapter votre solution de journalisation actuelle à l'environnement GKE Enterprise cible en fonction de vos contraintes et de vos exigences. Si votre solution actuelle est hébergée sur OpenShift, vous pouvez implémenter Cloud Logging comme décrit dans la section Établir les fondations - Surveillance et alertes.
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 :
- Contrôle d'accès basé sur les rôles (RBAC). Après avoir configuré l'authentification, vous pouvez mettre en œuvre vos règles d'autorisation en combinant Identity and Access Management et Kubernetes RBAC. Ces règles répondent aux exigences que vous avez répertoriées lors de l'évaluation du projet OpenShift et de la définition du modèle d'architecture mutualisée que vous avez choisi.
- Quotas de ressources. Si nécessaire, vous pouvez appliquer des quotas de ressources aux espaces de noms afin d'attribuer des quotas aux équipes de développeurs.
- Contexte de sécurité pour vos charges de travail. Vous pouvez utiliser l'outil Policy Controller afin de créer des contraintes visant à appliquer la sécurité relative aux pods sur la base de vos exigences et de la configuration des contraintes de contexte de sécurité OpenShift répertoriées lors de la phase d'évaluation.
- Règles et isolation du réseau. Vous pouvez mettre en œuvre l'isolation réseau requise entre les espaces de noms ou les charges de travail à l'aide des règles de réseau Kubernetes.
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 :
- Google Cloud Marketplace
- operatorhub.io
- Site Web ou dépôt GitHub spécifiques d'un fournisseur de logiciels
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, job 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 :
- Conserver votre dépôt d'images de conteneurs existant. Si vous utilisez un dépôt d'images de conteneurs externe qui ne s'exécute pas sur OpenShift et que vous n'êtes pas encore prêt à effectuer la migration, vous pouvez continuer à utiliser ce dépôt pour stocker vos images de conteneurs.
- Container Registry. Si vous préférez un service entièrement géré, vous pouvez utiliser Container Registry pour stocker vos images de conteneurs. Si vous avez besoin de couches de sécurité supplémentaires, vous pouvez gérer vous-même les clés de chiffrement Container Registry, configurer un périmètre sécurisé pour l'accès à Container Registry, améliorer la sécurité de votre chaîne d'approvisionnement logicielle, et analyser vos images de conteneurs pour y détecter des failles connues à l'aide d'Artifact Analysis. Container Registry accepte également les images de base gérées, dont la maintenance est assurée par Google, en tant que base pour vos images de conteneurs.
- Dépôt sur site. Si vous devez effectuer une migration depuis votre dépôt actuel parce qu'il est hébergé sur OpenShift et que vous devez stocker vos images de conteneurs sur site, vous pouvez choisir le registre fourni avec GitLab.
- Approche hybride. Vous pouvez combiner les options précédentes afin de tirer parti de leurs atouts respectifs. Par exemple, vous pouvez utiliser Container Registry comme dépôt principal et le dupliquer dans votre dépôt sur site. Dans ce cas, vous utilisez les fonctionnalités de Container Registry tout en bénéficiant d'un dépôt sur site.
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 |
|
SDN OpenShift et isolation réseau |
|
Contraintes de contexte de sécurité OpenShift |
|
Pipelines OpenShift |
|
OpenShift Source-to-Image |
|
Intégration de l'identité |
|
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 :
- Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation
- Définir vos exigences et vos objectifs d'optimisation
- Optimiser votre environnement et vos équipes
- 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 :
- Commencez à déployer des charges de travail dans un environnement sans serveur. Si vous devez réduire la pression à laquelle sont soumises vos équipes d'exploitation, vous pouvez commencer à utiliser des plates-formes sans serveur entièrement gérées telles que Cloud Run et Knative serving.
- Modernisez vos processus de déploiement. La documentation Migration vers Google Cloud : déployer vos charges de travail décrit des processus de déploiement de bout en bout classiques et explique comment moderniser vos processus existants. Si vous souhaitez moderniser vos processus de déploiement existants ou en concevoir de nouveaux, consultez la section Migration vers Google Cloud : passer des déploiements manuels aux déploiements automatisés en conteneurs pour obtenir des conseils.
- Déployez avec Spinnaker. Si vous devez mettre en œuvre une logique de déploiement (basée sur des déploiements Canary et des déploiements bleu-vert) pour améliorer la fiabilité de votre environnement et réduire l'impact pour vos utilisateurs, vous pouvez utiliser Spinnaker. Pour utiliser Spinnaker sur Google Cloud, vous devez préalablement l'installer. Une fois ceci fait, vous pouvez mettre en œuvre vos processus de déploiement à l'aide de Spinnaker. Par exemple, vous pouvez enregistrer vos clusters GKE existants dans Spinnaker, activer la compatibilité de Kustomize pour Spinnaker ou mettre en œuvre des pipelines de livraison continue avec Spinnaker et GKE.
- Mettez en œuvre une chaîne d'approvisionnement logicielle sécurisée. Pour les charges de travail pour lesquelles la sécurité est critique, vous pouvez mettre en œuvre une chaîne d'approvisionnement logicielle sécurisée dans vos clusters GKE Enterprise à l'aide de l'autorisation binaire.
- Passez à Cloud Service Mesh. Si vous utilisez déjà OpenShift Service Mesh ou si vous recherchez les fonctionnalités de gestion du trafic, d'observabilité et de sécurité fournies par un maillage de services, vous pouvez adopter la solution Cloud Service Mesh. Cloud Service Mesh fournit une distribution d'Istio testée et compatible avec GKE Enterprise, ainsi que des fonctionnalités de backend gérées par Google pour l'observabilité, la gestion des certificats mTLS et l'intégration avec Identity-Aware Proxy (IAP).
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.
Étapes suivantes
- Migration vers Google Cloud : premiers pas.
- Apprenez-en davantage sur GKE Enterprise et Migrate to Containers.
- Découvrez comment faciliter votre migration avec le déploiement du maillage de services Istio.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.