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 de votre part. Le système 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, nous vous recommandons de lire cette rubrique avant de mettre en œuvre la solution.
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 clés suivants :
ALB Ingress Controller : ce composant gère les ressources Ingress. Il interroge dynamiquement le API Server du cluster pour détecter les modifications apportées aux ressources Ingress et AlbConfig, puis met à jour les instances ALB en conséquence. À la différence du contrôleur NGINX Ingress, ALB Ingress Controller agit uniquement comme plan de contrôle pour les instances ALB : il les administre sans traiter directement le trafic utilisateur. Ce dernier est acheminé par les instances ALB elles-mêmes. Le contrôleur récupère les changements des ressources Ingress depuis l'API Server et actualise 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 regroupe les paramètres de configuration d'une instance ALB unique. L'instance ALB sert de point d'entrée au trafic et transmet les requêtes aux services backend. Elle est entièrement gérée par Application Load Balancer (ALB). Contrairement au contrôleur Nginx Ingress, 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 entrant. ALB Ingress Controller surveille les modifications apportées aux ressources Ingress et met à jour les instances ALB pour assurer le transfert du trafic.
Service : les pods Kubernetes étant des ressources temporaires et dynamiques, un Service fournit un point d'entrée stable et unifié pour les pods offrant les mêmes fonctionnalités. Les autres applications ou services communiquent avec les pods backend en adressant leurs requêtes à 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 d'équilibrage 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 d'équilibrage de charge, sauf indication contraire de la documentation officielle.
Le schéma ci-dessous illustre la relation logique entre les instances ALB et ALB Ingress :
Flux d'utilisation d'ALB Ingress
Pour réaliser les étapes décrites ci-dessus, 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 un service managé par Alibaba Cloud. Chaque instance ALB prend en charge jusqu'à un million de QPS, des dizaines de millions de connexions simultanées, une mise à l'échelle automatique et garantit une disponibilité de service de 99,995 %. NGINX Ingress doit être géré manuellement et nécessite une mise à l'échelle explicite. Pour une comparaison détaillée, consultez la rubrique Comparaison entre NGINX Ingress et ALB Ingress.
ALB Ingress constitue la solution idéale dans les scénarios suivants :
Connexions persistantes
Les applications nécessitant des interactions fréquentes, telles que l'IoT, la finance en ligne ou les jeux vidéo, 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 provenant d'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.
Débit QPS élevé
Les campagnes promotionnelles et les événements d'actualité exigent une capacité QPS importante. 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
Les services de commerce électronique et de jeux vidéo connaissent d'importantes fluctuations de charge. ALB propose une facturation à l'utilisation basée sur les unités de capacité d'équilibreur de charge (LCU). Moins de LCUs sont consommées pendant les heures creuses, et ALB s'adapte automatiquement sans réservation manuelle de ressources.
Redondance géographique et inter-zones
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. Cette approche permet de mettre en œuvre une redondance géographique active et une redondance inter-zones active.
Régions et zones prises en charge par ALB Ingress
Pour consulter la liste des régions et zones compatibles avec ALB Ingress, reportez-vous à 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 environnements comportant de grands clusters, de nombreuses instances ALB et un volume élevé de règles Ingress, certaines opérations — telles que la mise à jour des règles de transfert ou la synchronisation des groupes de serveurs backend — peuvent subir des délais lors d'actions groupées (création ou suppression massive d'Ingress, rolling upgrades de pods à grande échelle, mises à jour fréquentes des endpoints). Le temps de prise en compte 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, réalisez préalablement 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 liée à 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 qu'à destination 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 évolutions fonctionnelles d'ALB Ingress, reportez-vous à la rubrique ALB Ingress Controller.