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.

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

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.

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 composants configurables suivants :

• Règles de transfert : spécifient 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 sonde Kubernetes intégré pour déterminer si un point de terminaison spécifique est sain.

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 à 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 toujours acheminées vers le même backend.

Équilibreurs de charge mondiaux 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 dans 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. Ces adresses IP virtuelles ne sont pas accessibles depuis l'extérieur 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 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.

Limites

• La ressource BackendService ne doit pas être configurée avec une ressource HealthCheck pour les charges de travail de pod. Notez que 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 (ForwardingRuleExternal, ForwardingRuleInternal, BackendService ou HealthCheck) ne doit pas porter le même nom que ces ressources personnalisées d'équilibreur de charge zonal.

  Étapes suivantes

• Configurer des équilibreurs de charge internes

• Configurer des équilibreurs de charge externes