Partager via

Considérations architecturales générales relatives au choix d’un Azure container service

  • Article

Cet article vous guide tout au long du processus de choix d’un Azure container service. Il fournit une vue d’ensemble des considérations au niveau des fonctionnalités qui sont courantes et critiques pour certaines charges de travail. Il peut vous aider à prendre des décisions pour vous assurer que votre charge de travail répond aux exigences en matière de fiabilité, de sécurité, d’optimisation des coûts, d’excellence opérationnelle et d’efficacité des performances.

Remarque

Cet article représente la partie deux d’une série qui commence par Choisir un Azure container service. Nous vous recommandons vivement de lire cet article de vue d’ensemble pour obtenir d’abord un contexte pour ces considérations architecturales.

Vue d’ensemble

Les considérations de cet article sont divisées en quatre catégories :

Considérations relatives à l’architecture et au réseau

  • Prise en charge du système d’exploitation
  • Espaces d'adressage du réseau
  • Compréhension du flux de trafic
  • Planification des sous-réseaux
  • Nombre d’adresses IP d’entrée disponibles
  • Prise en charge d’itinéraires définis par l’utilisateur et de la passerelle NAT
  • Intégration de la mise en réseau privée
  • Couverture du protocole
  • Équilibrage de charge
  • Détection du service
  • Domaines personnalisés et TLS gérés
  • TLS mutuel
  • Concepts de mise en réseau pour des services Azure spécifiques

Considérations relatives à la sécurité

  • Sécurité du trafic intra-cluster à l’aide de stratégies réseau
  • Groupes de sécurité réseau
  • Intégration d’Azure Key Vault
  • Prise en charge des identités managées
  • Évaluations des vulnérabilités et de la protection contre les menaces avec Defender pour conteneurs
  • Bases de référence de sécurité
  • Azure Well-Architected Framework pour Sécurité

Considérations opérationnelles

  • Mises à jour et correctifs
  • Mises à jour d’une image conteneur
  • Scalabilité de l’infrastructure verticale
  • Scalabilité de l’infrastructure horizontale
  • Scalabilité des applications
  • Observabilité
  • Well-Architected Framework pour Excellence opérationnelle

Éléments de fiabilité à prendre en compte

  • Contrats de niveau de service
  • Redondance par le biais de zones de disponibilité
  • Vérifications d’intégrité et réparation automatique
  • Déploiements d’applications sans temps d’arrêt
  • Limites des ressources
  • Well-Architected Framework pour fiabilité

Notez que cet article se concentre sur un sous-ensemble d’Azure container services qui offrent un ensemble de fonctionnalités matures pour les applications web et les API, la mise en réseau, l’observabilité, les outils de développement et les opérations : Azure Kubernetes Service (AKS), Azure Container Apps et Web App pour conteneurs. Pour obtenir la liste complète de tous les Azure container services, consultez la page des catégories de produits des services de conteneur.

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 composants, tels que les API et les magasins de données, qui fonctionnent ensemble pour fournir des fonctionnalités de bout en bout spécifiques.

Considérations sur l’architecture

Cette section décrit les décisions architecturales difficiles à inverser ou à corriger sans temps d’arrêt ou redéploiement significatif. Il est particulièrement nécessaire de tenir compte de cette considération pour les composants fondamentaux tels que la mise en réseau et la sécurité.

Ces considérations ne sont pas spécifiques aux piliers well-architected Framework. Toutefois, ils méritent un examen et une évaluation supplémentaires des exigences des entreprises lorsque vous choisissez un Azure container service.

Prise en charge du système d’exploitation

La plupart des applications conteneurisées s’exécutent dans des conteneurs Linux, qui sont prises en charge par tous les Azure container services. Vos options sont plus limitées pour les composants de charge de travail qui nécessitent des conteneurs Windows.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge de Linux ✅ ✅ ✅
Prise en charge de Windows ❌ ✅ ✅
Prise en charge mixte du système d’exploitation ❌ ✅ ❌*

*La prise en charge du système d’exploitation mixte pour Web App for conteneurs nécessite des plans Azure App Service distincts pour Windows et Linux.

Mise en réseau - Éléments à prendre en compte

Il est important de comprendre la conception réseau au début de vos processus de planification en raison des contraintes de sécurité et de conformité et des directives imposées. En général, les principales différences entre les services Azure couverts dans ce guide dépendent des préférences :

  • Container Apps est une offre PaaS qui fournit de nombreuses fonctionnalités réseau gérées par Azure, telles que la découverte de services et les domaines managés internes. Les équipes de charge de travail qui ont besoin d’un peu plus de configurabilité peuvent être en mesure de tirer parti des profils de charge de travail/dédiés avant d’envisager d’autres solutions pour optimiser leurs options de mise en réseau.
  • AKS est le plus configurable des trois services et offre le plus de contrôle sur le flux réseau. Par exemple, il fournit des contrôleurs d’entrée personnalisés et le contrôle du trafic intra-cluster via des stratégies réseau Kubernetes. Les équipes chargées de la charge de travail peuvent tirer parti de divers modules complémentaires de mise en réseau gérée Azure, ainsi qu'installer et exploiter tout module complémentaire provenant de l'écosystème Kubernetes au sens large.
  • Web App for Containers est une fonctionnalité du service d'applications. Ainsi, les concepts de mise en réseau, en particulier l'intégration de la mise en réseau privée, sont très spécifiques à App Service. Ce service sera connu des équipes de charge de travail qui utilisent déjà App Service. Les équipes qui n’ont pas d’expérience avec App Service et qui souhaitent une intégration de réseau virtuel Azure plus familière sont encouragées à prendre en compte Container Apps.

N’oubliez pas que la mise en réseau est une couche d’infrastructure fondamentale. Il est souvent difficile d’apporter des modifications dans la conception sans redéployer la charge de travail, ce qui peut entraîner un temps d’arrêt. Par conséquent, si votre charge de travail a des exigences de mise en réseau spécifiques, passez en revue attentivement cette section avant de limiter la sélection de votre Azure container service.

Espaces d'adressage du réseau

Lorsque vous intégrez des applications dans des réseaux virtuels, vous devez planifier certaines adresses IP pour vous assurer que suffisamment d’adresses IP sont disponibles pour les instances de conteneur. Pendant ce processus, planifiez des adresses supplémentaires pour les mises à jour, les déploiements bleu/vert et les situations similaires dans lesquelles des instances supplémentaires sont déployées, qui consomment des adresses IP supplémentaires.

