Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
El dispositivo aislado de Google Distributed Cloud (GDC) proporciona balanceadores de cargas que permiten que las aplicaciones expongan servicios entre sí. Los balanceadores de cargas asignan una dirección IP virtual (VIP) estable que balancea el tráfico en un conjunto de cargas de trabajo de backend.
Los balanceadores de cargas en GDC realizan el balanceo de cargas de capa cuatro (L4), lo que significa que asignan un conjunto de puertos TCP o UDP de frontend configurados a los puertos de backend correspondientes. Los balanceadores de cargas se configuran a nivel del proyecto.
Los balanceadores de cargas se configuran para los siguientes tipos de cargas de trabajo:
Cargas de trabajo que se ejecutan en VMs
Cargas de trabajo alojadas en contenedores dentro del clúster de Kubernetes
Existen tres formas de configurar los balanceadores de cargas en GDC:
Usa la CLI de gcloud.
Puedes usar esta API para crear balanceadores de cargas.
Usa el servicio de Kubernetes directamente desde el clúster de Kubernetes. Este método solo crea balanceadores de cargas zonales.
Componentes del balanceador de cargas
Cuando usas la API de KRM o la CLI de gdcloud para configurar el balanceador de cargas, usas un balanceador de cargas de transferencia de L4:
L4 significa que el protocolo es TCP o UDP.
El modo de transferencia significa que no hay proxy entre la carga de trabajo y el cliente.
El balanceador de cargas consta de los siguientes componentes configurables:
Reglas de reenvío: Especifican qué tráfico se reenvía y a qué servicio de backend. Las reglas de reenvío tienen las siguientes especificaciones:
Consta de tres tuplas: CIDR, puerto y protocolo, para que el cliente acceda.
Admite protocolos TCP y UDP.
Ofrece reglas de reenvío internas y externas. Los clientes pueden acceder a las reglas de reenvío interno desde la nube privada virtual (VPC). Los clientes pueden acceder a las reglas de reenvío externas desde fuera de la plataforma de GDC o desde dentro por cargas de trabajo que tienen definido el valor EgressNAT.
Las reglas de reenvío se conectan a un servicio de backend. Puedes hacer que varias reglas de reenvío apunten al mismo servicio de backend.
Servicios de backend: Son el centro de balanceo de cargas que vincula las reglas de reenvío, las verificaciones de estado y los backends. Un servicio de backend hace referencia a un objeto de backend, que identifica las cargas de trabajo a las que el balanceador de cargas reenvía el tráfico. Existen limitaciones sobre los backends a los que puede hacer referencia un solo servicio de backend:
Un recurso de backend zonal por zona
Un recurso de backend del clúster por clúster. No se puede combinar con los backends del proyecto.
Backends: Es un objeto zonal que especifica los extremos que actúan como backends para los servicios de backend creados. Los recursos de backend deben tener un alcance limitado a una zona. Selecciona extremos con etiquetas. Delimita el selector a un proyecto o clúster:
Un backend de proyecto es un backend que no tiene especificado el campo ClusterName. En este caso, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto específico, en la VPC específica de una zona. Las etiquetas se aplican a las cargas de trabajo de VM y Pod en varios clústeres. Cuando un servicio de backend usa un backend del proyecto, no puedes hacer referencia a otro backend para esa zona en ese servicio de backend.
Un backend de clúster es un backend que tiene especificado el campo ClusterName. En este caso, las etiquetas especificadas se aplican a todas las cargas de trabajo del clúster con nombre en el proyecto especificado. Puedes especificar, como máximo, un backend por zona y por clúster en un solo servicio de backend.
Verificaciones de estado: Especifican los sondeos para determinar si un extremo de carga de trabajo determinado en el backend se encuentra en buen estado. El extremo en mal estado se quita del balanceador de cargas hasta que vuelve a estar en buen estado. Las verificaciones de estado solo se aplican a las cargas de trabajo de VM. Las cargas de trabajo de Pod pueden usar el mecanismo de sondeo integrado de Kubernetes para determinar si un extremo específico está en buen estado.
Cuando usas el servicio de Kubernetes directamente, usas el objeto Service en lugar de los componentes que se mencionaron anteriormente. Solo puedes segmentar las cargas de trabajo en el clúster en el que se crea el objeto Service.
Balanceo de cargas interno y externo
Las aplicaciones de GDC tienen acceso a los siguientes tipos de servicios de redes:
Balanceador de cargas interno (ILB): Te permite exponer un servicio a otros clústeres dentro de la organización.
Balanceador de cargas externo (ELB): Asigna una dirección VIP desde un rango que se puede enrutar desde cargas de trabajo externas y expone servicios fuera de la organización de GDC, como otras organizaciones dentro o fuera de la instancia de GDC.
Direcciones IP virtuales del servicio
Los ILB asignan direcciones VIP que son internas solo para la organización. No se puede acceder a estas direcciones VIP desde fuera de la organización. Por lo tanto, solo puedes usarlas para exponer servicios a otras aplicaciones dentro de una organización. Estas direcciones IP pueden superponerse entre organizaciones en la misma instancia.
Por otro lado, los ELB asignan direcciones VIP a las que se puede acceder externamente desde fuera de la organización. Por este motivo, las direcciones VIP de ELB deben ser únicas entre todas las organizaciones. Por lo general, habrá menos direcciones VIP de ELB disponibles para que las use la organización.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
