Panoramica dei controlli di integrità

Google Cloud offre controlli di integrità configurabili per il carico di Google Cloud bilanciatore del carico, Cloud Service Mesh backend e riparazione automatica basata su applicazioni per le istanze gestite gruppi. Questo documento tratta i principali concetti relativi al controllo di integrità.

Se non diversamente indicato, i controlli di integrità di Google Cloud sono implementati di attività software dedicate che si connettono ai backend in base ai parametri è specificato in una risorsa di controllo di integrità. Ogni tentativo di connessione viene chiamato probe. Google Cloud registra l'esito positivo o negativo di ogni probe.

In base a un numero configurabile di probe sequenziali riusciti o non riusciti, viene calcolato uno stato di integrità generale per ogni backend. Backend che rispondono correttamente per il numero di volte configurato vengono considerati sano. Backend che non rispondono correttamente per un'istanza un numero configurabile di volte è non integro.

Lo stato di integrità complessivo di ciascun backend determina l'idoneità a ricevere nuovi richieste o connessioni. Puoi configurare i criteri che definiscono un processo una sonda. Questo argomento viene discusso in dettaglio nella sezione Come i controlli di integrità. Google Workspace.

I controlli di integrità implementati da attività software dedicate usano route speciali che non sono definite nella rete Virtual Private Cloud (VPC). Per ulteriori informazioni, consulta Percorsi per i controlli di integrità.

Categorie, protocolli e porte del controllo di integrità

I controlli di integrità hanno una categoria e un protocollo. Le due categorie sono salute e controlli di integrità legacy con i relativi protocolli supportati:

• Controlli di integrità

  • Globale (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)
  • A livello di regione (gRPC, TCP, SSL, HTTP, HTTPS o HTTP/2)

• Controlli di integrità legacy:

  • Globale legacy (HTTP)
  • Globale legacy (HTTPS)

Il protocollo e la porta determinano il modo in cui vengono eseguiti i probe del controllo di integrità. Ad esempio, un il controllo di integrità può utilizzare il protocollo HTTP sulla porta TCP 80 o per una porta denominata in un gruppo di istanze.

Non puoi convertire un controllo di integrità legacy in un controllo di integrità e non puoi convertire un controllo di integrità in un controllo di integrità legacy.

Nota: il termine controllo di integrità non si riferisce ai controlli di integrità legacy. In questo documento, i controlli di integrità legacy sono chiamati esplicitamente controlli di integrità legacy. Inoltre, tieni presente che in questo documento viene utilizzato il termine gruppo di istanze per fare riferimento gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona e gruppi di istanze gestite a livello di regione gruppi di istanze.

Seleziona un controllo di integrità

I controlli di integrità devono essere compatibili con il tipo di bilanciatore del carico (o Cloud Service Mesh) e i tipi di backend. I fattori da considerare da considerare quando selezioni un controllo di integrità:

• Categoria: controllo di integrità o controllo di integrità precedente. Solo basate su pool di destinazione bilanciatori del carico di rete passthrough esterni richiedono controlli di integrità legacy. Per tutti gli altri prodotti, utilizzerai normali e controlli di integrità.
• Protocollo:protocollo utilizzato da Google Cloud per verificare i backend. È meglio utilizzare un controllo di integrità legacy il cui protocollo corrisponde al protocollo utilizzato dal servizio di backend o dal pool di destinazione del bilanciatore del carico. Tuttavia, i protocolli per il controllo di integrità e i protocolli del bilanciatore del carico non devono essere uguali.
• Specifiche della porta:porte utilizzate da Google Cloud con il protocollo. Devi specificare una porta per il controllo di integrità. I controlli di integrità hanno due porte metodi di specifica: --port e --use-serving-port. Per integrità legacy dei controlli, c'è un solo metodo: --port.

La sezione successiva descrive le selezioni valide per controllo di integrità per ciascun tipo di carico il bilanciatore del carico e il backend.

Guida al bilanciatore del carico

Questa tabella mostra la categoria, l'ambito e le specifiche della porta supportati per ogni bilanciatore del carico e tipo di backend.

