Choisissez un Azure Container Service

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

Remarque

Dans ce guide, le terme charge de travail fait référence à une collection de ressources d’application qui prennent en charge un objectif opérationnel ou l’exécution d’un processus opérationnel. 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.

Comment utiliser ce guide

Ce guide comprend deux articles : 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 encore engagé dans le conteneurisation, consultez Choisir un service de calcul Azure pour plus d’informations sur les autres options de calcul que vous pouvez utiliser pour héberger votre charge de travail.

Cet article d'introduction décrit les services de conteneurs Azure couverts par ce guide et compare les modèles de services en matière de compromis entre la configurabilité et les solutions basées sur l'opinion, notamment les approches gérées par le client par rapport à celles 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 prend en compte les compromis que vous devrez peut-être effectuer, en fonction des exigences techniques, de la taille et de la complexité de votre charge de travail et de l’expertise de l’équipe de votre charge de travail.

Azure container services dans l’étendue de ce guide

Ce guide se concentre sur un sous-ensemble des services de conteneur actuellement proposés par 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. Ces services de conteneur sont comparés :

Azure Container Apps est une plateforme d'applications basée sur Kubernetes entièrement gérée qui vous aide à déployer des applications HTTP et non HTTP à partir de code ou de conteneurs sans orchestrer l'infrastructure. Pour plus d’informations, consultez la documentation de Azure Container Apps.

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

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

Pour obtenir la liste complète de tous les Azure container services, consultez la page des catégories de produits des services de conteneur.

Considérations relatives au modèle de service

Le modèle de service fournit l’aperçu le plus large du niveau de flexibilité et de contrôle que tout Azure container service fournit, en échange de sa simplicité globale et de sa facilité d’utilisation.

Pour une présentation générale de la terminologie et des concepts relatifs aux modèles de service, notamment l’infrastructure en tant que service (IaaS) et la plateforme en tant que service (PaaS), consultez Responsabilité partagée dans le cloud.

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

AKS

En tant qu’hybride d’IaaS et PaaS, AKS donne la priorité du contrôle sur la simplicité. Bien qu’AKS simplifie la gestion de l’infrastructure de base sous-jacente, cette plateforme basée sur un ordinateur virtuel est toujours 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 Azure supplémentaires hébergées directement dans votre abonnement, comme les équilibreurs de charge Azure.

AKS fournit également l’accès au serveur d’API Kubernetes, qui vous permet de personnaliser l’orchestration de conteneurs et ainsi de déployer des projets à partir de la Cloud Native Computing Foundation (CNCF). Par conséquent, il existe une courbe d’apprentissage significative pour les équipes de charge de travail nouvelles pour Kubernetes. Si vous débutez avec les solutions conteneurisées, cette courbe d’apprentissage peut être un moyen de dissuasion. Les solutions PaaS suivantes permettent de réduire les obstacles à l’entrée. Vous pouvez passer à Kubernetes lorsque vos exigences dictent ce déplacement.

Azure Container Apps

Container Apps, une offre PaaS, équilibre le contrôle avec simplicité. Il offre à la fois des options de calcul serverless et dédiées, qui éliminent la nécessité de corriger le système d’exploitation ou de créer des garde-fous autour des applications, par rapport au système d’exploitation. Container Apps extrait également complètement l’API d’orchestration de conteneur et fournit un sous-ensemble de ses fonctionnalités clés via les API Azure que votre équipe peut déjà connaître. De plus, l’entrée de couche 7, le fractionnement du trafic, les tests A/B et la gestion du cycle de vie des applications sont entièrement disponibles.

Web App pour conteneurs

Web App pour conteneurs est également une offre PaaS, mais elle fournit plus de simplicité, et moins de contrôle, que Container Apps. Elle extrait l’orchestration des conteneurs, mais fournit toujours une mise à l’échelle appropriée, la gestion du cycle de vie des applications, le fractionnement du trafic, l’intégration réseau et l’observabilité.

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

Vous pouvez utiliser des ressources Azure, telles que des clusters AKS, pour héberger plusieurs charges de travail. Cela peut vous aider à simplifier les opérations et ainsi à réduire les coûts globaux. Si vous choisissez ce chemin, voici quelques considérations importantes :

