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 cible Google Cloud pour leurs charges de travail. Nous partons du principe que vous connaissez Kubernetes et Google Cloud, et que vous avez des connaissances sur les environnements d'exécution cloud sans serveur tels que Cloud Run, Cloud Run Functions ou AWS Lambda.

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

Google Cloud , de la plus gérée à la moins gérée.

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

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

    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, optimisé pour les charges de travail d'entreprise et offrant 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 un certain niveau de gestion de l'infrastructure au niveau de l'utilisateur, comme les machines virtuelles (VM) qui sous-tendent les capacités de calcul. Les VM dans GKE Standard sont les nœuds du cluster Kubernetes. Les VM dans Compute Engine constituent l'offre principale de la plate-forme, 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 d'ensemble 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. Ils présentent donc de nombreux points communs. Les deux plates-formes sont compatibles avec plusieurs options d'équilibrage de charge grâce aux services d'équilibrage de charge hautement fiables et évolutifs de Google. Ils sont également tous deux compatibles avec la mise en réseau VPC, Identity-Aware Proxy (IAP) et Google Cloud Armor lorsqu'une mise en réseau privée plus précise est requise. Les deux plates-formes ne vous facturent que les ressources exactes que vous utilisez pour vos applications.

Du point de vue de la livraison de logiciels, en tant qu'environnements d'exécution de conteneurs, Cloud Run et GKE Autopilot sont compatibles 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 à vous assurer que vos applications sont déployées 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 des points communs entre les deux plates-formes, vous pouvez tirer parti des points forts de chacune en adoptant une approche flexible pour le 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 le travail terminé.

Grâce à ces deux modèles de déploiement, Cloud Run peut prendre en charge un large éventail d'architectures d'applications tout en appliquant les bonnes pratiques et en permettant aux développeurs de 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, ainsi que la fonctionnalité d'exécution de conteneurs prédéfinis. 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 de cluster par défaut et recommandé dans GKE. Autopilot vous permet d'exécuter des applications sur Kubernetes sans avoir à gérer 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 stratégie de sécurité par défaut et d'autres paramètres préconfigurés. Avec Autopilot, qui gère les ressources des nœuds, vous ne payez que pour les ressources demandées par vos charges de travail. Autopilot surveille et optimise en permanence l'allocation des ressources d'infrastructure pour garantir la meilleure adéquation possible, tout en fournissant un SLA 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 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 sont adaptées à 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 autogérée et, par conséquent, les frais d'exploitation. À moins que vous ne souhaitiez ou n'ayez spécifiquement besoin de Kubernetes, nous vous recommandons de privilégier l'environnement 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 à une architecture 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 lorsqu'il n'y a pas de blocages techniques ou autres. Pour en savoir plus sur les options de migration, consultez Migrer de Cloud Run vers GKE et Migrer de Kubernetes vers Cloud Run.

Lorsque vous choisissez un environnement d'exécution pour votre charge de travail, vous devez prendre en 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-unes des considérations 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 : compatibilité avec l'augmentation et la réduction dynamiques de la capacité.
  • Compatibilité avec les applications avec état : fonctionnalités de stockage de l'état persistant.
  • Architecture de 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 des différentes ressources consommées.
  • Dépendance explicite envers Kubernetes : exigences d'utilisation de l'API Kubernetes.
  • RBAC complexe pour l'architecture mutualisée : compatibilité avec le partage de ressources groupées.
  • Délai avant expiration maximal de la tâche de conteneur : durée d'exécution des applications ou des 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 de cycle de vie des conteneurs et le partage d'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 la documentation de référence YAML pour l'objet de service Cloud Run et dans la documentation de référence YAML pour l'objet de job 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 exigences à respecter. 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 généraux 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 riche et puissant de primitives 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 de la couche réseau à l'aide d'espaces de noms et de règles de réseau, un remappage des ports et 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é permet de contrôler efficacement la manière dont le trafic est acheminé vers et entre les services du cluster.

Comme Autopilot est hautement configurable, il peut s'agir de la meilleure option si vous disposez de plusieurs services présentant un degré élevé de codépendance réseau ou des exigences complexes concernant l'acheminement du trafic entre les composants de votre application. Un exemple de ce modèle est une application distribuée qui est décomposée en de nombreux microservices présentant des modèles d'interdépendance complexes. Dans ce cas, les options de configuration réseau d'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 le scaling horizontal manuel et automatique des services et des jobs. Le scaling horizontal fournit une puissance de traitement accrue lorsque cela est nécessaire et supprime la puissance de traitement ajoutée lorsqu'elle n'est pas nécessaire. Pour une charge de travail standard, 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? montre que Cloud Run passe de zéro à plus de 10 000 instances en environ 10 secondes. Pour augmenter la vitesse du scaling horizontal sur Kubernetes (moyennant des frais supplémentaires), 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, Autopilot peut être plus adapté. Autopilot est compatible avec le scaling vertical pour faire varier de manière dynamique la quantité de puissance de traitement disponible sans augmenter le nombre d'instances en cours d'exécution de l'application.