Applications de conteneur AKS Web App pour conteneurs
Sous-réseaux dédiés Plan de consommation : facultatif
Plan dédié : obligatoire		 Requis Facultatif
Exigences relatives aux adresses IP Plan de consommation : consultez l’environnement Consommation uniquement.
Plan dédié : consultez l’environnement des profils de charge de travail.		 Consultez les réseaux virtuels Azure pour AKS. Consultez la configuration requise du sous-réseau App Service.

Notez que les exigences AKS dépendent du plug-in réseau choisi. Certains plug-ins réseau pour AKS nécessitent des réservations IP plus larges. Ces détails sortent du cadre de cet article. Pour plus d’informations, consultez Concepts relatifs aux réseaux pour AKS.

Compréhension du flux de trafic

Les types de flux de trafic requis pour une solution peuvent affecter la conception du réseau.

Les sections suivantes fournissent des informations sur les diverses contraintes de mise en réseau. Ces contraintes affectent votre besoin de déployer des sous-réseaux supplémentaires, selon que vous avez besoin :

  • De plusieurs charges de travail colocalisées.
  • D’une entrée privée et/ou publique.
  • D’un flux contrôlé par l’accès du trafic est-ouest dans un cluster (pour Container Apps et AKS) ou dans un réseau virtuel (pour tous les Azure container services).

Planification de sous-réseau

Vous assurer que vous disposez d’un sous-réseau suffisamment grand pour inclure des instances de votre application pour votre charge de travail n’est pas le seul facteur qui dicte l’empreinte réseau où ces applications sont déployées.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge des charges de travail colocalisées au sein d’un sous-réseau* ❌* ✅ N/A*

*Cela décrit une bonne pratique, et non une limitation technique.

Pour Container Apps, l’intégration de sous-réseau s’applique uniquement à un seul environnement Container Apps. Chaque environnement Container Apps est limité à une adresse IP d’entrée unique, publique ou privée.

Chaque environnement Container Apps est destiné uniquement à une seule charge de travail dans laquelle les applications dépendantes sont colocalisées. Par conséquent, vous devez introduire des appliances de mise en réseau Azure supplémentaires pour l’équilibrage de charge d’entrée si vous avez besoin d’entrée publique et privée. En voici des exemples : Azure Application Gateway et Azure Front Door. En outre, si vous avez plusieurs charges de travail qui doivent être séparées, d’autres environnements Container Apps sont nécessaires, un sous-réseau supplémentaire doit donc être alloué pour chaque environnement.

AKS fournit un contrôle granulaire de flux réseau est-ouest au sein du cluster sous la forme d’une stratégie réseau Kubernetes. Ce contrôle de flux vous permet de segmenter plusieurs charges de travail avec des limites de sécurité réseau différentes au sein du même cluster.

Pour Web App pour conteneurs, il n’existe aucune contrainte sur le nombre d’applications que vous pouvez intégrer à un seul sous-réseau, tant que le sous-réseau est suffisamment grand. Il n’existe aucune meilleure pratique pour le contrôle d’accès entre les applications web dans le même réseau virtuel. Chaque application web gère indépendamment le contrôle d’accès pour le trafic est-ouest ou nord-sud à partir du réseau virtuel ou d’Internet, respectivement.

Remarque

Vous ne pouvez pas redimensionner les sous-réseaux dont les ressources sont déployées. Prenez soin lorsque vous planifiez votre réseau pour éviter d’avoir à redéployer des composants de charge de travail entiers, ce qui peut entraîner un temps d’arrêt.

Nombre d’adresses IP d’entrée disponibles

Le tableau suivant prend en compte la section précédente de planification de sous-réseau pour définir le nombre d’adresses IP pouvant être exposées pour un nombre arbitraire d’applications hébergées dans un déploiement unique d’un Azure container service.

Applications de conteneur AKS Web App pour conteneurs
Nombre d’adresses IP d’entrée Une Divers App Service Environment : un
Nbre d’environnement App Service : plusieurs

Container Apps autorise une adresse IP par environnement, public ou privé. AKS autorise n’importe quel nombre d’adresses IP, publiques ou privées. Web App pour conteneurs, en dehors d’un environnement App Service, autorise une adresse IP publique pour toutes les applications au sein d’un plan App Service et plusieurs adresses IP privées différentes qui utilisent des points de terminaison privés Azure.

Il est important de noter que les applications web intégrées à un environnement App Service reçoivent uniquement le trafic via l’adresse IP d’entrée unique associée à l’environnement App Service, qu’il s’agisse d’un environnement public ou privé.

Prise en charge d’itinéraires définis par l’utilisateur et de la passerelle NAT

Si une charge de travail nécessite des itinéraires définis par l’utilisateur (UDR) et des fonctionnalités de passerelle NAT pour un contrôle réseau granulaire, Container Apps nécessite l’utilisation de profils de charge de travail. La compatibilité des passerelles UDR et NAT n’est pas disponible dans le plan consommation uniquement pour ACA.

AKS et Web Apppour conteneurs implémentent ces deux fonctionnalités réseau par le biais de fonctionnalités de réseau virtuel standard ou d’intégration de réseau virtuel, respectivement. Pour élaborer, les pools de Nodes AKS et Web App pour conteneurs dans un environnement App Service sont déjà des ressources de réseau virtuel directes. Web App pour conteneurs qui ne se trouve pas dans un environnement App Service prend en charge les UDR et la passerelle NAT via l’intégration de réseau virtuel. Avec l’intégration du réseau virtuel, la ressource ne réside pas directement dans le réseau virtuel, mais tous ses flux d’accès sortant via le réseau virtuel et les règles associées au réseau affectent le trafic comme prévu.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge des UDR Plan de consommation uniquement : ❌
Plan de profil de charge de travail : ✅		 ✅ ✅
Prise en charge de la passerelle NAT Plan de consommation uniquement : ❌
Plan de profil de charge de travail : ✅		 ✅ ✅

Intégration de la mise en réseau privée

Pour les charges de travail nécessitant une mise en réseau privée de couche 4 stricte pour l’entrée et la sortie, vous devez prendre en compte Container Apps, AKS et la référence SKU App Service Environment monolocataire, où les charges de travail sont déployées dans un réseau virtuel auto-géré, en fournissant les contrôles de mise en réseau privés granulaires habituels.

Applications de conteneur AKS Web App pour conteneurs
Entrée privée dans un réseau virtuel ✅ ✅ Via un point de terminaison privé
Sortie privée à partir d’un réseau virtuel ✅ ✅ Via une intégration du réseau virtuel
Point de terminaison public entièrement supprimé ✅ ✅ App Service Environment uniquement
Mise en réseau privée avec Web App pour conteneurs