• AKS est couramment utilisé pour héberger plusieurs charges de travail ou composants de charge de travail disparates. Vous pouvez isoler ces charges de travail et composants à l’aide de fonctionnalités natives 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 l’API Kubernetes fournit et que votre équipe de charge de travail a suffisamment d’expérience pour exploiter un cluster Kubernetes. Les équipes avec moins d’expérience Kubernetes peuvent toujours exploiter leurs propres clusters en tirant parti des modules complémentaires et fonctionnalités managés Azure, comme la mise à niveau automatique du cluster, pour réduire la surcharge opérationnelle.

• Container Apps doit être utilisé pour héberger une seule charge de travail avec une limite de sécurité partagée. Container Apps a une seule limite logique de niveau supérieur appelée un environnement Container Apps, qui sert également de limite de sécurité améliorée. Il n’existe aucun mécanisme pour un contrôle d’accès granulaire supplémentaire. 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 comporte plusieurs composants et plusieurs limites de sécurité, déployez plusieurs environnements Container Apps ou envisagez d’utiliser AKS à la place.

• Web App for Containers est une fonctionnalité d’App Service. App Service regroupe les applications dans une limite de facturation appelée plan App Service. Étant donné que vous pouvez étendre le contrôle d’accès en fonction du rôle (RBAC) au niveau de l’application, il peut être tentant d’héberger plusieurs charges de travail dans un seul plan. Toutefois, nous vous recommandons d’héberger une charge de travail unique par plan pour é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, vous devez savoir que les plans App Service s’exécutent généralement sur une 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 Azure container services peuvent héberger plusieurs applications qui ont plusieurs composants. Toutefois, Container Apps et Web App for Containers sont mieux adaptés à un composant à charge de travail unique ou à plusieurs composants de charge de travail hautement associés qui partagent un cycle de vie similaire, où une seule équipe possède et exécute les applications.

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

Le compromis entre contrôle et facilité d’utilisation

AKS offre la plus grande facilité de configuration, mais cette configurabilité est liée à l’augmentation de la surcharge opérationnelle, par rapport aux autres services. Bien que Container Apps et Web App for Containers soient tous deux des services PaaS qui ont des niveaux similaires de fonctionnalités gérées par Microsoft, Web App for Containers met l’accent sur la simplicité pour répondre à son public cible : les clients PaaS Azure existants, qui trouvent l’interface familière.

Règle d’or

En règle générale, les services qui offrent plus de simplicité ont tendance à convenir aux clients qui préfèrent se concentrer davantage sur le développement de fonctionnalités et moins sur l’infrastructure. Les services qui offrent plus de contrôle ont tendance à convenir aux clients qui ont besoin d’une plus grande configurabilité et ont les compétences, les ressources et la justification métier nécessaires pour gérer leur propre infrastructure.

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

Bien qu’une équipe de charge de travail préfère un modèle de service particulier, ce modèle peut ne pas répondre aux exigences de l’organisation dans son ensemble. Par exemple, les développeurs peuvent préférer moins de surcharge opérationnelle, mais les équipes de sécurité peuvent envisager ce type de surcharge nécessaire pour répondre aux exigences de conformité. Les équipes doivent collaborer pour faire les compromis appropriés.

