Composants Passerelle d'application pour conteneurs

Cet article fournit des descriptions et des exigences détaillées pour les composants de Passerelle d’application pour conteneurs. Il explique comment Application Gateway pour conteneurs accepte les requêtes entrantes et les achemine vers une cible back-end. Pour obtenir une présentation générale de Passerelle d’application pour conteneurs, consultez la rubrique Qu’est-ce que Passerelle d’application pour conteneurs ?.

Composants principaux

• Une ressource Passerelle d’application pour conteneurs est une ressource parente Azure qui déploie le plan de contrôle.
• Le plan de contrôle orchestre la configuration du proxy en fonction de l’intention du client.
• Application Gateway pour les conteneurs possède deux ressources enfants : des associations et des front-ends.
  • Les ressources enfants appartiennent exclusivement à leur Application Gateway pour les conteneurs parente et ne peuvent pas être partagées avec d’autres ressources Application Gateway pour les conteneurs.

Serveurs front-end de Passerelle d’application pour conteneurs

• Une ressource frontale de Passerelle d’application pour conteneurs est une ressource enfant Azure de la ressource parente Passerelle d’application pour conteneurs.
• Un front-end d’Application Gateway pour les conteneurs définit le point d’entrée utilisé par le trafic client pour un Application Gateway pour les conteneurs donné.
  • Vous ne pouvez pas associer un front-end à plusieurs applications Gateway pour conteneurs.
  • Vous pouvez créer un enregistrement CNAME à l’aide du nom de domaine complet unique fourni par chaque serveur frontal.
  • Les adresses IP privées ne sont actuellement pas prises en charge.
• Une seule instance Application Gateway pour conteneurs peut prendre en charge plusieurs serveurs front-end.

Associations de Passerelle d’application pour conteneurs

• Une ressource d’association de Passerelle d’application pour conteneurs est une ressource enfant Azure de la ressource parente Passerelle d’application pour conteneurs.
• Une association Passerelle d’application pour conteneurs définit un point de connexion dans un réseau virtuel. Une association est un mappage 1:1 d’une ressource d’association à un sous-réseau Azure délégué.
• Application Gateway pour les conteneurs est conçu pour permettre plus d’une association.
  • À ce stade, le nombre actuel d’associations est limité à 1.
• Lors de la création d’une association, le plan de données sous-jacent est approvisionné et connecté à un sous-réseau au sein du sous-réseau du réseau virtuel défini.
• Chaque association doit supposer qu’au moins 256 adresses sont disponibles dans le sous-réseau au moment de l’approvisionnement.
  • Un masque de sous-réseau /24 minimum pour chaque déploiement (en supposant qu’aucune ressource n’ait été préalablement provisionnée dans le sous-réseau).
    • Si vous envisagez de déployer plusieurs ressources Application Gateway pour conteneurs qui partagent le même sous-réseau, calculez les adresses requises comme n×256, où n est égal au nombre de ressources Application Gateway pour conteneurs. Cela suppose que chacun contient une association.
  • Toutes les ressources d’association de la Passerelle d’application pour conteneurs doivent correspondre à la même région que celle de la ressource Passerelle d’application pour conteneurs parente.

Contrôleur ALB pour Passerelle d’application pour conteneurs

• Un contrôleur ALB de Passerelle d’application pour conteneurs est un déploiement Kubernetes qui orchestre la configuration et le déploiement de Passerelle d’application pour conteneurs en regardant à la fois les ressources personnalisées et les configurations de ressources Kubernetes, telles que, mais pas limitées à, l’entrée, la passerelle et ApplicationLoadBalancer. Il utilise les API de configuration ARM et Application Gateway pour conteneurs pour propager la configuration au déploiement Azure d’Application Gateway pour conteneurs.
• Déployez ou installez le contrôleur ALB avec Helm.
• Le contrôleur ALB se compose de deux pods en exploitation.
  • Le pod alb-controller met en œuvre l'intention du client pour configurer l'équilibrage de charge des conteneurs via Application Gateway.
  • le pod alb-controller-bootstrap gère les CRDs (Custom Resource Definitions).

Stratégie de sécurité Application Gateway pour conteneurs

• Une stratégie de sécurité Application Gateway pour conteneurs définit des configurations de sécurité, telles que WAF, pour être utilisées par le contrôleur ALB.
• Une seule ressource Application Gateway pour conteneurs peut faire référence à plusieurs stratégies de sécurité.
• À ce stade, le seul type de stratégie de sécurité proposé est waf destiné aux fonctionnalités de pare-feu d’applications web.
• La waf stratégie de sécurité est un mappage un-à-un entre la ressource de stratégie de sécurité et une stratégie de pare-feu d’applications web.
  • Vous ne pouvez référencer qu’une seule stratégie de pare-feu d’applications web dans n’importe quel nombre de stratégies de sécurité pour une ressource Application Gateway pour conteneurs définie.

