Sélectionner un environnement d'exécution de conteneur géré

Last reviewed 2024-08-30 UTC

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 Google Cloud cible pour leurs charges de travail. 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 dans le cloud, tels que Cloud Run, Cloud Run Functions ou AWS Lambda.

Google Cloud propose plusieurs options d'environnement d'exécution offrant diverses fonctionnalités. Le schéma suivant montre la gamme d'offres gérées Google Cloud :

Google Cloud , du plus géré au moins géré.

Le schéma montre les éléments suivants :

  • Environnements d'exécution les plus gérés (objet de ce guide) :

    Ces options sont gérées par Google, sans gestion des utilisateurs 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ées pour les accélérateurs pour les charges de travail de machine learning (ML) et de calcul hautes performances (HPC).

    Ces options nécessitent une certaine gestion de l'infrastructure au niveau de l'utilisateur, comme les machines virtuelles (VM) qui sous-tendent les capacités de calcul. Dans GKE Standard, les VM sont les nœuds du cluster Kubernetes. Les VM dans 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 nombreux points communs entre les deux. Les deux plates-formes sont compatibles avec plusieurs options d'équilibrage de charge grâce aux services d'équilibrage de charge de Google, qui sont hautement fiables et évolutifs. Ils sont également compatibles avec la mise en réseau VPC, Identity-Aware Proxy (IAP) et Google Cloud Armor lorsque des réseaux privés plus précis sont nécessaires. Les deux plates-formes ne vous facturent que les ressources exactes que vous utilisez pour vos applications.

Du point de vue de la distribution de logiciels, Cloud Run et GKE Autopilot sont compatibles en tant qu'environnements d'exécution de conteneurs avec les services qui composent l'écosystème de conteneurs Google Cloud . Ces services incluent Cloud Build, Artifact Registry, l'autorisation binaire et la livraison continue avec Cloud Deploy, pour vous aider à déployer vos applications en production de manière sécurisée et fiable. Cela signifie que vous et vos équipes êtes responsables des décisions de compilation et de déploiement.

En raison de la similitude entre les deux plates-formes, vous pouvez tirer parti des avantages de chacune en adoptant une approche flexible quant à l'emplacement de déploiement de vos applications, comme indiqué dans le guide Utiliser conjointement GKE et Cloud Run. 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 le scaling 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'application tout en permettant d'appliquer 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 individuelles légères
  • 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 le FaaS et la possibilité de compiler à partir de la source, en plus de la fonctionnalité d'environnement 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é pour les clusters dans GKE. Autopilot vous permet d'exécuter des applications sur Kubernetes sans les frais généraux 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 garantir la meilleure adéquation tout en fournissant un SLA pour vos charges de travail.

GKE Autopilot est compatible avec les charges de travail qui ne sont pas adaptées à Cloud Run. Par exemple, GKE Autopilot est généralement compatible avec les charges de travail de longue durée 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 entraîner une réduction de l'infrastructure à gérer, une diminution de la configuration autogérée et, par conséquent, une diminution des frais généraux opérationnels. À moins que vous ne souhaitiez ou n'ayez besoin de Kubernetes, nous vous recommandons de considérer d'abord le sans serveur comme 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 certains 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 à celle 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 en l'absence de blocages techniques ou autres. Pour en savoir plus sur les options de migration, consultez 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 Cloud. Les 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-uns des éléments techniques qui influenceront votre choix de plate-forme :

  • Contrôle et configurabilité : précision du contrôle de l'environnement d'exécution.
  • Gestion et routage du trafic réseau : configurabilité des interactions sur le réseau.
  • Évolutivité horizontale et verticale : capacité de croissance et de réduction dynamiques.
  • Compatibilité avec les applications avec état : fonctionnalités permettant de stocker un état persistant.
  • Architecture du processeur : compatibilité avec différents types de processeurs.
  • Déchargement de l'accélérateur (GPU et TPU) : possibilité de décharger le calcul sur du matériel dédié.
  • Capacité élevée de mémoire, de processeur et d'autres ressources : niveau de diverses ressources consommées.
  • Dépendance explicite envers Kubernetes : exigences concernant l'utilisation de l'API Kubernetes.
  • RBAC complexe pour l'architecture mutualisée : compatibilité avec le partage des ressources mises en commun.
  • Délai avant expiration maximal pour les tâches 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, GKE Autopilot offre un contrôle plus précis de l'environnement d'exécution de 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 de privilège, les paramètres de qualité de service, les gestionnaires personnalisés pour les événements du cycle de vie des conteneurs et le partage de l'espace de noms de processus entre plusieurs conteneurs.