Bilanciatore del carico	Tipo di backend	Categoria e ambito del controllo di integrità	Specifica della porta
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico ^1 Bilanciatore del carico di rete proxy esterno globale Bilanciatore del carico di rete proxy classico	NEG supportati	Controllo di integrità (globale)	Numero di porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (globale)	Numero di porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico delle applicazioni esterno regionale	NEG supportati	Controllo di integrità (regionale)	Numero di porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (regionale)	Numero di porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico di rete proxy interno tra regioni	NEG supportati	Controllo di integrità (globale)	Numero di porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (globale)	Numero di porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico delle applicazioni interno regionale Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy esterno regionale	NEG supportati	Controllo di integrità (regionale)	Numero di porta personalizzato (--port) Numero di porta dell'endpoint (--use-serving-port)
	Gruppi di istanze	Controllo di integrità (regionale)	Numero di porta personalizzato (--port) Porta denominata del servizio di backend (--use-serving-port)
Bilanciatore del carico di rete passthrough esterno ^2	Gruppi di istanze	Controllo di integrità (regionale)	Numero di porta personalizzato (--port)
	Istanze nei pool di destinazione	Controllo di integrità precedente (globale con il protocollo HTTP)	I controlli di integrità legacy supportano solo il numero di porta (--port).
Bilanciatore del carico di rete passthrough interno ^2	NEG supportati	Controllo di integrità (global o regionale)	Numero di porta personalizzato (--port)
	Gruppi di istanze	Controllo di integrità (global o regionale)	Numero di porta personalizzato (--port)

¹ Per i bilanciatori del carico delle applicazioni esterni, i controlli di integrità legacy non sono consigliati, ma sono a volte supportate, a seconda della modalità del bilanciatore del carico.

Modalità bilanciatore del carico	Controlli di integrità legacy supportati
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni classico	Sì, se entrambe le seguenti condizioni sono vere: I backend sono gruppi di istanze. Le VM di backend gestiscono il traffico che utilizza protocollo HTTPS.
Bilanciatore del carico delle applicazioni esterno regionale	No

² Non puoi utilizzare il flag --use-serving-port perché i servizi di backend utilizzati con i bilanciatori del carico di rete passthrough interni e i bilanciatori del carico di rete passthrough esterni si abbonano a qualsiasi porta denominata. Inoltre, i bilanciatori del carico di rete passthrough interni supportano solo NEG a livello di zona con GCE_VM_IP endpoint, senza informazioni sulle porte.

Note aggiuntive sull'utilizzo

• Per i backend di gruppi di istanze VM, i controlli di integrità vengono eseguiti solo sulla VM che vengono avviate. Le istanze VM arrestate ricevono pacchetti di controllo di integrità.

• Per i bilanciatori del carico di rete passthrough interni, puoi utilizzare solo TCP o UDP per il del servizio di backend. Se gestisci traffico HTTP da VM dietro un Network Load Balancer passthrough interno, ha senso utilizzare un controllo di integrità utilizzando il protocollo protocollo.

• Un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione deve utilizzare un controllo di integrità HTTP legacy. it non possono utilizzare un controllo di integrità HTTPS legacy o qualsiasi controllo di integrità non legacy. Se usa un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione per bilanciare il traffico TCP, devi eseguire un servizio HTTP sulle VM con bilanciamento del carico in modo che possano rispondere probe del controllo di integrità.
  
  Per quasi tutti gli altri tipi di bilanciatore del carico, devi utilizzare standard Controlli di integrità in cui il protocollo corrisponde al servizio di backend del bilanciatore del carico protocollo.

• Per i servizi di backend che utilizzano il protocollo gRPC, utilizza solo l'integrità gRPC o TCP controlli. Non utilizzare controlli di integrità HTTP(S) o HTTP/2.

• Alcuni bilanciatori del carico basati su Envoy che utilizzano backend NEG ibridi non supportano i controlli di integrità gRPC. Per ulteriori informazioni, consulta la sezione NEG ibridi Panoramica.

Controllo di integrità con Cloud Service Mesh

Nota le seguenti differenze nel comportamento quando utilizzi i controlli di integrità con Cloud Service Mesh.

• Con Cloud Service Mesh, il comportamento del controllo di integrità per gli endpoint di rete il tipo INTERNET_FQDN_PORT e NON_GCP_PRIVATE_IP_PORT è diverso dall'integrità il controllo del comportamento di altri tipi di endpoint di rete. Invece di utilizzare di attività software dedicate, Cloud Service Mesh programma proxy Envoy per eseguire controlli di integrità per NEG internet (INTERNET_FQDN_PORT endpoint) e ambienti ibridi NEG (NON_GCP_PRIVATE_IP_PORT endpoint).

  Envoy supporta i seguenti protocolli per il controllo di integrità:

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• Quando Cloud Service Mesh è integrato con Service Directory Associa un servizio Service Directory a Cloud Service Mesh non puoi impostare un controllo di integrità per il servizio di backend.

