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) air-gapped. 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 facilement 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 : compatible avec 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 l'en-tête et la pondération du trafic.
  • Gestion centralisée du protocole TLS : fournit une gestion et une terminaison centralisées du protocole TLS.
  • Compatibilité avec les environnements hybrides : achemine de manière fluide 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 : vous pouvez choisir entre le NGINX Gateway Fabric moderne (qui utilise l'API Gateway) ou le contrôleur d'entrée HAProxy bien établi.
  • Préparation à l'air gap : intégration à 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 d'utiliser des stratégies avancées de répartition du trafic pour le déploiement 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 (en tant que 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'infrastructure, 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 de couche 7 qui ne sont pas fournies de manière native par l'équilibreur de couche 4 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 :

  1. 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.
  2. 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.
  3. 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 de l'hôte basées sur l'indication du nom du serveur (SNI) et de la terminaison TLS.
  4. Services de backend :
    • Pods conteneurisés : gérés en tant que déploiements standards et exposés avec des services Kubernetes standards.
    • VM externes : intégrées au cluster avec un service Kubernetes sans adresse IP de cluster et un point de terminaison personnalisé (ou EndpointSlice) contenant l'adresse IP directe de la VM
  5. Gestion des artefacts : toutes les images des proxys et des applications sont diffusées à partir d'un registre Harbor local pour garantir le fonctionnement dans un environnement sous air gap.

Concepts et technologies de base

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. Voici les principaux composants :

  • 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 adresse IP pour les VM externes.
  • Équilibreur de charge L4 GDC : équilibreur de charge L4 intégré servant de point d'entrée, qui distribue le trafic TCP/443 directement aux pods Kubernetes exécutant les contrôleurs Ingress ou Gateway.
  • 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 : mise en œuvre de l'API Gateway utilisant NGINX comme plan de données.
  • Ingress et Gateway (avec HTTPRoute) : ressources Kubernetes standardisées définissant le port d'écoute physique (443) et les règles de routage de l'hôte basées sur le SNI avec terminaison TLS.
  • Charge de travail conteneurisée (pods) : déploiement Kubernetes standard exposé en interne à l'aide d'un Service Kubernetes standard.
  • 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 adresse IP et un point de terminaison personnalisé contenant l'adresse IP directe de la VM.
  • Registre Harbor : registre de conteneurs privé utilisé pour stocker et diffuser les images de proxy et d'application dans l'environnement isolé.

API Ingress et Gateway

Le paysage de la mise en réseau Kubernetes passe de l'ancienne API Ingress à l'API Gateway moderne. Il est essentiel de comprendre les différences entre ces deux types de modèles 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. Il fournit un routage basé sur l'hôte et sur le chemin d'accès, mais sa conception est relativement basique et ne permet pas de gérer le trafic de manière avancée (par exemple, la mise en correspondance basée sur l'en-tête 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 figé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 orientée rôles, en séparant les responsabilités entre les fournisseurs d'infrastructure (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 compatibilité avec l'architecture mutualisée.

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

  • NGINX (API Gateway) : pour l'implémentation de NGINX, nous utilisons NGINX Gateway Fabric, 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 l'orientation stratégique, nous avons sélectionné l'API Ingress pour HAProxy dans ce guide. En effet, l'intégration de l'API Gateway de 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 un moyen d'accéder aux 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 air gap 1.15.x.
  • Registre local : nous partons du principe 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 le distribue ensuite aux proxys L7.

Contraintes

  • Solution gérée par le client : il n'existe pas de service L7 géré et couvert par un SLA dans GDC. Cette implémentation est entièrement gérée par le client.
  • Clusters standards uniquement : les clusters d'utilisateurs partagés ne sont pas concernés en raison des droits élevés requis pour le déploiement d'Ingress et du contrôleur de passerelle.
  • Maturité de l'API : alors que NGINX utilise l'API Gateway moderne, HAProxy est limité à l'API Ingress, car son intégration de l'API Gateway n'est pas encore considérée comme mature.
  • Maintenance sous air gap : toutes les images de conteneurs doivent être promues et gérées manuellement dans le registre Harbor local.
  • Éditions Community : l'architecture est conçue pour les éditions Open Source Community de Nginx et HAProxy. Les éditions Enterprise peuvent fonctionner, mais n'ont pas été explicitement testées.
  • Responsabilité opérationnelle : les clients doivent gérer eux-mêmes le scaling, la haute disponibilité et l'application de correctifs pour les contrôleurs tiers.
  • Limite 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 relèvent de la responsabilité du client ou du fournisseur.
  • Obsolescence de l'API : l'API Ingress (utilisée pour HAProxy) est figée par la communauté Kubernetes, ce qui peut limiter les futures fonctionnalités de routage.

Licences

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

Autres ressources