Lorsque vous exécutez des charges de travail conteneurisées dans des clusters ACK ou ACK Serverless, un équilibrage de charge de couche 7 est nécessaire pour acheminer le trafic HTTP, HTTPS et QUIC externe vers vos services. Les Ingress ALB répondent à ce besoin en intégrant Application Load Balancer (ALB) à l'API Kubernetes Ingress. Le contrôleur d'Ingress ALB traduit les ressources Ingress en configurations ALB, vous offrant ainsi un routage complexe, une découverte automatique des certificats et une compatibilité avec les Ingress NGINX.
Fonctionnement
Le contrôleur d'Ingress ALB s'exécute au sein d'un cluster Kubernetes et surveille les modifications apportées aux ressources AlbConfig, Ingress et Service sur le serveur API. Lorsqu'une modification survient, le contrôleur la traduit en configuration ALB et met à jour l'instance ALB. Pour plus d'informations, consultez la rubrique Contrôleur d'Ingress ALB.
L'architecture de l'Ingress ALB repose sur trois composants :
AlbConfig (CRD) : Configure les instances ALB et les écouteurs. Chaque AlbConfig correspond à une instance ALB unique.
Annotations : Définissent les règles de transfert qui acheminent les requêtes HTTP et HTTPS vers les Services.
Services : Abstraction d'une application backend exécutée sur un ensemble de pods répliqués. Un seul Service peut représenter plusieurs applications backend identiques.
Les Ingress ALB sont compatibles avec les Ingress NGINX. Les annotations prennent également en charge la persistance de session, les déploiements canaris et d'autres fonctionnalités avancées. Pour en savoir plus, consultez les rubriques suivantes :
Clusters ACK : Configurations avancées de l'Ingress ALB
Clusters ACK Serverless : Configurations avancées de l'Ingress ALB
Configuration des Ingress ALB
Les Ingress ALB sont gérés par ACK ou ACK Serverless. Ne configurez pas les Ingress ALB depuis la console ALB, sous peine de provoquer des anomalies de service. Pour connaître les quotas ALB, consultez la rubrique Limites.
Le tableau suivant décrit les étapes de configuration des Ingress ALB dans un cluster ACK ou ACK Serverless.
| Étape | Description |
|---|---|
| Installez le contrôleur d'Ingress ALB | Installez le contrôleur d'Ingress ALB lors de la création du cluster ou depuis la page Add-ons. Pour plus de détails, consultez :
Remarque
Le contrôleur d'Ingress ALB nécessite une version 1.18 ou ultérieure des clusters ACK. Si vous utilisez le plug-in Flannel, les Services backend des Ingress ALB prennent uniquement en charge les types NodePort et LoadBalancer. |
| (Facultatif) Accordez des autorisations d'accès aux clusters ACK dédiés | Pour accéder aux Services via un Ingress ALB dans un cluster ACK dédié, accordez les autorisations requises au contrôleur d'Ingress ALB avant de déployer les Services. |
| Déployez les services backend | Déployez les Services et les Deployments vers lesquels l'Ingress ALB transfère le trafic. Pour plus de détails, consultez :
|
| (Facultatif) Créez un AlbConfig et une IngressClass | Lors de la création du contrôleur d'Ingress ALB, si vous définissez Gateway Source sur New ou Existing, le contrôleur crée automatiquement un AlbConfig nommé alb et une IngressClass nommée alb. Dans ce cas, ignorez cette étape. Sinon, créez un AlbConfig et une IngressClass, puis associez-les. Pour plus de détails, consultez :
|
| Créez un Ingress | Créez une ressource Ingress qui définit les règles de transfert pour acheminer les requêtes vers les Services backend. Associez-la à l'IngressClass et à l'AlbConfig afin que les clients puissent accéder à vos applications Kubernetes via l'instance ALB. Pour plus de détails, consultez :
|
Quand privilégier les Ingress ALB plutôt que les Ingress NGINX
Les Ingress ALB sont gérés 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 une disponibilité de service de 99 995 %. Les Ingress NGINX sont autogérés et nécessitent une mise à l'échelle manuelle. Pour une comparaison détaillée, consultez la rubrique Comparaison entre un Ingress NGINX et un Ingress ALB.
Les Ingress ALB sont mieux adaptés aux scénarios suivants :
Connexions persistantes
Les applications nécessitant des interactions fréquentes, telles que l'IoT, la finance Internet et les jeux en ligne, s'appuient sur des connexions persistantes. Les Ingress ALB appliquent les modifications de configuration par rechargement à chaud sans interrompre ces connexions. En revanche, les Ingress NGINX doivent recharger leurs processus lors des changements de configuration, ce qui ferme temporairement les connexions persistantes.
Concurrence élevée
Les services IoT maintiennent un grand nombre de connexions simultanées provenant d'appareils terminaux. Les Ingress ALB s'exécutent sur la plateforme Cloud Network Management et gèrent les sessions à grande échelle. Chaque instance ALB prend en charge des dizaines de millions de connexions.
QPS élevé
Les activités promotionnelles et les événements d'actualité exigent une capacité QPS élevée. Les Ingress ALB mettent à l'échelle automatiquement et ajoutent 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 de travail. ALB prend en charge la facturation au paiement à l'utilisation basée sur les unités de capacité d'équilibreur de charge (LCU). Moins de LCU sont consommées pendant les heures creuses, et ALB met à l'échelle 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 multimédia, utilisez Distributed Cloud Container Platform for Kubernetes (ACK One) pour créer des passerelles multi-clusters ALB et gérer le trafic multi-clusters avec des Ingress ALB afin de mettre en œuvre une redondance géographique active et une redondance inter-zones active.
Fonctionnalités
Équilibrage de charge et ordonnancement à plusieurs niveaux, jusqu'à un million de QPS par instance
Transfert haute performance grâce à l'accélération matérielle
Mise à l'échelle automatique avec une disponibilité de service de 99 995 %
Routage personnalisable pour les charges de travail complexes