Google Distributed Cloud (GDC) air-gapped fornisce i meccanismi del controllo di integrità che determinano se le istanze di backend rispondono correttamente al traffico. Questo documento descrive come creare e utilizzare i controlli di integrità per i bilanciatori del carico.
Salvo diversa indicazione,i controlli di integrità Google Cloud 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 è 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 consecutivi riusciti o non riusciti. In altre parole, 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, identificato dal controllo di integrità, non riceverà traffico tramite il bilanciatore del carico. Sei tu a definire i criteri per un probe riuscito. Per saperne di più, consulta la sezione Come funzionano i controlli di integrità.
Protocolli dei controlli 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à, tieni presente i seguenti fattori:
- Protocollo: il protocollo utilizzato da GDC per eseguire il probe 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à workload HTTP o HTTPS.
- Specifica della porta: la porta utilizzata da GDC 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 di zona. I controlli di integrità globali si estendono a tutte le zone di un deployment GDC, mentre i controlli di integrità di zona 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 in base ai criteri configurati. Il probe continuerà le sue valutazioni e riprenderà a inviare traffico al backend dopo che quest'ultimo sarà stato considerato nuovamente integro.
È importante notare che le impostazioni del controllo di integrità si applicano in modo uniforme a tutti i backend di un servizio di backend o di 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 emesso dallo 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 corretta 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 sonda del controllo di integrità in modo che invii richieste HTTP a un percorso di richiesta specifico anziché al percorso di richiesta 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, situati 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 prober | Criteri di successo |
| Né RequestPath né Response specificati | Il prober utilizza / come percorso della richiesta.
|
Solo codice di risposta HTTP 200 (OK).
|
| Sono stati specificati sia RequestPath che Response | Il prober 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.
|
| È specificato solo Response | Il prober 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 prober utilizza il percorso della richiesta configurato. | Solo codice di risposta HTTP 200 (OK).
|
Criteri di esito positivo 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:
- Dal prober del controllo di integrità che invia un pacchetto FIN o RST (reimpostazione).
- 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 Crea un progetto.
I ruoli di identità e accesso necessari:
- Chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Amministratore bilanciatore del carico (
load-balancer-admin). - Per i bilanciatori del carico interni globali, chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Amministratore del bilanciatore del carico globale (
global-load-balancer-admin). Per saperne di più, consulta Descrizioni dei ruoli predefiniti.
- Chiedi all'amministratore dell'organizzazione IAM di concederti il ruolo Amministratore bilanciatore del carico (
Crea e gestisci i controlli di integrità
GDC supporta i controlli di integrità globali e a livello di zona.
API HealthCheck
Puoi configurare un oggetto HealthCheck come globale o di zona. Gli oggetti HealthCheck globali vengono utilizzati per le configurazioni dei bilanciatori del carico globali, mentre gli oggetti HealthCheck di zona vengono utilizzati per le configurazioni dei bilanciatori del carico di zona. Entrambi i tipi hanno lo stesso nome e la stessa specifica. Tuttavia, utilizzano valori apiVersion e server API diversi:
- apiVersion di zona:
networking.gdc.goog - apiVersion globale:
networking.global.gdc.goog
Puoi anche utilizzare l'CLI gdcloud per creare e gestire i controlli di integrità.
Crea un HealthCheck globale
L'esempio seguente mostra come creare un HealthCheck 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 HealthCheck 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 accuratamente le impostazioni HealthCheck richieste.
Note aggiuntive sull'utilizzo
Le sezioni seguenti includono note aggiuntive sull'utilizzo dei controlli di integrità su Google Cloud.
Certificati e controlli di integrità
Per protocolli come HTTPS, che richiedono certificati sui backend,
- I certificati possono essere autofirmati o provenire 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 delle richieste personalizzate che configuri solo alle richieste dei 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 (predefinita)
- Soglia stato integro: 2 (predefinita)
Il controllo di integrità funzionerà come segue:
- 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 per la restituzione di un codice di stato HTTP
200 (OK)(i criteri di esito positivo designati per i protocolli HTTP e HTTPS).
- Un backend è considerato non integro se almeno un sistema di probe del controllo di integrità esegue le seguenti operazioni:
- Non riceve una risposta HTTP
200 (OK)per due probe consecutivi a causa di una connessione rifiutata, un timeout della connessione o un timeout del socket. - Riceve due risposte consecutive che non corrispondono ai criteri di esito positivo specifici del protocollo.
- Non riceve una risposta HTTP
- Un backend è considerato integro quando almeno un sistema di probe del controllo di integrità riceve due risposte consecutive che soddisfano i criteri di esito positivo specifici del protocollo.
In questo esempio, ogni prober avvia una connessione ogni 30 secondi. Tra i tentativi di connessione di un prober trascorrono 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.
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 composto solo da pod o solo da VM come endpoint. Al momento, un bilanciatore del carico deve essere composto solo da pod o solo da VM come endpoint.
- La mutabilità del bilanciatore del carico e del controllo di integrità associato non è ancora supportata.