Web App pour conteneurs fournit des fonctionnalités de mise en réseau supplémentaires qui ne sont pas exposées de la même façon par les autres services Azure décrits dans cet article. Pour implémenter des exigences strictes en matière de mise en réseau privée, les équipes de charge de travail doivent se familiariser avec ces concepts de mise en réseau. Examinez attentivement ces fonctionnalités de mise en réseau :

Si vous souhaitez une solution PaaS et préférez les concepts de mise en réseau partagés entre plusieurs solutions Azure, vous devez envisager Container Apps.

Couverture du protocole

Une considération importante pour la plateforme d’hébergement est les protocoles de mise en réseau pris en charge pour les demandes d’application entrantes (entrée). Web App pour conteneurs est l’option la plus stricte, prenant uniquement en charge HTTP et HTTPS. Container Apps autorise également les connexions TCP entrantes. AKS est le plus flexible, prenant en charge l’utilisation non contrainte de TCP et UDP sur les ports auto-sélectionnés.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge des protocoles et des ports HTTP (port 80)*
HTTPS (port 443)*
TCP (ports 1-65535, sauf 80 et 443)		 TCP (tout port)
UDP (tout port)		 HTTP (port 80)
HTTPS (port 443)
Prise en charge de WebSocket ✅ ✅ ✅
Assistance HTTP/2 ✅ ✅ ✅

*Dans l’environnement Container Apps, HTTP/S peut être exposé sur n’importe quel port pour la communication intra-cluster. Dans ce scénario, les fonctionnalités HTTP intégrées de Container Apps telles que CORS et l’affinité de session ne s’appliquent pas.

Container Apps et Web App pour conteneurs prennent en charge TLS 1.2 pour leur entrée HTTPS intégrée.

Équilibrage de charge

Avec Container Apps et Web App pour conteneurs, Azure fait totalement abstraction des équilibreurs de charge de couche 4 et de couche 7.

En revanche, AKS utilise un modèle de responsabilité partagée dans lequel Azure gère l'infrastructure Azure sous-jacente que l'équipe chargée de la charge de travail configure en s'interfaçant avec l'API Kubernetes. Pour l’équilibrage de charge de couche 7 dans AKS, vous pouvez choisir une option gérée par Azure, comme le module complémentaire de routage d’applications managé par AKS ou Application Gateway pour les conteneurs, ou déployer et gérer automatiquement un contrôleur d’entrée de votre choix.

Applications de conteneur AKS Web App pour conteneurs
Équilibreur de charge de couche 4 Managé par Azure Responsabilité partagée Managé par Azure
Équilibreur de charge de couche 7 Managé par Azure Partagé ou autogéré Managé par Azure

Détection du service

Dans les architectures cloud, les runtimes peuvent être supprimés et recréés à tout moment pour rééquilibrer les ressources, de sorte que les adresses IP d’instance changent régulièrement. Ces architectures utilisent des noms de domaine complets (FQDN) pour une communication fiable et cohérente.

Applications de conteneur AKS Web App pour conteneurs
Détection du service Nom de domaine complet géré par Azure Kubernetes configurables Nom de domaine complet géré par Azure

Web Apps pour conteneurs fournit des noms de domaine complets (communication nord-sud) d’entrée publics prêts à l’emploi. Aucune configuration DNS supplémentaire n’est nécessaire. Toutefois, il n’existe aucun mécanisme intégré pour faciliter ou restreindre le trafic entre d’autres applications (communication est-ouest).

Container Apps fournit également des noms de domaine complets d’entrée publics. Toutefois, Container Apps va plus loin en autorisant le nom de domaine complet de l’application à être exposé et à restreindre le trafic uniquement dans l’environnement. Cette fonctionnalité facilite la gestion de la communication est-ouest et permet d’activer des composants tels que Dapr.

Les déploiements Kubernetes ne sont pas détectables initialement à l’intérieur ou depuis l’extérieur du cluster. Vous devez créer des services Kubernetes tels que définis par l’API Kubernetes, qui exposent ensuite les applications au réseau de manière adressable.

Important

Seules Container Apps et AKS fournissent une découverte de service via des schémas DNS internes au sein de leurs environnements respectifs. Cette fonctionnalité peut simplifier les configurations DNS dans les environnements de développement/test et de production. Par exemple, vous pouvez créer ces environnements avec des noms de service arbitraires qui doivent être uniques uniquement dans l’environnement ou le cluster, de sorte qu’ils peuvent être identiques dans le développement/test et la production. Avec Web App pour conteneurs, les noms de service doivent être uniques dans différents environnements pour éviter les conflits avec Azure DNS.

Domaines personnalisés et TLS gérés

Container Apps et Web App pour conteneurs fournissent des solutions prêtes à l’emploi pour les domaines personnalisés et la gestion des certificats.

Applications de conteneur AKS Web App pour conteneurs
Configurer des domaines personnalisés Prête à l’emploi BYO Prête à l’emploi
TLS managé pour les noms de domaine complets Azure Prête à l’emploi S/O Prête à l’emploi
TLS managé pour les domaines personnalisés En préversion BYO Prête à l’emploi ou BYO

Les utilisateurs d'AKS sont responsables de la gestion des DNS, des configurations de cluster et des certificats TLS pour leurs domaines personnalisés. Bien qu'AKS n'offre pas de TLS géré, les clients peuvent exploiter les logiciels de l'écosystème Kubernetes, par exemple le populaire cert-manager pour gérer les certificats TLS.

TLS mutuel

Une autre alternative pour restreindre le trafic entrant est TLS mutuel (mTLS). TLS mutuel est un protocole de sécurité qui veille à ce que le client et le serveur en communication soient authentifiés. Pour effectuer l’authentification, les deux parties échangent et vérifient les certificats avant toute transmission de données.

Web App pour conteneurs prend en charge mTLS intégré pour les connexions clientes entrantes. Toutefois, l’application doit valider le certificat en accédant à l’X-ARR-ClientCerten-tête HTTP que la plateforme App Service transfère.

Container Apps a également une prise en charge intégrée de mTLS. Il transfère le certificat client à l’application dans l’en-tête HTTP X-Forwarded-Client-Cert. Vous pouvez également activer facilement mTLS automatique pour la communication interne entre les applications dans un seul environnement.

Le TLS mutuel dans AKS peut être mis en œuvre via le maillage de services basé sur Istio en tant que module complémentaire géré, qui inclut des capacités mTLS pour les connexions client entrantes et la communication intra cluster entre les services. Les équipes de charge de travail peuvent également décider d’installer et de gérer une autre offre de maillage de service à partir de l’écosystème Kubernetes. Grâce à ces options, l’implémentation de mTLS dans Kubernetes est la plus flexible.

