Partager via

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

  • Article

Cet article vous guide tout au long du processus de choix d’un service de conteneur Azure. 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 fait partie deux d’une série qui commence par Choisir un service de conteneur Azure. 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 réseau
  • Présentation du flux de trafic
  • Planification des sous-réseaux
  • Nombre d’adresses IP d’entrée disponibles
  • Prise en charge des 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 du coffre de clés Azure
  • 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 la sécurité

Considérations opérationnelles

  • Mises à jour et correctifs
  • Mises à jour de l'image du conteneur
  • Scalabilité de l’infrastructure verticale
  • Scalabilité de l’infrastructure horizontale
  • Scalabilité des applications
  • Observabilité
  • Well-Architected Cadre pour l’excellence opérationnelle

Considérations relatives à la fiabilité

  • Contrats de niveau de service
  • Redondance par le biais de zones de disponibilité
  • Contrôles de santé et auto-réparation
  • Déploiements d’applications sans temps d’arrêt
  • Limites des ressources
  • Well-Architected Cadre pour la fiabilité

Notez que cet article se concentre sur un sous-ensemble de services de conteneur Azure 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), AKS Automatic, Azure Container Apps et Web App for Containers. 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

Certaines sections distinguent AKS Standard d’AKS Automatic. Si une section ne fait pas la distinction entre les deux, la parité des caractéristiques est supposée.

Considérations sur l’architecture

Cette section décrit les décisions architecturales difficiles à inverser ou à corriger sans nécessiter de temps d’arrêt ou de réexéploiement significatifs. 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 service de conteneur Azure.

Remarque

AKS Automatic est une solution plus avisée que AKS Standard. Certaines fonctionnalités d’origine ne peuvent pas être désactivées. Ce guide ne mentionne pas ces fonctionnalités. Pour obtenir des informations à jour sur ces contraintes, et la comparaison des fonctionnalités Standard et Automatique, consultez : comparaison des fonctionnalités AKS Automatique et Standard.

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 services de conteneur Azure. Vos options sont plus limitées pour les composants de charge de travail qui nécessitent des conteneurs Windows.

Applications de conteneur AKS AKS Automatic Web App pour conteneurs
Prise en charge de Linux ✅ ✅ ✅ ✅
Prise en charge de Windows ❌ ✅ ❌ ✅
Prise en charge de systèmes d'exploitation mixtes ❌ ✅ ❌ ❌*

*La prise en charge du système d’exploitation mixte pour Web App for Containers 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, les domaines managés internes et les contrôles de réseau virtuel.
  • 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 de charge de travail peuvent tirer parti de divers modules complémentaires de mise en réseau gérés par Azure , ainsi que d’installer et d’exploiter les modules complémentaires à partir de l’écosystème Kubernetes plus large.
  • Web App pour conteneurs est une fonctionnalité d’App Service. Ainsi, les concepts de mise en réseau, en particulier l’intégration de mise en réseau privée, sont très spécifiques à App Service. Ce service sera familier aux équipes responsables de la gestion des charges 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 service de conteneur Azure.

Espaces d’adressage 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		 Obligatoire Facultatif
Exigences d'adresse 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. Les détails sont en dehors de l’étendue de cet article. Pour plus d’informations, consultez Concepts relatifs aux réseaux pour AKS.

Présentation 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 différentes 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 :

  • De plusieurs charges de travail colocalisées.
  • Entrée privée et/ou publique.
  • Flux de trafic est-ouest contrôlé par des restrictions d'accès dans un cluster (pour Container Apps et AKS) ou au sein d'un réseau virtuel (pour tous les services de conteneur Azure).

Planification du 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. Les exemples incluent 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 for Containers, 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 qui ont des ressources 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 service de conteneur Azure.

Applications de conteneur AKS Web App pour conteneurs
nombre d’adresses IP d’entrée Un 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 for Containers, 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 des 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 uniquement basé sur la consommation pour ACA.

