Panoramica dei controlli di integrità

Google Cloud offre controlli di integrità configurabili per i backend del bilanciatore del carico Google Cloud, i backend Cloud Service Mesh e la riparazione automatica basata sulle applicazioni per i gruppi di istanze gestite. Questo documento illustra i principali concetti del controllo di integrità.

Se non diversamente indicato, i controlli di integrità di Google Cloud sono implementati da attività software dedicate che si connettono ai backend in base ai parametri specificati in una risorsa di controllo di integrità. Ogni tentativo di connessione è 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à complessivo per ciascun backend. I backend che rispondono correttamente per il numero di volte configurato sono considerati in stato integro. I backend che non riescono a rispondere correttamente per un numero di volte configurabile separatamente sono in stato non integro.

Lo stato di integrità complessivo di ciascun backend determina l'idoneità a ricevere nuove richieste o connessioni. Puoi configurare i criteri che definiscono un probe riuscito. Questo argomento è discusso in dettaglio nella sezione Come funzionano i controlli di integrità.

I controlli di integrità implementati da attività software dedicate usano route speciali non definite nella rete Virtual Private Cloud (VPC). Per maggiori 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 controlli di integrità e controlli di integrità legacy e i relativi protocolli supportati sono i seguenti:

• 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 controllo di integrità può utilizzare il protocollo HTTP sulla porta TCP 80 o il protocollo TCP per una porta denominata in un gruppo di istanze.

Non puoi convertire un controllo di integrità legacy in un controllo di integrità né convertire un controllo di integrità legacy in un controllo di integrità legacy.

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 quando si seleziona un controllo di integrità sono i seguenti:

• Categoria: controllo di integrità o controllo di integrità precedente. Solo i bilanciatori del carico di rete passthrough esterni basati su pool di destinazione richiedono controlli di integrità legacy. Per tutti gli altri prodotti, utilizzerai controlli di integrità regolari.
• Protocollo:protocollo utilizzato da Google Cloud per verificare i backend. È meglio utilizzare un controllo di integrità legacy il cui protocollo corrisponda a quello 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 metodi di specifica delle porte: --port e --use-serving-port. Per i controlli di integrità legacy, è disponibile un solo metodo: --port.

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

Guida al bilanciatore del carico

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

Note aggiuntive sull'utilizzo

• Per i backend di gruppi di istanze VM, i controlli di integrità vengono eseguiti solo sulle istanze VM avviate. Le istanze VM arrestate non ricevono pacchetti per il controllo di integrità.

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

• Un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione deve utilizzare un controllo di integrità HTTP legacy. Non può utilizzare un controllo di integrità HTTPS legacy o qualsiasi controllo di integrità non legacy. Se utilizzi 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 ai probe del controllo di integrità.
  
  Per quasi tutti gli altri tipi di bilanciatore del carico, devi utilizzare controlli di integrità regolari e non legacy, in cui il protocollo corrisponde a quello del servizio di backend del bilanciatore del carico.

• Per i servizi di backend che utilizzano il protocollo gRPC, utilizza solo i controlli di integrità gRPC o TCP. 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 maggiori informazioni, consulta la panoramica dei NEG ibridi.

Controllo di integrità con Cloud Service Mesh

Tieni presente le seguenti differenze di 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 di tipo INTERNET_FQDN_PORT e NON_GCP_PRIVATE_IP_PORT è diverso da quello di altri tipi di endpoint di rete. Anziché utilizzare le attività software dedicate, Cloud Service Mesh programma proxy Envoy per eseguire controlli di integrità per i NEG internet (INTERNET_FQDN_PORT endpoint) e i NEG ibridi (NON_GCP_PRIVATE_IP_PORT endpoint).

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

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

