Partager via

Qu’est-ce qu’un contrôleur d’entrée Application Gateway ?

Le contrôleur d’entrée Application Gateway (AGIC) est une application Kubernetes, qui permet aux clients d’Azure Kubernetes Service (AKS) de tirer parti de l’équilibreur de charge L7 Application Gateway natif d’Azure pour exposer un logiciel cloud à Internet. AGIC surveille le cluster Kubernetes sur lequel il est hébergé et met à jour en permanence une Application Gateway, afin que les services sélectionnés soient exposés à Internet.

Le contrôleur d’entrée s’exécute dans son propre pod sur l’AKS du client. AGIC surveille les modifications dans un sous-ensemble de ressources Kubernetes. L’état du cluster AKS est converti en configuration spécifique à l’Application Gateway et appliqué à Azure Resource Manager (ARM).

Conseil

Envisagez Application Gateway pour conteneurs pour votre solution d’entrée Kubernetes. Pour plus d’informations, consultez Démarrage rapide : Déployer Application Gateway pour conteneurs ALB Controller.

Avantages du contrôleur d’entrée Application Gateway

AGIC permet d’éliminer la nécessité d’avoir un autre /équilibreur de charge/adresse IP publique devant le cluster AKS et d’éviter plusieurs tronçons dans votre chemin d’accès aux données avant que les demandes atteignent le cluster AKS. Application Gateway communique directement avec les pods à l’aide de leur adresse IP privée et ne nécessite pas de services NodePort ou KubeProxy. Cette capacité offre également un meilleur niveau de performance à vos déploiements.

Le contrôleur d’entrée est pris en charge exclusivement par les références SKU Standard_v2 et WAF_v2, ce qui apporte également des avantages en matière de mise à l’échelle automatique. Application Gateway peut réagir en réponse à une augmentation ou une diminution de la charge du trafic et mettre à l’échelle en conséquence, sans consommer de ressources de votre cluster AKS.

L’utilisation d’Application Gateway en plus d’AGIC permet également de protéger votre cluster AKS en fournissant une stratégie TLS et la fonctionnalité de pare-feu d’applications web (WAF).

Azure Application Gateway + AKS

AGIC est configuré par le biais de la ressource d’entrée Kubernetes, ainsi que du service et des déploiements/pods. Il offre de nombreuses fonctionnalités, se servant de l’équilibreur de charge L7 Application Gateway natif d’Azure. Pour n’en nommer que quelques-unes :

  • Routage d’URL
  • Affinité basée sur les cookies
  • Arrêt TLS
  • TLS de bout en bout
  • Prise en charge des sites web publics, privés et hybrides
  • Pare-feu d’applications web intégré

Différence entre le déploiement avec Helm et en tant que module complémentaire AKS

Il y a deux façons de déployer AGIC pour votre cluster AKS : par le biais de Helm ou en tant que module complémentaire AKS. Le principal avantage du déploiement d’AGIC en tant que module complémentaire AKS est que cette méthode est plus simple que le déploiement avec Helm. Pour une nouvelle installation, vous pouvez déployer une nouvelle Application Gateway et un nouveau cluster AKS avec AGIC activé en tant que module complémentaire sur une seule ligne dans Azure CLI. De plus, le module complémentaire est un service entièrement managé qui offre d’autres avantages comme les mises à jour automatiques et une meilleure prise en charge. Les deux méthodes de déploiement d’AGIC (Helm et module complémentaire AKS) sont entièrement prises en charge par Microsoft. En outre, le module complémentaire permet une meilleure intégration avec AKS en tant que module complémentaire de première classe.

Le module complémentaire AGIC est toujours déployé en tant que pod dans le cluster AKS du client. Il y a toutefois quelques différences entre la version d’AGIC déployée avec Helm et celle déployée en tant que module complémentaire. Voici une liste des différences entre les deux versions :

  • Les valeurs de déploiement avec Helm ne peuvent pas être modifiées sur le module complémentaire AKS :
    • verbosityLevel a la valeur 5 par défaut
    • usePrivateIp est défini sur false par défaut ; ce paramètre peut être remplacé par l’annotation use-private-ip
    • shared n’est pas pris en charge sur module complémentaire
    • reconcilePeriodSeconds n’est pas pris en charge sur module complémentaire
    • armAuth.type n’est pas pris en charge sur module complémentaire
  • S’il a été déployé avec Helm, AGIC prend en charge ProhibitedTargets, ce qui signifie qu’AGIC peut configurer Application Gateway spécifiquement pour les clusters AKS sans perturber les autres serveurs back-end existants. Le module complémentaire AGIC ne prend pas cette capacité en charge pour le moment.
  • Étant donné que le module complémentaire AGIC est un service managé, les clients sont automatiquement mis à jour vers la dernière version du module complémentaire AGIC, ce qui n’est pas le cas dans un déploiement d’AGIC via Helm où le client doit mettre à jour AGIC manuellement.

