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

Introduction

Un équilibreur de charge de niveau 7 est le point où le réseau cesse de déplacer des paquets et commence à lire des requêtes. C'est la décision que cette unité régit : si votre edge doit comprendre HTTP (hôtes, chemins, en-têtes, méthodes) suffisamment bien pour acheminer les requêtes en fonction de ceux-ci, ou si celui-ci n'a besoin que de répartir les connexions TCP sur un pool. L'IONOS Managed Application Load Balancer (ALB) est l'option consciente du contenu, et c'est également là que la plateforme se substitue à un produit qu'elle ne vend pas, un API Gateway géré, en exposant des règles d'acheminement au lieu de cela. Cette unité commence à cette décision d'acheminement et de ses conséquences en matière de certificat et de coût, puis se termine par la construction de l'ALB public qui fait face au niveau d'application de FinCorp dans le Data Center Designer, situé sur le bord public LAN établi dans l'unité 3.1.

1. Lorsque la couche 7 gagne sa place

Le Managed Application Load Balancer distribue le trafic entrant de la couche application à des cibles en fonction de stratégies définies par l'utilisateur, en fonctionnant à la couche 7 du modèle OSI. Le Network Load Balancer (NLB), couvert dans l'unité 3.4, fonctionne à la couche 4. Les directives officielles dessinent une ligne nette : si votre logique d'équilibrage a besoin de traiter les 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 gagne 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, l'en-tête, la méthode, le cookie, la source IP, la redirection d'URL et le routage statique ou à réponse fixe. Un point d'entrée public peut donc envoyer /api à un groupe de cibles et /static à un autre, servir deux noms d'hôte à partir d'un IP, ou renvoyer une réponse fixe 503 pendant la maintenance, toutes des décisions dont un équilibreur de charge de la couche 4 est aveugle. Le compromis est que chaque requête est analysée et mise en correspondance, c'est pourquoi le NLB est réservé aux cas où ce travail est inutile : trafic chiffré de bout en bout que l'équilibreur ne devrait pas déchiffrer, ou tout protocole non HTTP. L'application réglementée de FinCorp est HTTP-fronted, avec un portail client et une surface API partageant un nom d'hôte et un certificat, donc la couche 7 est le bord correct ; le niveau de base de données privée reste à la couche 4. Il s'agit de la forme publique-L7-privée-L4 de l'unité 1.2.

Trois limites de plateforme déterminent 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 n'a pas de liste de IP autorisés et pas de groupe de sécurité réseau. Comme établi dans l'unité 3.2, les NSG et les pare-feu NIC sont liés aux NIC de serveur au niveau du VDC uniquement et ne s'appliquent pas aux équilibreurs gérés. Le filtrage appartient donc aux cibles : règles de pare-feu sur les NIC de backend plus logique d'application, avec le niveau de données maintenu inaccessible par la topologie.
• L'ALB ne fournit pas de source NAT pour les connexions cibles, il n'est donc pas un chemin de sortie. Les charges de travail privées atteignent Internet via la passerelle NAT de l'unité 3.6.
• IPv6 a des limitations documentées sur l'ALB, il faut donc traiter l'écouteur public comme un point de terminaison IPv4 sur une adresse IPv4 publique réservée et planifier toute exposition IPv6 séparément.

Il n'y a pas de produit IONOS API Gateway. Le substitut de la plateforme est exactement le mécanisme que cette unité construit : les règles de transfert ALB transportent un routage de contenu grossier (règles de chemin et d'hôte, redirections, réponses fixes) au bord, et un contrôleur d'entrée dans Cluster transporte un routage plus fin et plus conscient de l'application à l'intérieur d'un Kubernetes Cluster derrière lui. Vous composez le comportement de la passerelle API à partir d'un équilibreur géré plus d'entrée dans Cluster plutôt que de configurer 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 cible. Comprendre ce que fait chaque composant et ce que chaque composant coûte est ce qui permet de maintenir une conception Layer 7 élégante.

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. Le pondérage par cible (un poids compris entre 1 et 256) vous permet de biaiser la distribution, ce qui est le mécanisme pour un canari pondéré à Layer 7.

