Unité 3.3 : Équilibrage de charge - Couche 7 (Application)

Introduction

Un équilibreur de charge de couche 7 est le point où le réseau cesse de transférer des paquets et commence à lire les requêtes. C'est la décision que cette unité régit : votre point d'accès doit-il comprendre suffisamment le protocole HTTP (hôtes, chemins, en-têtes, méthodes) pour effectuer du routage sur ces éléments, ou se contente-t-il de répartir les connexions TCP sur un pool ? Le Managed Application Load Balancer (ALB) d'IONOS CLOUD est l'option consciente du contenu, et c'est également le point où la plateforme remplace un produit qu'elle ne commercialise pas, à savoir une passerelle API managée, en exposant des règles de routage à la place. Cette unité commence par cette décision de routage et ses conséquences en matière de certificats et de coûts, puis se termine par la création de l'ALB public qui fait face à la couche applicative de FinCorp dans Data Center Designer, en s'appuyant sur le LAN public établi dans l'Unité 3.1.

1. Quand la couche 7 justifie sa place

Le Managed Application Load Balancer répartit le trafic entrant de la couche application vers les cibles en fonction de politiques définies par l'utilisateur, en fonctionnant à la couche 7 du modèle OSI. Le Network Load Balancer (NLB), abordé dans l'Unité 3.4, fonctionne à la couche 4. Les recommandations officielles tracent une ligne claire : si votre logique d'équilibrage doit traiter des requêtes HTTP et leurs attributs, utilisez l'ALB ; si les performances de routage sont critiques et que la logique peut rester à la couche 4, routez le trafic TCP avec le NLB.

L'ALB justifie sa place lorsque vous routez sur le contenu de la requête plutôt que sur la connexion. Ses règles de transfert prennent en charge le routage basé sur le chemin, le nom d'hôte, la chaîne de requête, les en-têtes, la méthode, les cookies, l'adresse IP source, la redirection d'URL, ainsi que le routage vers une réponse statique ou fixe. Un point d'entrée public unique peut donc envoyer /api vers un groupe de cibles et /static vers un autre, servir deux noms d'hôte depuis une seule adresse IP, ou renvoyer un 503 fixe pendant la maintenance, autant de décisions auxquelles un équilibreur de couche 4 est aveugle. Le compromis est que chaque requête est analysée et correspondue, ce qui explique pourquoi le NLB est réservé aux cas où ce travail est inutile : le trafic chiffré de bout en bout que l'équilibreur ne doit pas déchiffrer, ou tout protocole non-HTTP. L'application réglementée de FinCorp est frontée par HTTP, avec un portail client et une surface API partageant un même nom d'hôte et certificat, de sorte que la couche 7 est le point d'accès approprié ; la couche base de données privée reste à la couche 4. C'est la forme publique-couche 7 vers privée-couche 4 décrite dans l'Unité 1.2.

Trois limites de la plateforme façonnent la manière dont vous sécurisez et dimensionnez l'ALB, et les trois sont des entrées de conception plutôt que des défauts :

• L'ALB ne dispose d'aucune liste blanche d'adresses IP et d'aucun Network Security Group. Comme établi dans l'Unité 3.2, les NSG et les pare-feu de NIC sont liés aux NIC des serveurs uniquement au niveau du VDC et ne s'appliquent pas aux équilibreurs gérés. Le filtrage appartient donc aux cibles : règles de pare-feu sur les NIC en arrière-plan plus logique applicative, avec la couche de données rendue inaccessible par la topologie.
• L'ALB ne fournit pas de NAT source pour les connexions vers les cibles, il ne constitue donc pas un chemin de sortie. Les charges de travail privées accèdent à Internet via la passerelle NAT de l'Unité 3.6.
• L'IPv6 présente des limitations documentées sur l'ALB, il convient donc de traiter l'écouteur public comme un point de terminaison IPv4 sur une adresse IPv4 publique réservée et de planifier toute exposition IPv6 séparément.

