Questo documento fornisce istruzioni per la configurazione del bilanciamento del carico HTTP(S) interno per i servizi in esecuzione sulle VM di Compute Engine.
Per configurare il bilanciamento del carico per i servizi in esecuzione nei pod GKE, consulta Bilanciamento del carico nativo del container con NEG autonomi e Collegamento di un bilanciatore del carico HTTP(S) interno a NEG autonomi.
Per configurare il bilanciamento del carico per l'accesso ad API e servizi Google mediante Private Service Connect, consulta l'articolo Configurare Private Service Connect con controlli di servizio HTTP consumer.
La configurazione del bilanciamento del carico HTTP(S) interno si compone di due parti:
- Eseguire attività preliminari, ad esempio garantire che gli account richiesti dispongano delle autorizzazioni corrette e preparare la rete Virtual Private Cloud (VPC).
- Configurazione delle risorse del bilanciatore del carico.
Prima di seguire questa guida, acquisisci familiarità con quanto segue:
- Panoramica del bilanciamento del carico HTTP(S) interno, inclusa la sezione Limitazioni
- Panoramica delle regole firewall VPC
Autorizzazioni
Per seguire questa guida, devi essere in grado di creare istanze e modificare una rete in un progetto. Devi essere un proprietario o un editor del progetto oppure devi disporre di tutti i seguenti ruoli IAM di Compute Engine.
Attività | Ruolo richiesto |
---|---|
Crea reti, subnet e componenti del bilanciatore del carico | Amministratore di rete |
Aggiungi e rimuovi regole firewall | Amministratore sicurezza |
Creare istanze | Amministratore istanza |
Per ulteriori informazioni, consulta le seguenti guide:
Panoramica della configurazione
Puoi configurare il bilanciamento del carico HTTP(S) interno come descritto nel seguente flusso di configurazione di alto livello. I passaggi numerati si riferiscono ai numeri nel diagramma.
Come mostrato nel diagramma, questo esempio crea un bilanciatore del carico HTTP(S) interno in una rete VPC nell'area geografica us-west1
, con un servizio di backend e due gruppi di backend.
Il diagramma mostra quanto segue:
Una rete VPC con due subnet:
Viene utilizzata una subnet per i backend (gruppi di istanze e NEG) e per la regola di forwarding. L'intervallo di indirizzi IP principali è
10.1.2.0/24
.Una subnet è una subnet solo proxy nell'area geografica
us-west1
. Devi creare una subnet solo proxy in ogni area geografica di una rete VPC in cui utilizzi i bilanciatori del carico HTTP(S) interni. La subnet solo proxy dell'area geografica è condivisa tra tutti i bilanciatori del carico HTTP(S) interni nell'area geografica. Gli indirizzi di origine dei pacchetti inviati dal bilanciatore del carico HTTP(S) interno ai backend del tuo servizio vengono allocati dalla subnet solo proxy. In questo esempio, la subnet solo proxy per l'area geografica ha un intervallo di indirizzi IP principali pari a10.129.0.0/23
, ovvero la dimensione della subnet consigliata. Per scoprire di più, consulta Subnet solo proxy.
Una regola firewall che consente il flusso del traffico delle subnet solo proxy nella rete. Ciò significa aggiungere una regola che consenta il traffico TCP sulle porte
80
,443
e8080
da10.129.0.0/23
(l'intervallo della subnet solo proxy in questo esempio). Un'altra regola firewall per i probe del controllo di integrità.Istanze di backend. Questo diagramma di esempio mostra i seguenti deployment di backend:
- VM di Compute Engine
- Backend di Google Kubernetes Engine (GKE) aggiunti a gruppi di endpoint di rete (NEG) di autonomia
Gruppi di istanze e NEG:
- Gruppi di istanze gestite o non gestite per i deployment delle VM di Compute Engine
- NEG per i deployment GKE
In ogni zona, puoi avere una combinazione di tipi di gruppi di backend in base ai requisiti del tuo deployment.
Un controllo di integrità a livello di area geografica che indica l'idoneità dei backend.
Un servizio di backend a livello di area geografica che monitora l'utilizzo e l'integrità dei backend.
Una mappa di URL a livello di area geografica, che analizza l'URL di una richiesta e inoltra le richieste a servizi di backend specifici in base all'host e al percorso dell'URL della richiesta.
Un proxy HTTP o HTTPS di destinazione a livello di area geografica, che riceve la richiesta dell'utente e la inoltra alla mappa degli URL. Per HTTPS, configura una risorsa di certificato SSL a livello di area geografica. Il proxy di destinazione utilizza il certificato SSL per decriptare il traffico SSL, se configuri il bilanciamento del carico HTTPS. Il proxy di destinazione può inoltrare il traffico alle tue istanze utilizzando HTTP o HTTPS.
Una regola di forwarding, che contiene l'indirizzo IP interno del bilanciatore del carico, per inoltrare ogni richiesta in entrata al proxy di destinazione.
L'indirizzo IP interno associato alla regola di forwarding può provenire da qualsiasi subnet (nella stessa rete e nella stessa area geografica) con il flag
--purpose
impostato suPRIVATE
. Ricorda:- L'indirizzo IP può provenire, ma non è necessario, dalla stessa subnet dei gruppi di istanze di backend.
- L'indirizzo IP non deve provenire da una subnet riservata al proxy che ha un flag
--purpose
impostato suREGIONAL_MANAGED_PROXY
.
Configurazione della rete e delle subnet
È necessaria una rete VPC con due subnet: una per i backend del bilanciatore del carico e l'altra per i proxy del bilanciatore del carico. Un bilanciatore del carico HTTP(S) interno è a livello di area geografica. Il traffico nella rete VPC è instradato al bilanciatore del carico, se l'origine del traffico si trova in una subnet nella stessa area geografica del bilanciatore del carico.
Questo esempio utilizza le seguenti reti, aree geografiche e subnet VPC:
Rete. La rete è una rete VPC in modalità personalizzata denominata
lb-network
.Subnet per i backend. Una subnet denominata
backend-subnet
nell'area geograficaus-west1
utilizza10.1.2.0/24
come intervallo IP principale.Subnet per i proxy. Una subnet denominata
proxy-only-subnet
nell'area geograficaus-west1
utilizza10.129.0.0/23
come intervallo IP principale.
Configurazione della rete e della subnet per i backend
console
- Vai alla pagina di rete VPC in Google Cloud Console.
Vai alla pagina Reti VPC - Fai clic su Crea rete VPC.
- In Nome, inserisci
lb-network
. - Nella sezione Subnet:
- Imposta la modalità di creazione subnet su Personalizzata.
- Nella sezione Nuova subnet, inserisci le seguenti informazioni:
- Nome:
backend-subnet
- Area geografica:
us-west1
- Intervallo di indirizzi IP:
10.1.2.0/24
- Nome:
- Fai clic su Fine.
- Fai clic su Crea.
gcloud
Crea la rete VPC personalizzata con il comando
gcloud compute networks create
:gcloud compute networks create lb-network --subnet-mode=custom
Crea una subnet nella rete
lb-network
nell'area geograficaus-west1
con il comandogcloud compute networks subnets create
:gcloud compute networks subnets create backend-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-west1
API
Fai una richiesta POST
al metodo
networks.insert
,
sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks { "routingConfig": { "routingMode": "REGIONAL" }, "name": "lb-network", "autoCreateSubnetworks": false }
Fai una richiesta POST
al metodo
subnetworks.insert
,
sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks { "name": "backend-subnet", "network": "projects/PROJECT_ID/global/networks/lb-network", "ipCidrRange": "10.1.2.0/24", "region": "projects/PROJECT_ID/regions/us-west1", }
Configurazione della subnet solo proxy
Questa subnet solo proxy è destinata a tutti i bilanciatori del carico HTTP(S) interni nell'area geografica us-west1
.
console
Se utilizzi Google Cloud Console, puoi attendere e creare la subnet solo proxy in un secondo momento nella pagina Bilanciamento del carico.
Se vuoi creare subito una subnet solo proxy, segui questi passaggi:
- In Google Cloud Console, vai alla pagina Reti VPC.
Vai alla pagina Reti VPC - Fai clic sul nome della rete VPC condivisa:
lb-network
. - Fai clic su Aggiungi subnet.
- In Nome, inserisci
proxy-only-subnet
. - Come Area geografica, seleziona
us-west1
. - Imposta Finalità su Proxy gestito a livello di area geografica.
- Per Intervallo di indirizzi IP, inserisci
10.129.0.0/23
. - Fai clic su Aggiungi.
gcloud
Crea la subnet solo proxy con il comando gcloud compute networks subnets
create
.
gcloud compute networks subnets create proxy-only-subnet \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-west1 \ --network=lb-network \ --range=10.129.0.0/23
API
Crea la subnet solo proxy con il metodo
subnetworks.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks { "name": "proxy-only-subnet", "ipCidrRange": "10.129.0.0/23", "network": "projects/PROJECT_ID/global/networks/lb-network", "region": "projects/PROJECT_ID/regions/us-west1", "purpose": "REGIONAL_MANAGED_PROXY", "role": "ACTIVE" }
Configurazione delle regole del firewall
In questo esempio vengono utilizzate le seguenti regole firewall:
fw-allow-ssh
. Una regola in entrata, applicabile alle istanze in bilanciamento del carico, che consente la connettività SSH in entrata sulla porta TCP22
da qualsiasi indirizzo. Puoi scegliere un intervallo IP di origine più restrittivo per questa regola; ad esempio, puoi specificare solo gli intervalli IP del sistema da cui avvii le sessioni SSH. In questo esempio viene utilizzato il tag di destinazioneallow-ssh
.fw-allow-health-check
. Una regola in entrata, applicabile alle istanze in bilanciamento del carico, che consente tutto il traffico TCP dai sistemi di controllo di integrità di Google Cloud (in130.211.0.0/22
e35.191.0.0/16
). In questo esempio viene utilizzato il tag di destinazioneload-balanced-backend
.fw-allow-proxies
. Una regola in entrata, applicabile alle istanze in fase di bilanciamento del carico, che consente il traffico TCP sulle porte80
,443
e8080
dal proxy del carico HTTP(S) interno. In questo esempio viene utilizzato il tag di destinazioneload-balanced-backend
.
Senza queste regole firewall, la regola predefinita per il traffico in entrata blocca il traffico in entrata verso le istanze di backend.
I tag di destinazione definiscono le istanze di backend. Senza i tag di destinazione, le regole firewall si applicano a tutte le tue istanze di backend nella rete VPC. Quando crei le VM di backend, assicurati di includere i tag di destinazione specificati, come mostrato nella sezione Creazione di un gruppo di istanze gestite.
console
- Vai alla pagina Regole firewall in Google Cloud Console.
Vai alla pagina Regole firewall - Fai clic su Crea regola firewall per creare la regola per consentire le connessioni SSH in entrata:
- Nome:
fw-allow-ssh
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione:
allow-ssh
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
0.0.0.0/0
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
22
per il numero di porta.
- Nome:
- Fai clic su Crea.
- Fai clic su Crea regola firewall una seconda volta per creare la regola per consentire i
controlli di integrità di Google Cloud:
- Nome:
fw-allow-health-check
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione:
load-balanced-backend
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
130.211.0.0/22
e35.191.0.0/16
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
80
per il numero di porta.
Come best practice, limita questa regola solo ai protocolli e alle porte corrispondenti a quelli utilizzati dal controllo di integrità. Se utilizzitcp:80
per il protocollo e la porta, Google Cloud può utilizzare HTTP sulla porta80
per contattare le tue VM, ma non può utilizzare HTTPS sulla porta443
per contattarli.
- Nome:
- Fai clic su Crea.
- Fai clic su Crea regola firewall una terza volta per creare la regola e consentire ai server proxy del bilanciatore del carico di connettere i backend:
- Nome:
fw-allow-proxies
- Rete:
lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione:
load-balanced-backend
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine:
10.129.0.0/23
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
80, 443, 8080
per i numeri di porta.
- Nome:
- Fai clic su Crea.
gcloud
Crea la regola firewall
fw-allow-ssh
per consentire la connettività SSH alle VM con il tag di reteallow-ssh
. Se omettisource-ranges
, Google Cloud interpreta la regola per indicare qualsiasi origine.gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Crea la regola
fw-allow-health-check
per consentire i controlli di integrità di Google Cloud. Questo esempio consente a tutto il traffico TCP da probe di controllo di integrità; tuttavia, puoi configurare un insieme di porte più ristretto in base alle tue esigenze.gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcp
Crea la regola
fw-allow-proxies
per consentire ai proxy del bilanciatore del carico HTTP(S) interno di connettersi ai backend. Impostasource-ranges
sugli intervalli allocati della subnet solo proxy, ad esempio10.129.0.0/23
.gcloud compute firewall-rules create fw-allow-proxies \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=source-range \ --target-tags=load-balanced-backend \ --rules=tcp:80,tcp:443,tcp:8080
API
Crea la regola firewall fw-allow-ssh
inviando una richiesta POST
al
metodo firewalls.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-ssh", "network": "projects/PROJECT_ID/global/networks/lb-network", "sourceRanges": [ "0.0.0.0/0" ], "targetTags": [ "allow-ssh" ], "allowed": [ { "IPProtocol": "tcp", "ports": [ "22" ] } ], "direction": "INGRESS" }
Crea la regola firewall fw-allow-health-check
inviando una richiesta POST
al
metodo firewalls.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-health-check", "network": "projects/PROJECT_ID/global/networks/lb-network", "sourceRanges": [ "130.211.0.0/22", "35.191.0.0/16" ], "targetTags": [ "load-balanced-backend" ], "allowed": [ { "IPProtocol": "tcp" } ], "direction": "INGRESS" }
Crea la regola firewall fw-allow-proxies
per consentire il traffico TCP all'interno della subnet proxy per il metodo firewalls.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-proxies", "network": "projects/PROJECT_ID/global/networks/lb-network", "sourceRanges": [ "10.129.0.0/23" ], "targetTags": [ "load-balanced-backend" ], "allowed": [ { "IPProtocol": "tcp", "ports": [ "80" ] }, { "IPProtocol": "tcp", "ports": [ "443" ] }, { "IPProtocol": "tcp", "ports": [ "8080" ] } ], "direction": "INGRESS" }
Configurazione del bilanciamento del carico HTTP(S) interno con un servizio basato su VM
Questa sezione mostra la configurazione richiesta per i servizi in esecuzione sulle VM di Compute Engine. Le VM client si connettono all'indirizzo IP e alla porta che configuri nella regola di forwarding. Quando le applicazioni client inviano traffico a questo indirizzo IP e a questa porta, le loro richieste vengono inoltrate alle tue macchine virtuali (VM) di backend in base alla mappa URL del tuo bilanciatore del carico HTTP(S) interno.
L'esempio in questa pagina imposta in modo esplicito un indirizzo IP interno riservato per la regola di forwarding interna del bilanciatore del carico HTTP(S) interno, anziché consentire l'allocazione di un indirizzo IP interno temporaneo. Come best practice, consigliamo di prenotare gli indirizzi IP per le regole di forwarding.
Per l'indirizzo IP della regola di forwarding, utilizza backend-subnet
. Se
tenta di utilizzare la subnet
solo proxy, la creazione della
regola di forwarding non riesce.
Creazione di un gruppo di istanze gestite
Questa sezione mostra come creare un modello e un gruppo di istanze gestite. Il gruppo di istanze gestite fornisce istanze VM che eseguono i server di backend di un bilanciatore del carico HTTP(S) interno di esempio. Per il tuo gruppo di istanze, puoi definire un servizio HTTP e mappare il nome di una porta alla porta pertinente. Il servizio di bilanciamento del carico inoltra il traffico alle porte con nome Il traffico proveniente dai client viene bilanciato con carico su tali server di backend. A scopo dimostrativo, i backend gestiscono i propri nomi host.
Cloud Console
Creare un modello di istanza. In Google Cloud Console, vai alla pagina Modelli di istanza.
- Fai clic su Crea modello istanza.
- In Nome, inserisci
l7-ilb-backend-template
. - Assicurati che il Disco di avvio sia impostato su un'immagine Debian, ad esempio
Debian GNU/Linux 9 (stretch). Queste istruzioni utilizzano comandi disponibili
solo su Debian, come
apt-get
. In Gestione, sicurezza, dischi, networking, single-tenancy, nella scheda Management, inserisci il seguente script nel campo Startup script.
#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" sudo echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html
In Networking, seleziona
lb-network
come Rete e, per la subnet, selezionabackend-subnet
.Aggiungi i seguenti tag di rete:
allow-ssh
eload-balanced-backend
.Fai clic su Crea.
Creare un gruppo di istanze gestite. Vai alla pagina Gruppi di istanze in Google Cloud Console.
- Fai clic su Crea gruppo di istanze.
- Seleziona Nuovo gruppo di istanze gestite (senza stato). Per ulteriori informazioni, consulta la sezione MIG stateless o stateful.
- In Nome, inserisci
l7-ilb-backend-example
. - In Località, seleziona Zona singola.
- Come Area geografica, seleziona
us-west1
. - In Zona, seleziona
us-west1-a
. - In Modello di istanza, seleziona
l7-ilb-backend-template
. Specifica il numero di istanze che vuoi creare nel gruppo.
Per questo esempio, specifica le seguenti opzioni in Scalabilità automatica:
- Per Modalità di scalabilità automatica, seleziona
Off:do not autoscale
. - In Numero massimo di istanze, inserisci
2
.
Facoltativamente, nella sezione Scalabilità automatica dell'interfaccia utente, puoi configurare il gruppo di istanze in modo da aggiungere o rimuovere automaticamente le istanze in base all'utilizzo della CPU dell'istanza.
- Per Modalità di scalabilità automatica, seleziona
Fai clic su Crea.
gcloud
Le istruzioni gcloud
riportate in questa guida presuppongono che tu stia utilizzando Cloud
Shell o un altro ambiente con installato Bash.
Creare un modello di istanza VM con un server HTTP con il comando
gcloud compute instance-templates create
.gcloud compute instance-templates create `l7-ilb-backend-template` \ --region=us-west1 \ --network=lb-network \ --subnet=backend-subnet \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-9 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" sudo echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html sudo systemctl restart apache2'
Crea un gruppo di istanze gestite nella zona con il comando
gcloud compute instance-groups managed create
.gcloud compute instance-groups managed create l7-ilb-backend-example \ --zone=us-west1-a \ --size=2 \ --template=l7-ilb-backend-template
API
Crea il modello di istanza con il metodo instanceTemplates.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates { "name":"l7-ilb-backend-template", "properties":{ "machineType":"e2-standard-2", "tags":{ "items":[ "allow-ssh", "load-balanced-backend" ] }, "metadata":{ "kind":"compute#metadata", "items":[ { "key":"startup-script", "value":"#! /bin/bash\nsudo apt-get update\nsudo apt-get install apache2 -y\nsudo a2ensite default-ssl\nsudo a2enmod ssl\nsudo vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n sudo echo \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsudo systemctl restart apache2" } ] }, "networkInterfaces":[ { "network":"projects/PROJECT_ID/global/networks/lb-network", "subnetwork":"regions/us-west1/subnetworks/backend-subnet", "accessConfigs":[ { "type":"ONE_TO_ONE_NAT" } ] } ], "disks":[ { "index":0, "boot":true, "initializeParams":{ "sourceImage":"projects/debian-cloud/global/images/family/debian-9" }, "autoDelete":true } ] } }
Crea un gruppo di istanze gestite in ogni zona con il metodo instanceGroupManagers.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers { "name": "l7-ilb-backend-example", "zone": "projects/PROJECT_ID/zones/us-west1-a", "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/l7-ilb-backend-template", "baseInstanceName": "l7-ilb-backend-example", "targetSize": 2 }
Configurazione del bilanciatore del carico
L'esempio seguente mostra come creare le seguenti risorse bilanciatore del carico HTTP(S) interne:
- Controllo di integrità HTTP
- Servizio di backend con un gruppo di istanze gestite come backend
- Una mappa URL
- Assicurati di fare riferimento a una mappa URL a livello di area geografica se è stata definita un'area geografica per il proxy HTTP(S) di destinazione. Una mappa URL a livello di area geografica instrada le richieste a un servizio di backend a livello di area geografica in base a regole che hai definito per l'host e il percorso di un URL in entrata. È possibile fare riferimento a una mappa URL a livello di area geografica solo con una regola proxy di destinazione a livello di area geografica nella stessa area geografica.
- Certificato SSL (per HTTPS)
- Proxy di destinazione
- Regola di forwarding
Per l'indirizzo IP della regola di forwarding, utilizza backend-subnet
. Se
tenta di utilizzare la subnet
solo proxy, la creazione della
regola di forwarding non riesce.
Disponibilità del proxy
A volte le aree geografiche Google Cloud non hanno una capacità proxy sufficiente per un nuovo bilanciatore del carico. In questo caso, Google Cloud Console fornisce un messaggio di avviso sulla disponibilità del proxy durante la creazione del bilanciatore del carico. Per risolvere il problema, puoi eseguire una delle seguenti operazioni:
- Seleziona un'area geografica diversa per il bilanciatore del carico. Può essere una soluzione pratica se hai backend in un'altra area geografica.
- Seleziona una rete VPC che ha già una subnet solo proxy allocata.
Attendi che il problema di capacità venga risolto.
Cloud Console
Seleziona un tipo di bilanciatore del carico
- Vai alla pagina Bilanciamento del carico in Google Cloud Console.
Vai alla pagina Bilanciamento del carico - In Bilanciamento del carico HTTP(S), fai clic su Avvia configurazione.
- Nella sezione Solo per Internet o interno, seleziona Solo tra le mie VM. Questa impostazione indica che il bilanciatore del carico è interno.
- Fai clic su Continua.
Prepara il bilanciatore del carico
- In Nome del bilanciatore del carico, inserisci
l7-ilb-map
. - Come Area geografica, seleziona
us-west1
. - In Rete, seleziona
lb-network
. - Per continuare, tieni aperta la finestra.
Prenota una subnet solo proxy
Per il bilanciamento del carico HTTP(S) interno, riserva una subnet proxy:
- Fai clic su Prenota una subnet.
- In Nome, inserisci
proxy-only-subnet
. - Per Intervallo di indirizzi IP, inserisci
10.129.0.0/23
. - Fai clic su Aggiungi.
Configura il servizio di backend
- Fai clic su Configurazione backend.
- Dal menu Crea o seleziona servizi di backend, seleziona Crea un servizio di backend.
- Imposta il Nome del servizio di backend su l7-ilb-backend-service.
- Imposta il Tipo di backend su gruppi di istanze.
- Nella sezione Nuovo backend:
- Imposta il Gruppo di istanze su l7-ilb-backend-example.
- Imposta Numeri di porta su
80
. - Imposta la modalità di bilanciamento su Utilizzo.
- Fai clic su Fine.
- Nella sezione Controllo di integrità, scegli Crea un controllo di integrità con i seguenti parametri:
- Nome: l7-ilb-basic-check
- Protocollo: HTTP
- Porta:
80
- Fai clic su Salva e continua.
- Fai clic su Crea.
Configura la mappa URL
Fai clic su Regole host e percorso. Assicurati che l7-ilb-backend-service sia l'unico servizio di backend per qualsiasi host senza corrispondenza e qualsiasi percorso senza corrispondenza.
Per informazioni sulla gestione del traffico, consulta Impostare la gestione del traffico.
Configura il frontend
Per HTTP:
- Fai clic su Configurazione frontend.
- Fai clic su Aggiungi IP e porta frontend.
- Imposta il Nome su l7-ilb-forwarding-rule.
- Imposta il Protocollo su HTTP.
- Imposta la subnet su backend-subnet.
- In IP interno, seleziona Prenota un indirizzo IP interno statico.
- Nel riquadro visualizzato, fornisci i seguenti dettagli:
- Nome: l7-ilb-ip
- Nella sezione Indirizzo IP statico, seleziona Fammi scegliere.
- Nella sezione Indirizzo IP personalizzato, inserisci
10.1.2.99
. - Fai clic su Prenota.
- Imposta il campo Porta su
80
. - Fai clic su Fine.
Per HTTPS:
Se utilizzi HTTPS tra il client e il bilanciatore del carico, sono necessarie una o più risorse certificato SSL per configurare il proxy. Per informazioni su come creare risorse dei certificati SSL, consulta Certificati SSL. I certificati gestiti da Google non sono attualmente supportati con bilanciatori del carico HTTP(S) interni.
- Fai clic su Configurazione frontend.
- Fai clic su Aggiungi IP e porta frontend.
- Nel campo Nome, inserisci
l7-ilb-forwarding-rule
. - Nel campo Protocollo, seleziona
HTTPS (includes HTTP/2)
. - Imposta la subnet su backend-subnet.
- In IP interno, seleziona Prenota un indirizzo IP interno statico.
- Nel riquadro che appare fornisci i seguenti dettagli:
- Nome: l7-ilb-ip
- Nella sezione Indirizzo IP statico, seleziona Fammi scegliere.
- Nella sezione Indirizzo IP personalizzato, inserisci
10.1.2.99
. - Fai clic su Prenota.
- Assicurati che la porta sia impostata su
443
per consentire il traffico HTTPS. - Fai clic sull'elenco a discesa Certificate (Certificato).
- Se hai già una risorsa certificato SSL autogestita che vuoi utilizzare come certificato SSL principale, selezionala dal menu a discesa.
- In alternativa, seleziona Crea un nuovo certificato.
- Inserisci un Nome di
l7-ilb-cert
. - Nei campi appropriati, carica i file in formato PEM:
- Certificato di chiave pubblica
- Catena di certificati
- Chiave privata
- Fai clic su Crea.
- Inserisci un Nome di
- Per aggiungere risorse dei certificati oltre alla risorsa principale del certificato SSL:
- Fai clic su Aggiungi certificato.
- Seleziona un certificato dall'elenco Certificati o fai clic su Crea un nuovo certificato e segui le istruzioni riportate sopra.
- Fai clic su Fine.
Completare la configurazione
Fai clic su Crea.
gcloud
Definisci il controllo di integrità HTTP con il comando
gcloud compute health-checks create http
.gcloud compute health-checks create http l7-ilb-basic-check \ --region=us-west1 \ --use-serving-port
Definisci il servizio di backend con il comando
gcloud compute backend-services create
.gcloud compute backend-services create l7-ilb-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTP \ --health-checks=l7-ilb-basic-check \ --health-checks-region=us-west1 \ --region=us-west1
Aggiungere backend al servizio di backend con il comando
gcloud compute backend-services add-backend
.gcloud compute backend-services add-backend l7-ilb-backend-service \ --balancing-mode=UTILIZATION \ --instance-group=l7-ilb-backend-example \ --instance-group-zone=us-west1-a \ --region=us-west1
Creare la mappa URL con il comando
gcloud compute url-maps create
.gcloud compute url-maps create l7-ilb-map \ --default-service=l7-ilb-backend-service \ --region=us-west1
Crea il proxy di destinazione.
Per HTTP:
Per un bilanciatore del carico HTTP interno, crea il proxy di destinazione con il comando
gcloud compute target-http-proxies create
.gcloud compute target-http-proxies create l7-ilb-proxy \ --url-map=l7-ilb-map \ --url-map-region=us-west1 \ --region=us-west1
Per HTTPS:
Per informazioni su come creare risorse dei certificati SSL, consulta Certificati SSL. I certificati gestiti da Google non sono attualmente supportati con bilanciatori del carico HTTP(S) interni.
Assegna i percorsi file a nomi di variabili.
export LB_CERT=path to PEM-formatted file
export LB_PRIVATE_KEY=path to PEM-formatted file
Creare un certificato SSL a livello di area geografica utilizzando il comando
gcloud compute ssl-certificates create
.gcloud compute ssl-certificates create l7-ilb-cert \ --certificate=$LB_CERT \ --private-key=$LB_PRIVATE_KEY \ --region=us-west1
Utilizza il certificato SSL a livello di area geografica per creare un proxy di destinazione con il comando
gcloud compute target-https-proxies create
.gcloud compute target-https-proxies create l7-ilb-proxy \ --url-map=l7-ilb-map \ --region=us-west1 \ --ssl-certificates=l7-ilb-cert
Crea la regola di forwarding.
Per le reti personalizzate, devi fare riferimento alla subnet nella regola di forwarding. Tieni presente che questa è la subnet della VM, non la subnet del proxy.
Per HTTP:
Utilizza il comando
gcloud compute forwarding-rules create
con i flag corretti.gcloud compute forwarding-rules create l7-ilb-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.99 \ --ports=80 \ --region=us-west1 \ --target-http-proxy=l7-ilb-proxy \ --target-http-proxy-region=us-west1
Per HTTPS:
Crea la regola di forwarding con il comando
gcloud compute forwarding-rules create
con i flag corretti.gcloud compute forwarding-rules create l7-ilb-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --address=10.1.2.99 \ --ports=443 \ --region=us-west1 \ --target-https-proxy=l7-ilb-proxy \ --target-https-proxy-region=us-west1
API
Crea il controllo di integrità effettuando una richiesta POST
per il
metodo regionHealthChecks.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/{region}/healthChecks { "name": "l7-ilb-basic-check", "type": "HTTP", "httpHealthCheck": { "portSpecification": "USE_SERVING_PORT" } }
Crea il servizio di backend a livello di area geografica effettuando una richiesta POST
al metodo regionBackendServices.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices { "name": "l7-ilb-backend-service", "backends": [ { "group": "projects/PROJECT_ID/zones/us-west1-a/instanceGroups/l7-ilb-backend-example", "balancingMode": "UTILIZATION" } ], "healthChecks": [ "projects/PROJECT_ID/regions/us-west1/healthChecks/l7-ilb-basic-check" ], "loadBalancingScheme": "INTERNAL_MANAGED" }
Per creare la mappa URL, invia una richiesta POST
al metodo
regionUrlMaps.insert
,
sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/urlMaps { "name": "l7-ilb-map", "defaultService": "projects/PROJECT_ID/regions/us-west1/backendServices/l7-ilb-backend-service" }
Per HTTP:
Crea il proxy HTTP di destinazione effettuando una richiesta POST
al metodo
regionTargetHttpProxies.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/targetHttpProxy { "name": "l7-ilb-proxy", "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map", "region": "us-west1" }
Per creare la regola di forwarding, invia una richiesta POST
al metodo
forwardingRules.insert
,
sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules { "name": "l7-ilb-forwarding-rule", "IPAddress": "10.1.2.99", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID/regions/us-west1/targetHttpProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet", "network": "projects/PROJECT_ID/global/networks/lb-network", "networkTier": "PREMIUM" }
Per HTTPS:
Leggi il certificato e i file della chiave privata, quindi crea il certificato SSL. L'esempio seguente mostra come fare con Python.
Crea il proxy HTTPS di destinazione effettuando una richiesta POST
al metodo
regionTargetHttpsProxies.insert
, sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionTargetHttpsProxy { "name": "l7-ilb-proxy", "urlMap": "projects/PROJECT_ID/regions/us-west1/urlMaps/l7-ilb-map", "sslCertificates": /projects/PROJECT_ID/regions/us-west1/sslCertificates/SSL_CERT_NAME }
Per creare la regola di forwarding, invia una richiesta POST
al metodo
forwardingRules.insert
,
sostituendo PROJECT_ID
con l'ID progetto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules { "name": "l7-ilb-forwarding-rule", "IPAddress": "10.1.2.99", "IPProtocol": "TCP", "portRange": "80-80", "target": "projects/PROJECT_ID/regions/us-west1/targetHttpsProxies/l7-ilb-proxy", "loadBalancingScheme": "INTERNAL_MANAGED", "subnetwork": "projects/PROJECT_ID/regions/us-west1/subnetworks/backend-subnet", "network": "projects/PROJECT_ID/global/networks/lb-network", "networkTier": "PREMIUM", }
Test
Creazione di un'istanza VM per testare la connettività in corso...
gcloud compute instances create l7-ilb-client-us-west1-a \ --image-family=debian-9 \ --image-project=debian-cloud \ --network=lb-network \ --subnet=backend-subnet \ --zone=us-west1-a \ --tags=allow-ssh
Test del bilanciatore del carico
Accedi all'istanza appena creata e testa che i servizi HTTP(S) sui backend siano raggiungibili tramite l'indirizzo IP della regola di forwarding HTTP(S) interno e che il bilanciamento del carico del traffico tra le istanze di backend sia in corso.
Connessione tramite SSH a ogni istanza client
gcloud compute ssh l7-ilb-client-us-west1-a \ --zone=us-west1-a
Verifica che l'IP stia gestendo il suo nome host
curl 10.1.2.99
Per il test HTTPS, sostituisci curl
con:
curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443
Il flag -k
fa sì che curl non superi la convalida dei certificati.
Eseguire 100 richieste e confermare che sono bilanciate dal carico
Per HTTP:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl --silent 10.1.2.99)" done echo "***" echo "*** Results of load-balancing to 10.1.2.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
Per HTTPS:
{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)" done echo "***" echo "*** Results of load-balancing to 10.1.2.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
Opzioni di configurazione aggiuntive
Questa sezione espande l'esempio di configurazione per fornire opzioni di configurazione alternative e aggiuntive. Tutte le attività sono facoltative. Puoi eseguire le operazioni in qualsiasi ordine.
Attivazione dell'affinità sessione
Queste procedure mostrano come aggiornare un servizio di backend per il bilanciatore del carico HTTP(S) di esempio in modo che il servizio di backend utilizzi un'affinità cookie generata, un'affinità campo di intestazione o un'affinità cookie HTTP.
Quando è abilitata un'affinità cookie generata, il bilanciatore del carico emette un cookie
alla prima richiesta. Per ogni richiesta successiva con lo stesso cookie, il bilanciatore del carico indirizza la richiesta alla stessa VM o endpoint di backend. Per i bilanciatori del carico HTTP(S) interni, il cookie è denominato GCILB
.
Quando è abilitata l'affinità campo di intestazione, il bilanciatore del carico instrada le richieste di backend a VM o endpoint in un NEG basato sul valore dell'intestazione HTTP denominata nel flag --custom-request-header
. L'affinità del campo di intestazione è valida solo se il criterio di località del bilanciamento del carico è RING_HASH
o MAGLEV
e se l'hash coerente del servizio di backend specifica il nome dell'intestazione HTTP.
Quando è attivata l'affinità cookie HTTP, il bilanciatore del carico instrada le richieste di
backend delle VM o degli endpoint in un NEG, in base a un cookie HTTP denominato nel
flag HTTP_COOKIE
con il flag --affinity-cookie-ttl
facoltativo. Se il client non fornisce il cookie nella richiesta HTTP, il proxy genera il cookie e lo restituisce al client in un'intestazione Set-Cookie
. L'affinità cookie HTTP è valida solo se il criterio di località del bilanciamento del carico è RING_HASH
o MAGLEV
e l'hash coerente del servizio di backend specifica il cookie HTTP.
Cloud Console
Per attivare o modificare l'affinità sessione per un servizio di backend:
- Vai alla pagina Bilanciamento del carico in Google Cloud Console.
Vai alla pagina Bilanciamento del carico - Fai clic su Backend.
- Fai clic su l7-ilb-backend-service (il nome del servizio di backend che hai creato per questo esempio) e fai clic su Modifica.
- Nella pagina Dettagli del servizio di backend, fai clic su Configurazione avanzata.
- In Affinità sessione, seleziona dal menu il tipo di affinità sessione che preferisci.
- Fai clic su Aggiorna.
gcloud
Utilizza i seguenti comandi gcloud per aggiornare il servizio di backend l7-ilb-backend-service
con diversi tipi di affinità sessione:
gcloud compute backend-services update l7-ilb-backend-service \ --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] --region=us-west1
API
Per impostare l'affinità sessione, invia una richiesta PATCH
al metodo regionBackendServices/patch
.
PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/regionBackendServices/l7-ilb-backend-service { "sessionAffinity": ["GENERATED_COOKIE" | "header_FIELD" | "HTTP_CO;
Limitazione dei client che possono inviare traffico al bilanciatore del carico
Puoi impedire ai client di comunicare con un bilanciatore del carico HTTP(S) interno per la regola di forwarding in uscita configurando le regole firewall in uscita su questi client. Imposta queste regole firewall su VM client specifiche in base agli account di servizio o ai tag.
Non puoi utilizzare le regole firewall per limitare il traffico in entrata a VIP specifici per le regole di forwarding per il bilanciatore del carico HTTP(S). In genere, qualsiasi client sulla stessa rete VPC e nella stessa area geografica del VIP con regola di forwarding può inviare traffico alla VIP regola di forwarding.
Inoltre, tutte le richieste ai backend provengono da proxy che utilizzano indirizzi IP nell'intervallo della subnet solo proxy. Non è possibile creare regole firewall che consentano o neghino il traffico in entrata su questi backend in base alla regola di forwarding VIP utilizzata da un client.
Ecco alcuni esempi su come utilizzare le regole firewall in uscita per limitare il traffico al VIP della regola di forwarding del bilanciatore del carico.
console
Per identificare le VM client, devi codificare le VM specifiche che vuoi limitare. Questi tag vengono utilizzati per associare le regole firewall
alle VM client codificate. Quindi aggiungi il tag nel campo TARGET_TAG
in questi passaggi.
Per eseguire la configurazione, utilizza una o più regole firewall.
Regola firewall in uscita singola
Puoi configurare una regola di traffico in uscita dal firewall per negare tutto il traffico in uscita dalle VM client codificate al VIP di un bilanciatore del carico.
- Vai alla pagina Regole firewall in Google Cloud Console.
Vai alla pagina Regole firewall - Fai clic su Crea regola firewall per creare una regola che rifiuti il traffico in uscita dalle VM dei client taggati al VIP di un bilanciatore del carico.
- Nome:
fr-deny-access
- Rete:
lb-network
- Priorità:
100
- Direzione del traffico: in uscita
- Azione in caso di corrispondenza: Nega
- Target: tag di destinazione specificati
- Tag di destinazione:
TARGET_TAG
- Filtro di destinazione: intervalli IP
- Intervalli IP di destinazione:
10.1.2.99
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
80
per il numero di porta.
- Nome:
- Fai clic su Crea.
Più regole firewall in uscita
Un approccio più scalabile prevede l'impostazione di due regole. Una regola predefinita a bassa priorità che impedisce a tutti i client di accedere al VIP del bilanciatore del carico. Una seconda regola con priorità più alta che consente a un sottoinsieme di client con tag di accedere al VIP del bilanciatore del carico. Solo le VM tag potranno accedere al VIP.
- Vai alla pagina Regole firewall in Google Cloud Console.
Vai alla pagina Regole firewall - Fai clic su Crea regola firewall per creare la regola di priorità inferiore per negare l'accesso per impostazione predefinita:
- Nome:
fr-deny-all-access-low-priority
- Rete:
lb-network
- Priorità:
200
- Direzione del traffico: in uscita
- Azione in caso di corrispondenza: Nega
- Target: tag di destinazione specificati
- Tag di destinazione:
TARGET_TAG
- Filtro di destinazione: intervalli IP
- Intervalli IP di destinazione:
10.1.2.99
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
80
per il numero di porta.
- Nome:
- Fai clic su Crea.
- Fai clic su Crea regola firewall per creare la regola con priorità più elevata in modo da consentire il traffico da determinate istanze con tag.
- Nome:
fr-allow-some-access-high-priority
- Rete:
lb-network
- Priorità:
100
- Direzione del traffico: in uscita
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione:
TARGET_TAG
- Filtro di destinazione: intervalli IP
- Intervalli IP di destinazione:
10.1.2.99
- Protocolli e porte:
- Scegli Protocolli e porte specificati.
- Seleziona la casella di controllo tcp, quindi inserisci
80
per il numero di porta.
- Nome:
- Fai clic su Crea.
gcloud
Per identificare le VM client, devi codificare le VM specifiche che vuoi limitare. Quindi aggiungi il tag nel campo TARGET_TAG
in questi passaggi.
Per eseguire la configurazione, utilizza una o più regole firewall.
Regola firewall in uscita singola
Puoi configurare una regola di traffico in uscita dal firewall per negare tutto il traffico in uscita dalle VM client codificate al VIP di un bilanciatore del carico.
gcloud compute firewall-rules create fr-deny-access \ --network=lb-network \ --action=deny \ --direction=egress \ --rules=tcp \ --priority=100 \ --destination-ranges=10.1.2.99 \ --target-tags=TARGET_TAG
Più regole firewall in uscita
Un approccio più scalabile prevede l'impostazione di due regole. Una regola predefinita a bassa priorità che impedisce a tutti i client di accedere al VIP del bilanciatore del carico. Una seconda regola con priorità più alta consente a un sottoinsieme di client con tag di accedere al VIP del bilanciatore del carico. Solo le VM con tag potranno accedere al VIP.
Crea la regola di priorità inferiore:
gcloud compute firewall-rules create fr-deny-all-access-low-priority \ --network=lb-network \ --action=deny \ --direction=egress \ --rules=tcp \ --priority=200 \ --destination-ranges=10.1.2.99
Crea la regola di priorità superiore:
gcloud compute firewall-rules create fr-allow-some-access-high-priority \ --network=lb-network \ --action=allow \ --direction=egress \ --rules=tcp \ --priority=100 \ --destination-ranges=10.1.2.99 \ --target-tags=TARGET_TAG
Per utilizzare gli account di servizio anziché i tag per controllare l'accesso, è sufficiente utilizzare il flag --target-service-accounts
anziché il flag --target-tags
durante la creazione delle regole firewall.
Scalabilità dell'accesso limitato ai backend del bilanciatore del carico HTTP(S) interni in base alle subnet
Mantenere separate le regole firewall o aggiungendo nuovi IP con bilanciamento del carico alle regole esistenti, come descritto nella sezione precedente, diventa scomodo man mano che il numero di regole di forwarding aumenta. Un modo per evitarlo è assegnare indirizzi IP delle regole di forwarding da una subnet riservata. Quindi, il traffico delle istanze o degli account di servizio provvisti di tag può essere consentito o bloccato utilizzando la subnet riservata come intervallo di destinazione per le regole firewall. Questo ti consente di controllare efficacemente l'accesso a un gruppo di VIP con regole di forwarding senza dover gestire le regole di traffico in uscita per firewall.
Di seguito sono riportati i passaggi generali per eseguire la configurazione, supponendo che creerai tutte le altre risorse del bilanciatore del carico separatamente.
gcloud
Crea una subnet regionale che verrà utilizzata per allocare indirizzi IP con bilanciamento del carico per le regole di forwarding:
gcloud compute networks subnets create l7-ilb-restricted-subnet \ --network=lb-network \ --region=us-west1 \ --range=10.127.0.0/24
Crea una regola di forwarding che prende un indirizzo dalla subnet appena allocata. Per questo esempio, abbiamo selezionato
10.127.0.1
dalla subnet creata nel passaggio precedente.gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=l7-ilb-restricted-subnet \ --address=10.127.0.1 \ --ports=80 \ --region=us-west1 \ --target-http-proxy=l7-ilb-proxy \ --target-http-proxy-region=us-west1
Crea una regola firewall per limitare il traffico destinato agli indirizzi IP dell'intervallo nella subnet delle regole di forwarding (
l7-ilb-restricted-subnet
):gcloud compute firewall-rules create restrict-traffic-to-subnet \ --network=lb-network \ --action=deny \ --direction=egress \ --rules=tcp:80 \ --priority=100 \ --destination-ranges=10.127.0.0/24 \ --target-tags=TARGET_TAG
Configurare l'impostazione secondaria di backend
Il sottoinsieme secondario del backend migliora le prestazioni e la scalabilità assegnando un sottoinsieme di backend a ciascuna istanza proxy. Quando è abilitato per un servizio di backend, regola il numero di backend utilizzati da ogni istanza del proxy come segue:
Con l'aumento del numero di istanze proxy che partecipano al bilanciatore del carico, la dimensione del sottoinsieme diminuisce.
Quando il numero totale di backend in una rete supera la capacità di una singola istanza proxy, le dimensioni del sottoinsieme vengono ridotte automaticamente per ogni servizio in cui è abilitato l'impostazione secondaria del backend.
L'esempio seguente mostra come creare risorse del bilanciatore del carico HTTP(S) interno e abilitare l'impostazione secondaria di backend:
- Utilizza la configurazione di esempio
per creare un servizio di backend a livello di area geografica
l7-ilb-backend-service
. Abilita l'impostazione secondaria del backend specificando
--subsetting-policy
comeCONSISTENT_HASH_SUBSETTING
. Lo schema di bilanciamento del carico èINTERNAL_MANAGED
.gcloud
Utilizza il seguente comando
gcloud
per aggiornarel7-ilb-backend-service
con l'impostazione secondaria del backend:gcloud beta compute backend-services update l7-ilb-backend-service \ --region=us-west1 \ --subsetting-policy=CONSISTENT_HASH_SUBSETTING
api
Fai una richiesta
PATCH
al metodoregionBackendServices/patch
.PATCH https://compute.googleapis.com/compute/beta/projects/
PROJECT_ID
/regions/us-west1/backendServices/l7-ilb-backend-service{ "subsetting": { "policy": CONSISTENT_HASH_SUBSETTING } }
Puoi anche perfezionare il bilanciamento del carico del backend impostando il criterio localityLbPolicy
.
Per ulteriori informazioni, consulta le norme sul traffico.
Passaggi successivi
Per informazioni sul funzionamento del bilanciamento del carico HTTP(S) interno, consulta Panoramica del bilanciamento del carico HTTP(S) interno.
Per gestire la risorsa di subnet solo proxy richiesta dal bilanciamento del carico HTTP(S) interno, consulta la sezione Subnet solo proxy per i bilanciatori del carico HTTP(S) interni.
Per scoprire come aggiornare il certificato SSL interno del bilanciatore del carico HTTP(S), vedi Utilizzo dei certificati SSL autogestiti.