Les composants se composent de manière hiérarchique, et c'est là que la discipline des règles compte. Un écouteur contient des règles de transfert ; une règle de transfert contient un ensemble ordonné de règles HTTP ; la demande correspond aux règles dans l'ordre et tombe dans une action par défaut lorsqu'aucune ne correspond. Vous placez donc les règles les plus spécifiques en premier et les règles de catch-all en dernier, avec une action par défaut claire par écouteur (souvent un transfert vers le groupe cible principal, ou une réponse fixe).

Gardez l'ensemble de règles élégant pour une raison au-delà de la clarté : les règles et les écouteurs sont la surface gérée de l'ALB, et un ensemble éparpillé est une responsabilité opérationnelle. Un ALB est limité à 10 écouteurs et un contrat à 5 ALB, donc la ressource est délibérément limitée. La discipline consiste à exprimer l'acheminement avec le moins de règles correctes, à pousser l'acheminement détaillé dans l'entrée in-Cluster où il appartient, et à réutiliser les groupes cible à travers les règles plutôt que de les dupliquer.

3. TLS Termination et sourcing de certificats

L'ALB effectue le déchargement de TLS : il met fin à TLS à l'écouteur afin que la connexion back-end puisse être en texte brut HTTP. Il s'agit du modèle normal de la couche 7 et c'est pourquoi le certificat est situé sur l'ALB, et non sur les cibles. L'ALB prend également en charge le SNI, donc un écouteur peut présenter le certificat approprié pour plusieurs noms d'hôte. (Lorsque le back-end doit conserver le certificat et que l'équilibrage de charge ne doit pas déchiffrer, il s'agit du cas de la couche 4 dans l'unité 3.4, et non d'une configuration ALB.)

Les contraintes de certificat sont spécifiques et constituent la partie la plus susceptible de faire échouer une première tentative de provisionnement, donc sourcez le certificat de manière délibérée. L'ALB nécessite exactement un certificat feuille (entité finale) et la clé doit être RSA. À partir de la documentation 2026-06, les certificats CA intermédiaires et Root peuvent être inclus aux côtés de la feuille dans le même fichier, donc une chaîne complète est maintenant autorisée ; ce qui est rejeté, c'est la fourniture de certificats CA uniquement, ou plus d'une feuille. La clé publique de la 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 offre deux chemins, et seul l'un d'entre eux alimente l'ALB. L'ALB consomme uniquement des certificats importés : vous téléchargez le certificat, la chaîne et la clé privée au format PEM, et attachez la ressource résultante à l'écouteur. Le chemin Auto Certificate (ACME), qui se renouvelle automatiquement via un fournisseur tel que Let's Encrypt et nécessite que la zone DNS du domaine soit hébergée dans IONOS Cloud DNS, répertorie CDN comme consommateur en aval, et non l'ALB. Vous ne pouvez donc pas vous appuyer sur la rénovation gérée ACME pour un écouteur ALB ; vous importez un certificat PEM et gérez sa rotation. Une contrainte suit : sur un certificat importé, la clé privée est définie lors de la création et ne peut pas être modifiée, donc la rotation signifie la création d'une nouvelle ressource de certificat et la redirection de l'écouteur, et non l'édition de la clé en place. Intégrez cela dans le livre de renouvellement. Pour FinCorp, le portail et API partagent un nom d'hôte et un certificat PEM à feuille RSA importé terminé à l'ALB, et le renouvellement est un échange calendrier.

DCD Marche à suivre pour la mise en œuvre