• Se Cloud Service Mesh è integrato con Service Directory e associ un servizio Service Directory a un servizio di backend Cloud Service Mesh, non puoi impostare un controllo di integrità sul 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à o un controllo di integrità legacy, devi specificare i seguenti flag o accettare i relativi valori predefiniti. Ogni controllo di integrità o controllo di integrità legacy che crei è implementato da più probe. Questi flag controllano la frequenza con cui ogni sonda valuta le istanze nei gruppi di istanze o negli endpoint nei NEG a livello di zona.

Le impostazioni di un controllo di integrità non possono essere configurate per singoli backend. I controlli di integrità sono associati a un intero servizio di backend. Per un bilanciatore del carico di rete passthrough esterno basato su pool di destinazione, un controllo di integrità HTTP legacy è associato all'intero pool di destinazione. Pertanto, i parametri del probe sono gli stessi per tutti i backend a cui fa riferimento un determinato servizio di backend o pool di destinazione.

Intervalli IP e regole firewall del probe

Affinché i controlli di integrità funzionino, devi creare regole firewall allow in entrata in modo 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:

Importanza delle regole firewall

Google Cloud richiede la creazione delle regole firewall allow in entrata necessarie per consentire il traffico dai prober ai tuoi backend. Come best practice, limita queste regole solo ai protocolli e alle porte che corrispondono a quelli utilizzati dai controlli di integrità. Per gli intervalli IP di origine, assicurati di utilizzare gli intervalli IP di probe documentati elencati nella sezione precedente.

Se non hai regole firewall allow in entrata che consentono il controllo di integrità, la regola deny implicita blocca il 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

Considera le seguenti informazioni quando pianifichi i controlli di integrità e le regole firewall necessarie:

• Gli intervalli IP del probe appartengono a Google. Google Cloud utilizza route speciali al di fuori della tua rete VPC, ma all'interno della rete di produzione di Google, per facilitare la comunicazione da parte dei probe.

• Google utilizza gli intervalli IP dei probe per inviare probe del controllo di integrità per Application Load Balancer esterni e bilanciatori del carico di rete proxy esterni. Se un pacchetto viene ricevuto da internet e l'indirizzo IP di origine del pacchetto è compreso in un intervallo IP del probe, Google elimina il pacchetto. Include l'indirizzo IP esterno di un'istanza Compute Engine o un nodo Google Kubernetes Engine (GKE).

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

Più probe e frequenza

Google Cloud invia probe del 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 di integrità: più prober valutano contemporaneamente le istanze nei backend dei gruppi di istanze o gli endpoint nei backend NEG a livello di zona. In caso di errore di un prober, Google Cloud continua a monitorare gli stati di integrità del backend.

