Contrôleur d’entrée Application Gateway pour Azure Kubernetes Service
Aujourd’hui, nous sommes ravis d’offrir une nouvelle solution qui relie Azure Kubernetes Service (AKS) et Application Gateway.
Aujourd’hui, nous sommes ravis d’offrir une nouvelle solution qui relie Azure Kubernetes Service (AKS) et Application Gateway. La nouvelle solution fournit un contrôleur d’entrée Application Gateway (AGIC) open source pour Kubernetes, ce qui permet aux clients AKS de tirer parti d’Application Gateway pour exposer leurs logiciels cloud sur Internet.
Bon nombre de nos clients demandaient une solution combinant les avantages d’Azure Kubernetes Service, notre service Kubernetes managé, qui facilite l’utilisation d’environnements Kubernetes avancés et d’Azure Application Gateway, notre service d’équilibrage de charge L7 natif, scalable et hautement disponible.
Comment cela fonctionne-t-il ?
Le contrôleur d’entrée Application Gateway s’exécute dans son propre pod sur l’AKS du client. Le contrôleur d’entrée supervise les modifications dans un sous-ensemble de ressources Kubernetes. L’état du cluster AKS est converti en configuration propre à l’Application Gateway et appliqué à Azure Resource Manager. La reconfiguration continue d’Application Gateway garantit un flux ininterrompu du trafic vers les services d’AKS. Le schéma ci-dessous illustre le flux des modifications de l’état et de la configuration de l’API Kubernetes, via le contrôleur d’entrée Application Gateway, vers Resource Manager puis Application Gateway.
Comme les contrôleurs d’entrée Kubernetes les plus populaires, le contrôleur d’entrée Application Gateway fournit plusieurs fonctionnalités, tirant parti de l’équilibreur de charge Application Gateway L7 natif d’Azure. Pour n’en nommer que quelques-unes :
- Routage d’URL
- Affinité basée sur les cookies
- Terminaison SSL (Secure Sockets Layer)
- SSL de bout en bout
- Prise en charge des sites web publics, privés et hybrides
- Pare-feu d’applications web basé intégré
L’architecture du contrôleur d’entrée Application Gateway diffère de celle d’un équilibreur de charge L7 classique au sein d’un cluster. Les différences architecturales sont présentées dans ce schéma :
- Un équilibreur de charge au sein d’un cluster effectue toutes les opérations de chemin de données en tirant parti des ressources de calcul du cluster Kubernetes. Il est en concurrence pour les ressources avec les applications métier qu’il précède. Les contrôleurs d’entrée au sein d’un cluster créent des ressources de service Kubernetes et tirent parti de kubenet pour le trafic réseau. En comparaison avec le contrôleur d’entrée, le trafic transite par un tronçon supplémentaire.
- Le contrôleur d’entrée tire parti de la mise en réseau avancée d’AKS, qui alloue une adresse IP pour chaque pod du sous-réseau partagé avec Application Gateway. Application Gateway a un accès direct à tous les pods Kubernetes. Cela élimine le besoin de transférer les données via kubenet. Pour plus d’informations à ce sujet , consultez l’article Concepts relatifs au réseau des applications dans Azure Kubernetes Service, et plus spécifiquement la section sur la comparaison des modèles de réseau.
Performances de la solution
Application Gateway ayant une connectivité directe aux pods Kubernetes, le contrôleur d’entrée Application Gateway peut atteindre une latence du réseau 50 % inférieure à celle des contrôleurs d’entrée situés au sein d’un cluster. Application Gateway est un service managé, soutenu par des groupes de machines virtuelles identiques Azure. Par conséquent, Application Gateway n’utilise pas les ressources de calcul AKS pour le traitement des chemins d’accès aux données. Il ne partage pas ni ne perturbe les ressources allouées au déploiement Kubernetes. La mise à l’échelle automatique Application Gateway aux heures de pointe, contrairement à une entrée au sein du cluster, n’empêche pas la possibilité d’effectuer un scale-up rapide des pods des applications. Et bien sûr, le passage de l’entrée L7 au sein d’un cluster à Application Gateway réduit immédiatement la charge de calcul utilisée par AKS.
Nous avons comparé les performances d’un contrôleur d’entrée au sein d’un cluster et du contrôleur d’entrée Application Gateway sur un cluster AKS à trois nœuds avec une application web simple exécutant 22 pods par nœud. Au total, 66 pods d’applications web partageaient des ressources avec trois entrées au sein d’un cluster : soit une par nœud. Nous avons configuré Application Gateway avec 2 instances. Nous avons utilisé Apache Bench pour créer un total de 100 000 demandes avec accès concurrentiel défini sur 3 000 demandes. Nous avons lancé Apache Bench à deux reprises : une première fois en le faisant pointer vers le SLB qui précède le contrôleur d’entrée au sein du cluster, et une deuxième fois en le connectant à l’adresse IP publique d’Application Gateway. Sur ce cluster AKS très occupé, nous avons enregistré la latence moyenne pour toutes les demandes :
- Application Gateway : 480 ms par demande
- Entrée au sein d’un cluster : 710 ms par demande
Comme l’attestent les données collectées ci-dessus, en cas de charge importante, le contrôleur d’entrée au sein d’un cluster a une latence par requête supérieure d’environ 48 % par rapport à l’entrée Application Gateway. En exécutant le même benchmark sur le même cluster mais avec 2 pods d’applications web par nœud, soit un total de 6 pods, nous avons observé que le contrôleur d’entrée au sein d’un cluster avait une latence supérieure d’environ 17 % par rapport à Application Gateway.
Étapes suivantes
Le contrôleur d’entrée Application Gateway est à présent stable et utilisable dans des environnements de production. Le projet s’affine rapidement et nous travaillons activement à l’ajout de nouvelles fonctionnalités. Nous travaillons à l’amélioration du produit avec les fonctionnalités demandées par les clients, telles que l’utilisation de certificats stockés sur Application Gateway, l’authentification TLS mutuelle, gRPC et HTTP/2. Nous vous invitons à essayer le nouveau contrôleur d’entrée Application Gateway pour AKS, à suivre notre progression et, plus important encore, à nous faire part de vos commentaires sur GitHub.