Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Architecture de référence pour l'équilibrage de charge de couche 7

Cette architecture de référence fournit une solution d'équilibrage de charge de couche 7 gérée par le client dans Google Distributed Cloud (GDC) sous air gap. En déployant des contrôleurs Open Source populaires tels que HAProxy Kubernetes Ingress ou NGINX Gateway Fabric sur un cluster GDC standard, les clients peuvent acheminer de manière transparente le trafic L7 vers des environnements hybrides. Cette architecture utilise la terminaison TLS (Ingress / HTTPRoute) pour acheminer le trafic en fonction de l'indication du nom du serveur (SNI) vers les pods conteneurisés intégrés et les applications hébergées sur des machines virtuelles externes.

Fonctionnalités et capacités

Routage avancé de couche 7 : prend en charge le routage basé sur l'hôte, le routage basé sur le chemin d'accès et la gestion avancée du trafic, comme la correspondance basée sur les en-têtes et la pondération du trafic.
Gestion centralisée des certificats TLS : fournit une gestion et une terminaison TLS centralisées.
Compatibilité avec les environnements hybrides : achemine de manière transparente le trafic L7 vers les pods conteneurisés intégrés et les applications hébergées sur des machines virtuelles externes.
Options de contrôleur flexibles : offre le choix entre NGINX Gateway Fabric moderne (à l'aide de l'API Gateway) ou le contrôleur d'entrée HAProxy bien établi.
Préparation pour l'air gap : intégré à Harbor Registry pour stocker et diffuser des images de proxy et d'application dans des environnements privés et déconnectés.
Répartition complexe du trafic : permet des stratégies avancées de distribution du trafic pour la livraison d'applications modernes.

Principes architecturaux

Modèle d'équilibrage de charge à deux niveaux : cette architecture combine l'équilibreur de charge L4 intégré de GDC (comme point d'entrée) avec une passerelle L7 gérée par le client et déployée dans Kubernetes.
Séparation basée sur les rôles : elle suit une conception qui sépare les responsabilités entre les fournisseurs d’infrastructures, les opérateurs de cluster et les développeurs via des ressources spécifiques (comme GatewayClass, Gateway, et HTTPRoute, ou Ingress).
Transition vers des normes modernes : l'architecture donne la priorité à l'API Gateway pour les fonctionnalités de routage modernes tout en maintenant la compatibilité avec l'ancienne API Ingress lorsque la stabilité de contrôleurs spécifiques est requise.
Flexibilité gérée par le client : en déployant des contrôleurs autogérés, les clients contrôlent les fonctionnalités et la configuration L7 qui ne sont pas fournies de manière native par l'équilibreur L4 géré par GDC.
Abstraction de l'emplacement de la charge de travail : l'architecture traite les charges de travail conteneurisées et basées sur des VM de manière cohérente via des abstractions de service Kubernetes (standard ou sans interface graphique).

Architecture conceptuelle

Diagramme de l'architecture conceptuelle pour l'équilibrage de charge de couche 7 sur GDC sous air gap.

Architecture logique

L'architecture logique se compose de plusieurs composants fonctionnels qui fonctionnent de concert pour acheminer le trafic externe vers des backends internes ou externes :

Point d'entrée Ingress/Gateway : un client lance des requêtes HTTPS qui atteignent d'abord l'équilibreur de charge L4 GDC. Cet équilibreur intégré sert de point d'entrée et distribue le trafic TCP/443 à l'équilibreur de charge L7.
Plan de contrôle : les contrôleurs d'Ingress ou de passerelle (opérateurs HAProxy ou NGINX) surveillent les ressources Kubernetes telles que Ingress, Gateway et HTTPRoute.
Plan de données : en fonction des ressources observées, les contrôleurs mettent à jour de manière dynamique les proxys sous-jacents qui effectuent le routage du trafic réel en fonction des règles de routage d'hôte basées sur SNI et de la terminaison TLS.
Services de backend
- Pods conteneurisés : gérés en tant que déploiements standards et exposés avec des services Kubernetes réguliers.
- VM externes : intégrées au cluster avec un service Kubernetes sans interface graphique et un point de terminaison personnalisé (ou EndpointSlice) contenant l'adresse IP directe de la VM.
Gestion des artefacts : toutes les images des proxys et des applications sont diffusées à partir d'un registre Harbor local pour garantir la fonctionnalité dans un environnement sous air gap.

Concepts et technologies fondamentaux

L'architecture utilise un modèle d'équilibrage de charge à deux niveaux, combinant l'équilibreur de charge L4 intégré de GDC avec une passerelle L7 gérée par le client et déployée dans Kubernetes. Les principaux composants sont les suivants :

Client : entité qui lance des requêtes HTTPS pour interagir avec les applications.
Cluster GDC standard : GDC fournit un moyen intégré de créer des clusters Kubernetes Vanilla. Dans cette solution, le cluster hébergera l'équilibreur de charge L7 et ses contrôleurs, ainsi que les charges de travail et le service sans interface graphique pour les VM externes.
Équilibreur de charge L4 GDC : équilibreur de charge L4 intégré servant de point d'entrée, distribuant le trafic TCP/443 directement aux pods Kubernetes exécutant les contrôleurs d'Ingress ou de passerelle.
Contrôleurs d'entrée et de passerelle : opérateurs HAProxy ou NGINX exécutés dans le cluster standard. Pour Nginx, ils surveillent les ressources de l'API Gateway (comme Gateway et HTTPRoute) et mettent à jour de manière dynamique les proxys sous-jacents. Pour HAProxy, ils surveillent les ressources Ingress et mettent à jour de manière dynamique les proxys sous-jacents.
- Contrôleur d'entrée HAProxy: contrôleur d'entrée pour Kubernetes qui utilise HAProxy comme proxy inverse et équilibreur de charge de couche 7, et qui gère également la terminaison TLS.
- Nginx Gateway Fabric : implémentation de l'API Gateway à l'aide de NGINX comme plan de données.
Entrée et passerelle (avec HTTPRoute) : ressources Kubernetes standardisées définissant le port d'écoute physique (443) et les règles de routage d'hôte basées sur SNI avec terminaison TLS.
Charge de travail conteneurisée (pods) : déploiement Kubernetes standard exposé en interne à l'aide d'un Service Kubernetes régulier.
Charge de travail basée sur une VM (externe) : charge de travail hébergée sur une VM externe sur le réseau du projet, exposée au proxy avec un Service Kubernetes sans interface graphique et un point de terminaison personnalisé contenant l'adresse IP directe de la VM.
Harbor Registry : registre de conteneurs privé utilisé pour stocker et diffuser les images de proxy et d'application dans l'environnement sous air gap.

Comparaison entre les API Ingress et Gateway

Le paysage de la mise en réseau Kubernetes passe de l'API Ingress héritée à l'API Gateway moderne. Il est essentiel de comprendre les différences entre ces deux API pour sélectionner l'architecture adaptée à vos charges de travail.

API Ingress : historiquement, Ingress est la norme pour gérer l'accès externe aux services HTTP. Elle fournit un routage basé sur l'hôte et sur le chemin d'accès, mais sa conception est relativement basique et ne prend pas en charge de manière intégrée la gestion avancée du trafic (par exemple, la correspondance basée sur les en-têtes ou la pondération du trafic) sans s'appuyer sur des annotations spécifiques au fournisseur. Il est important de noter que l'API Ingress est désormais considérée comme gelée par la communauté Kubernetes (limites d'Ingress et évolution de la mise en réseau Kubernetes).
API Gateway : souvent appelée V2 d'Ingress, l'API Gateway est un ensemble de définitions de ressources personnalisées (CRD) qui fournissent un modèle plus robuste et extensible pour la mise en réseau de services. Elle est conçue pour être basée sur les rôles, en séparant les responsabilités entre les fournisseurs d'infrastructures (GatewayClass), les opérateurs de cluster (Gateway) et les développeurs (HTTPRoute/TLSRoute) (API Gateway dans GKE). Cette séparation permet un contrôle plus précis et une meilleure prise en charge de la mutualisation.