AKS et Web App for Containers 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 expliquer en détail, les pools de nœuds 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 techniquement pas directement dans le réseau virtuel, mais tous ses flux d'accès sortent par le réseau virtuel, et les règles associées au réseau influencent le trafic comme prévu.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge de UDR Plan uniquement de consommation : ❌
Plan de profil de charge de travail : ✅		 ✅ ✅
Support des passerelles 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 stricte de couche 4 pour l'entrée et la sortie, vous devriez envisager Container Apps, AKS et l'App Service Environment SKU en mode monolocataire, où les charges de travail sont déployées dans un réseau virtuel autogéré, 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 for Containers 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.

Container Apps AKS Application Web pour conteneurs
Protocole et prise en charge des ports HTTP (port 80)*
HTTPS (port 443)*
TCP (ports 1-65535, sauf 80 et 443)		 TCP (n’importe quel port)
UDP (n’importe quel port)		 HTTP (port 80)
HTTPS (port 443)
Prise en charge de WebSocket ✅ ✅ ✅
Prise en charge de 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 for Containers 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 extrait entièrement les é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 de charge de travail configure en interfacant avec l’API Kubernetes. Pour l’équilibrage de charge de couche 7 dans AKS, vous pouvez choisir des options gérées par Azure, par exemple le module complémentaire de routage d’applications managées AKS ou le Application Gateway pour 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 Géré par Azure Responsabilité partagée Géré par Azure
Équilibreur de charge de couche 7 Géré par Azure Partagé ou autogéré Géré 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 requise. 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 FQDN d'accès public. 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 à partir de 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.

Essentiel

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 for Containers, 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 for Containers 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 N/A Prête à l’emploi
TLS managé pour les domaines personnalisés En préversion BYO Prête à l’emploi ou BYO

Les utilisateurs AKS sont responsables de la gestion des certificats DNS, de cluster et TLS pour leurs domaines personnalisés. Bien qu’AKS n’offre pas de protocole TLS managé, les clients peuvent tirer parti des logiciels de l’écosystème Kubernetes, par exemple le de gestionnaire de certificats populaire pour gérer les certificats TLS.

TLS mutuel

Un autre moyen de restreindre le trafic entrant est le TLS mutuel (mTLS). Le protocole TLS mutuel est un protocole de sécurité qui garantit que le client et le serveur en communication sont authentifiés. Pour effectuer l’authentification, les deux parties échangent et vérifient les certificats avant toute transmission de données.

Web App for Containers propose une prise en charge intégrée de mTLS pour les connexions clients 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 protocole TLS mutuel dans AKS peut être implémenté via le maillage de services basé sur Istio comme module complémentaire géré, qui inclut des fonctionnalités mTLS pour les connexions clientes entrantes et pour la communication intra-cluster entre les services. Les équipes de charge de travail peuvent également choisir d’installer et de gérer une autre offre de maillage de services à partir de l’écosystème Kubernetes. Ces options rendent l’implémentation mTLS dans Kubernetes 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 services de conteneur Azure 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é réseau et la sécurisation du trafic réseau.

Considérations relatives à la 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 de service de conteneur Azure 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 for Containers, s’intègrent à des offres de sécurité clés, notamment Key Vault et des identités managées.

Parmi les services de ce guide, AKS offre la plus configurabilité et extensibilité en partie en exposant les composants sous-jacents, qui peuvent souvent être sécurisés via des options de configuration. Par exemple, les clients peuvent désactiver des comptes locaux sur le serveur d’API Kubernetes ou activer les mises à jour automatiques vers des nœuds sous-jacents via des options de configuration.

Les clusters automatiques AKS sont fournis avec une configuration par défaut renforcée, avec de nombreux paramètres de sécurité de cluster, d’application et de mise en réseau activés par défaut. Ces configurations initiales ne réduisent pas seulement le temps de déploiement, mais donnent également aux utilisateurs une configuration standardisée qui est pré-validée et donne ainsi aux utilisateurs une base solide pour les responsabilités opérationnelles de jour 2. Cette base permet de raccourcir la courbe d’apprentissage de la gestion des clusters à long terme pour les équipes nouvelles de la technologie.

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é du 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.

Essentiel

Notez que cette section n’est pas pertinente pour Web App for Containers, 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. En dehors de la boîte de dialogue, 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 seul plan de verre 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, au lieu de cela, implémenter 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 Aucun 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é basée sur le 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 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 intégration au réseau virtuel du serveur d’API (préversion), où le serveur d’API est inséré dans un sous-réseau délégué. Pour en savoir plus, consultez la documentation.

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

