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 charges de travail.
Remarque
Si vous n’êtes pas encore engagé dans la conteneurisation, consultez Choisir un service de calcul Azure pour obtenir des informations sur les autres options de traitement 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 entièrement géré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 Azure Container Apps.
Azure Kubernetes Service (AKS) est un service Kubernetes géré pour l'exécution d'applications conteneurisées. Avec AKS, vous pouvez tirer parti des modules complémentaires et extensions gérées pour offrir des fonctionnalités supplémentaires tout en préservant le niveau de configurabilité le plus large. Pour plus d’informations, consultez la documentation de 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 intégrée de l'infrastructure, correctifs 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 hiérarchise le contrôle sur la simplicité, en tirant parti de la norme de facto pour l’orchestration de conteneurs : Kubernetes. 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 chargées de gérer les charges de travail nouvelles à l'utilisation de Kubernetes. Si vous débutez avec les solutions conteneurisées, cette courbe d’apprentissage doit être prise en compte. Les solutions PaaS suivantes permettent de réduire les obstacles à l’entrée. Vous pouvez passer à Kubernetes lorsque vos exigences dictent ce déplacement.
AKS Automatic
AKS Automatic simplifie l'adoption de Kubernetes en automatisant les tâches complexes de gestion des clusters, réduisant ainsi la nécessité d'une expertise approfondie de Kubernetes. Il offre une expérience de type PaaS plus rationalisée tout en conservant la flexibilité et l’extensibilité de Kubernetes. Azure gère la configuration du cluster, le provisionnement des nœuds, la mise à l'échelle, l'application des correctifs de sécurité, et applique certaines configurations de bonnes pratiques par défaut. Cela réduit l’effort opérationnel, mais est fourni avec un ensemble restreint d’options de topologie disponibles.
Remarque
Ce guide fait la distinction entre AKS Standard et AKS Automatic, le cas échéant. Dans le cas contraire, il peut être supposé que les fonctionnalités décrites ont une parité entre les offres Standard et Automatique.
Azure Container Apps
Azure Container Apps est une couche d'abstraction au-dessus de Kubernetes qui permet à vos applications de s'exécuter et de se mettre à l'échelle sans que vous ayez à gérer directement l'infrastructure sous-jacente. Container Apps propose des options de calcul sans serveur et dédié, ce qui vous donne un contrôle total sur le type et la quantité de ressources de calcul disponibles pour vos applications. En s'abstrayant des API d'orchestration de conteneurs, Container Apps vous donne toujours un accès prêt à l'emploi à des fonctionnalités clés comme l'ingress Layer 7, le fractionnement du trafic, les tests A/B et la gestion du cycle de vie des applications.
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. Il fait abstraction de l'orchestration des conteneurs, mais continue de fournir 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 des 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 ayant moins d'expérience avec Kubernetes peuvent toujours réussir à exploiter leurs propres clusters en profitant des modules complémentaires et des fonctionnalités gérées par Azure, comme la mise à niveau automatique des clusters, afin de réduire l'effort opérationnel.
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 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é du service conteneur. 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é nécessite davantage d’efforts opérationnels, 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 sur le développement de fonctionnalités plutôt que sur la gestion de 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 d’efforts opérationnels, 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 relatives à la mise en réseau | 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. |
| Considérations relatives à la 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 | AKS offre la plus grande personnalisation, mais elle 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 scalabilité et la flexibilité des SKU de matériel sont cruciales. AKS fournit des options matérielles flexibles, tandis que Container Apps et Web App for Containers offrent moins d’options. L’extensibilité des applications dans AKS est la responsabilité du client, ce qui signifie que vous pouvez 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é | Les configurations de sonde d’intégrité des Apps web pour conteneurs et des Container Apps sont limitées par rapport à celles d'AKS, mais elles sont plus simples à configurer parce qu'elles utilisent l’API de gestion des ressources Azure bien connue. 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 un effort opérationnel supplémentaire pour AKS. En outre, les contrats SLA pour Container Apps et Web App for Containers sont plus simples à calculer que ceux d’AKS, pour lesquels le plan de contrôle et les pools de nœuds 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 par refus par défaut entre les composants de charge de travail situés au même endroit, ce qui est une fonctionnalité propre à AKS utilisant les 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.
Auteurs principaux :
- Andre Dewes | Ingénieur client senior
- Marcos Martinez | Ingénieur de service senior
- Julie Ng | Ingénieur senior
Autres contributeurs :
- Mick Alberts | Rédacteur technique
- 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
Étape suivante
En savoir plus sur les considérations architecturales partagées pour les services mentionnés dans cet article.