Come funzionano i controlli di integrità

Le sezioni seguenti descrivono il funzionamento dei controlli di integrità.

Probe

Quando crei un controllo di integrità oppure un controllo di integrità legacy, devi specificare i seguenti flag o accettarne i valori predefiniti. Ogni controllo di integrità o il controllo di integrità legacy che crei viene implementato di test. Questi flag controllano la frequenza con cui ciascun il probe valuta le istanze dei gruppi di istanze o degli endpoint nei NEG a livello di zona.

Le impostazioni di un controllo di integrità non possono essere configurate per singoli backend. Salute sono associati a un intero servizio di backend. Per un servizio basato su pool di destinazione Network Load Balancer passthrough esterno, un controllo di integrità HTTP legacy è associato l'intero pool di destinazione. Di conseguenza, i parametri del probe sono gli stessi per backend a cui fa riferimento un determinato servizio di backend o pool di destinazione.

Flag di configurazione	Finalità	Valore predefinito
Intervallo di controllo check-interval	L'intervallo di controllo è la quantità di tempo dall'inizio di un probe emesso da un prober all'inizio del probe successivo emessi dallo stesso prober. Le unità sono in secondi.	5s (5 secondi)
Timeout timeout	Il timeout è il tempo di attesa di Google Cloud per una risposta a un probe. Il suo valore deve essere minore o uguale al intervallo di controllo. Le unità sono in secondi.	5s (5 secondi)

Intervalli IP e regole firewall del probe

Affinché i controlli di integrità funzionino, devi creare regole firewall allow in entrata, in modo che che il traffico proveniente dai probe di Google Cloud possa connettersi ai tuoi backend.

La seguente tabella mostra gli intervalli IP di origine da consentire:

Prodotto	Intervalli IP di origine del probe	Esempio di regola firewall
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico di rete proxy esterno globale	35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64 2600:2d00:1:1::/64	Regole firewall per tutti i prodotti tranne i bilanciatori del carico di rete passthrough esterni
Bilanciatore del carico delle applicazioni esterno regionale ^1-2 Bilanciatore del carico delle applicazioni interno tra regioni ^1 Bilanciatore del carico delle applicazioni interno regionale ^1-2 Bilanciatore del carico di rete passthrough interno Bilanciatore del carico di rete proxy interno regionale^1, 2 Bilanciatore del carico di rete proxy interno tra regioni^1 Bilanciatore del carico di rete proxy esterno regionale^1, 2	35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64	Regole firewall per tutti i prodotti tranne i bilanciatori del carico di rete passthrough esterni
Bilanciatore del carico di rete proxy classico Bilanciatore del carico delle applicazioni classico Cloud Service Mesh, tranne i backend NEG internet e il NEG ibrido backend	35.191.0.0/16 130.211.0.0/22	Regole firewall per tutti i prodotti tranne i bilanciatori del carico di rete passthrough esterni
Bilanciatore del carico di rete passthrough esterno	Per il traffico IPv4 verso i backend: 35.191.0.0/16 209.85.152.0/22 209.85.204.0/22 Per il traffico IPv6 verso i backend: 2600:1901:8001::/48 ^3	Regole firewall per bilanciatori del carico di rete passthrough esterni
Bilanciatore del carico di rete passthrough interno	Per il traffico IPv4 verso i backend: 35.191.0.0/16 130.211.0.0/22 Per il traffico IPv6 verso i backend: 2600:2d00:1:b029::/64	Regole firewall per bilanciatori del carico di rete passthrough interni
Cloud Service Mesh con backend NEG internet e backend NEG ibridi	Indirizzi IP delle VM che eseguono il software Envoy	Esempio di regola firewall

¹ Non è necessario aggiungere gli intervalli di probe del controllo di integrità di Google a una lista consentita per gli ambienti ibridi NEG. Tuttavia, se utilizzi una combinazione di NEG ibridi e a livello di zona un unico servizio di backend, devi aggiungere la classe Google intervalli di probe del controllo di integrità a una lista consentita per i NEG a livello di zona.

² Per i NEG internet a livello di regione, i controlli di integrità sono facoltativi. Traffico proveniente dal caricamento I bilanciatori che utilizzano NEG internet regionali provengono dalla subnet solo proxy e poi Tradotto da NAT (utilizzando Cloud NAT) in manuale o allocato automaticamente e gli indirizzi IP NAT. Questo traffico include sia probe del controllo di integrità che dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta la sezione A livello di regione NEG: utilizza Cloud NAT per il traffico in uscita.