Vous allez créer le point d'entrée public de niveau 7 pour le niveau d'application de FinCorp : un ALB public sur le bord LAN de l'unité 3.1, avec un écouteur HTTPS qui met fin à TLS, un groupe cible pointant vers les serveurs d'application, une règle de transfert basée sur le chemin, et une vérification de l'état HTTP. Cela réalise l'extrémité publique de l'architecture en couches et donne à la substitution de passerelle API sa moitié d'extrémité.

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

Prérequis : Une adresse publique IPv4 réservée de IP Management (un ALB public nécessite au moins un écouteur IP), la topologie à trois LAN et les serveurs d'application 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 le Data Center Designer) :

1. Créez d'abord le groupe cible. Allez dans Menu > Services réseau > Groupes cibles et sélectionnez Créer. 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 cible, ajoutez des cibles dans l'onglet Cibles : pour chaque serveur d'application, entrez son IP et le port de backend que le service écoute (le backend peut être du texte HTTP car l'ALB met fin à TLS). Définissez un poids par cible (1 à 256) si vous souhaitez biaiser la distribution, par exemple pour un canari pondéré.
3. Ajoutez la vérification de l'état dans l'onglet Connexion du groupe cible. Pour une vérification HTTP, définissez le chemin (valeur par défaut /), la méthode, et le type de correspondance (code d'état, ou corps de réponse avec une expression régulière facultative ou une négation). Notez qu'une vérification de l'état HTTP ne doit pas être configurée si vous avez l'intention 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 le canevas.
5. Connectez ses interfaces : attachez l'interface nord à l'accès Internet (le bord public) et l'interface sud au LAN du niveau d'application qui contient les cibles. Seuls les équilibreurs de charge publics nécessitent une adresse IP publique et une connectivité orientée vers Internet ; un ALB privé n'a pas besoin d'adresse IP publique.
6. Configurez l'écouteur comme HTTPS : attribuez l'adresse IP publique réservée comme adresse IP de l'écouteur, définissez le port de l'écouteur (443 pour HTTPS), et associez le certificat PEM importé de Certificate Manager afin que l'ALB mette fin à TLS à cet écouteur.
7. Ajoutez la règle de transfert dans l'onglet Règles de transfert : nommez-la, confirmez le protocole, définissez l'adresse IP de l'écouteur et le port, et examinez le délai d'expiration du 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 de transfert qui correspond au chemin spécifique (par exemple /api) et pointe vers le groupe cible de l'étape 1 ; ordonnez les règles les plus spécifiques en premier. Ensuite, définissez une action par défaut (un transfert vers le groupe cible principal, ou une réponse fixe statique) pour le trafic qui ne correspond à aucune règle spécifique.
9. Mettez en œuvre les modifications. L'ALB valide le certificat lors de la mise en œuvre, donc un certificat qui n'est pas une feuille RSA unique correspondante échouera ici plutôt que de se produire silencieusement.

Erreurs courantes :

• Ne pas réserver l'adresse IP publique en premier. Un ALB public nécessite au moins un écouteur IP de IP Management avant de pouvoir configurer l'écouteur ; réservez-le à l'avance.
• S'attendre à une renouvellement géré ACME sur l'ALB. L'ALB consomme uniquement des certificats PEM importés ; le chemin Auto Certificate (ACME) alimente CDN, et non l'ALB, donc planifiez la rotation des certificats comme une tâche manuelle et basée sur le calendrier.
• Oublier que la clé privée importée est immuable. La rotation signifie une nouvelle ressource de certificat et une réorientation de l'écouteur, et non une édition de clé sur place.
• Essayer de verrouiller l'ALB avec une liste d'autorisation ou un NSG. L'ALB n'en a pas ; placez des règles de pare-feu sur les cartes réseau cibles et comptez sur la topologie pour garder le niveau 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 transfert ; placez les règles spécifiques au-dessus de la règle de transfert par défaut, et définissez exactement une action par défaut claire.
• Configurer une vérification de l'état HTTP sur un groupe destiné à gRPC ou WebSocket. Les documents interdisent explicitement de les combiner ; choisissez la vérification de l'état pour correspondre au protocole du groupe.
• Traiter l'ALB comme un chemin de sortie. Il ne fournit pas de source NAT pour les cibles ; la sortie privée se fait via la passerelle NAT de l'unité 3.6.

Résumé

Le Managed Application Load Balancer est le bord conscient du contenu : choisissez-le lorsque le routage doit lire les hôtes HTTP, les chemins, les en-têtes ou les méthodes, et laissez la propagation de connexion pure au NLB de la couche 4. Ses trois composants (écouteur, règle de transfert, groupe cible) se composent en un arbre de routage ordonné, avec une valeur par défaut, que vous maintenez délibérément léger, car les règles et les écouteurs sont la surface gérée et limitée de la ressource. Le TLS se termine à l'écouteur sur un certificat PEM RSA-feuille importé (le gestionnaire ACME géré ne s'applique pas ici), le filtrage appartient aux cibles plutôt qu'à un équilibrage de charge qui n'a pas de groupe de sécurité réseau (NSG) ou de liste d'autorisation, et l'ALB plus l'entrée Cluster ensemble remplacent le API Gateway que la plateforme ne vend pas.