Remarque

Les clients ne peuvent déployer qu’un seul module complémentaire AGIC par cluster AKS, et chaque module complémentaire AGIC ne peut actuellement cibler qu’une seule passerelle applicative. Pour les déploiements qui requièrent plusieurs AGIC par cluster ou plusieurs AGIC ciblant un passerelle applicative, continuez à utiliser AGIC déployé via Helm.

Les modules complémentaires Helm et AGIC ne prennent pas en charge le service ExternalName.

Mise en réseau de conteneurs et AGIC

Application Gateway Ingress Controller prend en charge les offres réseau AKS suivantes :

  • Kubenet
  • CNI
  • Superposition CNI

Les superpositions Azure CNI et Azure CNI sont les deux options recommandées pour le contrôleur d’entrée Application Gateway. Lorsque vous choisissez un modèle de mise en réseau, tenez compte des cas d’usage pour chaque plug-in CNI et du type de modèle réseau qu’il utilise :

Plug-in CNI Modèle de mise en réseau Points forts de cas d’usage
Superposition Azure CNI Superposer - Meilleur pour la conservation des adresses IP de réseau virtuel
- Nombre maximal de nœuds pris en charge par le serveur d’API + 250 pods par nœud
- Configuration plus simple
-Aucun accès IP de pod externe direct
Sous-réseau de pod Azure CNI Plat - Accès direct aux pods externes
- Modes de prise en charge efficace de l’adresse IP du réseau virtuel ou de la prise en charge des grandes échelles de cluster
Sous-réseau de nœud Azure CNI Plat - Accès direct aux pods externes
- Configuration plus simple
- Échelle limitée
- Utilisation inefficace des adresses IP de réseau virtuel

Lors de l’approvisionnement d’Application Gateway pour conteneurs dans un cluster sur lequel la superposition CNI ou CNI est activée, Application Gateway pour conteneurs détecte automatiquement la configuration réseau prévue. Aucune modification n’est nécessaire dans la configuration de l’API passerelle ou d’entrée pour spécifier la superposition CNI ou CNI.

Avec la superposition Azure CNI, tenez compte des limitations suivantes :

  • Contrôleur AGIC : vous devez exécuter la version v1.9.1 ou ultérieure pour tirer parti de la superposition CNI.
  • Taille du sous-réseau : le sous-réseau Application Gateway doit être un préfixe /24 maximum ; un seul déploiement est pris en charge par sous-réseau.
  • Délégation de sous-réseau : le sous-réseau Application Gateway doit disposer d’une délégation de sous-réseau pour Microsoft.Network/applicationGateways.
  • Peering de réseaux virtuels régionaux : Application Gateway déployée dans un réseau virtuel dans la région A et les nœuds de cluster AKS d’un réseau virtuel dans la région A n’est pas pris en charge.
  • Peering de réseau virtuel global : Application Gateway déployée dans un réseau virtuel dans la région A et les nœuds de cluster AKS d’un réseau virtuel dans la région B n’est pas prise en charge.
  • Azure CNI Overlay avec le contrôleur d’entrée Application Gateway n’est pas pris en charge dans le cloud Azure Government ou Microsoft Azure géré par 21Vianet (Azure en Chine).

Remarque

La mise à niveau du cluster AKS de Kubenet ou CNI vers CNI Overlay est détectée automatiquement par le contrôleur d'entrée d'Application Gateway. Il est recommandé de planifier la mise à niveau pendant une fenêtre de maintenance, car une interruption du trafic peut se produire. La mise à niveau du contrôleur peut prendre quelques minutes après la mise à niveau du cluster pour détecter et configurer la prise en charge de CNI Overlay.

Avertissement

Vérifiez que le sous-réseau Application Gateway est un sous-réseau /24 ou plus petit avant la mise à niveau. La mise à niveau de CNI vers la superposition CNI avec un sous-réseau plus grand (c’est-à-dire /23) entraîne une panne et nécessite que le sous-réseau Application Gateway soit recréé avec une taille de sous-réseau prise en charge.

Étapes suivantes

  • Last updated on