Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
L'appliance Google Distributed Cloud (GDC) sous air gap 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 la CLI gdcloud.
Vous pouvez utiliser cette API pour créer des équilibreurs de charge.
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 associé 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 pour lequel 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 directement le service 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.
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 IP virtuelles ELB seront disponibles pour l'organisation.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["# Manage load balancers\n\nGoogle Distributed Cloud (GDC) air-gapped appliance provides load balancers that enable\napplications to expose services to one another. Load balancers allocate a stable\nvirtual IP (VIP) address that balances traffic over a set of backend workloads.\nLoad balancers in GDC perform layer four (L4) load balancing, which means they\nmap a set of configured frontend TCP or UDP ports to corresponding backend\nports. Load balancers are configured at the project level.\n\nLoad balancers are configured for the following workload types:\n\n- Workloads running on VMs.\n- Containerized workloads inside the Kubernetes cluster.\n\nThere are three ways to configure load balancers in\nGDC:\n\n- Use the [Networking Kubernetes Resource Model (KRM)\n API](/distributed-cloud/hosted/docs/latest/appliance/apis/service/networking/networking-api-overview). You can use this API to create load balancers.\n- Use the [gdcloud CLI](/distributed-cloud/hosted/docs/latest/appliance/resources/gdcloud-overview). You can use this API to create load balancers.\n- Use the Kubernetes Service directly from the Kubernetes cluster. This method only creates zonal load balancers.\n\nLoad balancer components\n------------------------\n\nWhen you use the KRM API or gdcloud CLI to configure the load\nbalancer, you use an L4 passthrough load balancer:\n\n- L4 means the protocol is either TCP or UDP.\n- Passthrough means there is no proxy between workload and client.\n\nThe load balancer consists of the following configurable components:\n\n- **Forwarding rules**: specify what traffic is forwarded, and to which\n backend service. Forwarding rules have the following specifications:\n\n - Consists of three tuples, CIDR, port and protocol, for the client to access.\n - Supports TCP and UDP protocols.\n - Offers internal and external forwarding rules. Clients can access internal forwarding rules from within the Virtual Private Cloud (VPC). Clients can access external forwarding rules from outside the GDC platform or from within by workloads that have `EgressNAT` value defined.\n - Forwarding rules connect to a backend service. You can point multiple forwarding rules to point to the same backend service.\n- **Backend services**: are the load balancing hub that link forwarding rules,\n health checks and backends together. A backend service references a backend\n object, that identifies the workloads the load balancer forwards the traffic\n to. There are limitations on what backends a single backend service can\n reference:\n\n - One zonal backend resource per zone.\n - One cluster backend resource per cluster. This cannot be mixed with the project backends.\n- **Backends**: a zonal object that specifies the endpoints that serve as the backends for the created backend services. Backend resources must be scoped to a zone. Select endpoints using labels. Scope the selector to a project or cluster:\n\n - A project backend is is a backend that does not have the `ClusterName` field specified. In this case the specified labels apply to all of the workloads in the specific project, in the specific VPC of a zone. The labels are applied to VM and pod workloads across multiple clusters. When a backend service uses a project backend, you can't reference another backend for that zone in that backend service.\n\n - A cluster backend is a backend that has the `ClusterName` field specified. In this case, the specified labels apply to all the workloads in the named cluster in the specified project. You can specify, at most, one backend per zone per cluster in a single backend service.\n\n- **Health checks**: specify the probes to determine whether a given\n workload endpoint in the backend is healthy. The unhealthy endpoint is\n taken out from the load balancer, until it becomes healthy again. Health\n checks are only applicable to VM workloads. Pod workloads can use the built-in Kubernetes probe mechanism to determine if a specific endpoint is healthy.\n\nWhen using the Kubernetes Service directly, you use the `Service` object instead of the previously listed components. You can only target workloads in the cluster where the `Service` object is created.\n\nExternal and internal load balancing\n------------------------------------\n\nGDC applications have access to the following\nnetworking service types:\n\n- **Internal Load Balancer (ILB)**: lets you expose a service to other clusters within the organization.\n- **External Load Balancer (ELB)**: allocates a VIP address from a range that is routable from external workloads and exposes services outside of the GDC organization, such as other organizations inside or outside of the GDC instance.\n\nService virtual IP addresses\n----------------------------\n\nILBs allocate VIP addresses that are internal only to the organization. These\nVIP addresses are not reachable from outside the organization; therefore, you\ncan only use them to expose services to other applications within an\norganization. These IP addresses may overlap between organizations in the same\ninstance.\n\nOn the other hand, ELBs allocate VIP addresses that are externally reachable\nfrom outside the organization. For this reason, ELB VIP addresses must be unique\namong all organizations. Typically, fewer ELB VIP addresses will be available\nfor use by the organization.\n\nWhat's next\n-----------\n\n- [Configure internal load balancers](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/ilb-service)\n- [Configure external load balancers](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/elb-service)"]]