Cloud Run est directement compatible avec un sous-ensemble de la surface de l'API Kubernetes Pod, qui est décrit dans le YAML de référence pour l'objet Cloud Run Service et dans le YAML de référence pour l'objet Cloud Run Job. 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 exigences à 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 que vous consacrez à 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 frais opérationnels.

Gestion et routage du trafic réseau

Cloud Run et GKE Autopilot s'intègrent à Google Cloud Load Balancing. Toutefois, 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 précises et une ségrégation au niveau du réseau à l'aide d'espaces de noms et de règles réseau, du remappage de ports et de la détection de services DNS intégrée au cluster. GKE Autopilot est également compatible avec l'API Gateway, qui est très configurable et flexible. Cette fonctionnalité permet de contrôler précisément la manière dont le trafic est acheminé vers les services du cluster et entre eux.

Autopilot étant hautement configurable, il peut être la meilleure option si vous avez plusieurs services avec un degré élevé de codépendance réseau ou des exigences complexes concernant la façon 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 qui présentent des modèles d'interdépendance complexes. Dans de tels scénarios, les options de configuration 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 compatibles avec le scaling 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 la supprime lorsqu'elle n'est pas requise. 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 vidéo de démonstration Nouveautés du calcul sans serveur montre le scaling de Cloud Run de zéro à plus de 10 000 instances en environ 10 secondes. Pour augmenter la vitesse du scaling horizontal sur Kubernetes (moyennant 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 des instances pour augmenter le niveau de ressources disponibles, elle peut être plus adaptée à Autopilot. 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 automatiquement réduire le nombre de répliques de vos applications à zéro lorsqu'elles ne sont pas utilisées. Cela est utile pour certains cas d'utilisation qui mettent l'accent sur l'optimisation des coûts. En raison des caractéristiques de la façon dont vos applications peuvent être mises à l'échelle à zéro, vous pouvez suivre plusieurs étapes d'optimisation pour minimiser le temps entre l'arrivée d'une requête et le moment où votre application est opérationnelle et capable de la traiter.

Compatibilité avec les applications avec état

Autopilot offre une compatibilité complète avec les volumes Kubernetes, soutenue 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 tous deux de vous connecter à d'autres services, tels que les buckets Filestore et Cloud Storage. Ils incluent également la possibilité d'installer des buckets Object Store dans le système de fichiers avec Cloud Storage FUSE.

Cloud Run utilise un système de fichiers en mémoire, qui peut ne pas convenir aux applications nécessitant 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 du système de fichiers éphémère, de l'application et du conteneur 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 conteneur de service ou de job Cloud Run dispose d'un délai avant expiration de la tâche maximal. Un conteneur exécuté dans un pod d'un cluster Autopilot peut être reprogrammé, sous réserve des contraintes configurées avec les 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 général, 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 des tâches, 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 d'architecture Arm, mais Autopilot l'est avec les nœuds gérés qui s'appuient sur l'architecture Arm. Si votre charge de travail nécessite l'architecture Arm, vous devrez 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 demandes de ressources GKE Autopilot, les ressources de processeur et de mémoire maximales pouvant être consommées par un seul service ou job Cloud Run (une seule instance) sont limitées. En fonction des caractéristiques de vos charges de travail, Cloud Run peut imposer d'autres limites qui restreignent les ressources disponibles. Par exemple, le délai avant expiration du démarrage et le nombre maximal de connexions sortantes peuvent être limités avec Cloud Run. Avec Autopilot, il est possible que certaines limites ne s'appliquent pas ou que les valeurs autorisées soient plus élevées.

Dépendance explicite envers Kubernetes

Certaines applications, bibliothèques ou certains frameworks peuvent avoir une dépendance explicite envers Kubernetes. La dépendance Kubernetes peut être due à l'un des éléments suivants :

  1. Exigences de l'application (par exemple, l'application appelle les API Kubernetes ou utilise des ressources personnalisées Kubernetes).
  2. Exigences de l'outil utilisé pour configurer ou déployer l'application (par exemple, Helm).
  3. Les 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 a des structures organisationnelles ou des exigences de multitenancy particulièrement complexes, utilisez Autopilot pour 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.
  • Exploiter l'écosystème Kubernetes : intérêt pour l'exploitation de la communauté OSS.
  • Outils internes existants : utilisation de certains outils.
  • Profils des équipes de développement : compétences et expérience des développeurs.
  • Assistance opérationnelle : capacités et priorités des équipes opérationnelles.