³ I bilanciatori del carico di rete passthrough esterni basati su pool di destinazione supportano solo il traffico IPv4 e i controlli di integrità possono essere inviati tramite il server dei metadati. In questo caso, le origini dei pacchetti per il controllo di integrità corrispondano all'indirizzo IP del server di metadati: 169.254.169.254. Non è necessario creare un firewall per autorizzare il traffico dal server dei metadati. Pacchetti da server di metadati sono sempre consentiti.

Importanza delle regole firewall

Google Cloud richiede la creazione del traffico allow in entrata necessario le regole firewall per consentire il traffico dai probe ai tuoi backend. Come migliore limita queste regole ai soli protocolli e porte che corrispondano a quelli utilizzati dai controlli di integrità. Per gli intervalli IP di origine, assicurati usano gli intervalli IP del probe documentati elencati nella sezione precedente.

Se non hai regole firewall allow in entrata che consentono il controllo di integrità, i blocchi implicita deny traffico in entrata. Quando i probe non riescono a contattare i backend, il bilanciatore del carico considera i tuoi backend in stato non integro.

Considerazioni sulla sicurezza per gli intervalli IP del probe

Prendi in considerazione le seguenti informazioni quando pianifichi i controlli di integrità e regole firewall:

• Gli intervalli IP del probe appartengono a Google. Google Cloud utilizza speciali route all'esterno del VPC ma all'interno della rete di produzione di Google per facilitare la comunicazione dai probatori.

• Google utilizza gli intervalli IP dei probe per inviare probe del controllo di integrità per bilanciatori del carico delle applicazioni esterni e bilanciatori del carico di rete proxy esterni. Se un pacchetto viene ricevute da internet e dall'IP di origine del pacchetto incluso in un intervallo IP del probe, Google elimina il pacchetto. Sono inclusi all'indirizzo IP esterno di un'istanza Compute Engine Nodo Google Kubernetes Engine (GKE).

• Gli intervalli IP del probe sono un insieme completo di possibili indirizzi IP utilizzati probe di Google Cloud. Se utilizzi tcpdump o uno strumento simile, potrebbe non osservare il traffico da tutti gli indirizzi IP in tutti gli intervalli IP del probe. Come best practice, crea regole firewall in entrata che consentano tutti i probe intervalli IP come origini. Google Cloud può implementare nuovi probe automaticamente senza notifica.

Più probe e frequenza

Google Cloud invia probe di controllo di integrità da più sistemi ridondanti chiamati prober. I prober utilizzano intervalli IP di origine specifici. Google Cloud non si affida a un solo prober per implementare un controllo controllo: più prober valutano contemporaneamente le istanze nell'istanza o gli endpoint nei backend NEG a livello di zona. Se un prober non funziona, Google Cloud continua a monitorare gli stati di integrità del backend.

Le impostazioni di intervallo e timeout configurate per un'integrità viene applicata a ogni prober. Per un determinato backend, i log degli accessi tcpdump mostra probe più frequenti rispetto alle impostazioni configurate.

Si tratta di un comportamento previsto e non è possibile configurare il numero di probe che Google Cloud utilizza per i controlli di integrità. Tuttavia, puoi stimare di più probe simultanee considerando i fattori riportati di seguito.

• Per stimare la frequenza di probe per servizio di backend, considera quanto segue:

  • Frequenza base per servizio di backend. Ogni controllo di integrità ha un frequenza di controllo associata, inversamente proporzionale intervallo di controllo:

    ¹⁄_{(intervallo di controllo)}

    Quando associ un controllo di integrità a un servizio di backend, stabilisci una frequenza di base utilizzata da ogni prober per i backend su quel backend completamente gestito di Google Cloud.

  • Fattore di scala della sonda. La frequenza di base del servizio di backend viene moltiplicata in base al numero di probe simultanei utilizzati da Google Cloud. Questo può variare, ma in genere è compreso tra 5 e 10.

• Regole di forwarding multiple per i bilanciatori del carico di rete passthrough interni. Se configurato più regole di forwarding interno (ognuna con un indirizzo IP diverso principale) che punta allo stesso servizio di backend interno a livello di regione, Google Cloud utilizza più probe per controllare ogni indirizzo IP. La sonda la frequenza per servizio di backend viene moltiplicata per il numero e le regole di forwarding.

