Ce guide est destiné aux administrateurs d'infrastructure et aux opérateurs d'applications qui exécutent un ensemble varié de charges de travail conteneurisées et qui souhaitent exploiter les atouts de Google Kubernetes Engine (GKE) et de Cloud Run pour déployer des applications sur Google Cloud Platform. Une stratégie hybride vous permet d'optimiser les coûts, les performances et les tâches de gestion.
Vous devez avoir des connaissances dans les domaines suivants :
Charges de travail avec et sans état
Pourquoi utiliser conjointement GKE et Cloud Run ?
GKE et Cloud Run offrent des avantages différents pour l'exécution d'applications conteneurisées et répondent à différents niveaux de complexité des charges de travail. Toutefois, vous n'avez pas besoin de choisir entre les deux plates-formes. Vous pouvez exploiter simultanément les avantages de GKE et de Cloud Run en migrant vos charges de travail entre les deux plates-formes selon vos besoins.
Voici quelques avantages de l'utilisation des deux environnements d'exécution pour déployer vos charges de travail :
GKE et Cloud Run offrent un niveau de portabilité relativement élevé :
Les deux plates-formes utilisent des images de conteneurs standards comme artefacts de déploiement. Vous pouvez utiliser la même image pour votre application sur l'une ou l'autre des plates-formes sans aucune modification, ce qui permet une migration fluide des charges de travail entre GKE et Cloud Run. Vous n'avez pas besoin de mettre à jour la configuration de l'intégration continue pour migrer entre GKE et Cloud Run tant que les images de conteneurs sont stockées dans Artifact Registry.
GKE et Cloud Run utilisent tous deux un modèle d'API déclaratif. L'API Cloud Run Admin v1 est conçue pour être compatible avec l'API Kubernetes. Cela signifie que vous pouvez utiliser des concepts Kubernetes courants tels que les déploiements, les services et les autoscalers horizontaux de pods pour gérer votre service Cloud Run. Cette similarité facilite la traduction des configurations entre les deux plates-formes.
Les ressources sont représentées dans des fichiers YAML ayant la même structure déclarative et standard, et peuvent donc facilement être migrées entre les environnements d'exécution. Voici un exemple permettant de comparer les fichiers YAML d'un déploiement Kubernetes et d'un service Cloud Run.
GKE et Cloud Run s'intègrent parfaitement à Cloud Logging et Cloud Monitoring, ce qui vous offre une vue centralisée dans la console Google Cloud pour observer les métriques des applications, quelle que soit leur plate-forme. Vous pouvez également utiliser la surveillance des objectifs de niveau de service (SLO) sur les deux plates-formes et afficher une vue unifiée des SLO dans le tableau de bord Cloud Monitoring.
Vous pouvez implémenter la livraison continue sur des ressources GKE ou des services Cloud Run à l'aide de Cloud Deploy. Si vous préférez, vous pouvez également déployer simultanément votre application sur GKE et Cloud Run à l'aide d'un déploiement parallèle.
Vous pouvez faciliter la gestion avancée du trafic en utilisant des équilibreurs de charge externes et internes pour les services sur GKE et Cloud Run. Cela inclut la possibilité d'exposer des points de terminaison externes afin de pouvoir déployer et exécuter différentes URL pour la même application sur les deux plates-formes. Vous pouvez également répartir le trafic sur le même service entre GKE et Cloud Run, ce qui permet une migration fluide d'une plate-forme à l'autre.
Google Cloud fournit des outils de sécurité permettant d'améliorer votre stratégie de sécurité lorsque vous utilisez les deux environnements d'exécution. L'analyse de l'OS vous permet de rechercher les failles des conteneurs avant de les déployer sur l'une des plates-formes. Une stratégie d'autorisation binaire centrale peut appliquer l'intégration au plan de contrôle GKE et Cloud Run pour autoriser ou bloquer le déploiement d'images en fonction des stratégies que vous définissez. Grâce à VPC Service Controls, les équipes chargées de la sécurité peuvent définir des contrôles de périmètre ultraprécis sur vos ressources GKE et Cloud Run.
Comparer GKE et Cloud Run
Pour profiter des meilleures fonctionnalités de GKE et de Cloud Run, et savoir quand déplacer des charges de travail entre ces services, il est important de comprendre ce qui les différencie.
| Sélection | GKE | Cloud Run |
|---|---|---|
| Déploiement et gestion | Gérez les clusters Kubernetes, y compris la configuration des nœuds, la mise en réseau, le scaling et les mises à niveau. Google Cloud gère l'infrastructure sous-jacente et fournit des outils permettant de simplifier les opérations sur les clusters. Cependant, vous restez responsable des principaux aspects de Kubernetes. |
Exécutez des conteneurs directement sur l'infrastructure évolutive de Google Cloud. Il vous suffit de fournir un code source ou une image de conteneur, et Cloud Run se charge de créer le conteneur pour vous. Vous n'avez pas besoin de créer de cluster, ni de provisionner et de gérer l'infrastructure. |
| Contrôle et flexibilité | Contrôle total sur le cluster Kubernetes. Vous pouvez créer des personnalisations avancées pour les configurations de nœuds, les règles de réseau, les paramètres de sécurité et les modules complémentaires. |
Contrôle limité sur l'infrastructure sous-jacente. Vous pouvez configurer des éléments tels que les variables d'environnement, la simultanéité et les connexions réseau, mais vous ne pouvez pas personnaliser l'infrastructure ou l'environnement sous-jacent. Solution idéale pour la simplicité et la rapidité. |
| Types d'applications | Compatible avec les applications sans état et avec état, et convient parfaitement aux applications complexes ayant des besoins en ressources spécifiques. | Idéal pour les services, les fonctions et les services Web sans état basés sur des requêtes ou des événements. |
| Modèle tarifaire | Tarification par cluster et par heure, quels que soient le mode de fonctionnement (Standard ou Autopilot), la taille du cluster ou la topologie. | Tarification à l'utilisation, le total étant arrondi à la centaine de millisecondes la plus proche. |
Cas d'utilisation
Supposons que vous êtes un administrateur de plate-forme dans une entreprise de commerce de détail chargé de créer une grande plate-forme d'e-commerce. Vous devez déployer les charges de travail conteneurisées suivantes :
Interface du site Web et application mobile : application Web sans état dans laquelle il est possible de parcourir les produits, d'en rechercher et d'effectuer des achats.
Gestion de l'inventaire des produits : service avec état permettant de gérer la disponibilité et les mises à jour des produits.
Moteur de recommandations : microservice complexe qui génère des recommandations de produits personnalisées pour chaque utilisateur.
Jobs de traitement par lot : incluent des tâches périodiques telles que la mise à jour des catalogues de produits et l'analyse du comportement des utilisateurs.
Ces charges de travail représentent une combinaison de services sans état et avec état. Vous décidez donc d'exploiter GKE et Cloud Run pour optimiser les performances. Voici une manière d'implémenter une approche hybride pour vos charges de travail.
Après avoir lu les critères de pertinence des charges de travail Cloud Run, vous décidez d'utiliser Cloud Run pour le site Web et l'application mobile, ainsi que pour les jobs de traitement par lot. Le déploiement de ces services sur Cloud Run présente les avantages suivants :
Le scaling automatique en fonction des pics de trafic et les jobs par lot volumineux sont gérés sans intervention manuelle.
Rentabilité avec un modèle de paiement à l'utilisation. Vous ne payez que lorsque les utilisateurs naviguent ou effectuent un achat, et lorsque des ressources sont utilisées lors de l'exécution du job par lot.
Déploiements plus rapides du fait que les mises à jour soient disponibles instantanément, améliorant ainsi l'expérience utilisateur.
Intégration facile à d'autres services Google Cloud. Par exemple, pour le traitement basé sur des événements, vous pouvez utiliser Cloud Functions pour lancer des jobs de traitement par lot sur Cloud Run et fluidifier les workflows.
La gestion de l'inventaire des produits est un service avec état qui nécessite un contrôle ultraprécis et des solutions de stockage potentiellement personnalisées. Vous décidez d'utiliser GKE pour déployer ce service, car il offre un stockage persistant et vous permet d'associer des volumes pour la persistance et la fiabilité des données produit.
Le moteur de recommandations est un microservice complexe qui exploite GKE. GKE vous permet de gérer des dépendances complexes, et d'exercer un contrôle précis sur l'allocation et le scaling des ressources.
GKE convient mieux aux architectures de microservices complexes, aux applications avec état, aux charges de travail nécessitant une infrastructure personnalisée ou des configurations réseau, et aux scénarios dans lesquels un niveau de contrôle très élevé sur Kubernetes est essentiel. Cloud Run est particulièrement adapté aux applications basées sur des événements. Cette solution est idéale pour les services Web sans état, les API, les jobs par lot et les autres charges de travail bénéficiant d'une tarification à l'utilisation.
L'exemple précédent montre comment la combinaison de GKE et Cloud Run peut offrir une solution puissante et flexible pour votre plate-forme d'e-commerce. Vous bénéficiez des avantages des deux plates-formes, de l'efficacité sans serveur pour les charges de travail sans état, et du contrôle de Kubernetes pour les microservices complexes et les composants avec état.
Remarques
GKE et Cloud Run se complètent pour répondre à différents besoins dans un environnement applicatif complexe.
Voici quelques éléments à prendre en compte lors de l'adoption d'une approche hybride pour le déploiement de charges de travail :
Exécutez des microservices sans état sur Cloud Run pour plus de rentabilité et d'évolutivité.
Déployez des applications avec état complexes nécessitant une personnalisation approfondie sur GKE.
Si vous utilisez un réseau privé sur Google Cloud, pour accéder aux ressources de votre cluster GKE à partir de votre service Cloud Run, vous pouvez envoyer une requête à un réseau cloud privé virtuel (VPC) en utilisant la sortie VPC directe. Pour accéder aux services du cluster GKE, le service Cloud Run doit être connecté au réseau VPC du cluster et le service GKE doit utiliser un équilibreur de charge réseau passthrough interne.
Pour migrer le trafic entre Cloud Run et GKE, vous pouvez exposer des points de terminaison externes derrière un équilibreur de charge d'application externe global. Lorsque vous implémentez cet équilibreur de charge devant des services dans les deux environnements d'exécution, vous pouvez déployer la même application sur Cloud Run et GKE, ce qui vous permet de transférer progressivement le trafic d'une plate-forme à l'autre.
Pour exposer des services Cloud Run dans un cloud privé virtuel derrière des adresses IP privées, utilisez un équilibreur de charge interne.
N'oubliez pas que si vos charges de travail s'exécutent déjà sur Cloud Run, vous pouvez toujours migrer vers GKE si nécessaire.
Quand ne pas utiliser conjointement GKE et Cloud Run
Bien que GKE et Cloud Run représentent une approche intéressante pour de nombreuses charges de travail conteneurisées, leur utilisation conjointe n'est pas forcément la meilleure solution dans certains cas. Voici quelques exemples de situations dans lesquelles vous pouvez décider de ne pas adopter une approche hybride :
Microservices à couplage fort : si vos microservices sont fortement dépendants les uns des autres et nécessitent une communication fréquente et à faible latence, leur gestion sur des plates-formes distinctes peut introduire des complexités. Les appels réseau fréquents entre les plates-formes peuvent entraîner une surcharge et des goulots d'étranglement potentiels, ce qui peut avoir une incidence sur les performances.
Anciennes applications avec des dépendances personnalisées : si votre application repose sur des bibliothèques, des frameworks ou des configurations spécifiques non compatibles avec Cloud Run, l'utilisation de ce service sur certaines parties de l'application peut nécessiter une refactorisation importante ou des solutions de contournement. Cela peut réduire les avantages offerts par le sans serveur et engendrer des coûts de maintenance spécifiques à la plate-forme.
Contraintes budgétaires avec des charges de travail prévisibles : si votre charge de travail présente des besoins constants en ressources et que vous disposez d'un budget serré, le modèle de tarification par nœud de GKE peut s'avérer plus rentable que celui de paiement à l'usage de Cloud Run. Si vous avez des charges de travail prévisibles, vous risquez de ne pas utiliser pleinement les avantages du scaling automatique de Cloud Run, ce qui rend le coût fixe de GKE plus attrayant.
En définitive, la meilleure approche dépend de vos besoins et priorités spécifiques. Évaluez soigneusement les exigences de votre application, les contraintes liées aux ressources et l'expertise de votre équipe avant de choisir une architecture GKE et Cloud Run hybride.
Étapes suivantes
Pour découvrir comment convertir votre service Cloud Run en déploiement Kubernetes, consultez la page Migrer depuis Cloud Run vers GKE.
Empaquetez votre déploiement Kubernetes dans un conteneur compatible avec Cloud Run en suivant la procédure de la page Migrer de Kubernetes vers Cloud Run.