Gérer les équilibreurs de charge

Cette page de présentation explique comment configurer des équilibreurs de charge internes et externes dans Google Distributed Cloud (GDC) air-gapped pour les configurations réseau zonales et mondiales.

L'équilibrage de charge pour GDC assure une distribution efficace du trafic entre les charges de travail de backend, ce qui améliore la disponibilité et les performances des applications. L'algorithme utilisé pour répartir le trafic est Maglev. Pour en savoir plus, consultez Algorithme d'équilibrage de charge.

Cette page s'adresse aux administrateurs réseau du groupe d'administrateurs de plate-forme ou aux développeurs du groupe d'opérateurs d'applications, qui sont chargés de gérer le trafic réseau de leur organisation. Pour en savoir plus, consultez Audiences pour la documentation GDC sous air gap.

Architecture d'équilibrage de charge

GDC fournit des équilibreurs de charge qui permettent aux applications d'exposer des services les unes aux autres. Les équilibreurs de charge attribuent une adresse IP virtuelle (VIP) stable qui équilibre le trafic sur un ensemble de charges de travail de backend. Les équilibreurs de charge dans GDC effectuent un équilibrage de charge de couche 4 (L4), ce qui signifie qu'ils mappent un ensemble de ports TCP ou UDP de frontend configurés aux ports de backend correspondants. Les équilibreurs de charge sont configurés au niveau du projet.

Les équilibreurs de charge sont configurés pour les types de charges de travail suivants :

• Charges de travail exécutées sur des VM.
• Charges de travail conteneurisées dans le cluster Kubernetes.

Il existe trois façons de configurer des équilibreurs de charge dans GDC :

• Utilisez l'API Networking Kubernetes Resource Model (KRM). Vous pouvez utiliser cette API pour créer des équilibreurs de charge globaux ou zonaux.
• Utilisez la CLI gdcloud. Vous pouvez utiliser cette API pour créer des équilibreurs de charge globaux ou zonaux.
• Utilisez le service Kubernetes directement depuis le cluster Kubernetes. Cette méthode ne crée que des équilibreurs de charge zonaux.

Remarque : Le service Kubernetes est la seule méthode acceptée pour configurer des équilibreurs de charge pour les clusters standards.

Composants de l'équilibreur de charge

Lorsque vous utilisez l'API KRM ou la CLI gdcloud pour configurer l'équilibreur de charge, vous utilisez un équilibreur de charge de transfert L4 :

• L4 signifie que le protocole est TCP ou UDP.
• Passthrough signifie qu'il n'y a pas de proxy entre la charge de travail et le client.

L'équilibreur de charge se compose des éléments configurables suivants :

• Règles de transfert : spécifiez le trafic à transférer et le service de backend vers lequel le transférer. Les règles de transfert présentent les spécifications suivantes :

  • Il se compose de trois tuples (CIDR, port et protocole) pour l'accès client.
  • Compatible avec les protocoles TCP et UDP.
  • Propose des règles de transfert internes et externes. Les clients peuvent accéder aux règles de transfert internes depuis le cloud privé virtuel (VPC). Les clients peuvent accéder aux règles de transfert externes depuis l'extérieur de la plate-forme GDC ou depuis l'intérieur par des charges de travail dont la valeur EgressNAT est définie.
  • Les règles de transfert se connectent à un service de backend. Vous pouvez faire pointer plusieurs règles de transfert vers le même service de backend.

• Les services de backend sont le centre d'équilibrage de charge qui relie les règles de transfert, les vérifications de l'état et les backends. Un service de backend fait référence à un objet de backend qui identifie les charges de travail vers lesquelles l'équilibreur de charge transfère le trafic. Il existe des limites concernant les backends auxquels un même service de backend peut faire référence :

  • Une ressource de backend zonal par zone.
  • Une ressource de backend de cluster par cluster. Il ne peut pas être mélangé aux backends du projet.

• Backends : objet zonal qui spécifie les points de terminaison servant de backends pour les services de backend créés. Les ressources de backend doivent être limitées à une zone. Sélectionnez des points de terminaison à l'aide de libellés. Définissez le champ d'application du sélecteur sur un projet ou un cluster :

  • Un backend de projet est un backend dont le champ ClusterName n'est pas spécifié. Dans ce cas, les libellés spécifiés s'appliquent à toutes les charges de travail du projet spécifique, dans le VPC spécifique d'une zone. Les libellés sont appliqués aux charges de travail des VM et des pods sur plusieurs clusters. Lorsqu'un service de backend utilise un backend de projet, vous ne pouvez pas référencer un autre backend pour cette zone dans ce service de backend.

  • Un backend de cluster est un backend dont le champ ClusterName est spécifié. Dans ce cas, les libellés spécifiés s'appliquent à toutes les charges de travail du cluster nommé dans le projet spécifié. Vous pouvez spécifier au maximum un backend par zone et par cluster dans un même service de backend.

