Choisir un service de conteneur Azure

Azure fournit une gamme de services d’hébergement de conteneurs conçus pour prendre en charge différentes charges de travail, architectures et exigences métier. Ce guide de sélection de service de conteneur peut aider votre équipe de charge de travail à comprendre quel service de conteneur Azure convient le mieux à vos scénarios de charge de travail et exigences.

Remarque

Dans ce guide, la charge de travail fait référence à une collection de ressources d’application qui prennent en charge un objectif métier ou l’implémentation d’un processus métier. Une charge de travail utilise plusieurs services, tels que les API et les magasins de données, qui fonctionnent ensemble pour fournir des fonctionnalités de bout en bout spécifiques.

Vue d'ensemble

Ce guide inclut cet article d’introduction et un autre article sur les considérations partagées entre tous les types de charge de travail.

Remarque

Si vous n’êtes pas engagé dans la conteneurisation, choisissez une autre option informatique pour héberger votre charge de travail.

Cet article d’introduction décrit les Azure services de conteneur abordés dans ce guide et compare leurs modèles de service en fonction de la configurabilité et des solutions prédéfinies, telles que les approches gérées par le client et gérées par Microsoft. Une fois que vous avez identifié les services candidats en fonction de vos préférences de modèle de service, l’étape suivante consiste à évaluer les options par rapport aux exigences de votre charge de travail en examinant l’article sur les considérations partagées relatives à la mise en réseau, à la sécurité, aux opérations et à la fiabilité.

Ce guide vous aide à évaluer les compromis en fonction des exigences techniques, de la taille et de la complexité de votre charge de travail. Il considère également l’expertise de votre équipe pour garantir une prise de décision éclairée.

Services de conteneurs Azure couverts par ce guide

Ce guide se concentre sur un sous-ensemble des services de conteneur fournis Azure. Ce sous-ensemble fournit un ensemble de fonctionnalités mature pour les applications web et les API, la mise en réseau, l’observabilité, les outils de développement et les opérations. Les services de conteneur suivants sont comparés :

Azure Container Apps est une plateforme entièrement managée qui vous permet d’exécuter des applications conteneurisées sans vous soucier de l’orchestration ou de l’infrastructure. Pour plus d’informations, consultez la documentation de Container Apps.

Logo AKS

Azure Kubernetes Service (AKS) est un service Kubernetes managé pour l’exécution d’applications conteneurisées. Avec AKS, vous pouvez tirer parti des extensions et des extensions managées pour des fonctionnalités supplémentaires tout en préservant le niveau de configuration le plus large. Pour plus d’informations, consultez la documentation de AKS.

Logo de l'App Service

Web App for Containers est une fonctionnalité de Azure App Service. App Service est un service entièrement géré pour l’hébergement d’applications web basées sur HTTP qui ont une maintenance intégrée de l’infrastructure, des correctifs de sécurité, une mise à l’échelle et des outils de diagnostic. Pour plus d’informations, consultez Documentation d’App Service.

Pour obtenir la liste complète des services de conteneur Azure, consultez Containers sur Azure.

Considérations relatives au modèle de service

Un modèle de service vous aide à comprendre la flexibilité et le contrôle de chaque service de conteneur Azure fournit. Les services complexes offrent davantage de contrôle, tandis que les services plus simples facilitent la gestion, mais limitent la personnalisation.

Pour plus d’informations sur la terminologie et les concepts du modèle de service, notamment l’infrastructure as a service (IaaS) et la plateforme en tant que service (PaaS), consultez Responsabilité partagée dans le cloud.

Comparer les modèles de service des solutions de conteneur Azure

Azure Kubernetes Service (AKS)

AKS est un mélange d’IaaS et PaaS qui se concentrent davantage sur le contrôle que sur la simplicité. Il utilise Kubernetes, qui est le système standard pour orchestrer des conteneurs. AKS simplifie la gestion de l’infrastructure de base sous-jacente. Toutefois, cette plateforme basée sur une machine virtuelle est exposée à vos applications et nécessite des garde-fous et des processus appropriés, tels que la mise à jour corrective, pour garantir la sécurité et la continuité de l’activité. L’infrastructure de calcul est prise en charge par des ressources de Azure supplémentaires hébergées directement dans votre abonnement, comme Azure équilibreurs de charge, registres de conteneurs ou passerelles d’application.