Sachez que les considérations partagées sont larges. Seul un sous-ensemble peut être pertinent pour vous, en fonction non seulement du type de charge de travail, mais également de votre rôle au sein de l’organisation.

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 sur les réseaux	La mise en réseau dans les Azure container services varie en fonction de votre préférence pour la simplicité et la configurabilité. AKS est hautement configurable, ce qui offre un contrôle étendu sur le flux réseau, mais nécessite davantage d’efforts opérationnels. Container Apps offre des fonctionnalités de mise en réseau gérées par Azure. Il s’agit d’un milieu intermédiaire entre AKS et Web App for Containers, qui est adapté aux clients qui connaissent App Service. De façon cruciale, les décisions de conception réseau peuvent avoir des conséquences à long terme en raison des défis liés à leur changement sans redéployer les charges de travail. Plusieurs facteurs, tels que la planification d’adresses IP, les responsabilités d’équilibrage de charge, les méthodes de découverte de service et les fonctionnalités de mise en réseau privée, diffèrent entre ces services. Vous devez examiner attentivement la façon dont les services répondent à des exigences de mise en réseau spécifiques.
Sécurité	Container Apps, AKS et Web App for Containers fournissent toutes une intégration avec des offres de sécurité Azure clés telles qu’Azure Key Vault et des identités managées. AKS offre des fonctionnalités supplémentaires telles que la protection contre les menaces d’exécution et les stratégies réseau. Bien qu’il semblerait que les services PaaS tels que Container Apps offrent moins de fonctionnalités de sécurité, cela est en partie dû au fait que davantage de composants d’infrastructure sous-jacents sont gérés par Azure et non exposés aux clients, ce qui réduit les risques.
Considérations opérationnelles	Bien qu’AKS offre la plus grande personnalisation, il exige une entrée opérationnelle plus importante. En revanche, les solutions PaaS telles que Container Apps et Web App pour conteneurs permettent à Azure de gérer des tâches telles que les mises à jour du système d’exploitation. La flexibilité de la référence SKU matérielle et de l’extensibilité est cruciale. AKS fournit des options matérielles flexibles, tandis que Container Apps et Web App for Containers fournissent des configurations définies. L’extensibilité des applications dans AKS est la seule responsabilité du client. Container Apps et Web App for Containers offrent des approches plus simplifiées.
Éléments de fiabilité à prendre en compte	Les configurations de sonde d’intégrité d’Application web pour conteneurs et Container Apps sont plus rationalisées que celles d’AKS, étant donné qu’elles utilisent l’API Azure Resource Manager familière. AKS nécessite l’utilisation de l’API Kubernetes. Elle vous oblige également à assumer la responsabilité supplémentaire de gérer l’évolutivité et la disponibilité du pool de Nodes Kubernetes afin de planifier correctement les instances d’application. Ces exigences entraînent une surcharge supplémentaire pour AKS. En outre, les contrats SLA pour Container Apps et Web App pour conteneurs sont plus simples que ceux d’AKS, pour lesquels le plan de contrôle et les pools de Nodes ont chacun leur propre contrat SLA et doivent être composés en conséquence. Tous les services offrent une redondance de zone dans les centres de données qui l’offrent.

Après avoir examiné les considérations précédentes, vous n’avez peut-être pas trouvé l’ajustement parfait. C’est parfaitement normal.

Évaluation des compromis

Le choix d’un service cloud n’est pas un exercice simple. Compte tenu de la complexité du cloud computing, la collaboration entre de nombreuses équipes et contraintes de ressources impliquant des personnes, des budgets et du temps, chaque solution a des compromis.

N’oubliez pas que, pour une charge de travail donnée, certaines exigences peuvent être plus critiques que d’autres. Par exemple, une équipe d’application peut préférer une solution PaaS comme Container Apps, mais choisir AKS, car son équipe de sécurité requiert des contrôles réseau refusés par défaut entre les composants de charge de travail colocalisés, qui est une fonctionnalité AKS uniquement qui utilise des stratégies réseau Kubernetes.

Enfin, notez que les considérations partagées précédentes incluent les exigences les plus courantes, mais ne sont pas complètes. Il incombe à l’équipe de charge de travail d’examiner chaque exigence par rapport à l’ensemble de fonctionnalités du service préféré avant de confirmer une décision.

Conclusion

Ce guide décrit les considérations les plus courantes que vous rencontrez lorsque vous choisissez un Azure container service. Il est conçu pour guider les équipes de charge de travail dans la prise de décisions éclairées. Le processus commence par choisir un modèle de service cloud, ce qui implique de déterminer le niveau de contrôle souhaité. Le contrôle est au détriment de la simplicité. En d’autres termes, il s’agit d’un processus de recherche d’un juste équilibre entre une infrastructure auto-gérée et une infrastructure gérée par Microsoft.

De nombreuses équipes de charge de travail peuvent choisir un Azure container service. uniquement en fonction du modèle de service préféré : PaaS et 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.

Toutes les équipes de charge de travail doivent utiliser ce guide en plus d’intégrer la diligence raisonnable pour éviter les décisions difficiles à inverser. Sachez toutefois que la décision n’est pas confirmée tant que les développeurs n’essaient pas le service et décident en fonction de l’expérience plutôt que de la théorie.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Principaux auteurs :

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

Autres contributeurs :

• Mick Alberts | Rédacteur technique
• Martin Gjoshevski | Ingénieur client senior
• Don High | Ingénieur client principal
• Nelly Kiboi | Ingénieure de service
• Xuhong Liu | Ingénieur de service senior
• Faisal Mustafa | Ingénieur client senior
• Walter Myers | Responsable principal de l’ingénierie du client
• Sonalika Roy | Ingénieure client senior
• Paolo Salvatori | Ingénieur client principal
• Victor Santana | Ingénieur client principal

Étape suivante

En savoir plus sur les considérations architecturales partagées pour les services mentionnés dans cet article.

Considérations sur l’architecture partagée