Concepts Azure/généraux

Adresse IP privée

• Une adresse IP privée n’est pas explicitement définie en tant que ressource Azure Resource Manager. Une adresse IP privée fait référence à une adresse hôte spécifique dans le sous-réseau d’un réseau virtuel donné.

Délégation de sous-réseau

• Microsoft.ServiceNetworking/trafficControllers est l’espace de noms adopté par Application Gateway pour conteneurs et vous pouvez le déléguer au sous-réseau d’un réseau virtuel.
• Lorsque vous déléguez, vous ne provisionnez pas de ressources Application Gateway pour les conteneurs, et il n’existe pas de mappage exclusif vers une ressource d’association Application Gateway pour les conteneurs.
• Un nombre quelconque de sous-réseaux peut avoir une délégation de sous-réseau identique ou différente de Passerelle d’application pour conteneurs. Une fois défini, vous ne pouvez pas provisionner d’autres ressources dans le sous-réseau, sauf si elle est définie explicitement par l’implémentation du service.

Identité managée affectée par l’utilisateur

• Les identités gérées pour les ressources Azure éliminent la nécessité de gérer les informations d’identification dans le code.
• Vous avez besoin d’une identité managée affectée par l’utilisateur pour chaque contrôleur Azure Load Balancer afin d’apporter des modifications à Application Gateway pour conteneurs.
• AppGw for Containers Configuration Manager est un rôle RBAC intégré qui permet au contrôleur ALB d’accéder et de configurer la ressource Passerelle d’application pour conteneurs.

Comment Passerelle d’application pour conteneurs accepte une requête

Chaque front-end Application Gateway pour les conteneurs fournit un nom de domaine complet généré et géré par Azure. Vous pouvez utiliser le nom de domaine complet tel quel ou le masquer avec un enregistrement CNAME.

Avant qu’un client envoie une requête à Application Gateway pour conteneurs, le client résout un CNAME qui pointe vers le nom de domaine complet du serveur frontal, ou le client résout directement le nom de domaine complet fourni par Application Gateway pour conteneurs à l’aide d’un serveur DNS.

Le résolveur DNS convertit l’enregistrement DNS en adresse IP.

Lorsque le client lance la requête, le nom DNS spécifié est transmis en tant qu’en-tête d’hôte à Passerelle d’application pour conteneurs sur le front-end défini.

Un ensemble de règles d’acheminement évalue comment la demande de ce nom d’hôte doit être lancée sur un serveur principal cible défini.

Comment Passerelle d’application pour conteneurs route une requête

Requêtes HTTP/2

Application Gateway pour conteneurs prend en charge les protocoles HTTP/2 et HTTP/1.1 pour la communication entre le client et le serveur frontal. Le paramètre HTTP/2 est toujours activé et ne peut pas être modifié. Si les clients préfèrent utiliser HTTP/1.1 pour leur communication avec le front-end d’Application Gateway pour conteneurs, ils peuvent continuer à négocier en conséquence.

La communication entre Application Gateway pour conteneurs et la cible principale est toujours via HTTP/1.1, à l’exception de gRPC, qui utilise HTTP/2.

Modifications apportées à la requête

Application Gateway pour les conteneurs ajoute trois en-têtes supplémentaires à toutes les requêtes avant d’envoyer les requêtes vers une cible de back-end :

• x-forwarded-for
• x-forwarded-proto
• x-request-id

X-forwarded-for est l’adresse IP du client du demandeur d’origine. Si la requête passe par un proxy, la valeur d’en-tête ajoute l’adresse qu’elle reçoit, délimitée par des virgules. Par exemple : 1.2.3.4,5.6.7.8 ; où 1.2.3.4 est l’adresse IP du client au proxy devant Application Gateway pour conteneurs, et 5.6.7.8 est l’adresse du trafic de transfert de proxy vers Application Gateway pour conteneurs.

X-forwarded-proto retourne le protocole que l'Application Gateway pour conteneurs reçoit du client. La valeur est http ou https.

x-request-id est un guid unique généré par Application Gateway pour conteneurs pour chaque requête cliente et présente dans la requête transférée à la cible back-end. Le guid se compose de 32 caractères alphanumériques, séparés par des tirets (par exemple : aaaa0000-bb11-2222-33cc-444444dddddd). Vous pouvez utiliser ce GUID pour corréler une requête reçue par Application Gateway pour les conteneurs et initiée vers une cible de back-end, comme défini dans les journaux d’accès.

Délais d’expiration des requêtes

Application Gateway pour conteneurs applique les délais d’expiration suivants au fur et à mesure qu’il lance et gère les requêtes entre le client, Application Gateway pour conteneurs et le back-end.