AKS fournit l’accès au serveur d’API Kubernetes, qui vous permet de personnaliser l’orchestration de conteneurs et de déployer des applications auxiliaires à partir de Cloud Native Computing Foundation. Par conséquent, les équipes de charge de travail nouvelles de Kubernetes sont confrontées à une courbe d’apprentissage significative. Si vous ne connaissez pas les solutions conteneurisées, vous devez prendre en compte cette courbe d’apprentissage. Les solutions PaaS suivantes constituent une barrière inférieure à l’entrée. Vous pouvez passer à Kubernetes lorsque vos besoins le demandent.

AKS Automatic

AKS Automatic facilite l’adoption de Kubernetes en automatisant les tâches de gestion de cluster complexes. Cette automatisation réduit la nécessité d’une expertise Kubernetes avancée. Il offre une expérience plus rationalisée et de type PaaS tout en conservant la flexibilité et l’extensibilité de Kubernetes. Azure gère la configuration du cluster, l’approvisionnement de nœuds, la mise à l’échelle, les correctifs de sécurité et applique les configurations recommandées par défaut. Cette automatisation réduit l’effort opérationnel, mais limite les options de topologie disponibles.

Remarque

Ce guide différencie AKS Standard et AKS Automatic, le cas échéant. Sinon, vous pouvez supposer que la fonctionnalité décrite est cohérente dans les deux offres.

Container Apps

Container Apps est une couche d’abstraction sur Kubernetes qui permet à vos applications d’exécuter et de mettre à l’échelle sans nécessiter de gestion directe de l’infrastructure sous-jacente. Container Apps fournit à la fois des options de calcul serverless et dédiées. Ces options vous donnent un contrôle total sur le type et la quantité de ressources de calcul disponibles pour vos applications. Container Apps extrait les API d’orchestration de conteneurs tout en fournissant un accès intégré aux fonctionnalités clés telles que l’entrée de couche 7, le fractionnement du trafic, les tests A/B et la gestion du cycle de vie des applications.

Web App pour conteneurs

Web App for Containers est une offre PaaS qui privilégie la simplicité par rapport au contrôle, comparé à Container Apps. Il abstrait l’orchestration des conteneurs tout en prenant en charge la mise à l’échelle, la gestion du cycle de vie des applications, la répartition du trafic, l’intégration réseau et l’observabilité.

Considérations relatives au modèle d’hébergement

Vous pouvez utiliser Azure ressources, comme les clusters AKS, pour héberger plusieurs charges de travail. Cette approche peut vous aider à simplifier les opérations, ce qui réduit le coût global. Si vous choisissez cette option, tenez compte des fonctionnalités suivantes :

• AKS est couramment utilisé pour héberger plusieurs charges de travail ou des composants de charge de travail disparates. Vous pouvez isoler ces charges de travail et composants à l’aide des fonctionnalités natives de Kubernetes, telles que les espaces de noms, les contrôles d’accès et les contrôles réseau, pour répondre aux exigences de sécurité.

  Vous pouvez également utiliser AKS dans des scénarios à charge de travail unique si vous avez besoin des fonctionnalités supplémentaires que fournit l’API Kubernetes et que votre équipe de charge de travail dispose d’une expérience suffisante d’exploitation d’un cluster Kubernetes. Les équipes avec moins d’expérience Kubernetes peuvent toujours gérer efficacement leurs propres clusters à l’aide de Azure-managed add-ons et de fonctionnalités telles que cluster mise à niveau automatique pour réduire les efforts opérationnels.

• Les Container Apps doivent être utilisés pour héberger une charge de travail unique avec une frontière de sécurité partagée. Container Apps a une seule limite logique de niveau supérieur appelée environnement Container Apps, qui sert également de limite de sécurité améliorée. Il n’existe aucun mécanisme de contrôle d’accès plus granulaire. Par exemple, la communication intra-environnement est illimitée et toutes les applications partagent un espace de travail Log Analytics unique.

  Si la charge de travail a plusieurs composants et limites de sécurité, déployez plusieurs environnements Container Apps ou envisagez AKS à la place.