Il n'existe pas de produit IONOS CLOUD API Gateway. Le substitut de la plateforme est exactement le mécanisme que cette unité construit : les règles de transfert de l'ALB assurent le routage de contenu grossier (règles de chemin et d'hôte, redirections, réponses fixes) au point d'accès, et un contrôleur d'ingress au sein du cluster assure un routage plus fin, conscient de l'application, à l'intérieur d'un cluster Kubernetes situé derrière. Vous composez le comportement de passerelle API à partir d'un équilibreur géré et d'un ingress au sein du cluster, plutôt que de provisionner un produit de passerelle unique.

2. Les trois composants requis et le coût des règles

Chaque ALB nécessite au moins un écouteur, une règle de transfert et un groupe de cibles. Comprendre le rôle de chaque composant, ainsi que son coût, est essentiel pour maintenir une conception de couche 7 efficace.

Le tableau suivant résume les trois composants et leurs rôles.

L'algorithme d'équilibrage par défaut est Round Robin ; les algorithmes disponibles sont Round Robin, Least Connections, Random et Source IP. L'attribution de poids par cible (un poids compris entre 1 et 256) permet d'influencer la répartition, ce qui constitue le mécanisme d'un canari pondéré en couche 7.

Les composants sont composés hiérarchiquement, et c'est dans cette hiérarchie que la discipline des règles prend tout son sens. Un écouteur contient des règles de transfert ; une règle de transfert contient un ensemble ordonné de règles HTTP ; la requête correspond aux règles dans l'ordre et aboutit à une action par défaut si aucune ne correspond. Il convient donc de placer les règles les plus spécifiques en premier et la règle générale en dernier, avec une action par défaut claire par écouteur (souvent un transfert vers le groupe de cibles principal, ou une réponse fixe).

Maintenez le jeu de règles minimal pour une raison qui va au-delà de la clarté : les règles et les écouteurs constituent la surface gérée de l'ALB, et un ensemble trop étendu représente un risque opérationnel. Un ALB est limité à 10 écouteurs et un contrat à 5 ALBs, de sorte que la ressource est délibérément bornée. La discipline consiste à exprimer le routage avec le minimum de règles correctes, à confier le routage fin à l'ingress intra-cluster où il se situe naturellement, et à réutiliser les groupes de cibles entre les règles plutôt que de les dupliquer.

3. Terminaison TLS et provenance des certificats

L'ALB effectue la déportation TLS : il termine la connexion TLS au niveau de l'écouteur, ce qui permet à la connexion vers l'arrière-plan d'être en HTTP en clair. Il s'agit du schéma standard de la couche 7, et c'est pourquoi le certificat est hébergé sur l'ALB, et non sur les cibles. L'ALB prend également en charge le SNI, de sorte qu'un seul écouteur peut présenter le certificat approprié pour plusieurs noms d'hôte. (Lorsque l'arrière-plan doit conserver le certificat et que l'équilibreur de charge ne doit pas le déchiffrer, il s'agit du cas de la couche 4 décrit dans l'unité 3.4, et non d'une configuration de l'ALB.)

Les contraintes liées aux certificats sont spécifiques et constituent l'aspect le plus susceptible de provoquer l'échec d'une première tentative de provisionnement. Il convient donc de choisir la source du certificat avec soin. L'ALB exige exactement un certificat de feuille (entité finale), et la clé doit être au format RSA. Selon la documentation de juin 2026, les certificats des autorités de certification intermédiaires et racine peuvent être inclus avec le certificat de feuille dans le même fichier, ce qui autorise désormais une chaîne complète. Ce qui est rejeté, c'est la fourniture de certificats d'autorité de certification uniquement, ou de plus d'un certificat de feuille. La clé publique du certificat de feuille doit correspondre à la clé privée fournie, et la clé privée doit être une clé RSA unique au format PKCS#1 (RSA PRIVATE KEY) ou PKCS#8 (PRIVATE KEY).

Le Certificate Manager propose deux chemins, et seul l'un d'entre eux alimente l'ALB. L'ALB n'utilise que les certificats importés : vous téléversez le certificat, la chaîne et la clé privée au format PEM, puis vous associez la ressource résultante à l'écouteur. Le chemin du certificat automatique (ACME), qui effectue le renouvellement automatiquement via un fournisseur tel que Let's Encrypt et qui exige que la zone DNS du domaine soit hébergée dans IONOS Cloud DNS, indique le CDN comme consommateur aval, et non l'ALB. Vous ne pouvez donc pas vous appuyer sur le renouvellement ACME géré pour un écouteur ALB ; vous importez un certificat PEM et vous êtes responsable de sa rotation. Une contrainte en découle : pour un certificat importé, la clé privée est définie à la création et ne peut pas être modifiée. La rotation consiste donc à créer une nouvelle ressource de certificat et à rediriger l'écouteur, et non à modifier la clé sur place. Intégrez cette étape dans le guide de renouvellement. Pour FinCorp, le portail et l'API partagent un même nom d'hôte et un même certificat PEM de feuille RSA importé, terminé au niveau de l'ALB, et le renouvellement consiste en un remplacement planifié dans le calendrier.

Déroulement de la mise en œuvre de DCD

Vous allez construire le point d'entrée public de couche 7 pour la couche applicative de FinCorp : un ALB public sur le LAN de bordure issu de l'Unité 3.1, avec un écouteur HTTPS qui met fin à la session TLS, un groupe de cibles pointant vers les serveurs applicatifs, une règle de transfert basée sur le chemin, et une vérification d'état HTTP. Cela réalise l'extrémité publique de l'architecture en couches et fournit la moitié côté bordure du remplacement par une passerelle API.

Objectif de construction : Construire un équilibreur de charge public de couche 7 avec un écouteur HTTPS, un groupe de cibles, une règle de chemin et une vérification d'état.

Prérequis : Une adresse IPv4 publique réservée depuis la gestion des IP (un ALB public nécessite au moins une IP d'écouteur), la topologie à trois LAN et les serveurs applicatifs de l'Unité 3.1, et un certificat PEM importé dans le Certificate Manager (feuille RSA unique, chaîne facultative, clé privée RSA correspondante) pour l'écouteur HTTPS.

Étapes (dans Data Center Designer) :

1. Créez d'abord le groupe de cibles. Allez dans Menu > Network Services > Target Groups et sélectionnez Create. Donnez-lui un nom et choisissez un algorithme (Round Robin est la valeur par défaut ; Least Connections, Random et Source IP sont les alternatives).
2. Dans le groupe de cibles, ajoutez les cibles dans l'onglet Targets : pour chaque serveur applicatif, saisissez son IP et le port arrière-plan sur lequel le service écoute (l'arrière-plan peut être du HTTP en clair car l'ALB met fin à la session TLS). Définissez un poids par cible (de 1 à 256) si vous souhaitez influencer la distribution, par exemple pour un canari pondéré.
3. Ajoutez la vérification d'état dans l'onglet Connection du groupe de cibles. Pour une vérification HTTP, définissez le Path (valeur par défaut /), la Method et le Match Type (code de statut, ou corps de réponse avec une expression régulière facultative ou une négation). Notez qu'une vérification d'état HTTP ne doit pas être configurée si vous prévoyez d'utiliser le support gRPC ou WebSocket sur ce groupe.
4. Placez l'ALB : dans l'espace de travail du centre de données, faites glisser un Load Balancer de type Application sur la zone de dessin.
5. Connectez ses interfaces : attachez l'interface nord à Internet Access (le bord public) et l'interface sud au LAN de la couche applicative contenant les cibles. Seuls les équilibreurs de charge publics nécessitent une IP publique et une connectivité orientée Internet ; un ALB privé n'a pas besoin d'IP publique.
6. Configurez l'écouteur en HTTPS : assignez l'IP publique réservée comme IP d'écouteur, définissez le port de l'écouteur (443 pour HTTPS) et associez le certificat PEM importé depuis le Certificate Manager afin que l'ALB mette fin à la session TLS sur cet écouteur.
7. Ajoutez la règle de transfert dans l'onglet Forwarding rules : nommez-la, confirmez le protocole, définissez l'IP et le port de l'écouteur, et vérifiez le délai d'attente client (la valeur par défaut documentée est de 50000 ms).
8. Ajoutez les règles HTTP sous la règle de transfert. Ajoutez une règle Forward qui correspond au chemin spécifique (par exemple /api) et pointe vers le groupe de cibles de l'étape 1 ; placez les règles les plus spécifiques en premier. Définissez ensuite une action par défaut (un transfert vers le groupe de cibles principal, ou une réponse fixe Static) pour le trafic qui ne correspond à aucune règle spécifique.
9. Déployez les modifications. L'ALB valide le certificat lors du déploiement, donc un certificat qui n'est pas une feuille RSA unique correspondante échouera ici plutôt que de façon silencieuse.

Erreurs courantes :

• Ne pas réserver l'IP publique d'abord. Un ALB public a besoin d'au moins une IP d'écouteur depuis la gestion des IP avant de pouvoir configurer l'écouteur ; réservez-la avant la construction.
• S'attendre à un renouvellement ACME géré sur l'ALB. L'ALB n'utilise que des certificats PEM importés ; le chemin Auto Certificate (ACME) alimente le CDN, pas l'ALB, donc planifiez la rotation des certificats comme une tâche manuelle, pilotée par le calendrier.
• Oublier que la clé privée importée est immuable. La rotation signifie un nouveau certificat et un réorientement de l'écouteur, jamais une modification de clé sur place.
• Essayer de verrouiller l'ALB avec une liste d'autorisation ou un NSG. L'ALB n'en a aucun ; placez des règles de pare-feu sur les NIC des cibles et fiez-vous à la topologie pour garder la couche de données inaccessible.
• Laisser l'ordre des règles au hasard. Les règles HTTP correspondent dans l'ordre avec une valeur par défaut de repli ; placez les règles spécifiques au-dessus de la règle générale, et définissez exactement une action par défaut claire.
• Configurer une vérification d'état HTTP sur un groupe destiné à gRPC ou WebSocket. La documentation interdit explicitement de les combiner ; choisissez la vérification d'état pour correspondre au protocole du groupe.
• Considérer l'ALB comme un chemin de sortie. Il ne fournit pas de NAT source pour les cibles ; la sortie privée passe par la passerelle NAT de l'Unité 3.6.

Résumé

Le Managed Application Load Balancer est le point d'accès conscient du contenu : choisissez-le lorsque le routage doit lire les hôtes, chemins, en-têtes ou méthodes HTTP, et laissez la simple répartition des connexions au NLB de couche 4. Ses trois composants (écouteur, règle de transfert, groupe de cibles) composent un arbre de routage ordonné, doté d'une action par défaut, que vous devez maintenir volontairement minimal, car les règles et les écouteurs constituent la surface gérée et bornée de la ressource. Le TLS se termine à l'écouteur sur un certificat RSA-leaf PEM importé (le ACME géré ne s'applique pas ici), le filtrage doit être appliqué sur les cibles plutôt que sur un équilibreur qui ne dispose d'aucun NSG ni de liste d'autorisation, et l'ALB ainsi que l'ingress intra-cluster remplacent ensemble la passerelle API que la plateforme ne propose pas.

Points clés :

• Utilisez l'ALB lorsque la logique d'équilibrage doit traiter des attributs HTTP ; utilisez le NLB lorsque le travail peut rester à la couche 4 ou lorsque le chiffrement de bout en bout doit atteindre l'arrière-plan.
• Chaque ALB nécessite au moins un écouteur (de 1 à 10 par ALB), une règle de transfert et un groupe de cibles ; un contrat est limité à 5 ALB.
• L'ALB termine le TLS (déchargement TLS) et prend en charge le SNI ; la connexion vers l'arrière-plan peut être en HTTP en clair.
• Les certificats doivent être une feuille RSA unique au format PEM (une chaîne complète est désormais autorisée, mais un certificat CA seul ou une multi-feuille est rejeté), importé via le Certificate Manager ; l'ALB n'utilise pas le chemin Auto Certificate du ACME géré, et la clé privée importée ne peut pas être modifiée après la création.
• L'ALB ne propose ni liste d'autorisation IP, ni NSG, et ne fournit pas de NAT source ; le filtrage doit être appliqué sur les cibles et le trafic sortant passe par la NAT Gateway.
• Le remplacement de la passerelle API repose sur les règles de chemin et d'hôte de l'ALB au point d'accès, ainsi que sur l'ingress intra-cluster au sein du cluster, le tout maintenu minimal afin de contrôler la surface des règles et des écouteurs.

Terminologie importante :

• Déchargement TLS (termination) : l'ALB déchiffre le TLS à l'écouteur afin de pouvoir lire et router sur la requête HTTP, en transférant vers les arrière-plans en HTTP en clair ; c'est pourquoi le certificat réside sur l'ALB.
• Règle de transfert et règle HTTP : une règle de transfert liée à un écouteur contient un ensemble ordonné de règles HTTP (Forward, Redirect, Static) ; les requêtes sont appariées dans l'ordre et aboutissent à une action par défaut en cas d'absence de correspondance.
• Groupe de cibles : un groupe réutilisable de cibles enregistrées (IP et port) avec un algorithme, des poids par cible et une vérification d'état que l'ALB effectue une fois le groupe lié à une règle de transfert.

Lecture complémentaire

• Unité 3.1 : Topologie et segmentation des VDC (le LAN de bordure et l'IP publique réservée sur lesquels cette configuration dépend)
• Unité 3.2 : Sécurité du réseau : pare-feu et groupes de sécurité (pourquoi le filtrage est lié aux NIC cibles, et non à l'ALB)
• Unité 3.4 : Équilibrage de charge - couche 4 (réseau) (l'équilibreur privé qui complète la structure en couches)
• Unité 6.2 : Provisionnement d'un Cluster public (la moitié d'entrée intra-cluster de la substitution de l'API-gateway)