Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
L'appliance con air gap di Google Distributed Cloud (GDC) fornisce bilanciatori del carico che consentono
alle applicazioni di esporre i servizi l'una all'altra. I bilanciatori del carico allocano un indirizzo IP virtuale (VIP) stabile che bilancia il traffico su un insieme di carichi di lavoro di backend.
I bilanciatori del carico in GDC eseguono il bilanciamento del carico di livello 4 (L4), il che significa che
mappano un insieme di porte TCP o UDP frontend configurate alle porte
backend corrispondenti. I bilanciatori del carico sono configurati a livello di progetto.
I bilanciatori del carico sono configurati per i seguenti tipi di workload:
Carichi di lavoro in esecuzione sulle VM.
Carichi di lavoro containerizzati all'interno del cluster Kubernetes.
Esistono tre modi per configurare i bilanciatori del carico in
GDC:
Utilizza gcloud CLI.
Puoi utilizzare questa API per creare bilanciatori del carico.
Utilizza il servizio Kubernetes direttamente dal cluster Kubernetes. Questo metodo crea solo bilanciatori del carico zonali.
Componenti del bilanciatore del carico
Quando utilizzi l'API KRM o gcloud CLI per configurare il bilanciatore del carico, utilizzi un bilanciatore del carico pass-through L4:
L4 indica che il protocollo è TCP o UDP.
Passthrough significa che non esiste un proxy tra il workload e il client.
Il bilanciatore del carico è costituito dai seguenti componenti configurabili:
Regole di forwarding: specificano il traffico inoltrato e il servizio di backend a cui viene inoltrato. Le regole di forwarding hanno le seguenti specifiche:
È composto da tre tuple, CIDR, porta e protocollo, a cui il client deve accedere.
Supporta i protocolli TCP e UDP.
Offre regole di forwarding interne ed esterne. I client possono accedere alle regole di forwarding interno dall'interno di Virtual Private Cloud (VPC). I client possono accedere alle regole di forwarding esterno dall'esterno della piattaforma GDC o dall'interno tramite carichi di lavoro con valore EgressNAT definito.
Le regole di forwarding si connettono a un servizio di backend. Puoi indirizzare più regole di forwarding allo stesso servizio di backend.
Servizi di backend: sono l'hub di bilanciamento del carico che collega regole di forwarding, controlli di integrità e backend. Un servizio di backend fa riferimento a un oggetto di backend che identifica i carichi di lavoro a cui il bilanciatore del carico inoltra il traffico. Esistono limitazioni ai backend a cui un singolo servizio di backend può
fare riferimento:
Una risorsa di backend di zona per zona.
Una risorsa di backend del cluster per cluster. Non può essere combinato con i backend del progetto.
Backend: un oggetto zonale che specifica gli endpoint che fungono da backend per i servizi di backend creati. Le risorse di backend devono essere limitate a una zona. Seleziona gli endpoint utilizzando le etichette. Limita l'ambito del selettore a un progetto o un cluster:
Un backend di progetto è un backend in cui non è specificato il campo ClusterName. In questo caso, le etichette specificate vengono applicate a tutti i workload nel progetto specifico, nel VPC specifico di una zona. Le etichette vengono applicate ai carichi di lavoro di VM e pod in più cluster. Quando un servizio di backend utilizza un backend di progetto, non puoi fare riferimento a un altro backend per quella zona nel servizio di backend.
Un backend cluster è un backend in cui è specificato il campo ClusterName. In questo caso, le etichette specificate si applicano a tutti i carichi di lavoro nel cluster denominato nel progetto specificato. Puoi specificare al massimo un backend per zona per cluster in un singolo servizio di backend.
Controlli di integrità: specifica i probe per determinare se un determinato endpoint del workload nel backend è integro. L'endpoint in stato non integro viene rimosso dal bilanciatore del carico finché non torna in stato integro. I controlli
di integrità si applicano solo ai carichi di lavoro delle VM. I carichi di lavoro dei pod possono utilizzare il meccanismo di probe Kubernetes integrato per determinare se un endpoint specifico è integro.
Quando utilizzi direttamente il servizio Kubernetes, utilizzi l'oggetto Service anziché i componenti elencati in precedenza. Puoi scegliere come target solo i carichi di lavoro nel cluster in cui viene creato l'oggetto Service.
Bilanciamento del carico esterno e interno
Le applicazioni GDC hanno accesso ai seguenti tipi di servizi di rete:
Bilanciatore del carico interno (ILB): consente di esporre un servizio ad altri cluster all'interno dell'organizzazione.
Bilanciatore del carico esterno (ELB): alloca un indirizzo VIP da un intervallo instradabile da carichi di lavoro esterni ed espone servizi al di fuori dell'organizzazione GDC, ad esempio altre organizzazioni all'interno o all'esterno dell'istanza GDC.
Indirizzi IP virtuali del servizio
I bilanciatori del carico interni allocano indirizzi VIP interni solo all'organizzazione. Questi
indirizzi VIP non sono raggiungibili dall'esterno dell'organizzazione, pertanto
puoi utilizzarli solo per esporre servizi ad altre applicazioni all'interno di
un'organizzazione. Questi indirizzi IP possono sovrapporsi tra le organizzazioni nella stessa
istanza.
D'altra parte, gli ELB allocano indirizzi VIP raggiungibili esternamente
dall'esterno dell'organizzazione. Per questo motivo, gli indirizzi VIP ELB devono essere univoci
in tutte le organizzazioni. In genere, saranno disponibili meno indirizzi VIP ELB
per l'utilizzo da parte dell'organizzazione.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)"]]