• Web App for Containers est une fonctionnalité d'App Service. App Service regroupe des applications dans une limite de calcul logique appelée plan App Service. Étant donné que vous pouvez étendre le contrôle d’accès en fonction du rôle au niveau de l’application, vous pouvez héberger plusieurs charges de travail dans un seul plan. Toutefois, il est préférable d’héberger une charge de travail unique pour chaque plan afin d’éviter le problème de voisin bruyant. Toutes les applications d’un plan App Service unique partagent les mêmes ressources de calcul, de mémoire et de stockage allouées.

  Lorsque vous envisagez l’isolation matérielle, gardez à l’esprit que les plans App Service s’exécutent généralement sur l’infrastructure partagée avec d’autres clients Azure. Vous pouvez choisir des niveaux dédiés pour les ordinateurs virtuels dédiés ou les niveaux isolés pour les ordinateurs virtuels dédiés dans un réseau virtuel dédié.

En général, tous les services de conteneur Azure peuvent héberger plusieurs applications qui ont plusieurs composants. Toutefois, Container Apps et Web App for Containers fonctionnent le mieux pour un composant de charge de travail unique ou plusieurs composants de charge de travail étroitement associés qui partagent un cycle de vie similaire et une seule équipe possède et exécute l’application.

Si vous devez héberger des composants ou charges de travail d’application disparates, potentiellement non liés sur un hôte, envisagez AKS.

Compromis entre contrôle et facilité d’utilisation

AKS fournit la plus grande facilité de configuration, mais cette configurabilité nécessite plus d’efforts opérationnels par rapport aux autres services. Container Apps et Web App for Containers sont des services PaaS qui ont des niveaux similaires de fonctionnalités gérées par Microsoft. Web App for Containers se concentre sur la simplicité de servir son public cible, qui est des clients App Service existants qui connaissent l’interface.

Meilleures pratiques

Les services qui fournissent plus de simplicité conviennent généralement aux clients qui se concentrent sur le développement de fonctionnalités au lieu de la gestion de l’infrastructure. Les services qui fournissent plus de contrôle conviennent généralement aux clients qui ont besoin de la configuration et qui ont les compétences, les ressources et la justification métier pour gérer leur propre infrastructure.

Considérations partagées sur toutes les charges de travail

Une équipe de charge de travail peut préférer un modèle de service spécifique, mais ce modèle peut ne pas répondre aux exigences globales de l’organisation. Par exemple, les développeurs peuvent souhaiter moins d’efforts opérationnels, mais les équipes de sécurité peuvent envisager cette surcharge nécessaire à la conformité. Les équipes doivent collaborer pour faire les bons compromis.

Les considérations partagées couvrent un large éventail de facteurs. Seul un sous-ensemble de considérations peut s’appliquer à vous en fonction du type de charge de travail. Votre rôle au sein de l’organisation affecte également les considérations pertinentes.

Le tableau suivant fournit une vue d’ensemble générale des considérations, notamment les comparaisons de fonctionnalités de service. Passez en revue les considérations de chaque catégorie et comparez-les aux exigences de votre charge de travail.

Catégorie	Vue d'ensemble
Considérations relatives à la mise en réseau	La mise en réseau dans Azure services de conteneur dépend de vos préférences en matière de simplicité ou de configuration. AKS offre un contrôle étendu sur le flux réseau, mais nécessite un effort opérationnel plus important. Container Apps dispose de fonctionnalités de mise en réseau gérées par Azure et se trouve entre AKS et Web App for Containers, qui sert aux clients qui utilisent déjà App Service. Les décisions de conception réseau ont des conséquences à long terme, car leur modification nécessite souvent de redéployer des charges de travail. Plusieurs facteurs, tels que la planification d’adresses IP, l’équilibrage de charge, la découverte de services et la mise en réseau privée, varient entre ces services. Vous devez examiner attentivement la façon dont chaque service répond à des exigences de mise en réseau spécifiques.
Considérations relatives à la sécurité	Container Apps, AKS et Web App for Containers s’intègrent à des offres de sécurité Azure clés telles que Azure Key Vault et les identités managées. AKS fournit des fonctionnalités supplémentaires telles que la protection contre les menaces d’exécution et les stratégies réseau. Les services PaaS comme Container Apps peuvent sembler avoir moins de fonctionnalités de sécurité, mais cela est en partie dû au fait que Azure gère davantage les composants d'infrastructure sous-jacents. Étant donné que ces composants ne sont pas exposés aux clients, le risque est inférieur.
Considérations opérationnelles	AKS fournit la plus grande personnalisation, mais nécessite une entrée plus opérationnelle. Les solutions PaaS telles que Container Apps et Web App pour conteneurs permettent Azure gérer des tâches telles que les mises à jour du système d’exploitation. La scalabilité et la flexibilité de la SKU matérielle sont importantes. AKS fournit des options matérielles flexibles, mais Container Apps et Web App pour conteneurs ont moins de choix. Dans AKS, l’extensibilité des applications est votre responsabilité. Vous pouvez donc appliquer n’importe quelle solution compatible Kubernetes. AKS Automatic, Container Apps et Web App for Containers se concentrent sur des approches plus simples.
Considérations relatives à la fiabilité	Web App pour conteneurs et Container Apps présentent des configurations de sonde d’intégrité limitées par rapport à AKS. Toutefois, ils sont plus simples à configurer, car ils utilisent l'API Azure Resource Manager familière. AKS nécessite l’API Kubernetes et vous oblige également à gérer l’extensibilité et la disponibilité du pool de nœuds Kubernetes pour planifier correctement les instances d’application. Ces exigences augmentent l’effort opérationnel pour AKS. Les contrats de niveau de service (SLA) pour Container Apps et Web App for Containers sont plus simples à calculer que les contrats SLA AKS. Le plan de contrôle AKS et les pools de nœuds ont chacun leurs propres accords de niveau de service (SLA), qui doivent être pris en compte ensemble. Tous les services fournissent une redondance de zone dans les centres de données qui le prennent en charge.

