ALB Ingress s'appuie sur le service Application Load Balancer (ALB) d'Alibaba Cloud. Il offre un point d'entrée unifié pour les services déployés dans un cluster. Contrairement à Nginx Ingress, ALB Ingress est un service entièrement géré : aucune maintenance n'est requise. Le service détecte automatiquement les modifications apportées aux ressources Ingress dans un cluster Kubernetes et répartit le trafic vers les services backend selon des règles prédéfinies. Par ailleurs, ALB Ingress intègre un mécanisme robuste de mise à l'échelle élastique. Il s'adapte automatiquement aux variations dynamiques du trafic, garantissant ainsi la stabilité du système.
Avant de commencer
Pour mieux appréhender les fonctionnalités d'ALB Ingress, lisez cette rubrique avant de mettre en œuvre le service.
Avant de poursuivre, consultez la documentation officielle Kubernetes relative à Ingress afin de maîtriser les concepts fondamentaux d'Ingress et d'Ingress Class.
Fonctionnement d'ALB Ingress
ALB Ingress repose sur les concepts suivants :
ALB Ingress Controller : ce composant gère les ressources Ingress. Il récupère dynamiquement les modifications des ressources Ingress et AlbConfig depuis l'API Server du cluster, puis met à jour les instances ALB en conséquence. Contrairement au contrôleur NGINX Ingress, ALB Ingress Controller agit comme plan de contrôle pour les instances ALB. Il gère ces instances sans traiter directement le trafic utilisateur ; ce dernier est acheminé par les instances ALB elles-mêmes. Le contrôleur surveille en continu les changements des ressources Ingress et ajuste les instances ALB selon les règles de transfert définies.
AlbConfig : il s'agit d'une définition de ressource personnalisée (CRD) au niveau du cluster, créée par ALB Ingress Controller. Chaque AlbConfig contient les paramètres de configuration d'une instance ALB unique. L'instance ALB sert de point d'entrée au trafic et transfère les requêtes vers les services backend. Elle est entièrement gérée par Application Load Balancer (ALB). Contrairement à Nginx Ingress Controller, ALB Ingress ne nécessite aucune opération ni maintenance (O&M) et offre une élasticité supérieure.
IngressClass : cette ressource définit l'association entre un Ingress et un AlbConfig.
Ingress : dans Kubernetes, Ingress est un objet de ressource qui définit les règles de routage et d'accès pour le trafic externe. ALB Ingress Controller surveille les modifications apportées aux ressources Ingress et met à jour les instances ALB pour assurer le transfert du trafic.
Service : dans Kubernetes, les pods sont des ressources éphémères et dynamiques. Un Service fournit un point d'entrée stable et unifié pour les pods ayant la même fonctionnalité. Les autres applications ou services peuvent communiquer avec les pods backend en accédant à l'adresse IP virtuelle (VIP) et au port du Service, sans avoir à suivre les éventuels changements de pods. Pour plus d'informations sur les Services, consultez la rubrique Gestion des services.
Toute modification manuelle de la configuration d'une instance ALB via la console de l'équilibreur de charge risque d'être écrasée par le mécanisme de synchronisation automatique d'ALB Ingress. Cette situation peut entraîner une perte de configuration, voire une indisponibilité de l'instance. Ne modifiez pas directement la configuration des instances ALB gérées par ACK via la console de l'équilibreur de charge, sauf indication contraire de la documentation officielle.
Consultez le schéma ci-dessous pour comprendre la relation logique entre les instances ALB et ALB Ingress :
Flux d'utilisation d'ALB Ingress
Pour mettre en œuvre ce processus, reportez-vous à la rubrique Créer et utiliser ALB Ingress pour exposer des services.
Quand privilégier ALB Ingress plutôt que NGINX Ingress
ALB Ingress est géré par Alibaba Cloud. Chaque instance ALB prend en charge jusqu'à un million de QPS, des dizaines de millions de connexions simultanées, la mise à l'échelle automatique et garantit une disponibilité de service de 99 995 %. NGINX Ingress est auto-géré et nécessite une mise à l'échelle manuelle. Pour une comparaison détaillée, consultez la rubrique Comparaison entre NGINX Ingress et ALB Ingress.
ALB Ingress est particulièrement adapté aux scénarios suivants :
Connexions persistantes
Les applications nécessitant des interactions fréquentes, telles que l'IoT, la finance en ligne et les jeux en ligne, s'appuient sur des connexions persistantes. ALB Ingress applique les modifications de configuration par rechargement à chaud, sans interrompre ces connexions. À l'inverse, NGINX Ingress doit recharger ses processus lors des changements de configuration, ce qui ferme temporairement les connexions persistantes.
Forte concurrence
Les services IoT maintiennent un grand nombre de connexions simultanées depuis des appareils terminaux. ALB Ingress s'exécute sur la plateforme Cloud Network Management et gère les sessions à grande échelle. Chaque instance ALB prend en charge des dizaines de millions de connexions.
QPS élevé
Les campagnes promotionnelles et les événements d'actualité exigent une capacité QPS élevée. ALB Ingress effectue une mise à l'échelle automatique et ajoute des adresses IP virtuelles à mesure que le QPS augmente. Chaque instance ALB prend en charge jusqu'à un million de QPS.
Fluctuations de charge de travail
Les services de commerce électronique et de jeu vidéo connaissent d'importantes fluctuations de charge. ALB propose une facturation au paiement à l'utilisation basée sur les unités de capacité de l'équilibreur de charge (LCU). Moins de LCUs sont consommées pendant les heures creuses, et ALB s'adapte automatiquement sans réservation manuelle des ressources.
Redondance inter-zones et géographique
Pour les applications exigeant une haute disponibilité, telles que les réseaux sociaux et le streaming, utilisez Distributed Cloud Container Platform for Kubernetes (ACK One) afin de créer des passerelles multi-clusters ALB et de gérer le trafic multi-clusters avec ALB Ingress, mettant ainsi en œuvre une redondance géographique active et une redondance inter-zones active.
Régions et zones prises en charge par ALB Ingress
Pour connaître les régions et zones prises en charge par ALB Ingress, consultez la rubrique Régions et zones prises en charge par ALB.
Recommandations pour ALB Ingress dans les clusters à grande échelle
ALB Ingress pilote les modifications de configuration via l'OpenAPI Alibaba Cloud. Dans les scénarios impliquant des clusters de grande taille, de nombreuses instances ALB et un grand nombre de règles Ingress, les opérations telles que la mise à jour des règles de transfert et la synchronisation des groupes de serveurs backend peuvent subir des délais lors d'opérations par lot (création ou suppression massive d'Ingress, mises à niveau rolling de pods à grande échelle ou mises à jour fréquentes des endpoints). Le temps de prise en effet de la configuration dépend du temps de réponse de l'API ALB. Le nombre de ressources configurables est soumis aux limites de quota ALB.
Si vos besoins métier imposent des modifications à grande échelle, effectuez au préalable une évaluation de la capacité et des tests de charge. Planifiez le rythme des changements afin d'éviter toute interruption de service ou anomalie d'accès due à des délais de traitement ou au dépassement des quotas.
Limites d'ALB Ingress
Pour connaître les limites de quota d'ALB Ingress, consultez la rubrique Méthode de calcul des quotas ALB.
Avec Flannel, ALB Ingress ne peut transférer les requêtes que vers des services NodePort et LoadBalancer. Les services ClusterIP ne sont pas pris en charge.
Journal des modifications d'ALB Ingress Controller
Pour consulter l'historique des modifications des fonctionnalités d'ALB Ingress, reportez-vous à la rubrique ALB Ingress Controller.