Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Un réseau virtuel crée une limite de sécurité autour de votre Azure Container Apps environment. Par défaut, les environnements sont créés avec un réseau virtuel généré automatiquement. Toutefois, l’utilisation d’un réseau virtuel existant fournit davantage de fonctionnalités réseau Azure, telles que l’intégration à Azure Application Gateway, les groupes de sécurité réseau et la communication avec des ressources derrière des points de terminaison privés. Cette configuration est importante pour les clients d’entreprise qui doivent isoler les applications internes et stratégiques de l’Internet public.
Lorsque vous créez un réseau virtuel, gardez à l’esprit les situations suivantes :
Si vous souhaitez que votre application de conteneur limite tout accès extérieur, créez un environnement Container Apps interne.
Si vous utilisez votre propre réseau virtuel, vous devez fournir un sous-réseau dédié exclusivement à votre application conteneur. Ce sous-réseau n’est pas accessible à d’autres services.
Les adresses réseau sont affectées à partir d’une plage de sous-réseaux que vous définissez à mesure que l’environnement est créé.
Vous pouvez définir la plage de sous-réseaux utilisée par l’environnement Container Apps.
Vous pouvez limiter les demandes entrantes à l’environnement exclusivement au réseau virtuel en déployant l’environnement en tant qu’environnement interne.
Remarque
Lorsque vous fournissez votre propre réseau virtuel, des ressources managées supplémentaires sont créées. Ces ressources entraînent des coûts à leurs tarifs associés.
Lorsque vous commencez à concevoir le réseau autour de votre application conteneur, reportez-vous à Planifier des réseaux virtuels.
Remarque
Le déplacement de réseaux virtuels entre différents groupes de ressources ou abonnements n’est pas autorisé si un environnement Container Apps utilise le réseau virtuel.
Subnet
L’intégration au réseau virtuel dépend d’un sous-réseau dédié. L’allocation d’adresses IP dans un sous-réseau et les tailles de sous-réseau prises en charge dépendent du plan que vous utilisez dans Container Apps.
Sélectionnez soigneusement la taille de votre sous-réseau. Vous ne pouvez pas modifier les tailles de sous-réseau après avoir créé un environnement Container Apps.
Chaque type d’environnement a ses propres exigences de sous-réseau :
La taille minimale du sous-réseau requise pour l’intégration de réseau virtuel est
/27.Vous devez déléguer votre sous-réseau à
Microsoft.App/environments.Lorsque vous utilisez un environnement externe avec une entrée externe, le trafic entrant est acheminé via l’adresse IP publique de l’infrastructure plutôt que via votre sous-réseau.
Container Apps réserve automatiquement 12 adresses IP pour l’intégration au sous-réseau. Le nombre d’adresses IP requises pour l’intégration de l’infrastructure ne varie pas en fonction des exigences de mise à l’échelle de l’environnement.
Des adresses IP supplémentaires sont allouées en fonction des règles suivantes, selon le type de profil de charge de travail que vous utilisez :
Profil de charge de travail dédié : à mesure que votre application conteneur subit un scale-out, chaque nœud a une adresse IP affectée.
Profil de consommation de la charge de travail : chaque adresse IP peut être partagée entre plusieurs réplicas. Lorsque vous planifiez le nombre d’adresses IP requises pour votre application, planifiez une adresse IP par 10 réplicas.
Lorsque vous apportez une modification à une révision en mode révision unique, l’espace d’adressage requis est doublé pendant une courte période pour prendre en charge les déploiements sans temps d’arrêt. Ce doublement affecte le nombre réel de réplicas ou de nœuds pris en charge et disponibles pour une taille de sous-réseau donnée. Le tableau suivant indique à la fois le nombre maximal d’adresses disponibles par bloc CIDR et l’effet sur la mise à l’échelle horizontale.
Taille du sous-réseau Adresses IP disponibles1 Nombre maximal de nœuds (profil de charge de travail dédié)2 Nombre maximal de réplicas (profil de charge de travail Consommation)2 /23 498 249 2,490 /24 242 121 1,210 /25 114 57 570 /26 50 25 250 /27 18 9 90 1 Le nombre d’adresses IP disponibles est la taille du sous-réseau moins les 14 adresses IP requises pour Azure Container Apps infrastructure (qui inclut 5 adresses IP que le sous-réseau réserve).
2 Ces numéros comptent pour les applications en mode de révision unique.
Restrictions pour les plages d’adresses de sous-réseau
Les plages d'adresses de sous-réseau ne peuvent pas chevaucher les plages suivantes qui Azure Kubernetes Service réserves :
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
En outre, un environnement de profil de charge de travail réserve les adresses suivantes :
- 100.100.0.0/17
- 100.100.128.0/19
- 100.100.160.0/19
- 100.100.192.0/19
Configuration du sous-réseau avec l’interface CLI
Quand vous créez un environnement Container Apps, vous indiquez des ID de ressource pour un seul sous-réseau.
Si vous utilisez le Azure CLI, le paramètre permettant de définir l'ID de ressource de sous-réseau est infrastructure-subnet-resource-id. Le sous-réseau héberge les composants d’infrastructure et les conteneurs d’application utilisateur.
Si vous utilisez le Azure CLI avec un environnement Consommation uniquement et la plage platformReservedCidr est définie, les deux sous-réseaux ne doivent pas chevaucher la plage IP définie dans platformReservedCidr.
intégration de Azure NAT Gateway
Vous pouvez utiliser Azure NAT Gateway pour simplifier la connectivité de votre trafic Internet sortant dans votre réseau virtuel dans un environnement de profil de charge de travail.
Lorsque vous configurez une passerelle NAT (Network Address Translation) sur votre sous-réseau, la passerelle NAT fournit une adresse IP publique statique pour votre environnement. Tout le trafic sortant de votre application conteneur est routé via l’adresse IP publique statique de la passerelle NAT.
Remarque
La référence SKU StandardV2 de Azure NAT Gateway n’est actuellement pas prise en charge pour l’intégration.
Ressources managées
Quand vous déployez un environnement interne ou externe dans votre propre réseau, un nouveau groupe de ressources est créé dans l’abonnement Azure où votre environnement est hébergé. Ce groupe de ressources contient des composants d’infrastructure que la plateforme Azure Container Apps gère. Ne modifiez ni les services de ce groupe, ni le groupe de ressources lui-même.
Remarque
Les balises définies par l’utilisateur affectées à votre environnement Container Apps sont répliquées sur toutes les ressources du groupe de ressources, y compris le groupe de ressources lui-même.
Le nom du groupe de ressources créé dans l’abonnement Azure où votre environnement est hébergé est préfixé par ME_ par défaut. Vous pouvez personnaliser le nom du groupe de ressources lorsque vous créez votre environnement Container Apps.
Pour les environnements externes, le groupe de ressources contient une adresse IP publique utilisée spécifiquement pour la connectivité entrante à votre environnement externe et un équilibreur de charge. Pour les environnements internes, le groupe de ressources contient uniquement un équilibreur de charge.
En plus de la facturation standard de Container Apps, vous êtes facturé pour :
Une adresse IP publique statique standard pour la sortie si vous utilisez un environnement interne ou externe, ainsi qu’une adresse IP publique statique standard pour l’entrée si vous utilisez un environnement externe. Si vous avez besoin d’adresses IP publiques supplémentaires pour le trafic sortant en raison de problèmes de NAT source (SNAT), ouvrez un ticket d’assistance pour demander une dérogation.
Un équilibreur de charge standard.
Le coût des données traitées (en gigaoctets) comprend à la fois l’entrée et la sortie pour les opérations de gestion.