• Vérifications de l'état : spécifiez les sondes permettant de déterminer si un point de terminaison de charge de travail donné dans le backend est opérationnel. Le point de terminaison non opérationnel est retiré de l'équilibreur de charge jusqu'à ce qu'il redevienne opérationnel. Les vérifications de l'état ne s'appliquent qu'aux charges de travail de VM. Les charges de travail des pods peuvent utiliser le mécanisme de vérification Kubernetes intégré pour déterminer si un point de terminaison spécifique est sain. Pour en savoir plus, consultez la section Vérifications d'état.

Lorsque vous utilisez le service Kubernetes directement à partir du cluster d'utilisateur Kubernetes, vous utilisez l'objet Service au lieu des composants listés précédemment. Vous ne pouvez cibler que les charges de travail du cluster dans lequel l'objet Service est créé.

Équilibrage de charge externe et interne

Les applications GDC ont accès aux types de services réseau suivants :

• Équilibreur de charge interne (ILB) : vous permet d'exposer un service à d'autres clusters de l'organisation.
• Équilibreur de charge externe (ELB) : alloue une adresse IP virtuelle (VIP) à partir d'une plage routable à partir de charges de travail externes et expose les services en dehors de l'organisation GDC, tels que d'autres organisations à l'intérieur ou à l'extérieur de l'instance GDC. Utilisez l'affinité de session pour les équilibreurs de charge ELB afin de vous assurer que les requêtes d'un client sont systématiquement acheminées vers le même backend.

Équilibreurs de charge globaux et zonaux

Vous pouvez créer des équilibreurs de charge globaux ou zonaux. Le champ d'application des équilibreurs de charge mondiaux s'étend à un univers GDC. Chaque univers GDC peut être constitué de plusieurs zones GDC organisées en régions interconnectées et partageant un plan de contrôle. Par exemple, un univers composé de deux régions avec trois zones chacune peut se présenter comme suit : us-virginia1-a, us-virginia1-b, us-virginia1-c et eu-ams1-a, eu-ams1-b, eu-ams1-c.

Le champ d'application des équilibreurs de charge zonaux est limité aux zones spécifiées au moment de la création. Chaque zone est un domaine de reprise après sinistre indépendant. Une zone gère l'infrastructure, les services, les API et les outils qui utilisent un plan de contrôle local.

Pour en savoir plus sur les ressources globales et zonales dans un univers GDC, consultez Présentation multizone.

Vous pouvez créer des équilibreurs de charge mondiaux à l'aide des méthodes suivantes :

• Utilisez l'API Networking Kubernetes Resource Model (KRM). Utilisez la version networking.global.gdc.goog de l'API pour créer des ressources globales.
• Utilisez la CLI gdcloud. Utilisez l'indicateur --global lorsque vous utilisez les commandes gdcloud CLI pour spécifier un champ d'application global.

Vous pouvez créer des équilibreurs de charge zonaux à l'aide des méthodes suivantes :

• Utilisez l'API Networking Kubernetes Resource Model (KRM). Utilisez la version networking.gdc.goog de l'API pour créer des ressources zonales.
• Utilisez la CLI gdcloud. Utilisez l'indicateur --zone lorsque vous utilisez les commandes gdcloud CLI pour spécifier les zones pour lesquelles créer des équilibreurs de charge.
• Utilisez le Service Kubernetes directement depuis le cluster Kubernetes.

Adresses IP virtuelles de service

Les équilibreurs de charge internes attribuent des adresses IP virtuelles qui sont internes à l'organisation uniquement. Ces adresses IP virtuelles ne sont pas accessibles en dehors de l'organisation. Vous ne pouvez donc les utiliser que pour exposer des services à d'autres applications au sein d'une organisation. Ces adresses IP peuvent se chevaucher entre les organisations d'une même instance.

En revanche, les équilibreurs de charge ELB allouent des adresses IP virtuelles accessibles en externe depuis l'extérieur de l'organisation. C'est pourquoi les adresses VIP ELB doivent être uniques pour toutes les organisations. En général, moins d'adresses VIP ELB sont disponibles pour l'organisation.

Algorithme d'équilibrage de charge

Notre équilibreur de charge utilise Maglev, un algorithme de hachage cohérent, pour distribuer le trafic entrant vers les cibles de backend. Cet algorithme est conçu pour offrir des performances et une résilience élevées. Il permet de répartir le trafic de manière uniforme et prévisible, tout en maximisant la localité des données dans les backends.

Fonctionnement de Maglev : le mécanisme de hachage

Maglev prend des décisions de transfert en hachant les propriétés de chaque paquet entrant. Cela garantit que tous les paquets d'une connexion donnée sont systématiquement envoyés au même backend pour maximiser la localité des données.

• Entrée de hachage (5-tuple) : l'algorithme utilise un 5-tuple standard de l'en-tête du paquet pour générer un hachage. Ce tuple se compose des éléments suivants :
  1. Adresse IP source
  2. Port source
  3. Adresse IP de destination
  4. Port de destination
  5. Protocole (par exemple, TCP, UDP)