Concepts de mise en réseau spécifiques au service

Les sections précédentes décrivent certaines des considérations les plus courantes à prendre en compte. Pour plus d’informations et pour en savoir plus sur les fonctionnalités de mise en réseau spécifiques à des Azure container services individuels, consultez les articles suivants :

Les sections précédentes se concentrent sur la conception du réseau. Passez à la section suivante pour en savoir plus sur la sécurité de mise en réseau et la sécurisation du trafic réseau.

Considérations de sécurité

L’échec de la résolution des risques de sécurité peut entraîner un accès non autorisé, des violations de données ou des fuites d’informations sensibles. Les conteneurs offrent un environnement encapsulé pour votre application. Toutefois, les systèmes d’hébergement et les superpositions réseau sous-jacentes nécessitent des garde-fous supplémentaires. Votre choix d’Azure container service doit prendre en charge vos exigences spécifiques pour sécuriser chaque application individuellement et fournir des mesures de sécurité appropriées pour empêcher l’accès non autorisé et atténuer le risque d’attaques.

Vue d’ensemble de la comparaison de sécurité

La plupart des services Azure, notamment Container Apps, AKS et Web App pour conteneurs, s’intègrent à des offres de sécurité clés, notamment Key Vault et des identités managées.

Parmi les services présentés dans ce guide, AKS est celui qui offre le plus de possibilités de configuration et d'extension, en partie parce qu'il fait apparaître les composants sous-jacents, qui peuvent souvent être sécurisés au moyen d'options de configuration. Par exemple, les clients peuvent désactiver les comptes locaux du serveur API Kubernetes ou activer les mises à jour automatiques des nœuds sous-jacents via les options de configuration.

Pour une comparaison détaillée, examinez attentivement les considérations suivantes pour vous assurer que vos exigences de sécurité de charge de travail peuvent être satisfaites.

Sécurité de plan de contrôle Kubernetes

AKS offre la plus grande flexibilité des trois options prises en compte dans cet article, fournissant un accès complet à l’API Kubernetes afin de pouvoir personnaliser l’orchestration de conteneur. Toutefois, cet accès à l’API Kubernetes représente également une surface d’attaque importante et vous devez le sécuriser.

Important

Notez que cette section n’est pas pertinente pour Web App pout conteneurs, qui utilise l’API Azure Resource Manager comme plan de contrôle.

Sécurité basée sur l'identité

Les clients sont responsables de la sécurisation de l’accès basé sur l’identité à l’API. Prête à l’emploi, Kubernetes fournit son propre système de gestion de l’authentification et des autorisations, qui doit également être sécurisé avec des contrôles d’accès.

Pour tirer parti d’un écran unique pour la gestion des identités et des accès sur Azure, il est recommandé de désactiver les comptes locaux spécifiques à Kubernetes et d’implémenter plutôt l’intégration Microsoft Entra managée par AKS avec Azure RBAC pour Kubernetes. Si vous implémentez cette bonne pratique, les administrateurs n’ont pas besoin d’effectuer la gestion des identités et des accès sur plusieurs plateformes.

Applications de conteneur AKS
Contrôles d’accès aux API Kubernetes Pas d’accès Accès total

Les clients qui utilisent Container Apps n’ont pas accès à l’API Kubernetes. Microsoft assure la sécurité de cette API.

Sécurité réseau

Si vous souhaitez restreindre l’accès réseau au plan de contrôle Kubernetes, vous devez utiliser AKS, qui fournit deux options. La première option consiste à utiliser des clusters AKS privés, qui utilisent Azure Private Link entre le réseau privé du serveur d’API et le réseau privé du cluster AKS. La deuxième option est l’intégration au réseau virtuel du serveur d’API (préversion), où le serveur d’API est intégré à un sous-réseau délégué. Pour plus d’informations, consultez la documentation.

Il existe des conséquences pour implémenter l’accès restreint au réseau à l’API Kubernetes. En particulier, la gestion ne peut être effectuée qu’à partir du réseau privé. Ce qui signifie généralement que vous devez déployer des agents auto-hébergés pour Azure DevOps ou GitHub Actions. Pour en savoir plus sur les autres limitations, consultez la documentation spécifique au produit.

Applications de conteneur AKS
Sécurité réseau de l’API Kubernetes Non configurable dans PaaS Configurable : adresse IP publique ou adresse IP privée

Ces considérations ne s’appliquent pas à Container Apps. Étant donné qu’il s’agit de PaaS, Microsoft extrait l’infrastructure sous-jacente.

Sécurité réseau du plan de données

Les fonctionnalités réseau suivantes peuvent être utilisées pour contrôler l’accès à, depuis et au sein d’une charge de travail.

Utilisation de stratégies réseau pour assurer la sécurité du trafic intra-cluster

Certaines postures de sécurité nécessitent la séparation du trafic réseau au sein d’un environnement, par exemple lorsque vous utilisez des environnements multilocataires pour héberger plusieurs applications ou multiniveau. Dans ces scénarios, vous devez choisir AKS et implémenter des stratégies réseau, une technologie native cloud qui permet une configuration granulaire de la mise en réseau de couche 4 au sein des clusters Kubernetes.

Applications de conteneur AKS Web App pour conteneurs
Stratégies réseau Plan Consommation : ❌
Plan dédié : ❌		 ✅ ❌

Parmi les trois services Azure décrits dans cet article, AKS est le seul qui prend en charge une isolation supplémentaire de la charge de travail au sein du cluster. Les stratégies réseau ne sont pas prises en charge dans Container Apps ou Web App pour conteneurs.

Groupes de sécurité réseau

Dans tous les scénarios, vous pouvez réglementer la communication réseau au sein du réseau virtuel plus large à l’aide de groupes de sécurité réseau, ce qui vous permet d’utiliser des règles de trafic de couche 4 qui régissent l’entrée et la sortie au niveau du réseau virtuel.

Applications de conteneur AKS Web App pour conteneurs
Groupes de sécurité réseau Plan Consommation : ✅
Plan dédié : ✅		 ✅ ✅ Applications intégrées au réseau virtuel : sortie uniquement

Restrictions IP pour l'entrée

En règle générale, les restrictions du trafic réseau sont appliquées via les règles de la couche 4 décrites ci-dessus. Cependant, dans les scénarios PaaS d'applications sans intégration de réseau virtuel, il peut être utile de restreindre le trafic sur la couche d'application.

Container Apps et Web App pour conteneurs fournissent des restrictions IP sources intégrées pour le trafic d’entrée sur des applications individuelles.