Applications de conteneur AKS
Sécurité du 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 politiques de sécurité nécessitent la séparation du trafic réseau dans un environnement, par exemple lorsque vous utilisez des environnements multilocataires pour héberger plusieurs applications ou des applications à plusieurs niveaux. Dans ces scénarios, vous devez choisir AKS et implémenter stratégies réseau, une technologie native cloud qui permet une configuration granulaire de la mise en réseau de couche 4 au sein de 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 for Containers.

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 intégrées pour l’entrée

Container Apps et Web App for Containers fournissent des restrictions IP sources intégrées pour le trafic d’entrée pour les applications individuelles. AKS peut obtenir la même fonctionnalité, mais nécessite des fonctionnalités natives Kubernetes via l'api-resource Kubernetes Service qui vous permet de définir des valeurs pour loadBalancerSourceRanges.

Applications de conteneur AKS Web App pour conteneurs
Restrictions IP d'entrée intégrées ✅ ❌* ✅
consommation des ressources - Consomme des ressources de cluster -

Remarque

AKS offre des restrictions d’adresse IP d’entrée, mais il s’agit d’une fonctionnalité native Kubernetes et non d’Azure Native comme les autres services.

Sécurité au niveau de l’application

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 solutions de conteneur Azure 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 de Key Vault

Il est recommandé de stocker et de gérer des secrets, 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 secrets 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 services de conteneur Azure 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, voir :

Prise en charge des identités managées

L’identité managée peut être utilisée par les applications pour s’authentifier auprès des services protégés par l’ID Microsoft Entra sans avoir à utiliser de clés ou de secrets. Applications de conteneur et application Web pour conteneur offrent une prise en charge intégrée, native à Azure, pour la gestion des identités au niveau des applications. La prise en charge des identités managées au niveau de l’application pour AKS est effectuée via l’ID de charge de travail Entra. AKS nécessite également une identité managée liée à l’infrastructure pour autoriser les opérations de cluster pour le Kubelet, le plan de contrôle du cluster et divers modules complémentaires AKS.

Applications de conteneur AKS Web App pour conteneurs
Prise en charge des identités managées de l’infrastructure N/A ✅ N/A
Prise en charge de l’identité managée par extraction de conteneurs ✅ ✅ ✅
Prise en charge de l’identité managée d’application ✅ ✅ ✅

Pour plus d'informations, voir :

É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 service de conteneur Azure, et non pas seulement celles décrites dans cet article. Toutefois, la protection du runtime de Defender pour conteneurs n'est disponible que pour AKS.

Comme AKS expose l’API Kubernetes native, la sécurité du cluster peut également être évaluée avec des outils de sécurité spécifiques à Kubernetes à partir 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 :

Remarque

Les clusters automatiques AKS sont configurés avec des paramètres de sécurité spécifiques. Vérifiez que ces éléments sont alignés sur vos besoins en charge de travail.

Well-Architected Cadre pour la 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 Well-Architected Révision du cadre - 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 qu’un système d’exploitation sous-jacent d’une application soit mis à jour et corrigé régulièrement. 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. Toutefois, les équipes de charge de travail sont responsables de l’application des mises à jour à leurs clusters. Vous pouvez déclencher manuellement des mises à jour ou profiter de la fonctionnalité des chaînes de mise à niveau automatique du cluster 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 for Containers 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 AKS Automatic Web App pour conteneurs
Mises à jour du plan de contrôle Plateforme Client Plateforme Plateforme
Mises à jour et correctifs de l’hôte Plateforme Client Plateforme Plateforme
Mises à jour et correctifs d’images conteneur Customer Customer Customer Customer

Mises à jour de l'image du conteneur

Quelle que soit la solution de conteneur Azure, 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.

Extensibilité

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 solution de conteneur Azure, 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 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 services de conteneur Azure 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 consommation : N/A
Plan dédié : configurable		 Configurable Configurable
Provisionnement matériel flexible Plan de consommation : N/A
Plan dédié : abstrait avec des profils de charge de travail		 N’importe quelle référence SKU de machine virtuelle Abstrait. Consultez Plan App Service.