• Décision de transfert : le résultat de ce hachage mappe de manière déterministe la connexion à l'un des backends opérationnels du pool d'équilibrage de charge. Pendant toute la durée de vie de cette connexion, tous ses paquets seront transférés vers le même backend.
• Entropie pour l'équilibrage : en utilisant les cinq éléments du tuple, Maglev génère suffisamment d'entropie pour s'assurer que les différentes connexions sont réparties de manière égale sur tous les backends disponibles.

Gérer l'état et les défaillances du backend

Maglev est conçu pour être résilient et minimiser les perturbations lorsque l'ensemble des backends disponibles change.

• Échec du backend : lorsqu'un backend échoue à ses vérifications de l'état, il est supprimé de la liste des cibles disponibles. Les connexions qui étaient auparavant acheminées vers le backend défaillant sont interrompues. Les nouvelles connexions seront automatiquement redistribuées entre les backends opérationnels restants en fonction de l'algorithme de hachage. Il est important de noter que les connexions à d'autres backends opérationnels ne sont pas affectées ni redirigées.
• Récupération du backend : lorsque le backend non opérationnel redevient opérationnel et est ajouté au pool, la nature cohérente du hachage garantit que ce backend est ajouté au pool avec un minimum de perturbations. L'équilibreur de charge rééquilibrera la charge en tenant compte de ce nouveau backend opérationnel. Cette approche de "perturbation minimale" empêche un remaniement massif de toutes les connexions existantes, qui pourrait submerger les caches ou l'état des applications.

Comportement dans les déploiements multizones

Il est essentiel de comprendre que Maglev est indépendant de la topologie. Il distribue le trafic en fonction du résultat mathématique du hachage, sans tenir compte de l'emplacement physique ni du chemin réseau vers les backends.

• Distribution égale, quelle que soit la localisation : Maglev traite tous les backends de son pool comme des cibles égales. Si vos backends sont répartis dans différentes zones, le trafic sera réparti de manière égale entre eux. L'algorithme ne privilégie pas les backends dans une zone "locale" ni ne tient compte de la latence réseau entre les zones.
• Assurez-vous que la capacité de l'interconnexion multizone est suffisante : comme les backends peuvent s'étendre sur plusieurs zones, il est essentiel que l'administrateur réseau s'assure que l'interconnexion multizone dispose d'une capacité réseau suffisante pour gérer le trafic interzone entre les nœuds de l'équilibreur de charge et les backends.

Limites

• La ressource BackendService ne doit pas être configurée avec une ressource HealthCheck pour les charges de travail de pod. Le HealthCheckName dans la spécification BackendService est facultatif et doit être omis lors de la configuration d'un équilibreur de charge avec des pods.

• Une configuration d'équilibreur de charge ne peut pas cibler des charges de travail mixtes impliquant des pods et des VM. Par conséquent, les backends mixtes impliquant des pods et des VM dans une même ressource BackendService ne sont pas autorisés.

• Une ressource personnalisée d'équilibreur de charge global, telle que ForwardingRuleExternal, ForwardingRuleInternal, BackendService ou HealthCheck, ne doit pas porter le même nom que ces ressources personnalisées d'équilibreur de charge zonal.

• Une organisation peut définir un maximum de 500 règles de transfert par zone dans laquelle elle réside. Les règles de transfert globales sont comptabilisées dans cette limite pour toutes les zones.

Limites pour les clusters standards

Les limites suivantes s'appliquent à l'équilibrage de charge pour les clusters standards :

Champ d'application à un seul cluster

• Portée d'un seul cluster : tout équilibreur de charge (ILB ou ELB) provisionné pour un cluster standard à l'aide d'une ressource Service type=LoadBalancer doit cibler des points de terminaison de backend qui sont des pods situés exclusivement dans ce cluster standard. Une seule définition d'équilibreur de charge qui tente de distribuer le trafic vers des pods s'exécutant sur plusieurs clusters standards différents, ou sur un mélange de clusters standards et partagés, n'est pas acceptée.

• La gdcloud CLI et l'API Networking Kubernetes Resource Model ne sont pas compatibles avec les clusters standards. Utilisez la ressource Service Kubernetes standard avec type=LoadBalancer et les annotations associées pour gérer l'équilibrage de charge des clusters standards.

• Les équilibreurs de charge à portée de projet ignorent les clusters standards. Si une configuration d'équilibreur de charge à portée de projet est créée à l'aide de la commande gdcloud CLI ou de l'API Networking Kubernetes Resource Model, elle ignore tous les clusters Standard du projet.

• L'équilibrage de charge global n'est pas compatible. Les ressources ILB et ELB provisionnées pour les clusters standards sont des ressources zonales limitées à une seule zone. L'équilibrage de charge global n'est pas compatible avec les équilibreurs de charge de cluster standards.

• La connectivité ILB multizone n'est pas acceptée. La connectivité d'un pod de cluster standard à un équilibreur de charge interne (ILB) global ou à un ILB zonal dans une autre zone n'est pas prise en charge.

Étapes suivantes

• Configurer des équilibreurs de charge internes
• Configurer des équilibreurs de charge externes