Google Distributed Cloud (GDC) air-gapped fornisce meccanismi di controllo di integrità che determinano se le istanze di backend rispondono in modo appropriato al traffico. Questo documento descrive come creare e utilizzare i controlli di integrità per i bilanciatori del carico.
Se non diversamente indicato, Google Cloud i controlli di integrità vengono 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 viene chiamato probe. Google Cloud registra l'esito positivo o negativo di ogni probe.
Lo stato di integrità di ogni backend è determinato da un numero configurabile di probe riusciti o non riusciti consecutivi. ovvero configuri il numero di probe riusciti consecutivi necessari per contrassegnare un backend come integro e il numero di errori consecutivi per contrassegnarlo come non integro.
Questo stato di integrità determina se un backend è idoneo a ricevere nuove richieste o connessioni. Un backend non integro, come identificato dal controllo di integrità, non riceverà traffico tramite il bilanciatore del carico. Definisci i criteri per una sonda riuscita. Per saperne di più, consulta la sezione Come funzionano i controlli di integrità.
Protocolli di controllo di integrità
I controlli di integrità supportano i seguenti protocolli:
- TCP
- HTTP
- HTTPS
Seleziona un controllo di integrità
I controlli di integrità devono essere compatibili con il tipo di bilanciatore del carico e con i tipi di backend. Quando selezioni un controllo di integrità, prendi in considerazione i seguenti fattori:
- Protocollo:il protocollo utilizzato da GDC per eseguire il probing dei backend. I protocolli supportati sono TCP, HTTP e HTTPS. Il protocollo TCP è utile per i controlli di integrità di base che convalidano la connettività a un backend, mentre i protocolli HTTP e HTTPS forniscono meccanismi di controllo di integrità più granulari per le VM che eseguono già carichi di lavoro HTTP o HTTPS.
- Specifica della porta:la porta che GDC utilizza con il protocollo per verificare l'integrità di un backend. Devi specificare una porta per il controllo di integrità.
- Categoria:i controlli di integrità possono essere globali o zonali. I controlli di integrità globali si estendono a tutte le zone di un deployment GDC, mentre i controlli di integrità zonali corrispondono a una zona.
Come funzionano i controlli di integrità
Le sezioni seguenti descrivono il funzionamento dei controlli di integrità.
Probe
Quando stabilisci un controllo di integrità, definisci o accetti le impostazioni predefinite che regolano la frequenza con cui ogni probe valuta l'integrità degli endpoint associati. Queste impostazioni sono fondamentali perché il bilanciatore del carico interrompe l'instradamento delle richieste a un backend considerato non integro utilizzando i criteri che hai configurato. Il probe continuerà le sue valutazioni e riprenderà a inviare traffico al backend dopo che sarà di nuovo considerato integro.
È importante notare che le impostazioni del controllo di integrità si applicano uniformemente a tutti i backend in un servizio di backend o in un pool di destinazione e non possono essere configurate per backend.
| Flag di configurazione | Spiegazione | Valore predefinito |
| intervallo di controllo
|
Il tempo (in secondi) dall'inizio di un probe all'inizio del probe successivo dello stesso prober. | 5s (5 secondi)
|
| timeoutSec
|
Il tempo (in secondi) di attesa di un probe prima di dichiarare l'errore. | 5s (5 secondi)
|
| healthyThreshold
|
Il numero di probe sequenziali che devono riuscire affinché l'endpoint sia considerato integro. | 2 |
| unhealthyThreshold
|
Il numero di probe sequenziali che non devono riuscire affinché l'endpoint sia considerato non integro. | 2 |
Criteri di esito positivo per i controlli di integrità HTTP e HTTPS
Per i controlli di integrità HTTP e HTTPS, è necessario un codice di stato HTTP 200 (OK) per una risposta riuscita prima del timeout del controllo di integrità. Altri codici di risposta HTTP, inclusi i reindirizzamenti (ad esempio 301, 302), sono considerati non integri.
Oltre a richiedere un codice di risposta HTTP 200 (OK), puoi:
- Configura ogni probe di controllo di integrità per inviare richieste HTTP a un percorso della richiesta specifico anziché a quello predefinito,
/. - Configura ogni prober di controllo di integrità in modo che verifichi la presenza di una stringa di risposta prevista nel corpo della risposta HTTP. La stringa di risposta prevista deve essere costituita solo da caratteri ASCII stampabili a byte singolo e deve trovarsi nei primi 1024 byte del corpo della risposta HTTP.
La tabella seguente elenca le combinazioni valide dei campi requestPath e response disponibili per i controlli di integrità HTTP e HTTPS.
| Flag di configurazione | Comportamento del probe | Criteri di successo |
| Né RequestPath né Response specificati | Il probe utilizza / come percorso della richiesta.
|
Solo codice di risposta HTTP 200 (OK).
|
| Sono stati specificati sia RequestPath che Response | Il probe utilizza il percorso della richiesta configurato. | Il codice di risposta HTTP 200 (OK) e fino ai primi 1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere alla stringa di risposta prevista.
|
| È stata specificata solo la Risposta | Il probe utilizza / come percorso della richiesta.
|
Il codice di risposta HTTP 200 (OK) e fino ai primi 1024 caratteri ASCII del corpo della risposta HTTP devono corrispondere alla stringa di risposta prevista.
|
| È stato specificato solo RequestPath | Il probe utilizza il percorso della richiesta configurato. | Solo codice di risposta HTTP 200 (OK).
|
Criteri di successo per i controlli di integrità TCP
I controlli di integrità TCP hanno i seguenti criteri di successo di base:
- Per i controlli di integrità TCP, un prober del controllo di integrità deve aprire correttamente una connessione TCP al backend prima del timeout del controllo di integrità.
- Per i controlli di integrità TCP, la connessione TCP deve essere chiusa in uno dei seguenti modi:
- Il prober del controllo di integrità invia un pacchetto FIN o RST (reset).
- Il backend invia un pacchetto FIN.
- Se un backend invia un pacchetto TCP RST, il probe potrebbe essere considerato non riuscito se il prober del controllo di integrità ha già inviato un pacchetto FIN.
Prima di iniziare
Per configurare i probe del controllo di integrità, devi disporre di quanto segue:
- Essere proprietario del progetto per cui stai configurando il bilanciatore del carico. Per saperne di più, consulta Creare un progetto.
I ruoli di identità e accesso necessari:
- Chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore bilanciatore del carico (
load-balancer-admin). - Per i bilanciatori del carico interni globali, chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore bilanciamento del carico globale (
global-load-balancer-admin). Per saperne di più, consulta Descrizioni dei ruoli predefiniti.
- Chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore bilanciatore del carico (
Creare e gestire i controlli di integrità
GDC supporta i controlli di integrità globali e zonali.
API HealthCheck
Puoi configurare un oggetto HealthCheck come globale o zonale. Gli oggetti HealthCheck globali vengono utilizzati per le configurazioni del bilanciatore del carico globale, mentre gli oggetti HealthCheck zonali vengono utilizzati per le configurazioni del bilanciatore del carico zonale. Entrambi i tipi hanno lo stesso nome e la stessa specifica. Tuttavia, utilizzano valori apiVersion e server API diversi:
- apiVersion zonale:
networking.gdc.goog - apiVersion globale:
networking.global.gdc.goog
Puoi anche utilizzare gcloud CLI per creare e gestire i controlli di integrità.
Crea un globale HealthCheck
L'esempio seguente mostra come creare un controllo di integrità utilizzando l'API:
kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
namespace: PROJECT
name: my-hc
spec:
httpHealthCheck:
port: PORT
host: HOST
requestPath: requestPath
response: responseT
EOF
Crea un HealthCheck a livello di zona
L'esempio seguente mostra come creare un controllo di integrità utilizzando l'API:
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
namespace: PROJECT
name: my-hc
spec:
httpHealthCheck:
port: PORT
host: HOST
requestPath: requestPath
response: response
EOF
Per collegare un controllo di integrità a un bilanciatore del carico, consulta quanto segue:
Verifica della configurazione
Per assicurarti che la configurazione sia corretta, verifica la condizione Ready dell'oggetto HealthCheck. Questa condizione indica eventuali errori di configurazione. Inoltre, verifica che i campi riflettano con precisione le impostazioni HealthCheck richieste.
Note aggiuntive sull'utilizzo
Le seguenti sezioni includono note aggiuntive sull'utilizzo dei controlli di integrità su Google Cloud.
Certificati e controlli di integrità
Per i protocolli come HTTPS, che richiedono certificati sui backend,
- I certificati possono essere autofirmati o emessi da qualsiasi autorità di certificazione (CA).
- Sono accettati certificati scaduti o con data futura.
Intestazioni
Quando configuri i controlli di integrità per i protocolli HTTP o HTTPS, puoi specificare un'intestazione HTTP Host utilizzando il flag --host.
È importante notare che il bilanciatore del carico aggiunge le intestazioni della richiesta personalizzate che configuri solo alle richieste client, non ai probe del controllo di integrità. Pertanto, se il backend richiede un'intestazione specifica per l'autorizzazione che non è presente nel pacchetto del controllo di integrità, il controllo di integrità potrebbe non riuscire.
Esempio di controllo di integrità
Se un controllo di integrità è configurato con i seguenti parametri:
- Intervallo: 30 secondi
- Timeout: 5 secondi
- Protocollo: HTTP
- Soglia stato non integro: 2 (valore predefinito)
- Soglia stato integro: 2 (valore predefinito)
Il controllo di integrità funzionerà nel seguente modo:
- Ogni prober di controllo di integrità:
- Avvia una connessione HTTP da un indirizzo IP di origine all'istanza di backend ogni 30 secondi.
- Attendi fino a cinque secondi che venga restituito un codice di stato HTTP
200 (OK)(i criteri di esito positivo designati per i protocolli HTTP e HTTPS).
- Un backend viene considerato non integro se almeno uno dei sistemi di probe del controllo di integrità esegue le seguenti operazioni:
- Non riceve una risposta HTTP
200 (OK)per due probe consecutivi a causa di un rifiuto di connessione, di un timeout di connessione o di un timeout del socket. - Riceve due risposte consecutive che non sono in linea con i criteri di successo specifici del protocollo.
- Non riceve una risposta HTTP
- Un backend è considerato integro quando almeno uno dei sistemi di probe del controllo di integrità riceve due risposte consecutive che soddisfano i criteri di successo specifici del protocollo.
In questo esempio, ogni sonda avvia una connessione ogni 30 secondi. Tra un tentativo di connessione e l'altro di un probe trascorrono 30 secondi, indipendentemente dalla durata del timeout (che la connessione sia scaduta o meno). In altre parole, il timeout deve essere sempre inferiore o uguale all'intervallo e non lo aumenta mai.
Limitazioni
- I controlli di integrità di GDC gestiranno solo gli endpoint VM.
- I bilanciatori del carico con controlli di integrità non possono essere configurati con pod e VM come backend misti. Un bilanciatore del carico deve essere costituito solo da pod o solo da VM come endpoint. Al momento, un bilanciatore del carico deve essere costituito solo da pod o solo da VM come endpoint.
- La modificabilità del bilanciatore del carico e del controllo di integrità associato non è ancora supportata.