Partager via

Composants d’Application Gateway pour les conteneurs

  • Article

Cet article fournit des descriptions et des exigences détaillées pour les composants de Passerelle d’application pour conteneurs. Les informations sur la façon dont Passerelle d’application pour conteneurs accepte les requêtes entrantes et les route vers un serveur principal cible sont fournies. 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 de base

  • 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 est chargé d’orchestrer la configuration du proxy en fonction de l’intention du client.
  • Passerelle d’application pour conteneurs possède deux ressources enfants : les associations et les serveurs frontaux.
    • Les ressources enfants sont propres à la Passerelle d’application pour conteneurs dont elles dépendent et ne peuvent pas être référencées par une autre ressource Passerelle d’application pour 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 serveur frontal de Passerelle d’application pour conteneurs définit le point d’entrée du trafic client qui doit être reçu par une ressource Passerelle d’application pour conteneurs donnée.
    • Un serveur front-end ne peut pas être associé à plusieurs Passerelles d’application pour conteneurs.
    • Chaque serveur front-end fournit un FQDN unique qui peut être référencé par l’enregistrement CNAME d’un client.
    • Les adresses IP privées ne sont actuellement pas prises en charge.
  • Une seule Passerelle d’application 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 qui a été délégué.
  • La Passerelle d’application pour conteneurs est conçue pour permettre plusieurs associations.
    • À ce stade, le nombre d’associations est actuellement 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écédemment provisionnée dans le sous-réseau).
      • Si un nombre n de Passerelles d’application pour conteneurs est provisionné, en supposant que chaque Passerelle d’application pour conteneurs contient une association, et que l’intention est de partager le même sous-réseau, les adresses requises disponibles doivent être n*256.
    • 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/Passerelle d’application pour conteneurs pour propager la configuration au déploiement Azure de Passerelle d’application pour conteneurs.
  • Le contrôleur ALB est déployé / installé via Helm.
  • Le contrôleur ALB se compose de deux pods en exploitation.
    • Le pod alb-controller est responsable de l’orchestration de l’intention du client vers la configuration de l’équilibrage de charge de la Passerelle d’application pour conteneurs.
    • Le pod alb-controller-bootstrap est responsable de la gestion des CRD.

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 Passerelle d’application pour conteneurs et peut être délégué au sous-réseau d’un réseau virtuel.
  • Lorsque la délégation se produit, l’approvisionnement des ressources Passerelle d’application pour conteneurs ne se produit pas, et il n’existe pas de mappage exclusif à une ressource d’association Passerelle d’application pour 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éfinie, aucune autre ressource, autre que le service défini, ne peut être provisionnée dans le sous-réseau, sauf si elle est explicitement définie 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.
  • Une identité managée par l’utilisateur est requise pour chaque contrôleur Azure Load Balancer afin d’apporter des modifications à la Passerelle d’application 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.

Remarque

Le rôle AppGw for Containers Configuration Manager a les autorisations d’action de données que les rôles Propriétaire et Contributeur n’ont pas. Il est essentiel que les autorisations appropriées soient déléguées pour empêcher les problèmes liés au contrôleur ALB apportant des modifications au service Passerelle d’application pour conteneurs.

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

Chaque serveur front-end de Passerelle d’application pour conteneurs fournit un nom de domaine complet (FQDN) généré managé par Azure. Le FQDN peut être utilisé tel quel ou les clients peuvent choisir de masquer le nom de domaine complet avec un enregistrement CNAME.

Avant qu’un client envoie une requête à Passerelle d’application pour conteneurs, le client résout un CNAME qui pointe vers le FQDN du front-end ; ou le client peut résoudre directement le FQDN fourni par Passerelle d’application 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

La Passerelle d'application pour conteneurs prend entièrement en charge le protocole HTTP/2 pour la communication du client vers le serveur front-end. La communication de la Passerelle d'application pour conteneurs vers la cible back-end utilise le protocole HTTP/1.1. 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 serveur front-end de la Passerelle d'application pour conteneurs, ils peuvent continuer à négocier en conséquence.

Modifications apportées à la requête

Passerelle d’application pour conteneurs insère trois en-têtes supplémentaires à toutes les requêtes avant que celles-ci ne soient lancées depuis Passerelle d’application pour conteneurs vers un serveur principal cible :

  • 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 reçue, entre 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 Passerelle d’application pour conteneurs, et 5.6.7.8 est l’adresse du trafic de transfert de proxy vers Passerelle d’application pour conteneurs.

x-forwarded-proto retourne le protocole reçu par Passerelle d’application pour conteneurs de la part du client. La valeur est http ou https.

x-request-id est un GUID unique généré par Passerelle d’application pour conteneurs pour chaque demande de client et présenté dans la demande transférée à un serveur principal cible. Le guid se compose de 32 caractères alphanumériques, séparés par des tirets (par exemple : aaaa0000-bb11-2222-33cc-444444dddddd). Ce GUID peut être utilisé pour mettre en corrélation une demande reçue par Passerelle d’application pour conteneurs et adressée à un serveur principal cible telle que défini dans les journaux d’accès.

Délais d’expiration des requêtes

Passerelle d’application pour conteneurs applique les délais suivants lorsque les requêtes sont initiées et gérées entre le client, Passerelle d'application pour conteneurs et le serveur principal.

Délai d'expiration Durée Description
Délai de demande 60 secondes durée pendant laquelle Passerelle d'application pour conteneurs for Containers attend la réponse de la cible du backend.
Délai d’inactivité HTTP 5 minutes Délai d’inactivité avant de fermer une connexion HTTP.
Délai d’inactivité du flux 5 minutes Délai d’inactivité avant de fermer un flux individuel porté par une connexion HTTP.
Délai de connexion en amont 5 secondes Délai d’établissement d’une connexion avec le serveur cible.