Après avoir examiné les considérations précédentes, il se peut que vous ne trouviez toujours pas l’ajustement parfait, ce qui est typique.

Évaluer les compromis

Le cloud computing est complexe. Elle implique une collaboration entre de nombreuses équipes et doit tenir compte des contraintes des personnes, des budgets et du temps. Ces facteurs rendent la sélection du service cloud difficile et pleine de compromis.

Pour toute charge de travail, certaines exigences peuvent être plus critiques que d’autres. Par exemple, une équipe d’application pourrait préférer une solution PaaS comme Container Apps, mais choisir AKS parce que leur équipe de sécurité exige des contrôles réseau en mode refus par défaut entre les composants de charge de travail colocalisés. Cette fonctionnalité, uniquement pour AKS, utilise des stratégies réseau Kubernetes.

Les considérations partagées précédentes couvrent les exigences les plus courantes, mais ne sont pas complètes. Vous devez évaluer chaque exigence par rapport à l’ensemble de fonctionnalités de votre service préféré avant de prendre une décision.

Conclusion

Ce guide aborde les considérations les plus courantes lorsque vous choisissez un service de conteneur Azure. Il est conçu pour aider votre équipe de charge de travail à prendre des décisions éclairées. Le processus commence par la sélection d’un modèle de service cloud, ce qui implique de déterminer le niveau de contrôle souhaité. Plus de contrôle est au détriment de la simplicité. En d’autres termes, l’objectif est de trouver le bon équilibre entre une infrastructure auto-gérée et une infrastructure gérée par Microsoft.

De nombreuses équipes de charge de travail choisissent un service de conteneur Azure uniquement en fonction de leur préférence PaaS ou IaaS. D’autres équipes doivent examiner plus en détail la façon dont les fonctionnalités spécifiques au service répondent aux besoins de la charge de travail ou de l’organisation.

Utilisez ce guide pour évaluer soigneusement vos options et éviter de prendre des décisions difficiles à inverser. Toutefois, aucune décision n’est finale jusqu’à ce que les développeurs essaient le service et l’évaluent en fonction de l’expérience pratique au lieu de la théorie.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

• Andre Dewes | Ingénieur client senior
• Marcos Martinez | Ingénieur de service senior
• Julie Ng | Ingénieur senior

Autres contributeurs :

• Martin Gjoshevski | Ingénieur client senior
• Don High | Ingénieur client principal
• Nelly Kiboi | Ingénieur de service
• Xuhong Liu | Ingénieur service senior
• Faisal Mustafa | Ingénieur client senior
• Walter Myers | Responsable principal de l'ingénierie client
• Sonalika Roy | Ingénieur client senior
• Paolo Salvatori | Ingénieur client principal
• Victor Santana | Ingénieur client principal
• Carlos Mestre del Pino | Architecte de solution en cloud

Pour afficher les profils de LinkedIn non publics, connectez-vous à LinkedIn.

Ressource associée

• Considérations architecturales partagées