Le impostazioni di intervallo e timeout configurate per un controllo di integrità vengono applicate a ogni dispositivo di controllo. Per un determinato backend, i log di accesso al software e tcpdump mostrano 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 l'effetto di più probe simultanei prendendo in considerazione 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 una frequenza di controllo associata, inversamente proporzionale all'intervallo di controllo configurato:

    ¹⁄_{(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 servizio di backend.

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

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

• Più regole di forwarding per bilanciatori del carico di rete passthrough esterni. Se hai configurato più regole di forwarding che puntano allo stesso servizio di backend o pool di destinazione, Google Cloud utilizza più probe per controllare ogni indirizzo IP. La frequenza del probe per VM di backend viene moltiplicata per il numero 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 alla stessa mappa URL, Google Cloud utilizza più probe per verificare l'indirizzo IP associato a ciascun proxy di destinazione. La frequenza del probe per servizio di backend viene moltiplicata per il numero di 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 servizio di backend, Google Cloud utilizza più probe per verificare l'indirizzo IP associato a ciascun proxy di destinazione. La frequenza del probe per servizio di backend viene moltiplicata per il numero di proxy di destinazione configurati.

• Somma sui servizi di backend. Se un backend viene utilizzato da più servizi di backend, le istanze di backend vengono contattate con la stessa frequenza della 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 di probe del controllo di integrità. Ad esempio, lo stesso endpoint può trovarsi in più NEG a livello di zona. Questi NEG a livello di zona non hanno necessariamente lo stesso insieme di endpoint ed 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 cui i 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 associarsi all'indirizzo IP del bilanciatore del carico (o a qualsiasi indirizzo IP 0.0.0.0).

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 la consegna di un codice di stato HTTP 200 (OK) prima del timeout probe. Puoi anche eseguire le seguenti operazioni:

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

• Se configuri un 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 disponibili per i controlli di integrità che utilizzano i protocolli HTTP, HTTPS e HTTP/2.

Criteri di successo per SSL e TCP

A meno che non specifichi una stringa di risposta prevista, i probe per i controlli di integrità che utilizzano i protocolli SSL e TCP hanno esito positivo se entrambe le seguenti condizioni di base sono vere:

• Ogni prober Google Cloud può completare correttamente un 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 invia un pacchetto TCP RST (reimpostazione) mentre è ancora stabilita la sessione TCP al prober

Se il backend invia un pacchetto TCP RST (reimpostazione) per chiudere una sessione TCP 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 controllata.

Puoi creare un controllo di integrità basato sui contenuti se fornisci una stringa di richiesta e una stringa di risposta prevista, ognuna con una lunghezza massima di 1024 caratteri ASCII (byte singolo). Quando si configura 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.

Le seguenti combinazioni di flag di richiesta e risposta sono disponibili per i controlli di integrità che utilizzano i protocolli SSL e TCP.

Criteri di successo per gRPC

Se utilizzi i controlli di integrità gRPC, assicurati che il servizio gRPC invii la 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 i controlli di integrità gRPC
• Documentazione gRPC per i controlli di integrità

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 viene considerato riuscito. Tutti gli altri codici di risposta HTTP, incluso un reindirizzamento (301, 302), sono considerati non integri.

Stato di integrità

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

Google Cloud considera i backend in integrità dopo aver raggiunto questa soglia in stato integro. I backend in stato integro sono idonei a ricevere nuove connessioni.

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

Le connessioni esistenti potrebbero non restituire le risposte, a seconda della causa del errore del probe. Un backend non integro può diventare integro se riesce a raggiungere di nuovo la soglia di stato integro.

Il comportamento specifico quando tutti i backend sono in stato non integro varia a seconda del tipo di bilanciatore del carico in uso:

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 di integrità basato sui contenuti i cui criteri di successo dipendono dalla valutazione di una stringa di risposta prevista. Utilizza un controllo di integrità basato sui contenuti per indicare ai probe del controllo di integrità di Google Cloud di 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 un percorso di richiesta. Per maggiori dettagli, vedi Criteri di successo per HTTP, HTTPS e HTTP/2.

• Puoi configurare un controllo di integrità basato sui contenuti SSL o TCP specificando una stringa di risposta prevista e, facoltativamente, definendo una stringa di richiesta. Per ulteriori dettagli, 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 l'utilizzo di certificati (SSL, HTTPS e HTTP/2) da parte dei backend, ad esempio:

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

Intestazioni

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

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

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. Più sistemi ridondanti vengono configurati contemporaneamente con i parametri del controllo di integrità. Le impostazioni di intervallo e timeout vengono applicate a ciascun sistema. Per maggiori informazioni, consulta Frequenza e probe multipli.

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

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

3. Un backend è considerato non integro quando almeno un sistema di probe del controllo di integrità 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 della connessione o del socket.
   2. Riceve due risposte consecutive che non corrispondono ai criteri di successo specifici del protocollo.

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

In questo esempio, ogni prober avvia una connessione ogni 30 secondi. Tra i tentativi di connessione di un prober passano 30 secondi, indipendentemente dalla durata del timeout (indipendentemente dal fatto che la connessione sia scaduta o meno). In altre parole, 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 il logging dei controlli di integrità.