Applications de conteneur AKS Web App pour conteneurs
Restrictions IP à l'entrée sur la couche d'application Prête à l’emploi Autogestion ou via un module complémentaire géré Prête à l’emploi
Consommation des ressources - Consomme des ressources de cluster -

Pour les charges de travail AKS, la mise en œuvre dépend du contrôleur d'entrée choisi. L'autogestion et le module complémentaire de routage d'applications géré par Azure consomment tous deux des ressources de cluster.

Sécurité au niveau des applications

Vous devez sécuriser les charges de travail non seulement au niveau du réseau et de l’infrastructure, mais également au niveau de la charge de travail et de l’application. Les Azure container solutions s’intègrent aux offres de sécurité Azure pour vous aider à normaliser l’implémentation et les contrôles de sécurité pour vos applications.

Intégration dans Key Vault

Il est recommandé de stocker et de gérer des clés secrètes, des clés et des certificats dans une solution de gestion de clés telle que Key Vault, qui offre une sécurité renforcée pour ces composants. Au lieu de stocker et de configurer des clés secrètes dans du code ou dans un service de calcul Azure, toutes les applications doivent s’intégrer à Key Vault.

L’intégration de Key Vault permet aux développeurs d’applications de se concentrer sur leur code d’application. Les trois Azure container services décrits dans cet article peuvent synchroniser automatiquement les secrets à partir du service Key Vault et les fournir à l’application, généralement en tant que variables d’environnement ou fichiers montés.

Applications de conteneur AKS Web App pour conteneurs
Intégration dans Key Vault ✅ ✅ ✅

Pour plus d’informations, consultez l’article suivant :

Prise en charge des identités managées

Les applications auxquelles des identités gérées ont été attribuées peuvent accéder aux ressources Azure sans mot de passe. Tous les services de conteneurs mentionnés dans ce guide prennent en charge les identités gérées.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge des identités managées ✅ ✅ ✅

Pour plus d’informations, consultez l’article suivant :

Évaluations des vulnérabilités et de la protection contre les menaces avec Defender pour conteneurs

La protection contre les menaces contre les vulnérabilités est également importante. Il est recommandé d’utiliser Defender pour conteneurs. Les évaluations des vulnérabilités sont prises en charge dans les registres de conteneurs Azure, afin qu’elles puissent être utilisées par n’importe quel Azure container service, et non pas seulement celles décrites dans cet article. Toutefois, la protection du runtime Defender pour les conteneurs est disponible uniquement pour AKS.

Comme AKS expose l'API native de Kubernetes, la sécurité du cluster peut également être évaluée à l'aide d'outils de sécurité spécifiques à Kubernetes provenant de l'écosystème Kubernetes.

Applications de conteneur AKS Web App pour conteneurs
Protection contre les menaces de runtime ❌ ✅ ❌

Pour plus d’informations, consultez la matrice de prise en charge des conteneurs dans Defender pour le cloud.

Notez que les évaluations des vulnérabilités d’image conteneur ne sont pas des analyses en temps réel. Le registre de conteneurs Azure est analysé à intervalles réguliers.

Bases de référence de sécurité

En général, la plupart des services de conteneur Azure intègrent des offres de sécurité Azure. Dans l’ensemble, gardez à l’esprit qu’un ensemble de fonctionnalités de sécurité n’est qu’une petite partie de l’implémentation de la sécurité cloud. Pour plus d’informations sur l’implémentation de la sécurité pour les services de conteneur, consultez les bases de référence de sécurité spécifiques au service suivantes :

Les bases de référence de sécurité couvrent d’autres intégrations Azure, notamment le chiffrement matériel et la journalisation, qui sont hors de portée pour cet article.

Well-Architected Framework pour sécurité

Cet article se concentre sur les principales différences entre les fonctionnalités des services de conteneur décrites ici.

Pour obtenir des conseils de sécurité plus complets sur AKS, consultez la révision de Well-Architected Framework - AKS.

Considérations opérationnelles

Pour exécuter avec succès une charge de travail en production, les équipes doivent implémenter des pratiques d’excellence opérationnelle, notamment la journalisation centralisée, la supervision, la scalabilité, les mises à jour régulières et la gestion des mises à jour correctives et de la gestion des images.

Mises à jour et correctifs

Il est important que le système d'exploitation sous-jacent d'une application soit mis à jour et régulièrement patché. Gardez à l’esprit toutefois que chaque mise à jour présente un risque de défaillance. Cette section et la suivante décrivent les principales considérations relatives aux trois services de conteneur en ce qui concerne la responsabilité partagée entre le client et la plateforme.

En tant que service Kubernetes managé, AKS fournit les images mises à jour pour les composants du système d’exploitation et du plan de contrôle du nœud. Mais les équipes chargées de la charge de travail sont responsables de l'application des mises à jour à leurs clusters. Vous pouvez déclencher manuellement des mises à jour ou exploiter la fonction de chaînes de mise à niveau automatique des clusters pour vous assurer que vos clusters sont à jour. Consultez le guide des opérations AKS jour-2 pour en savoir plus sur la mise à jour corrective et la mise à niveau des clusters AKS.

Container Apps et Web App pour conteneurs sont des solutions PaaS. Azure est responsable de la gestion des mises à jour et des correctifs, afin que les clients puissent éviter la complexité de la gestion des mises à niveau AKS.

Applications de conteneur AKS Web App pour conteneurs
Mises à jour du plan de contrôle Plateforme Client Plateforme
Mises à jour et correctifs d’hôte Plateforme Client Plateforme
Mises à jour et correctifs d’images conteneur Client Customer Client

Mises à jour d’une image conteneur

Quelle que soit l’Azure container solution, les clients sont toujours responsables de leurs propres images conteneur. S’il existe des correctifs de sécurité pour les images de base de conteneur, il est de votre responsabilité de reconstruire vos images. Pour obtenir des alertes sur ces vulnérabilités, utilisez Defender pour conteneurs pour les conteneurs hébergés dans Container Registry.

Évolutivité

La mise à l’échelle est utilisée pour ajuster la capacité des ressources afin de répondre aux demandes, en ajoutant davantage de capacité pour garantir les performances et supprimer la capacité inutilisée pour économiser de l’argent. Lorsque vous choisissez une solution de conteneur, vous devez prendre en compte les contraintes d’infrastructure et les stratégies de mise à l’échelle.

Scalabilité de l’infrastructure verticale

La mise à l’échelle verticale fait référence à la possibilité d’augmenter ou de diminuer l’infrastructure existante, c’est-à-dire le processeur de calcul et la mémoire. Différentes charges de travail nécessitent différentes quantités de ressources de calcul. Lorsque vous choisissez une Azure container solution, vous devez connaître les offres de référence SKU matérielles disponibles pour un service Azure particulier. Ils varient et peuvent imposer des contraintes supplémentaires.