Points clés :

• Utilisez l'ALB lorsque la logique d'équilibrage doit traiter les attributs HTTP ; utilisez le NLB lorsque le travail peut rester à la couche 4 ou lorsque le chiffrement de bout en bout doit atteindre le backend.
• Chaque ALB a besoin d'au moins un écouteur (1 à 10 par ALB), d'une règle de transfert et d'un groupe cible ; un contrat est limité à 5 ALB.
• L'ALB termine le TLS (déchargement du TLS) et prend en charge le SNI ; la connexion backend peut être du texte HTTP non chiffré.
• Les certificats doivent être une feuille RSA unique en PEM (une chaîne complète est maintenant autorisée, la chaîne CA-seulement ou multi-feuille est rejetée), importée via le Certificate Manager ; l'ALB ne consomme pas le chemin de certificat Auto géré ACME, et la clé privée importée ne peut pas être modifiée après sa création.
• L'ALB n'a pas de liste d'autorisation IP et n'a pas de groupe de sécurité réseau (NSG), et ne fournit pas de source NAT ; le filtrage appartient aux cibles et la sortie se fait par la passerelle NAT.
• Le remplacement de la passerelle API est constitué des règles de chemin et d'hôte ALB au bord, ainsi que de l'entrée Cluster à l'intérieur du Cluster, maintenue légère pour contrôler la surface des règles et des écouteurs.

Terminologie importante :

• Déchargement (termination) du TLS : l'ALB déchiffre le TLS à l'écouteur afin de pouvoir lire et router la demande HTTP, en transférant vers les backends sur le HTTP non chiffré ; c'est pourquoi le certificat vit 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 (Transfert, Redirection, Statique) ; les demandes correspondent dans l'ordre et tombent dans une action par défaut.
• Groupe cible : un groupe réutilisable de cibles enregistrées (IP plus port) avec un algorithme, des poids par cible, et un contrôle de santé que l'ALB effectue une fois le groupe lié à une règle de transfert.

Lecture supplémentaire

• Unité 3.1 : Topologie et segmentation du centre de données virtuel (le LAN de bord et les adresses IP publiques réservées IP sur lesquelles cette construction dépend)
• Unité 3.2 : Sécurité du réseau : pare-feu et groupes de sécurité (pourquoi le filtrage est lié aux NICs cibles, et non à l'ALB)
• Unité 3.4 : Équilibrage de charge - Couche 4 (Réseau) (l'équilibreur de charge privé qui complète la forme en couches)
• Unité 6.2 : Provisionnement d'un Cluster public (la moitié d'entrée dans le Cluster de la substitution de passerelle API)