• Più regole di forwarding per bilanciatori del carico di rete passthrough esterni. Se disponi configurato più regole di forwarding che puntano allo stesso servizio di backend pool di destinazione, Google Cloud utilizza più probe per controllare ogni IP . La frequenza di probe per VM di backend viene moltiplicata per di regole di forwarding configurate.

• Più proxy di destinazione per bilanciatori del carico delle applicazioni esterni. Se hai più proxy di destinazione che indirizzano il traffico allo stesso mappa URL, Google Cloud utilizza più prober per verificare l'indirizzo IP associato a ciascun proxy di destinazione. La frequenza di probe per servizio di backend viene moltiplicata per il numero di ai proxy di destinazione configurati.

• Più proxy di destinazione per bilanciatori del carico di rete proxy esterni e bilanciatori del carico di rete proxy interni regionali. Se hai configurato più proxy di destinazione che indirizzano il traffico allo stesso di servizio di backend, Google Cloud utilizza più probe per verificare l'indirizzo IP associato con ciascun proxy di destinazione. La frequenza del probe per servizio di backend viene moltiplicata in base al numero di proxy di destinazione configurati.

• Somma sui servizi di backend. Se un backend è in esecuzione utilizzate da più servizi di backend, le istanze di backend vengono contattate come spesso pari alla somma delle frequenze per il controllo di integrità di ciascun servizio di backend.

  Con i backend NEG a livello di zona, è più difficile determinare il numero esatto probe del controllo di integrità. Ad esempio, lo stesso endpoint può trovarsi in più zone NEG. Questi NEG a livello di zona non hanno necessariamente lo stesso insieme di endpoint, e endpoint diversi possono puntare allo stesso backend.

Destinazione per i pacchetti di probe

La tabella seguente mostra l'interfaccia di rete e gli indirizzi IP di destinazione a quali probe del controllo di integrità inviano i pacchetti, a seconda del tipo di bilanciatore del carico.

Per i bilanciatori del carico di rete passthrough esterni e i bilanciatori del carico di rete passthrough interni, l'applicazione deve essere associata l'indirizzo IP del bilanciatore del carico (o qualsiasi indirizzo IP 0.0.0.0).

Bilanciatore del carico	Interfaccia di rete di destinazione	Indirizzo IP di destinazione
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico di rete proxy esterno globale	Per i backend di gruppi di istanze, l'interfaccia di rete principale (nic0). Per i backend NEG a livello di zona con GCE_VM_IP_PORT endpoint, all'interfaccia di rete nella rete VPC associata con il NEG. Per i backend NEG a livello di zona con NON_GCP_PRIVATE_IP_PORT endpoint, l'endpoint deve rappresentare un'interfaccia di un raggiungibile tramite una route nel VPC associata al NEG e nella regione che contiene NEG.	Per i backend di gruppi di istanze, l'indirizzo IPv4 o IPv6 interno principale associata all'interfaccia di rete principale (nic0) di ogni istanza. Per i backend NEG a livello di zona con GCE_VM_IP_PORT endpoint, l'indirizzo IP dell'endpoint: un IPv4 interno primario o indirizzo dell'interfaccia di rete oppure un indirizzo IPv4 o IPv6 interno da un intervallo IP alias dell'interfaccia di rete. Per i backend NEG a livello di zona con NON_GCP_PRIVATE_IP_PORT endpoint, l'indirizzo IP dell'endpoint.
Bilanciatore del carico delle applicazioni classico Bilanciatore del carico delle applicazioni esterno regionale Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni interno Bilanciatore del carico di rete proxy classico Bilanciatore del carico di rete proxy interno regionale Bilanciatore del carico di rete proxy interno tra regioni Cloud Service Mesh	Per i backend di gruppi di istanze, l'interfaccia di rete principale (nic0). Per i backend NEG a livello di zona con GCE_VM_IP_PORT endpoint, all'interfaccia di rete nella rete VPC associata con il NEG. Per i backend NEG a livello di zona con NON_GCP_PRIVATE_IP_PORT endpoint, l'endpoint deve rappresentare un'interfaccia di un raggiungibile tramite una route nel VPC associata al NEG e nella regione che contiene NEG.	Per i backend di gruppi di istanze, l'indirizzo IPv4 interno principale associata all'interfaccia di rete principale (nic0) di ogni istanza. Per i backend NEG a livello di zona con GCE_VM_IP_PORT endpoint, l'indirizzo IP dell'endpoint: un indirizzo IPv4 interno primario dell'interfaccia di rete o di un indirizzo IPv4 interno da un IP alias dell'interfaccia di rete. Per i backend NEG a livello di zona con NON_GCP_PRIVATE_IP_PORT endpoint, l'indirizzo IP dell'endpoint.
Bilanciatore del carico di rete passthrough esterno	Interfaccia di rete principale (nic0)	L'indirizzo IP della regola di forwarding esterno. Se più regole di forwarding puntano allo stesso servizio di backend (per i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione, lo stesso pool di destinazione), Google Cloud invia probe all'indirizzo IP di ogni regola di forwarding. Ciò può causare un aumento del numero di probe.
Bilanciatore del carico di rete passthrough interno	Per i backend di gruppi di istanze e quelli del NEG a livello di zona con GCE_VM_IP endpoint, l'interfaccia di rete utilizzata dipende da configurazione del servizio di backend. Per maggiori dettagli, vedi Backend e interfacce di rete.	L'indirizzo IP della regola di forwarding interno. Se più regole di forwarding puntano allo stesso servizio di backend, Google Cloud invia probe all'indirizzo IP di ogni regola di forwarding. Ciò può comportare il numero di probe è aumentato.