Pour AKS, passez en revue les tailles des machines virtuelles dans la documentation Azure et les restrictions AKS par région.

Ces articles fournissent des détails sur les offres de référence SKU pour les deux autres services :

Scalabilité de l’infrastructure horizontale

La mise à l’échelle horizontale fait référence à la possibilité d’augmenter ou de diminuer la capacité via une nouvelle infrastructure, comme les Nodes d’ordinateur virtuel. Pendant l’augmentation ou la diminution de la mise à l’échelle, le niveau de consommation Container Apps extrait les machines virtuelles sous-jacentes. Pour les Azure container services restants, vous gérez la stratégie de mise à l’échelle horizontale à l’aide de l’API Azure Resource Manager standard.

Notez que le scale-out et le rééquilibrage des instances incluent également un risque de temps d’arrêt. Le risque est inférieur au risque correspondant avec la mise à l’échelle verticale. Néanmoins, les équipes de charge de travail sont toujours responsables de s’assurer que leurs applications peuvent gérer les défaillances et implémenter des démarrages et des arrêts appropriés de leurs applications afin d’éviter les temps d’arrêt.

Applications de conteneur AKS Web App pour conteneurs
Scale-in et out de l’infrastructure Plan de la consommation : S/O
Plan dédié : configurable		 Configurable Configurable
Approvisionnement matériel flexible Plan de la consommation : S/O
Plan dédié : abstrait avec des profils de charge de travail		 N’importe quelle référence SKU d’ordinateur virtuel Abstrait. Consultez Plan App Service.

Important

Les options d’approvisionnement matérielle disponibles via le plan dédié Container Apps (profils de charge de travail) et Web App pour conteneurs (plans App Service) ne sont pas aussi flexibles qu’AKS. Vous devez vous familiariser avec les références SKU disponibles dans chaque service pour vous assurer que vos besoins sont satisfaits.

Scalabilité des applications

La mesure classique sur laquelle déclencher la mise à l’échelle de l’infrastructure et des applications est la consommation de ressources : processeur et mémoire. Certaines solutions de conteneur peuvent mettre à l’échelle le nombre d’instances de conteneur sur des métriques avec un contexte spécifique à l’application, comme les requêtes HTTP. Par exemple, AKS et Container Apps peuvent mettre à l’échelle des instances de conteneur en fonction des files d’attente de messages via KEDA et de nombreuses autres métriques via ses scalers. Ces fonctionnalités offrent une flexibilité lorsque vous choisissez la stratégie d’extensibilité de votre application. Web App pour conteneurs s’appuie sur les options de scalabilité fournies par Azure. (Consultez le tableau suivant.) Web App pour conteneurs ne prend pas en charge les configurations de scaler personnalisées telles que KEDA.

Applications de conteneur AKS Web App pour conteneurs
Scale-out du conteneur HTTP, TCP ou basé sur des métriques (processeur, mémoire, piloté par les événements). Basée sur des métriques (processeur, mémoire ou personnalisée). Manuel, basé sur des métriques ou automatique (préversion).
Scalabilité pilotée par les événements Oui. Natif cloud. Oui. Natif cloud. Une configuration supplémentaire est requise. Oui. Spécifique à la ressource Azure.

Observabilité

Instrumentation de la charge de travail

La collecte de métriques pour les applications complexes ou multiniveau peut être difficile. Pour obtenir des métriques, vous pouvez intégrer des charges de travail conteneurisées à Azure Monitor de deux façons :

  • Instrumentation automatique. Aucune modification de code requise :
  • Instrumentation manuelle. Modifications minimales du code requises pour intégrer et configurer le Kit de développement logiciel (SDK) et/ou le client.
Applications de conteneur AKS Web App pour conteneurs
Instrumentation automatique via la plateforme ❌ ❌ Prise en charge partielle*
Instrumentation automatique ❌ Prise en charge partielle* S/O
Instrumentation manuelle Via le KIT SDK ou OpenTelemetry Via le KIT SDK ou OpenTelemetry Via le KIT SDK ou OpenTelemetry

*AKS et Web App pour conteneurs prennent en charge l’instrumentation automatique pour certaines configurations de charges de travail Linux et Windows, en fonction du langage de l’application. Pour plus d’informations, consultez les articles suivants :

L’instrumentation au sein du code d’application est la responsabilité des développeurs d’applications, donc elle est indépendante de n’importe quelle Azure container solution. Votre charge de travail peut utiliser des solutions telles que :

Journaux d’activité

Tous les Azure container services fournissent des fonctionnalités de journal d’application et de plateforme. Les journaux d’application sont des journaux de console générés par votre charge de travail. Les journaux de plateforme capturent les événements qui se produisent au niveau de la plateforme, en dehors de l’étendue de votre application, comme la mise à l’échelle et les déploiements.

Les principales différences entre les fonctionnalités de journalisation des services de conteneur concernent la journalisation de plateforme : ce qui est journalisé et comment les journaux sont organisés en interne. Azure Monitor est le principal service de journalisation dans Azure qui s’intègre à ces services. Monitor utilise les journaux de ressources pour séparer les journaux d’activité provenant de différentes sources en catégories. Une façon de déterminer les journaux d’activité disponibles à partir de chaque service Azure consiste à examiner les catégories de journaux de ressources disponibles pour chacun des services.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge de la diffusion en continu des journaux (streaming en temps réel) ✅ ✅ ✅
Prise en charge d’Azure Monitor ✅ ✅ ✅
Journaux de ressources Azure Monitor Console et système Serveur d’API Kubernetes, Audit, Planificateur, Mise à l’échelle automatique du cluster, etc. ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs, etc.

Pour obtenir une description détaillée de chacun des journaux de ressources de la table, sélectionnez les liens dans la table.

Voici un bref résumé des fonctionnalités de journalisation des services de conteneur :

  • Container Apps extrait tous ses journaux Kubernetes internes en deux catégories. L’un, appelé journaux de console, contient les journaux de conteneur de charge de travail. Une deuxième catégorie système contient tous les journaux liés à la plateforme.
  • AKS fournit tous les journaux liés à Kubernetes et un contrôle granulaire sur ce qui peut être journalisé. Il conserve également une compatibilité complète avec les outils clients Kubernetes pour la diffusion en continu des journaux, comme kubectl.
  • Web App pour conteneurs fournit de nombreuses catégories de journaux de ressources, car sa plateforme (App Service) n’est pas exclusivement destinée aux charges de travail de conteneur. Pour les opérations spécifiques au conteneur qui gèrent sa plateforme Docker interne, elle fournit la catégorie de journal AppServicePlatformLogs. Une autre catégorie importante est AppServiceEnvironmentPlatformLogs, qui journalise les événements tels que la mise à l’échelle et les modifications de configuration.