Cloud Run peut effectuer un scaling automatique de vos applications jusqu'à zéro instance répliquée lorsqu'elles ne sont pas utilisées, ce qui est utile pour certains cas d'utilisation qui mettent l'accent 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 capable de traiter la requête.

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 de vous connecter à d'autres services, comme Filestore et les buckets Cloud Storage. Ils incluent également tous deux la possibilité d'installer des buckets de store d'objets 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 en mémoire local est partagé avec la mémoire de votre application. Par conséquent, le système de fichiers éphémère et l'utilisation de la mémoire de l'application et du conteneur contribuent à é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 est soumis à un délai avant expiration de la tâche maximal. Un conteneur s'exécutant 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 causé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 d'une tâche 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 terminées dans la durée maximale de la tâche, Autopilot peut être la meilleure option.

architecture de processeur

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 est compatible 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 sur l'accélérateur

Autopilot permet d'utiliser des GPU et des TPU, y compris de consommer des ressources réservées. Cloud Run permet d'utiliser des GPU avec certaines limites.

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 job 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 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, 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 :

  1. Les exigences de l'application (par exemple, l'application appelle des API Kubernetes ou utilise des ressources personnalisées Kubernetes).
  2. Les exigences des outils utilisés pour configurer ou déployer l'application (tels que Helm).
  3. Les exigences d'assistance d'un créateur ou d'un 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 présente des structures organisationnelles particulièrement complexes ou des exigences de mutualisation, utilisez Autopilot pour 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éparation intégrées à Cloud Run.

Considérations organisationnelles

Voici quelques-unes des considérations organisationnelles qui influenceront votre choix d'environnement :

  • Stratégie technique générale : 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 en place.
  • 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 générale

Les organisations ou les équipes peuvent avoir des stratégies convenues pour privilégier certaines technologies par rapport à d'autres. Par exemple, si une équipe a convenu de standardiser, dans la mesure du possible, l'utilisation d'un environnement sans serveur ou de Kubernetes, cet accord peut influencer, voire dicter, un environnement d'exécution cible.

Si une charge de travail donnée n'est pas adaptée à 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 correspondantes :

  • Réarchitecturez 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 fréquentes, cela peut entraîner un portefeuille technologique disparate.
  • Reconsidérez la stratégie. Toutefois, cela peut entraîner une surcharge de règles susceptible d'entraver ou de bloquer la progression.

Exploiter l'écosystème Kubernetes

Dans le cadre de la stratégie technique générale 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 son écosystème important et en pleine croissance. Ce choix est différent de la sélection de Kubernetes en raison de dépendances d'application techniques, 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 des normes et une portabilité solides. L'exploitation de l'écosystème Kubernetes peut accélérer votre vitesse de développement et réduire les délais de mise sur le marché.

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 n'importe quel environnement). Par exemple, si vous utilisez Kubernetes, vous pouvez choisir de continuer à utiliser des outils de déploiement tels qu'ArgoCD, des outils de sécurité et de règles tels que Gatekeeper et des outils de gestion de packages 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 de mise en œuvre pour un autre environnement cible.

Profils des équipes de développement

Une équipe chargée des applications ou des charges de travail peut avoir une expérience préalable de Kubernetes, ce qui peut accélérer sa vélocité et sa capacité à livrer sur 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 potentiellement entraîner une baisse de la fiabilité de la plate-forme pendant la période de perfectionnement.

Pour une équipe en pleine croissance, la capacité de recrutement peut influencer le choix de la plate-forme par une organisation. Sur certains marchés, les compétences Kubernetes peuvent être rares et donc exiger 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 capacités de vos équipes SRE, DevOps et de plates-formes, ainsi que des autres membres du personnel opérationnel. Les capacités des équipes opérationnelles à prendre en charge efficacement l'environnement de production sont cruciales 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 vitesse de développement n'est pas entravée par les temps d'arrêt, la dépendance à des processus manuels ou des mécanismes de déploiement fastidieux.

Si vous utilisez Kubernetes, une équipe centrale d'ingénierie des opérations ou de la 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 minimiser les perturbations de vos charges de travail. Certaines organisations choisissent de mettre à niveau manuellement les versions du plan de contrôle. GKE 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 continus ni de mises à niveau du plan de contrôle. En utilisant Cloud Run, vous pouvez 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 dispose de la capacité, 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 parties prenantes. Pour chaque application, constituez un groupe de travail composé de développeurs, de membres du 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é, d'équipes d'optimisation financière du cloud et d'autres rôles ou groupes au sein 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 parties prenantes requises. La présence de tous les représentants n'est pas forcément requise pour 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 à chacune des plates-formes potentielles.

Nous vous recommandons de planifier un point de contrôle après quelques mois pour confirmer ou revoir 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 :