Criteri di successo per HTTP, HTTPS e HTTP/2

Quando un controllo di integrità utilizza il protocollo HTTP, HTTPS o HTTP/2, ogni probe richiede l'invio di un codice di stato HTTP 200 (OK) prima del probe timeout. Puoi anche eseguire le seguenti operazioni:

• Puoi configurare i probe di Google Cloud per inviare richieste HTTP a un di un percorso di richiesta specifico. Se non specifichi un percorso di richiesta, viene utilizzato /.

• Se configuri controllo di integrità basato sui contenuti specificando una stringa di risposta prevista, Google Cloud deve trovare la stringa prevista entro i primi 1024 byte del corpo della risposta HTTP.

Le seguenti combinazioni di flag di percorso di richiesta e stringa di risposta sono disponibile per i controlli di integrità che utilizzano i protocolli HTTP, HTTPS e HTTP/2.

Flag di configurazione	Criteri di successo
Percorso richiesta request-path	Specifica il percorso dell'URL a cui Google Cloud invia il controllo di integrità richieste di probe. Se omesso, Google Cloud invia richieste di probe al percorso principale, /.
Risposta response	Il flag di risposta facoltativa ti consente di configurare una richiesta controllo di integrità. La stringa di risposta prevista deve essere minore o uguale a fino a 1024 caratteri ASCII (byte singolo). Quando è configurato, Google Cloud prevede che questa stringa rientri nei primi 1024 byte del oltre a ricevere un HTTP 200 (OK) codice di stato.

Criteri di successo per SSL e TCP

A meno che non specifichi una stringa di risposta prevista, il probe è sottoposto a controlli di integrità che i protocolli SSL e TCP hanno esito positivo quando entrambi i seguenti sono vere:

• Ogni prober di Google Cloud può completare handshake SSL o TCP prima del timeout del probe configurato.
• Per i controlli di integrità TCP, la sessione TCP viene terminata normalmente in base a:
  • Il backend, o
  • Il prober di Google Cloud che invia un pacchetto TCP RST (reimpostazione) mentre La sessione TCP verso il prober è ancora stabilita

Se il backend invia un pacchetto TCP RST (reimpostazione) per chiudere un sessione per un controllo di integrità TCP, il probe potrebbe essere considerato non riuscito. Questo accade quando Google Cloud Prober ha già avviato una terminazione TCP.

Puoi creare un controllo di integrità basato sui contenuti se fornisci una stringa di richiesta e una stringa di risposta prevista, ciascuno fino a 1024 caratteri ASCII (byte singolo) di lunghezza. Quando viene configurata una stringa di risposta prevista, Google Cloud considera un probe riuscito solo se le condizioni di base sono soddisfatte e la stringa di risposta restituita corrisponde esattamente alla stringa di risposta prevista.

Sono disponibili le seguenti combinazioni di flag di richiesta e risposta che utilizzano i protocolli SSL e TCP.