Well-Architected Framework pour Excellence opérationnelle

Cet article se concentre sur les principales différences entre les fonctionnalités des services de conteneur décrites ici. Consultez ces articles pour consulter les conseils complets sur l’excellence opérationnelle pour les services suivants :

Fiabilité

La fiabilité est la capacité d’un système à réagir face aux défaillances et à rester totalement fonctionnel. Au niveau du logiciel d’application, les charges de travail doivent implémenter les meilleures pratiques telles que la mise en cache, la nouvelle tentative, les modèles de disjoncteur et les vérifications d’intégrité. Au niveau de l’infrastructure, Azure est responsable de la gestion des défaillances physiques, telles que les défaillances matérielles et les pannes de courant, dans les centres de données. Des défaillances peuvent toujours se produire. Les équipes de charge de travail doivent sélectionner le niveau de service Azure approprié et appliquer les configurations minimales nécessaires pour implémenter des basculements automatiques entre les zones de disponibilité.

Pour choisir le niveau de service approprié, vous devez comprendre comment fonctionnent les contrats de niveau de service (SLA) et les zones de disponibilité.

Contrats de niveau de service

La fiabilité est généralement mesurée par des métriques basées sur l’entreprise, telles que les contrats SLA ou les métriques de récupération, comme les objectifs de temps de récupération (RTO).

Azure dispose de nombreux contrats SLA pour des services spécifiques. Il n’existe pas de niveau de service à 100 %, car les défaillances peuvent toujours se produire dans les logiciels et le matériel, et dans la nature, par exemple, les tempêtes et les tremblements de terre. Un contrat SLA n’est pas une garantie, mais plutôt un accord financier de disponibilité du service.

Pour obtenir les derniers contrats SLA et les détails, téléchargez le dernier contrat SLA pour Microsoft Online Services à partir du site web de licences Microsoft.

Niveaux gratuits et payants

En règle générale, les niveaux gratuits des services Azure ne proposent pas de contrat SLA, ce qui les rend rentables pour les environnements hors production. Toutefois, pour les environnements de production, il est recommandé de choisir un niveau payant disposant d’un contrat SLA.

Facteurs supplémentaires pour AKS

AKS dispose de différents contrats SLA pour différents composants et configurations :

  • Plan de contrôle. Le serveur d’API Kubernetes dispose d’un contrat SLA distinct.
  • Plan de données. Les pools de Nodes utilisent les contrats SLA de référence SKU d’ordinateur virtuel sous-jacents.
  • Zones de disponibilité. Il existe différents contrats SLA pour les deux plans, selon que le cluster AKS a des zones de disponibilité activées et exécute plusieurs instances entre les zones de disponibilité.

Notez que lorsque vous utilisez plusieurs services Azure, les contrats SLO composites peuvent différer et être inférieurs aux contrats SLA de service individuels.

Redondance avec des zones de disponibilité

Les zones de disponibilité sont des centres de données distincts qui ont une alimentation électrique indépendante, un refroidissement, et ainsi de suite, dans une seule région. La redondance résultante augmente la tolérance des défaillances sans nécessiter l’implémentation d’architectures multirégions.

Azure dispose de zones de disponibilité dans chaque pays/région où Azure exploite une région de centre de données. Pour autoriser plusieurs instances de conteneurs à traverser des zones de disponibilité, veillez à sélectionner des références SKU, des niveaux de service et des régions qui fournissent une prise en charge des zones de disponibilité.

Fonctionnalité Applications de conteneur AKS Web App pour conteneurs
Prise en charge des zones de disponibilité Complète Complète Complète

Par exemple, une application ou une infrastructure configurée pour exécuter une seule instance devient indisponible si un problème se produit dans la zone de disponibilité où le matériel est hébergé. Pour utiliser entièrement la prise en charge des zones de disponibilité, vous devez déployer des charges de travail avec une configuration minimale de trois instances du conteneur, réparties entre les zones.

Vérifications d’intégrité et réparation automatique

Les points de terminaison de vérification d’intégrité sont essentiels à une charge de travail fiable. Mais la création de ces points de terminaison n’est que la moitié de la solution. L’autre moitié contrôle ce que fait la plateforme d’hébergement et comment, quand il y a des défaillances.

Pour mieux distinguer les types de sondes d’intégrité, examinez les types intégrés de sondes à partir de Kubernetes :

  • Startup. Vérifie si l’application a démarré correctement.
  • Préparation. Vérifie si l’application est prête à gérer les demandes entrantes.
  • Fonctionnement. Vérifie si l’application est toujours en cours d’exécution et réactive.

Une autre considération importante est la fréquence à laquelle ces vérifications d’intégrité sont demandées à partir de l’application (granularité interne). Si vous avez un intervalle long entre ces demandes, vous pouvez continuer à traiter le trafic jusqu’à ce que l’instance soit considérée comme non intègre.

La plupart des applications prennent en charge les vérifications d’intégrité via le protocole HTTP(S). Toutefois, certains peuvent avoir besoin d’autres protocoles, comme TCP ou gRPC, pour effectuer ces vérifications. Gardez cela à l’esprit lorsque vous concevez votre système de vérification d’intégrité.

Applications de conteneur AKS Web App pour conteneurs
Sondes de démarrage ✅ ✅ Prise en charge partielle
Probe readiness ✅ ✅ ❌
Probe liveness ✅ ✅ ✅
Granularité d’intervalle Secondes Secondes 1 minute
Prise en charge du protocole HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

Les vérifications d’intégrité sont plus faciles à implémenter dans Web App pour conteneurs. Il existe quelques points importants à prendre en compte :

  • Ses sondes de démarrage sont intégrées et ne peuvent pas être modifiées. Elle envoie une requête HTTP au port de départ de votre conteneur. Toute réponse de votre application est considérée comme un démarrage réussi.
  • Elle ne prend pas en charge les sondes de préparation. Si la sonde de démarrage réussit, l’instance de conteneur est ajoutée au pool d’instances intègres.
  • Elle envoie la vérification d’intégrité à intervalles d’une minute. Vous ne pouvez pas modifier l’intervalle.
  • Le seuil minimal que vous pouvez définir pour qu’une instance non intègre soit supprimée du mécanisme d’équilibrage de charge interne est de deux minutes. L’instance non intègre obtient le trafic pendant au moins deux minutes après l’échec d’une vérification d’intégrité. La valeur par défaut pour ce paramètre est de 10 minutes.