Essentiel

Les options d’approvisionnement matérielle disponibles via le plan dédié Container Apps (profils de charge de travail) et Web App for Containers (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 ajuster le nombre d’instances de conteneurs en fonction de métriques spécifiques au contexte de 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 for Containers s’appuie sur les options d’extensibilité fournies par Azure. (Consultez le tableau suivant.) L'application Web pour conteneurs ne prend pas en charge les configurations personnalisées de mise à l'échelle comme par exemple 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. Configuration supplémentaire requise. Oui. Spécifique à la ressource Azure.

AKS Automatic active par défaut le Horizontal Pod Autoscaler (HPA), la mise à l'échelle automatique basée sur les événements Kubernetes (KEDA) et le Vertical Pod Autoscaler (VPA).

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 par agent ❌ Prise en charge partielle* N/A
Instrumentation manuelle Via le SDK ou OpenTelemetry Via SDK ou OpenTelemetry Via le SDK ou OpenTelemetry

*AKS et Web App for Containers prennent en charge l’instrumentation automatique pour certaines configurations de charges de travail Linux et Windows, en fonction du langage de l’application. Pour en savoir plus, voir 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 solution de conteneur Azure. Votre charge de travail peut utiliser des solutions telles que :

Journaux et métriques

Tous les services conteneurs Azure fournissent des fonctionnalités de journal et de métriques 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 métriques sont des valeurs numériques qui décrivent un aspect d’un système à un moment donné, ce qui vous permet de surveiller et d’alerter sur les performances et l’intégrité du système.

Azure Monitor est le principal service de journalisation et de métriques dans Azure qui s’intègre à ces services. Azure Monitor utilise des journaux de ressources pour séparer les journaux de différentes sources en catégories et collecte des métriques pour fournir des aperçus sur les performances des ressources. Une façon de déterminer quels journaux et métriques sont disponibles à partir de chaque service Azure consiste à examiner les catégories de journaux de ressources et les métriques disponibles pour chacun des services.

Applications de conteneur AKS AKS Automatic Web App pour conteneurs
Prise en charge du streaming de journaux ✅ ✅ ✅ ✅
Prise en charge d’Azure Monitor ✅ ✅ ✅ ✅
Journaux de ressources Azure Monitor Console et System serveur d’API Kubernetes, Audit, Planificateur, Mise à l’échelle automatique du cluster, etc. Identique à AKS ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs, etc.
Collecte et surveillance des métriques Métriques via Azure Monitor ; Métriques personnalisées via des métriques Dapr Métriques via Azure Monitor ; Métriques personnalisées via Prometheus (nécessite une configuration manuelle) Préconfiguré Managed Prometheus pour la collecte de métriques et Managed Grafana pour la visualisation ; Métriques via Azure Monitor Métriques via Azure Monitor
Prometheus préconfiguré et Grafana ❌ Nécessite une configuration manuelle ✅ Prometheus managé et Grafana managé sont préconfigurés par défaut. ❌

Container Apps extrait tous ses journaux Kubernetes internes en deux catégories : les journaux de console, qui contiennent des journaux de conteneur de charge de travail et les journaux système, qui contiennent tous les journaux liés à la plateforme. Pour les métriques, Container Apps s’intègre à Azure Monitor pour collecter des métriques standard et prend en charge les métriques personnalisées via l’intégration de Dapr pour les scénarios avancés.

AKS fournit tous les journaux liés à Kubernetes et un contrôle granulaire sur ce qui est journalisé. AKS conserve la compatibilité complète avec les outils clients Kubernetes pour le streaming des journaux, tels que kubectl. Pour les métriques, AKS s’intègre à Azure Monitor pour collecter des métriques de cluster et de nœud. La collecte de métriques personnalisées à l’aide de Prometheus et la visualisation avec Grafana sont possibles, mais nécessitent une configuration et une configuration manuelles.

AKS automatique est préconfiguré avec des outils de surveillance spécifiques. Il utilise Managed Prometheus pour la collecte de métriques et Managed Grafana pour la visualisation. Les métriques de cluster et d’application sont automatiquement collectées et peuvent être visualisées. AKS Automatic s’intègre également à Azure Monitor pour la collecte des logs et des métriques.

Web App for Containers fournit plusieurs catégories de journaux de ressources, car sa plateforme (App Service) n’est pas exclusivement destinée aux charges de travail basées sur des conteneurs. 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. Les métriques sont collectées via Azure Monitor, ce qui vous permet de surveiller les performances des applications et l’utilisation des ressources.

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é

fiabilité fait référence à la capacité d’un système à réagir aux défaillances et à rester entièrement 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 contrôles 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. Les 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 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'y a pas de niveau de service de 100%, car des défaillances peuvent toujours survenir dans les logiciels, le matériel, ou en raison de phénomènes naturels comme 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 SLA et détails, téléchargez le dernier SLA pour Microsoft Online Services à partir du site de licences de 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 dans lequel 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 auto-guérison

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 de santé, consultez les types intégrés de sondes 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 long intervalle entre ces demandes, vous pouvez continuer à gérer le trafic jusqu’à ce que l’instance soit considérée en mauvais état.

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 quand vous concevez votre système de vérification de santé.

Container Apps AKS Application Web pour conteneurs
Probes de démarrage ✅ ✅ Prise en charge partielle
Probes readiness ✅ ✅ ❌
Probes 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. Il 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 saines.
  • 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 saine soit supprimé 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 de ce paramètre est de 10 minutes.

Container Apps et AKS, d’autre part, 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 défaillante et arrêter l'envoi du trafic vers celle-ci, c'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 la comparaison des trois services de conteneurs :

  • Dans Web App pour conteneurs, il n’existe aucune option permettant de redémarrer une instance de conteneur immédiatement après qu’un contrôle d’intégrité de échoue. Si l’instance échoue pendant une heure, elle est remplacée par une nouvelle instance. Il existe une autre fonctionnalité, appelée de réparation automatique, qui surveille et redémarre les instances. Il n’est pas directement lié aux contrôles de santé. Il 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 de temps d’arrêt zéro Mise à jour propagée Rolling update, ainsi que toutes les autres stratégies Kubernetes. Emplacements de déploiement

Notez que les architectures d’application doivent également prendre en charge le déploiement sans temps d’arrêt. Consultez Azure Framework Well-Architected 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 for Containers: vous pouvez héberger plusieurs applications (conteneurs) dans un seul plan App Service. Par exemple, vous pouvez allouer un plan avec deux cœurs de processeur et 4 Gio de RAM où 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 vCPU et de mémoire, tant que vos nœuds disposent du matériel pour les 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 Cadre de 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 conteneur Azure, un thème apparaît : AKS expose l’infrastructure la plus sous-jacente, offrant ainsi le plus grand contrôle et configurabilité, tandis qu’AKS Automatic offre un équilibre entre le contrôle et la simplicité en automatisant de nombreuses tâches opérationnelles.

La charge opérationnelle et la complexité sont très variables pour les charges de travail AKS. Certaines équipes peuvent réduire considérablement la surcharge opérationnelle en utilisant des extensions et des extensions gérées par Microsoft, ainsi que des fonctionnalités de mise à niveau automatique. D’autres clients peuvent préférer un contrôle total du cluster afin de tirer parti de l’extensibilité totale de Kubernetes et de l’écosystème CNCF. Par exemple, bien que Microsoft offre Flux en tant qu’extension GitOps managée, de nombreuses équipes choisissent plutôt de configurer et d’exploiter ArgoCD par eux-mêmes.

Les équipes de charge de travail qui, par exemple, ne nécessitent pas d’applications CNCF, ont moins d’expérience d’exploitation ou préfèrent se concentrer sur les fonctionnalités d’application peuvent préférer une offre PaaS. Nous recommandons de commencer par envisager Container Apps.

Bien que Container Apps et Web App for Containers 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 pilotée par les événements, l’intégration de 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 for Containers.

Les généralisations peuvent vous aider à affiner la liste des services de conteneur Azure à 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 correspondant 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.

Auteurs principaux :

Autres contributeurs :

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

Étapes suivantes