Flag di configurazione	Criteri di successo
Nessuna richiesta né risposta specificate Nessuno dei due flag specificato: --request, --response	Google Cloud considera il probe riuscito quando la base siano soddisfatte.
Richiesta e risposta specificate Entrambi i flag specificati: --request, --response	Google Cloud invia la stringa di richiesta configurata e attende per la stringa di risposta prevista. Google Cloud esamina il probe riuscito quando le condizioni di base sono soddisfatte e la risposta la stringa restituita corrisponde esattamente alla stringa di risposta prevista.
Solo la risposta specificata Flag specificati: solo --response	Google Cloud attende la stringa di risposta prevista e considera il probe ha esito positivo quando le condizioni di base sono soddisfatte e la stringa di risposta restituita corrisponde esattamente alla risposta prevista stringa. Devi usare --response da solo solo se invia automaticamente una stringa di risposta come parte del TCP handshake SSL.
Solo richiesta specificata Flag specificati: solo --request	Google Cloud invia la stringa di richiesta configurata e considera il probe ha esito positivo quando sono soddisfatte le condizioni di base. La risposta, se qualsiasi, non è selezionata.

Criteri di successo per gRPC

Se utilizzi i controlli di integrità gRPC, assicurati che il servizio gRPC invii Risposta RPC con lo stato OK e il campo di stato impostato su SERVING o NOT_SERVING di conseguenza.

Tieni presente quanto segue:

• I controlli di integrità gRPC vengono utilizzati solo con le applicazioni gRPC e Cloud Service Mesh.
• I controlli di integrità gRPC non supportano TLS.

Per ulteriori informazioni, consulta le seguenti risorse:

• Flag aggiuntivo per integrità gRPC controlli
• Documentazione di gRPC per l'integrità controlli

Criteri di successo per i controlli di integrità legacy

Se la risposta ricevuta dal probe di controllo di integrità legacy è HTTP 200 OK, il probe è considerato riuscito. Tutti gli altri codici di risposta HTTP, incluso un reindirizzamento (301, 302) sono considerati in stato non integro.

Stato di integrità

Google Cloud utilizza i seguenti flag di configurazione per determinare stato di integrità complessivo di ciascun backend verso il quale viene bilanciato il carico del traffico.

Flag di configurazione	Finalità	Valore predefinito
Soglia stato integro healthy-threshold	La soglia di stato integro specifica il numero di errori sequenziali i risultati del probe di tempo per un backend da considerare integro.	Una soglia di 2 e i sonde.
Soglia stato non integro unhealthy-threshold	La soglia di stato non integro specifica il numero di probe sequenziale non riuscito risultati non integri di un backend.	Una soglia di 2 e i sonde.

Google Cloud considera i backend in integrità dopo questo stato integro sia stata raggiunta la soglia. I backend in stato integro sono idonei a ricevere nuove connessioni.

Google Cloud considera i backend in stato non integro quando lo stato non è integro sia stata raggiunta la soglia. I backend in stato non integro non sono idonei a ricevere nuovi connessioni; tuttavia, le connessioni esistenti non vengono terminate immediatamente. La connessione rimane aperta fino a quando non si verifica un timeout o fino a quando il traffico non viene è caduto.

Le connessioni esistenti potrebbero non restituire le risposte, a seconda della causa il mancato funzionamento della sonda. Un backend non integro può diventare in stato integro se può soddisfare la soglia stato integro.

Il comportamento specifico quando tutti i backend sono in stato non integro varia a seconda del e il tipo di bilanciatore del carico che stai utilizzando:

Bilanciatore del carico	Comportamento quando tutti i backend sono in stato non integro
Bilanciatore del carico delle applicazioni classico	Restituisce un codice di stato HTTP "502" ai client quando tutti i backend sono non è integro.
Bilanciatore del carico delle applicazioni esterno globale Bilanciatore del carico delle applicazioni esterno regionale Bilanciatore del carico delle applicazioni interno	Restituisce un codice di stato HTTP "503" ai client quando tutti i backend sono non è integro.
Bilanciatori del carico di rete proxy	Termina le connessioni client quando tutti i backend sono in stato non integro.
Bilanciatori del carico di rete passthrough interni e bilanciatori del carico di rete passthrough esterni basati su servizio di backend	Distribuisci il traffico a tutte le VM di backend come ultima risorsa quando i backend sono in stato non integro e il failover non è configurato. Per ulteriori informazioni su questo comportamento, consulta Distribuzione del traffico per i bilanciatori del carico di rete passthrough interni e Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni basati sul servizio di backend.
Bilanciatori del carico di rete passthrough esterni basati su pool di destinazione	Distribuisci il traffico a tutte le VM di backend come ultima risorsa quando sono in stato non integro.

Note aggiuntive

Le sezioni seguenti includono alcune note aggiuntive sull'utilizzo dei controlli di integrità su Google Cloud.

Controlli di integrità basati sui contenuti