Par ailleurs, Container Apps et AKS sont beaucoup plus flexibles et offrent des options similaires. En termes de différences spécifiques, AKS offre les options suivantes pour effectuer des contrôles de santé, qui ne sont pas disponibles dans Container Apps :

Réparation automatique

Identifier une instance de conteneur incorrecte et arrêter l’envoi du trafic à celui-ci est un début. L’étape suivante consiste à implémenter la réparation automatique. La réparation automatique est le processus de redémarrage de l’application dans une tentative de récupération à partir d’un état défectueux. Voici comment les trois services de conteneur comparent :

  • Dans Web App pour conteneurs, il n’existe aucune option permettant de redémarrer une instance de conteneur immédiatement après un échec d’une vérification d’intégrité. Si l’instance échoue pendant une heure, elle est remplacée par une nouvelle instance. Il existe une autre fonctionnalité, appelée réparation automatique, qui surveille et redémarre les instances. Elle n’est pas directement liée aux vérifications d’intégrité. Elle utilise différentes métriques d’application, telles que les limites de mémoire, la durée de la requête HTTP et les codes d’état.
  • Container Apps et AKS tentent automatiquement de redémarrer une instance de conteneur si la sonde liveness atteint le seuil d’échec défini.

Déploiements d’applications sans temps d’arrêt

La possibilité de déployer et de remplacer des applications sans provoquer de temps d’arrêt pour les utilisateurs est cruciale pour une charge de travail fiable. Les trois services de conteneur décrits dans cet article prennent en charge les déploiements sans temps d’arrêt, mais de différentes façons.

Applications de conteneur AKS Web App pour conteneurs
Stratégie sans temps d’arrêt Mise à jour propagée Rolling update, ainsi que toutes les autres stratégies Kubernetes. Emplacements de déploiement

Veuillez noter que les architectures d'application doivent également prendre en charge le déploiement sans temps d'arrêt. Consultez Azure Well-Architected Framework pour obtenir des conseils.

Limites des ressources

Un autre composant important d’un environnement partagé fiable est votre contrôle sur l’utilisation des ressources (comme le processeur ou la mémoire) de vos conteneurs. Vous devez éviter les scénarios dans lesquels une seule application prend toutes les ressources et laisse d’autres applications dans un état incorrect.

Applications de conteneur AKS Web App pour conteneurs
Limites de ressources (processeur ou mémoire) Par application/conteneur Par application/conteneur
Par espace de noms		 Par plan App Service
  • Web App pour conteneurs : vous pouvez héberger plusieurs applications (conteneurs) dans un seul plan App Service. Par exemple, vous pouvez allouer un plan avec deux cœurs d’UC et 4 Gio de RAM dans lesquels vous pouvez exécuter plusieurs applications web dans des conteneurs. Toutefois, vous ne pouvez pas restreindre l’une des applications à une certaine quantité de processeur ou de mémoire. Ils sont tous en concurrence pour les mêmes ressources de plan App Service. Si vous souhaitez isoler vos ressources d’application, vous devez créer des plans App Service supplémentaires.
  • Container Apps : vous pouvez définir des limites de processeur et de mémoire par application dans votre environnement. Toutefois, vous êtes limité à un ensemble de combinaisons autorisées de processeur et de mémoire. Par exemple, vous ne pouvez pas configurer un processeur virtuel et 1 Gio de mémoire, mais vous pouvez configurer un processeur virtuel et 2 Gio de mémoire. Un environnement Container Apps est analogue à un espace de noms Kubernetes.
  • AKS : vous pouvez choisir n’importe quelle combinaison de processeurs virtuels et de mémoire, tant que vos Nodes disposent du matériel pour le prendre en charge. Vous pouvez également limiter les ressources au niveau de l’espace de noms si vous souhaitez segmenter votre cluster de cette façon.

Well-Architected Framework pour fiabilité

Cet article se concentre sur les principales différences entre les fonctionnalités des services de conteneur dans Azure. Si vous souhaitez consulter les conseils de fiabilité complets pour un service spécifique, consultez les articles suivants :

Conclusion

Les solutions bien conçues définissent les bases des charges de travail réussies. Bien que les architectures puissent être ajustées à mesure qu’une charge de travail augmente et que les équipes progressent sur leurs parcours cloud, certaines décisions, en particulier autour de la mise en réseau, sont difficiles à inverser sans temps d’arrêt ou de redéploiement significatif.

En général, lorsque vous comparez les services de conteneurs Azure, un thème émerge : AKS expose l’infrastructure la plus sous-jacente, offrant ainsi une configurabilité et une extensibilité optimales. Le niveau de complexité et de surcharge opérationnelle est très variable pour les charges de travail AKS. Certaines équipes peuvent réduire considérablement la surcharge opérationnelle en utilisant des modules complémentaires et des extensions managés par Microsoft, ainsi que des fonctions de mise à niveau automatique. D’autres clients peuvent préférer un contrôle total du cluster afin de tirer parti de l’extensibilité optimale de Kubernetes et de l’écosystème CNCF. Par exemple, même si Microsoft propose Flux en tant qu’extension GitOps managée, de nombreuses équipes choisissent plutôt de configurer et d’exploiter ArgoCD par leurs propres moyens.

Les équipes chargées de la charge de travail qui, par exemple, n'ont pas besoin d'applications CNCF, ont moins d'expérience en matière d'opérations ou préfèrent se concentrer sur les fonctionnalités des applications, pourraient préférer une offre PaaS. Nous recommandons de commencer par envisager Container Apps.

Bien que Container Apps et Web App pour conteneurs soient des offres PaaS qui fournissent des niveaux similaires d’infrastructure managée par Microsoft, une différence clé est que Container Apps est plus proche de Kubernetes et fournit des fonctionnalités natives cloud supplémentaires pour la découverte de services, la mise à l’échelle automatique basée sur les événements, l’intégration Dapr, etc. Toutefois, les équipes qui n’ont pas besoin de ces fonctionnalités et qui connaissent bien les modèles de mise en réseau et de déploiement App Service peuvent préférer Web App pour conteneurs.

Les généralisations peuvent vous aider à affiner la liste des Azure container services à prendre en compte. Mais gardez à l’esprit que vous devez également vérifier votre choix en examinant en détail les exigences individuelles et en les faisant correspondre aux ensembles de fonctionnalités spécifiques au service.

Contributeurs

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

Principaux auteurs :

Autres contributeurs :

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

Étapes suivantes