Dans cette solution GDC sous air gap, nous avons délibérément choisi différentes API pour les deux contrôleurs présentés :

NGINX (API Gateway) : pour l'implémentation NGINX, nous utilisons NGINX Gateway Fabric, qui est une implémentation mature et intégrée de l'API Gateway. L'utilisation de l'API Gateway pour NGINX permet aux clients de bénéficier des normes modernes et des fonctionnalités de routage avancées (comme HTTPRoute) intégrées à l'API.
HAProxy (API Ingress) : bien que l'API Gateway soit la direction stratégique, nous avons sélectionné l'API Ingress pour HAProxy dans ce guide. En effet, l'intégration de l'API Gateway à HAProxy n'est pas considérée comme mature. En utilisant le contrôleur d'entrée HAProxy bien établi, nous garantissons une solution L7 stable et fiable pour les clients qui préfèrent HAProxy, tout en offrant une voie vers des fonctionnalités L7 modernes.

Hypothèses et contraintes

Hypothèses

Préparation de l'infrastructure : le déploiement suppose la disponibilité de clusters standards GDC sous air gap 1.15.x.
Registre local : il est supposé qu'un registre Harbor local est correctement configuré pour stocker et diffuser des images de proxy et d'application dans l'environnement sous air gap.
Point d'entrée natif : le trafic est supposé atteindre d'abord l'équilibreur de charge L4 GDC intégré, qui distribue ensuite le trafic aux proxys L7.

Contraintes

Solution gérée par le client : il n'existe aucun service L7 géré et couvert par un contrat de niveau de service dans GDC. Cette implémentation est entièrement autogérée par le client.
Clusters standards uniquement : les clusters d'utilisateur partagés ne sont pas concernés en raison des privilèges élevés requis pour le déploiement des contrôleurs d'Ingress et de passerelle.
Maturité de l'API : bien que NGINX utilise l'API Gateway moderne, HAProxy est limité à l'API Ingress, car son intégration à l'API Gateway n'est pas encore considérée comme mature.
Maintenance sous air gap : toutes les images de conteneur doivent être promues et gérées manuellement dans le registre Harbor local.
Éditions communautaires : l'architecture est conçue pour les éditions communautaires Open Source de Nginx et HAProxy. Les éditions Enterprise peuvent fonctionner, mais n'ont pas été explicitement testées.
Propriété opérationnelle : les clients doivent gérer leur propre scaling, leur haute disponibilité et leurs correctifs pour les contrôleurs tiers.
Limites de l'assistance : l'assistance Google ne couvre que l'infrastructure GDC sous-jacente. Les problèmes liés au logiciel HAProxy ou NGINX lui-même sont de la responsabilité du client ou du fournisseur.
Obsolescence de l'API : l'API Ingress (utilisée pour HAProxy) est gelée par la communauté Kubernetes, ce qui peut limiter les futures fonctionnalités de routage.

Licences

Éditions communautaires : l'architecture est conçue pour les éditions communautaires Open Source (généralement Apache 2.0 ou similaire), qui sont sans frais, mais gérées par le client.
Achat d'éditions Enterprise : l'achat et la gestion des licences commerciales, telles que NGINX Plus ou HAProxy Enterprise, sont de la seule responsabilité du client.

Architecture de référence pour l'équilibrage de charge de couche 7 Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.