Un controllo di integrità basato sui contenuti è un controllo i cui criteri di successo dipendono dalla valutazione di una stringa di risposta prevista. Utilizza un controllo di integrità basato sui contenuti per indicare probe di controllo di integrità di Google Cloud per convalidare in modo più completo la risposta del backend.

• Puoi configurare un controllo di integrità basato sui contenuti HTTP, HTTPS o HTTP/2 specificando una stringa di risposta prevista e, facoltativamente, definendo una richiesta del tuo percorso di apprendimento. Per ulteriori dettagli, consulta Criteri di successo per HTTP, HTTPS e HTTP/2.

• Puoi configurare un controllo di integrità basato sui contenuti SSL o TCP specificando un la stringa di risposta prevista e, facoltativamente, definendo una stringa di richiesta. Per ulteriori informazioni Vedi Criteri di successo per SSL e TCP.

Certificati e controlli di integrità

I probe del controllo di integrità di Google Cloud non eseguono la convalida dei certificati, anche per i protocolli che richiedono ai backend di utilizzare certificati (SSL, HTTPS, e HTTP/2), ad esempio:

• Puoi utilizzare certificati autofirmati o certificati firmati da qualsiasi certificato l'autorità competente (CA).
• Sono accettati i certificati scaduti o non ancora validi.
• Né gli attributi CN né subjectAlternativeName devono corrispondere a un intestazione Host o record PTR DNS.

Intestazioni

I controlli di integrità che utilizzano qualsiasi protocollo, ma non i controlli di integrità legacy, ti consentono imposta un'intestazione proxy utilizzando il flag --proxy-header.

Controlli di integrità che utilizzano protocolli HTTP, HTTPS o HTTP/2 e integrità legacy ti consentono di specificare un'intestazione Host HTTP utilizzando il flag --host.

Se utilizzi intestazioni delle richieste personalizzate, tieni presente che il bilanciatore del carico aggiunge le intestazioni solo alle richieste del client, non ai probe del controllo di integrità. Se il backend richiede un'intestazione specifica per l'autorizzazione mancante e il pacchetto del controllo di integrità, il controllo di integrità potrebbe non riuscire.

Esempio di controllo di integrità

Supponi di configurare un controllo di integrità con le seguenti impostazioni:

• Intervallo: 30 secondi
• Timeout: 5 secondi
• Protocollo: HTTP
• Soglia di stato non integro: 2 (impostazione predefinita)
• Soglia stato integro: 2 (impostazione predefinita)

Con queste impostazioni, il controllo di integrità si comporta come segue:

1. Vengono configurati più sistemi ridondanti contemporaneamente parametri del controllo di integrità. Le impostazioni di intervallo e timeout vengono applicate a ciascun . Per ulteriori informazioni, vedi Più probe e frequenza.

2. Ogni prober del controllo di integrità esegue le seguenti operazioni:

   1. Avvia una connessione HTTP da uno degli IP di origine indirizzi IP all'istanza di backend ogni 30 secondi.
   2. Attende fino a cinque secondi un codice di stato HTTP 200 (OK) (il messaggio riuscito criteri per HTTP, HTTPS e HTTP/2 protocolli).

3. Un backend è considerato in stato non integro quando almeno un probe del controllo di integrità di sistema esegue le seguenti operazioni:

   1. Non riceve un codice di risposta HTTP 200 (OK) per due probe consecutivi. Ad esempio, la connessione potrebbe essere rifiutata o potrebbe esserci un timeout di connessione o socket.
   2. Riceve due risposte consecutive che non corrispondono al criteri di successo specifici del protocollo.

4. Un backend è considerato integro quando almeno un probe del controllo di integrità riceve due risposte consecutive che corrispondono al protocollo criteri di successo.

In questo esempio, ogni prober avvia una connessione ogni 30 secondi. Trenta tra un tentativo di connessione e l'altra, indipendentemente dal fatto che durata del timeout (indipendentemente dal fatto che la connessione sia scaduta o meno). In altre il timeout deve essere sempre inferiore o uguale all'intervallo e il timeout non aumenta mai l'intervallo.

In questo esempio, il tempo di ogni prober è il seguente, in secondi:

1. t=0: avvia il probe A.
2. t=5: Arresta la sonda A.
3. t=30: Avvia sonda B.
4. t=35: sonda di arresto B.
5. t=60: avvia la sonda C.
6. t=65: sonda di arresto C.

Passaggi successivi

• Per creare, modificare e utilizzare i controlli di integrità, vedi Utilizzare i controlli di integrità.
• Per risolvere i problemi relativi ai controlli di integrità, abilita Controllo di integrità il logging.