Ce document vous aide à évaluer les exigences de votre application et à choisir entre Cloud Run et Google Kubernetes Engine (GKE) Autopilot, en fonction de considérations techniques et organisationnelles. Ce document s'adresse aux architectes cloud qui doivent choisir un environnement d'exécution de conteneur cible pour leurs charges de travail. Google Cloud Nous partons du principe que vous connaissez Kubernetes et Google Cloud, et que vous avez des connaissances de base sur les environnements d'exécution sans serveur cloud tels que Cloud Run, Cloud Run Functions ou AWS Lambda.
Google Cloud propose plusieurs options d'environnement d'exécution qui disposent d'un large éventail de fonctionnalités. Le schéma suivant présente la gamme d'offres gérées par Google Cloud:
Le schéma montre les éléments suivants :
Environnements d'exécution les plus gérés (objet de ce guide):
- Cloud Run, qui inclut les fonctions Cloud Run.
- GKE Autopilot.
Ces options sont gérées par Google, sans gestion par l'utilisateur de l'infrastructure de calcul sous-jacente.
Environnements d'exécution les moins gérés:
- GKE Standard, qui est optimisé pour les charges de travail d'entreprise et offre une évolutivité sur un seul cluster jusqu'à 65 000 nœuds.
- Compute Engine, qui inclut la famille de machines virtuelles A3 optimisée pour les accélérateurs pour les charges de travail de machine learning (ML) et de calcul hautes performances (HPC).
Ces options nécessitent un certain niveau de gestion de l'infrastructure au niveau de l'utilisateur, comme les machines virtuelles (VM) sous-jacentes aux capacités de calcul. Les VM dans GKE Standard sont les nœuds de cluster Kubernetes. Les VM de Compute Engine constituent l'offre de plate-forme de base, que vous pouvez personnaliser en fonction de vos besoins.
Ce guide vous aide à choisir entre les environnements d'exécution les plus gérés, Cloud Run et GKE Autopilot. Pour une vue plus large des environnements d'exécution Google Cloud , consultez le guide Google Cloud Options d'hébergement d'applications.
Présentation des environnements
Cette section présente les fonctionnalités de Cloud Run et de GKE Autopilot. Cloud Run et GKE Autopilot sont tous deux étroitement intégrés à Google Cloud. Il existe donc de nombreuses similitudes entre les deux. Les deux plates-formes proposent plusieurs options d'équilibrage de charge avec les services d'équilibrage de charge de Google, qui sont très fiables et évolutifs. Ils sont également compatibles avec la mise en réseau VPC, le proxy Identity-Aware Proxy (IAP) et Google Cloud Armor lorsque vous avez besoin d'une mise en réseau privée plus précise. Les deux plates-formes ne vous facturent que les ressources exactes que vous utilisez pour vos applications.
Du point de vue de la diffusion logicielle, en tant qu'environnements d'exécution de conteneur, Cloud Run et GKE Autopilot sont compatibles avec les services qui constituent l' Google Cloud écosystème de conteneurs. Ces services incluent Cloud Build, Artifact Registry, Binary Authorization et la livraison continue avec Cloud Deploy, qui vous aident à vous assurer que vos applications sont déployées en production de manière sûre et fiable. Cela signifie que vous et vos équipes êtes responsables des décisions de compilation et de déploiement.
En raison des points communs entre les deux plates-formes, vous pouvez exploiter les points forts de chacune d'elles en adoptant une approche flexible pour le déploiement de vos applications, comme indiqué dans le guide Utiliser GKE et Cloud Run ensemble. Les sections suivantes décrivent les aspects uniques de Cloud Run et d'Autopilot.
Cloud Run
Cloud Run est une plate-forme de calcul gérée sans serveur qui vous permet d'exécuter vos applications directement sur l'infrastructure évolutive de Google. Cloud Run fournit l'automatisation et la mise à l'échelle pour deux principaux types d'applications:
- Services Cloud Run : pour le code qui répond aux requêtes Web.
- Jobs Cloud Run : pour le code qui effectue une ou plusieurs tâches en arrière-plan, puis se ferme une fois la tâche terminée.
Grâce à ces deux modèles de déploiement, Cloud Run peut prendre en charge un large éventail d'architectures d'applications, tout en permettant de suivre les bonnes pratiques et en laissant les développeurs se concentrer sur le code.
Cloud Run permet également de déployer du code d'application à partir des sources suivantes:
- Fonctions légères individuelles
- Applications complètes à partir du code source
- Applications conteneurisées
Cloud Run intègre une fonctionnalité de compilation et de déploiement qui prend en charge à la fois le FaaS et la possibilité de compiler à partir de la source, en plus de la fonctionnalité d'exécution de conteneur prédéfini. Lorsque vous utilisez Cloud Run de cette manière, les étapes de création et de déploiement de l'image de conteneur d'application qui sera exécutée sont entièrement automatiques et ne nécessitent aucune configuration personnalisée de votre part.
GKE Autopilot
GKE Autopilot est le mode de fonctionnement par défaut et recommandé des clusters dans GKE. Autopilot vous permet d'exécuter des applications sur Kubernetes sans les coûts liés à la gestion de l'infrastructure. Lorsque vous utilisez Autopilot, Google gère les principaux aspects sous-jacents de la configuration de votre cluster, y compris le provisionnement et le scaling des nœuds, la posture de sécurité par défaut et d'autres paramètres préconfigurés. Avec Autopilot qui gère les ressources de nœud, vous ne payez que pour les ressources demandées par vos charges de travail. Autopilot surveille et optimise en permanence les ressources d'infrastructure pour s'assurer d'une adéquation optimale, tout en fournissant un contrat de niveau de service pour vos charges de travail.
GKE Autopilot est compatible avec les charges de travail qui ne sont peut-être pas adaptées à Cloud Run. Par exemple, GKE Autopilot est généralement compatible avec les charges de travail durables ou avec état.
Choisir un environnement d'exécution
En général, si les caractéristiques de votre charge de travail conviennent à une plate-forme gérée, l'environnement d'exécution sans serveur de Cloud Run est idéal. L'utilisation de Cloud Run peut réduire l'infrastructure à gérer, la configuration gérée par l'utilisateur et donc les coûts opérationnels. À moins que vous ne souhaitiez ou n'ayez spécifiquement besoin de Kubernetes, nous vous recommandons de commencer par considérer le sans serveur comme votre environnement d'exécution cible. Bien que Kubernetes fournisse l'abstraction puissante d'une plate-forme ouverte, son utilisation ajoute de la complexité. Si vous n'avez pas besoin de Kubernetes, nous vous recommandons de déterminer si votre application est adaptée au sans serveur. Si des critères rendent votre charge de travail moins adaptée au sans serveur, nous vous recommandons d'utiliser Autopilot.
Les sections suivantes fournissent plus de détails sur certains des critères qui peuvent vous aider à répondre à ces questions, en particulier la question de savoir si la charge de travail est adaptée au sans serveur. Compte tenu des points communs entre Autopilot et Cloud Run décrits dans les sections précédentes, la migration entre les plates-formes est une tâche simple lorsqu'il n'y a pas de blocages techniques ou autres. Pour en savoir plus sur les options de migration, consultez les pages Migrer depuis Cloud Run vers GKE et Migrer depuis Kubernetes vers Cloud Run.
Lorsque vous choisissez un environnement d'exécution pour votre charge de travail, vous devez tenir compte des considérations techniques et organisationnelles. Les considérations techniques sont des caractéristiques de votre application ou de l'environnement d'exécution. Google CloudLes considérations organisationnelles sont des caractéristiques non techniques de votre organisation ou de votre équipe qui peuvent influencer votre décision.
Questions techniques
Voici quelques-unes des considérations techniques qui influenceront votre choix de plate-forme:
- Contrôle et configurabilité: granularité du contrôle de l'environnement d'exécution.
- Gestion et routage du trafic réseau: possibilité de configurer les interactions sur le réseau.
- Évolutivité horizontale et verticale: prise en charge de la croissance et de la réduction dynamique de la capacité.
- Compatibilité avec les applications avec état: fonctionnalités permettant de stocker un état persistant.
- Architecture de processeur: compatibilité avec différents types de processeurs.
- Déchargement d'accélérateur (GPU et TPU): possibilité de décharger le calcul sur du matériel dédié.
- Capacité élevée de la mémoire, du processeur et d'autres ressources: niveau de consommation des différentes ressources.
- Dépendance explicite envers Kubernetes: exigences concernant l'utilisation de l'API Kubernetes.
- RBAC complexe pour l'architecture multitenancy: permet de partager des ressources mutualisées.
- Délai avant expiration maximal de la tâche de conteneur: durée d'exécution des applications ou composants de longue durée.
Les sections suivantes détaillent ces considérations techniques pour vous aider à choisir un environnement d'exécution.
Contrôle et configurabilité
Par rapport à Cloud Run, Autopilot GKE offre un contrôle plus précis de l'environnement d'exécution pour vos charges de travail. Dans le contexte d'un pod, Kubernetes fournit de nombreuses primitives configurables que vous pouvez ajuster pour répondre aux exigences de votre application. Les options de configuration incluent le niveau d'autorisation, les paramètres de qualité de service, les gestionnaires personnalisés pour les événements de cycle de vie des conteneurs et le partage d'espace de noms de processus entre plusieurs conteneurs.
Cloud Run est compatible directement avec un sous-ensemble de la surface de l'API Kubernetes Pod, qui est décrite dans le fichier YAML de référence pour l'objet de service Cloud Run et dans le fichier YAML de référence pour l'objet de tâche Cloud Run. Ces guides de référence peuvent vous aider à évaluer les deux plates-formes en fonction des exigences de votre application.
Le contrat de conteneur pour l'environnement d'exécution Cloud Run est relativement simple et convient à la plupart des charges de travail de diffusion. Toutefois, le contrat spécifie certaines conditions à remplir. Si votre application ou ses dépendances ne peuvent pas répondre à ces exigences, ou si vous avez besoin d'un contrôle plus précis sur l'environnement d'exécution, Autopilot peut être plus adapté.
Si vous souhaitez réduire le temps consacré à la configuration et à l'administration, envisagez de choisir Cloud Run comme environnement d'exécution. Cloud Run propose moins d'options de configuration qu'Autopilot. Il peut donc vous aider à maximiser la productivité des développeurs et à réduire les coûts opérationnels.
Gestion et routage du trafic réseau
Cloud Run et GKE Autopilot s'intègrent à Google Cloud Load Balancing. Cependant, GKE Autopilot fournit également un ensemble de primitives riche et puissant pour configurer l'environnement réseau pour les communications de service à service. Les options de configuration incluent des autorisations et une ségrégation précises au niveau de la couche réseau à l'aide d'espaces de noms et de règles réseau, de remappage de port et de détection de services DNS intégrée au cluster. GKE Autopilot est également compatible avec l'API Gateway, qui est hautement configurable et flexible. Cette fonctionnalité offre un contrôle puissant sur la manière dont le trafic est acheminé vers et entre les services du cluster.
Étant donné qu'Autopilot est hautement configurable, il peut être la meilleure option si vous disposez de plusieurs services présentant un degré élevé de codépendance réseau ou des exigences complexes concernant la manière dont le trafic est acheminé entre les composants de votre application. Un exemple de ce modèle est une application distribuée décomposée en de nombreux microservices présentant des schémas d'interdépendance complexes. Dans de tels scénarios, les options de configuration de la mise en réseau Autopilot peuvent vous aider à gérer et à contrôler les interactions entre les services.
Évolutivité horizontale et verticale
Cloud Run et GKE Autopilot sont tous deux compatibles avec l'autoscaling horizontal manuel et automatique pour les services et les jobs. Le scaling horizontal fournit une puissance de calcul accrue lorsque cela est nécessaire et supprime la puissance de calcul supplémentaire lorsqu'elle n'est pas nécessaire. Pour une charge de travail typique, Cloud Run peut généralement effectuer un scaling horizontal plus rapidement que GKE Autopilot pour répondre aux pics du nombre de requêtes par seconde. Par exemple, la démonstration vidéo "What's New in Serverless Compute?" (Nouveautés du calcul sans serveur) montre Cloud Run passer de zéro à plus de 10 000 instances en environ 10 secondes. Pour accélérer le scaling horizontal sur Kubernetes (à un coût supplémentaire), Autopilot vous permet de provisionner une capacité de calcul supplémentaire.
Si votre application ne peut pas évoluer en ajoutant d'autres instances pour augmenter le niveau de ressources disponibles, Autopilot peut être plus adapté. Autopilot est compatible avec le scaling vertical pour faire varier dynamiquement la puissance de traitement disponible sans augmenter le nombre d'instances en cours d'exécution de l'application.
Cloud Run peut réduire automatiquement vos applications à zéro réplication lorsqu'elles ne sont pas utilisées, ce qui est utile pour certains cas d'utilisation axés sur l'optimisation des coûts. En raison des caractéristiques de la mise à l'échelle de vos applications à zéro, vous pouvez suivre plusieurs étapes d'optimisation pour réduire le temps entre l'arrivée d'une requête et le moment où votre application est opérationnelle et peut traiter la requête.
Prise en charge des applications avec état
Autopilot offre une compatibilité complète avec les volumes Kubernetes, soutenus par des disques persistants qui vous permettent d'exécuter un large éventail de déploiements avec état, y compris des bases de données autogérées. Cloud Run et GKE Autopilot vous permettent de vous connecter à d'autres services tels que Filestore et les buckets Cloud Storage. Ils incluent également la possibilité d'installer des buckets d'objets dans le système de fichiers avec Cloud Storage FUSE.
Cloud Run utilise un système de fichiers en mémoire, qui n'est peut-être pas adapté aux applications qui nécessitent un système de fichiers local persistant. De plus, le système de fichiers local en mémoire est partagé avec la mémoire de votre application. Par conséquent, l'utilisation de la mémoire de l'application et du conteneur, ainsi que du système de fichiers éphémère, contribue à épuiser la limite de mémoire. Vous pouvez éviter ce problème si vous utilisez un volume en mémoire dédié avec une limite de taille.
Un service ou un conteneur de tâche Cloud Run dispose d'un délai avant expiration maximal. Un conteneur exécuté dans un pod d'un cluster Autopilot peut être reprogrammé, sous réserve de toute contrainte configurée avec des budgets d'interruption de pod (PDB). Toutefois, les pods peuvent s'exécuter pendant sept jours maximum lorsqu'ils sont protégés contre l'éviction provoquée par des mises à niveau automatiques des nœuds ou des événements de réduction de capacité. En règle générale, le délai avant expiration des tâches est plus susceptible d'être pris en compte pour les charges de travail par lot dans Cloud Run. Pour les charges de travail de longue durée et les tâches par lot qui ne peuvent pas être effectuées dans la durée maximale de la tâche, Autopilot peut être la meilleure option.
Architecture de CPU
Toutes les plates-formes de calcul Google Cloud sont compatibles avec l'architecture de processeur x86. Cloud Run n'est pas compatible avec les processeurs de l'architecture Arm, mais Autopilot est compatible avec les nœuds gérés basés sur l'architecture Arm. Si votre charge de travail nécessite l'architecture Arm, vous devez utiliser Autopilot.
Déchargement de l'accélérateur
Autopilot prend en charge l'utilisation de GPU et de TPU, y compris la possibilité de consommer des ressources réservées. Cloud Run prend en charge l'utilisation de GPU avec certaines limitations.
Exigences élevées en termes de mémoire, de processeur et d'autres ressources
Par rapport aux limites de requêtes de ressources GKE Autopilot, les ressources de processeur et de mémoire maximales pouvant être consommées par un seul service ou tâche Cloud Run (une seule instance) sont limitées. Selon les caractéristiques de vos charges de travail, Cloud Run peut avoir d'autres limites qui limitent les ressources disponibles. Par exemple, le délai avant expiration de démarrage et le nombre maximal de connexions sortantes peuvent être limités avec Cloud Run. Avec Autopilot, certaines limites peuvent ne pas s'appliquer ou avoir des valeurs autorisées plus élevées.
Dépendance explicite envers Kubernetes
Certaines applications, bibliothèques ou frameworks peuvent avoir une dépendance explicite envers Kubernetes. La dépendance Kubernetes peut être due à l'un des éléments suivants:
- Les exigences de l'application (par exemple, l'application appelle des API Kubernetes ou utilise des ressources personnalisées Kubernetes).
- Les exigences des outils utilisés pour configurer ou déployer l'application (par exemple, Helm).
- Exigences d'assistance d'un créateur ou fournisseur tiers
Dans ces scénarios, Autopilot est l'environnement d'exécution cible, car Cloud Run n'est pas compatible avec Kubernetes.
RBAC complexe pour l'architecture mutualisée
Si votre organisation dispose de structures organisationnelles ou de conditions requises pour la multi-tenancy particulièrement complexes, utilisez Autopilot afin de pouvoir profiter du contrôle des accès basé sur les rôles (RBAC) de Kubernetes. Pour une option plus simple, vous pouvez utiliser les fonctionnalités de sécurité et de ségrégation intégrées à Cloud Run.
Considérations organisationnelles
Voici quelques-unes des considérations organisationnelles qui influenceront votre choix d'environnement:
- Stratégie technique globale: orientation technique de votre organisation.
- Exploitation de l'écosystème Kubernetes: intérêt à exploiter la communauté Open Source.
- Outils internes existants: utilisation actuelle de certains outils.
- Profils de l'équipe de développement: compétences et expérience des développeurs.
- Assistance opérationnelle: capacités et objectifs des équipes opérationnelles.
Les sections suivantes détaillent ces considérations organisationnelles pour vous aider à choisir un environnement.
Stratégie technique globale
Les organisations ou les équipes peuvent avoir des stratégies convenues pour préférer certaines technologies à d'autres. Par exemple, si une équipe s'est engagée à standardiser dans la mesure du possible sur le modèle sans serveur ou sur Kubernetes, cet engagement peut influencer ou même dicter un environnement d'exécution cible.
Si une charge de travail donnée ne convient pas à l'environnement d'exécution spécifié dans la stratégie, vous pouvez décider d'effectuer une ou plusieurs des opérations suivantes, avec les mises en garde associées:
- Réorganiser la charge de travail Toutefois, si la charge de travail n'est pas adaptée, cela peut entraîner des performances, des coûts, une sécurité ou d'autres caractéristiques non optimales.
- Enregistrez la charge de travail en tant qu'exception à l'orientation stratégique. Toutefois, si les exceptions sont trop utilisées, cela peut entraîner un portefeuille technologique disparate.
- Réfléchissez à votre stratégie. Toutefois, cela peut entraîner des frais liés aux règles qui peuvent entraver ou bloquer la progression.
Exploiter l'écosystème Kubernetes
Dans le cadre de la stratégie technique globale décrite précédemment, les organisations ou les équipes peuvent choisir Kubernetes comme plate-forme de leur choix en raison de l'écosystème important et croissant. Ce choix est distinct de la sélection de Kubernetes en raison des dépendances techniques de l'application, comme décrit dans la section précédente Dépendance explicite envers Kubernetes. L'utilisation de l'écosystème Kubernetes met l'accent sur une communauté active, des outils tiers riches, ainsi que sur des normes et une portabilité solides. Exploiter l'écosystème Kubernetes peut accélérer votre vitesse de développement et réduire les délais de commercialisation.
Outils internes existants
Dans certains cas, il peut être avantageux d'utiliser les écosystèmes d'outils existants dans votre organisation ou votre équipe (pour l'un des environnements). Par exemple, si vous utilisez Kubernetes, vous pouvez choisir de continuer à utiliser des outils de déploiement tels que ArgoCD, des outils de sécurité et de gestion des règles tels que Gatekeeper, et des outils de gestion de paquets tels que Helm. Les outils existants peuvent inclure des règles établies pour l'automatisation de la conformité organisationnelle et d'autres fonctionnalités qui peuvent être coûteuses ou nécessiter un long délai d'implémentation pour un autre environnement cible.
Profils de l'équipe de développement
Une équipe d'applications ou de charges de travail peut avoir une expérience préalable avec Kubernetes, ce qui peut accélérer la vitesse et la capacité de l'équipe à livrer avec Autopilot. Il peut s'écouler un certain temps avant qu'une équipe ne maîtrise un nouvel environnement d'exécution. Selon le modèle d'exploitation, cela peut entraîner une baisse de la fiabilité de la plate-forme pendant la période de montée en compétences.
Pour une équipe en pleine croissance, les possibilités d'embauche peuvent influencer le choix de plate-forme d'une organisation. Sur certains marchés, les compétences Kubernetes peuvent être rares et donc faire l'objet d'une prime d'embauche. Choisir un environnement tel que Cloud Run peut vous aider à simplifier le processus de recrutement et à développer plus rapidement votre équipe dans le respect de votre budget.
Assistance opérationnelle
Lorsque vous choisissez un environnement d'exécution, tenez compte de l'expérience et des compétences de vos équipes SRE, DevOps, plates-formes et autres membres du personnel opérationnel. Les capacités des équipes opérationnelles à prendre en charge efficacement l'environnement de production sont essentielles d'un point de vue de fiabilité. Il est également essentiel que les équipes opérationnelles puissent prendre en charge les environnements de préproduction pour s'assurer que la vitesse de développement n'est pas entravée par les temps d'arrêt, la dépendance à l'égard de processus manuels ou les mécanismes de déploiement lourds.
Si vous utilisez Kubernetes, une équipe d'exploitation centrale ou d'ingénierie de plate-forme peut gérer les mises à niveau Kubernetes Autopilot. Bien que les mises à niveau soient automatiques, l'équipe d'exploitation les surveille généralement de près pour limiter au maximum les perturbations de vos charges de travail. Certaines organisations choisissent de mettre à niveau manuellement les versions du plan de contrôle. GKE Enterprise inclut également des fonctionnalités permettant de simplifier la gestion des applications sur plusieurs clusters.
Contrairement à Autopilot, Cloud Run ne nécessite pas de frais de gestion ni de mises à niveau du plan de contrôle en cours. En utilisant Cloud Run, vous pouvez simplifier vos processus d'exploitation. En sélectionnant un seul environnement d'exécution, vous pouvez simplifier davantage vos processus d'exploitation. Si vous choisissez d'utiliser plusieurs environnements d'exécution, vous devez vous assurer que l'équipe dispose des capacités, des compétences et de l'intérêt nécessaires pour prendre en charge ces environnements d'exécution.
Sélection
Pour commencer le processus de sélection, discutez avec les différentes personnes concernées. Pour chaque application, constituez un groupe de travail composé de développeurs, de membres de l'équipe opérationnelle, de représentants de tout groupe de gouvernance technologique central, d'utilisateurs et de consommateurs internes de l'application, d'équipes de sécurité et d'optimisation financière du cloud, ainsi que d'autres rôles ou groupes de votre organisation qui pourraient être pertinents. Vous pouvez choisir de diffuser une enquête de collecte d'informations pour rassembler les caractéristiques de l'application et partager les résultats avant la session. Nous vous recommandons de sélectionner un petit groupe de travail qui n'inclut que les personnes concernées requises. Il est possible que tous les représentants ne soient pas nécessaires à chaque session de travail.
Vous pouvez également trouver utile d'inclure des représentants d'autres équipes ou groupes ayant de l'expérience dans la création et l'exécution d'applications sur Autopilot ou Cloud Run, ou les deux. Utilisez les considérations techniques et organisationnelles de ce document pour guider votre conversation et évaluer l'adéquation de votre application à chacune des plates-formes potentielles.
Nous vous recommandons de planifier un point de contrôle après quelques mois pour confirmer ou revenir sur votre décision en fonction des résultats du déploiement de votre application dans le nouvel environnement.
Étape suivante
- Découvrez-en plus sur ces environnements d'exécution avec le démarrage rapide de GKE Autopilot et l'atelier Cloud Run.
- Découvrez comment migrer de Cloud Run vers GKE et de Kubernetes vers Cloud Run.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Cloud Architecture Center.
Contributeurs
Auteur: Henry Bell | Architecte de solutions cloud
Autres contributeurs :
- Marco Ferrari | Architecte de solutions cloud
- Gari Singh | Responsable produit orienté client
- Maridi (Raju) Makaraju | Supportability Tech Lead
- Parag Doshi | Architecte d'entreprise principal
- Daniel Stamer | Ingénieur client, Digital Natives
- Steren Giannini | Responsable groupe de produits
- Victor Szalvay | Responsable produit principal
- William Denniss | Responsable groupe de produits