Les sections suivantes détaillent ces considérations organisationnelles pour vous aider à choisir un environnement.

Stratégie technique générale

Les organisations ou les équipes peuvent avoir convenu de stratégies pour privilégier certaines technologies par rapport à d'autres. Par exemple, si une équipe a convenu de standardiser, dans la mesure du possible, le modèle sans serveur ou Kubernetes, cet accord peut influencer, voire 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 actions suivantes, avec les mises en garde qui s'y rapportent :

  • Repensez l'architecture de la charge de travail. Toutefois, si la charge de travail ne convient pas, cela peut entraîner des performances, des coûts, une sécurité ou d'autres caractéristiques non optimales.
  • Enregistrez la charge de travail comme exception à l'orientation stratégique. Toutefois, si les exceptions sont utilisées de manière excessive, cela peut entraîner un portefeuille technologique disparate.
  • Reconsidérez la stratégie. Toutefois, cela peut entraîner une surcharge de règles qui peut 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 décider de sélectionner Kubernetes comme plate-forme de choix en raison de l'écosystème important et en pleine croissance. Ce choix est différent de la sélection de Kubernetes en raison des dépendances techniques des applications, comme décrit dans la section précédente Dépendance explicite envers Kubernetes. L'écosystème Kubernetes est privilégié en raison de sa communauté active, de ses nombreux outils tiers, et de ses normes et de sa portabilité solides. L'écosystème Kubernetes peut vous aider à accélérer le 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 règles tels que Gatekeeper, et la gestion de packages comme Helm. Les outils existants peuvent inclure des règles établies pour l'automatisation de la conformité organisationnelle et d'autres fonctionnalités dont l'implémentation dans un autre environnement cible peut être coûteuse ou nécessiter un long délai.

Profils de l'équipe de développement

Une équipe chargée des applications ou des 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 à fournir des résultats sur Autopilot. Il peut falloir du temps à une équipe pour maîtriser un nouvel environnement d'exécution. Selon le modèle opérationnel, cela peut potentiellement entraîner une fiabilité moindre de la plate-forme pendant la période de montée en compétences.

Pour une équipe en pleine croissance, la capacité d'embauche peut influencer le choix de la plate-forme par une organisation. Sur certains marchés, les compétences Kubernetes peuvent être rares et donc entraîner une prime à l'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 et de plate-forme, ainsi que des autres membres du personnel opérationnel. La capacité des équipes opérationnelles à prendre en charge efficacement l'environnement de production est essentielle du point de vue de la fiabilité. Il est également essentiel que les équipes opérationnelles puissent prendre en charge les environnements de préproduction pour s'assurer que la vélocité des développeurs n'est pas entravée par les temps d'arrêt, la dépendance aux processus manuels ou les mécanismes de déploiement complexes.

Si vous utilisez Kubernetes, une équipe centrale d'ingénierie des opérations ou de plate-forme peut gérer les mises à niveau Kubernetes Autopilot. Bien que les mises à niveau soient automatiques, le personnel opérationnel les surveille généralement de près pour s'assurer que vos charges de travail ne sont pas trop perturbées. 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 continu. Cloud Run vous permet de simplifier vos processus opérationnels. En sélectionnant un seul environnement d'exécution, vous pouvez simplifier davantage vos processus opérationnels. Si vous choisissez d'utiliser plusieurs environnements d'exécution, vous devez vous assurer que l'équipe a la capacité, les compétences et l'intérêt nécessaires pour les prendre en charge.

Sélection

Pour commencer le processus de sélection, discutez avec les différentes parties prenantes. Pour chaque application, constituez un groupe de travail composé de développeurs, de personnel opérationnel, de représentants de tout groupe central de gouvernance technologique, d'utilisateurs et de consommateurs d'applications internes, 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 des applications et partager les résultats avant la session. Nous vous recommandons de sélectionner un petit groupe de travail qui n'inclut que les parties prenantes requises. Il n'est pas nécessaire que tous les représentants soient présents à chaque session de travail.

Il peut également être 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 orienter votre conversation et évaluer l'adéquation de votre application pour chacune des plates-formes potentielles.

Nous vous recommandons de planifier un point de contrôle après quelques mois pour confirmer ou réexaminer la décision en fonction des résultats du déploiement de votre application dans le nouvel environnement.

Étape suivante

Contributeurs

Auteur : Henry Bell | Architecte de solutions cloud

Autres contributeurs :