Questo documento mostra come implementare l'alta disponibilità per gli indirizzi IP permanenti su Google Kubernetes Engine (GKE) utilizzando il bilanciamento del carico basato sul controllo di integrità. Sebbene le configurazioni IP permanenti standard mappino un singolo indirizzo IP permanente a un singolo pod, il bilanciamento del carico basato sul controllo di integrità consente di distribuire il traffico da uno o più indirizzi IP permanenti in un pool di pod integri.
Per richiedere indirizzi IP permanenti specifici e identificare i pod che ricevono il traffico, crea una risorsa personalizzata GKEIPRoute. Integrando la risorsa GKEIPRoute con i controlli di integrità regionali, GKE monitora i tuoi workload a livello di rete e instrada il traffico solo ai pod pronti a riceverlo. Puoi anche designare pod di backup facoltativi utilizzando l'oggetto GKEIPRoute. GKE indirizza il traffico a questi pod di standby solo se tutti i pod attivi principali non superano il controllo di integrità.
Requisiti e limitazioni
- Per utilizzare il bilanciamento del carico basato sul controllo di integrità, il cluster deve utilizzare GKE versione 1.32.3-gke.1440000 o successive. GKE supporta la selezione dei pod di backup solo nella versione 1.35.0-gke.1403000 o successive.
- Nel cluster devono essere abilitati GKE Dataplane V2 e l'API Gateway.
- Un singolo oggetto GKEIPRoute supporta solo un pod corrispondente per nodo. Se più pod su un nodo corrispondono al selettore di pod di GKEIPRoute, GKE sceglie il pod creato più di recente sul campo di quel nodo per garantire la corretta distribuzione dei pod.
- Non puoi modificare una classe Gateway dopo aver creato l'oggetto GKEIPRoute.
- Il bilanciamento del carico basato sul controllo di integrità supporta solo il traffico avviato al di fuori del workload. Il traffico avviato dall'interno del workload all'indirizzo IP permanente non è supportato.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
installala e poi
inizializza
gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima
versione eseguendo il comando
gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
- Scopri di più sugli indirizzi IP.
Implementare il bilanciamento del carico basato sul controllo di integrità
Questa sezione riassume il flusso di lavoro per implementare il bilanciamento del carico basato sul controllo di integrità:
- Crea un controllo di integrità a livello di regione: definisci i parametri che GKE utilizza per monitorare lo stato dei tuoi pod. Questo oggetto indica al livello di rete quali endpoint sono integri e idonei a ricevere traffico dall'indirizzo IP permanente.
- Crea un cluster: configura un cluster GKE con GKE Dataplane V2 e l'API Gateway abilitate. Questi componenti forniscono l'infrastruttura di base necessaria per gestire il routing IP persistente e il bilanciamento del carico basato sul controllo di integrità.
- Prenota un indirizzo IP: seleziona e prenota un indirizzo IP interno o esterno statico nella stessa regione del cluster. Questo indirizzo funge da punto di ingresso persistente che GKE distribuirà nel tuo pool di pod attivi o di backup.
- Crea un gateway: configura un oggetto Gateway per gestire gli indirizzi IP permanenti riservati. L'oggetto GKEIPRoute rivendica e utilizza indirizzi IP specifici dal gateway per i tuoi carichi di lavoro.
- Crea un oggetto GKEIPRoute: definisci le regole di routing che mappano il tuo indirizzo IP permanente a un gruppo di pod utilizzando i selettori di etichette. All'interno di questo oggetto, fai riferimento al controllo di integrità regionale e, se vuoi, designa i pod di backup per gli scenari di failover.
- Visualizza gli endpoint corrispondenti: verifica che GKE abbia identificato correttamente i pod attivi e di backup esaminando gli EndpointSlice generati automaticamente. Questo passaggio conferma che le etichette corrispondono ai pod previsti e che il livello di rete è pronto a instradare il traffico.
Passaggio 1: crea un controllo di integrità regionale e regole firewall
Per creare un controllo di integrità a livello di regione, segui i passaggi descritti in Creare controlli di integrità. Il nome che fornisci qui verrà utilizzato nella configurazione GKEIPRoute. Ad esempio:
gcloud compute health-checks create http reg-lb-hc \
--region=us-central1 \
--check-interval=5s \
--timeout=5s \
--healthy-threshold=2 \
--unhealthy-threshold=2
Per consentire ai probe del controllo di integrità di Google Cloud raggiungere i tuoi nodi, devi anche creare regole firewall.
Passaggio 2: crea un cluster GKE
Crea un cluster con l'API Gateway e GKE Dataplane V2 abilitati. Ad esempio:
gcloud container clusters create cluster-1 \
--enable-dataplane-v2 \
--gateway-api=standard \
--region=us-central1
Se configuri l'oggetto GKEIPRoute su una rete VPC diversa dalla rete VPC predefinita del cluster, devi creare un cluster GKE con funzionalità multi-rete. Per ulteriori informazioni, vedi Configurare il supporto di più reti per i pod.
Passaggio 3: prenota gli indirizzi IP
Prenota gli indirizzi IP che vuoi utilizzare per i tuoi workload. Puoi scegliere tra la prenotazione di indirizzi IP forniti da Google o l'utilizzo dei tuoi (BYOIP).
Passaggio 3a: prenota gli indirizzi IP forniti da Google
Per prenotare indirizzi IP esterni, esegui questo comando:
gcloud compute addresses create ADDRESS_NAME \
--region=REGION
Sostituisci quanto segue:
ADDRESS_NAME: il nome che vuoi associare a questo indirizzo.REGION: la regione in cui vuoi prenotare questo indirizzo. Questa regione deve essere la stessa del pod a cui vuoi collegare l'indirizzo IP.Nota: devi specificare una regione quando prenoti un indirizzo IP perché le regole di forwarding, che gestiscono il routing del traffico per gli indirizzi IP permanenti, sono regionali. Per il corretto funzionamento del routing, l'indirizzo IP e il cluster GKE devono trovarsi nella stessa regione.
Per prenotare indirizzi IP interni, esegui questo comando:
gcloud compute addresses create ADDRESS_NAME \
--region REGION
--subnet SUBNETWORK \
--addresses IP_ADDRESS
Sostituisci quanto segue:
ADDRESS_NAME: i nomi di uno o più indirizzi che vuoi prenotare. In caso di più indirizzi, specifica tutti gli indirizzi come elenco, separati da spazi. Ad esempio, example-address-1 example-address-2 example-address-3.REGION: la regione per questa richiesta.SUBNETWORK: la subnet per questo indirizzo IPv4 interno.IP_ADDRESS: un indirizzo IP interno non utilizzato dall'intervallo di indirizzi IP primario della subnet selezionata.
Per garantire che il traffico venga instradato correttamente all'interno della rete privata, gli indirizzi IP interni devono appartenere alla subnet predefinita del cluster o alla subnet di rete aggiuntiva.
Per saperne di più sugli indirizzi IP esterni e interni o per scoprire come prenotare indirizzi utilizzando la console Google Cloud , consulta Prenota un indirizzo IP esterno statico e Prenota un indirizzo IP interno statico.
Passaggio 3b: Bring Your Own IP (BYOIP)
Puoi utilizzare i tuoi indirizzi IP (BYOIP) anziché affidarti a quelli forniti da Google. BYOIP è utile se hai bisogno di indirizzi IP specifici per le tue applicazioni o se stai spostando sistemi esistenti in Google Cloud. Per utilizzare BYOIP, Google verifica che l'intervallo di indirizzi IP sia di tua proprietà e, dopo l'importazione degli indirizzi IP in Google Cloud, puoi assegnarli come indirizzi IP per i pod GKE. Per saperne di più, consulta Bring Your Own IP.
Passaggio 4: crea oggetti Gateway
Crea un gateway utilizzando una delle seguenti classi Gateway che supportano solo il tipo di rete L3:
- gke-passthrough-lb-external-managed o
- gke-passthrough-lb-internal-managed.
L'esempio seguente definisce un gateway che gestisce un pool di indirizzi IP esterni:
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
name: lb-gateway
spec:
gatewayClassName: gke-passthrough-lb-external-managed
listeners:
- name: default
port: 443
protocol: none
allowedRoutes:
namespaces:
from: All
addresses:
- value: "34.123.10.1/32"
type: "gke.networking.io/cidr"
- value: "34.123.10.2/32"
type: "gke.networking.io/cidr"
Nell'esempio precedente, nota i seguenti campi:
- addresses: elenca tutti gli intervalli di indirizzi IP per i quali il gateway specifico gestisce le autorizzazioni.
- listeners: identifica gli spazi dei nomi da cui gli oggetti GKEIPRoute possono fare riferimento a questo gateway.
Per informazioni dettagliate sull'utilizzo di Listener, vedi Creare oggetti Gateway.
Passaggio 5: crea un oggetto GKEIPRoute con la configurazione del bilanciamento del carico e del controllo di integrità
Crea un oggetto GKEIPRoute in cui definisci i selettori di pod primari e di backup e associa il controllo di integrità creato nel passaggio 1.
kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
namespace: default
name: my-ip-route
spec:
parentRefs:
- name: lb-gateway
addresses:
- value: "34.123.10.1/32"
type: "gke.networking.io/cidr"
- value: "34.123.10.2/32"
type: "gke.networking.io/cidr"
network: default
podSelector:
matchLabels:
component: activePodSelector
loadBalancing:
healthCheckName: "reg-lb-hc"
backupPodSelector:
namespaceSelector:
matchLabels:
environment: test
dc: us-central
podSelector:
matchLabels:
component: backupPodSelector
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: default
name: proxy-deployment
spec:
replicas: 1
selector:
matchLabels:
component: proxy
template:
metadata:
# annotations: <- Include these lines if the pods are multi-nic pods
# networking.gke.io/default-interface: 'eth0'
# networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
labels:
component: proxy
spec:
containers:
- name: hello-app
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
Tieni presente quanto segue:
podSelector: identifica i pod attivi principali che ricevono traffico dagli indirizzi IP permanenti definiti. Questo campo utilizza le etichette per trovare i pod all'interno dello stesso spazio dei nomi della risorsa GKEIPRoute. GKE distribuisce il traffico su tutti i pod integri che corrispondono a questo selettore. Se più pod corrispondenti si trovano sullo stesso nodo, GKE seleziona solo il pod creato più di recente per ricevere il traffico. Le etichette definite qui non devono sovrapporsi a quelle nel campobackupPodSelector. Questo campo è modificabile.backupPodSelector: definisce i pod di standby che ricevono traffico solo se tutti i pod principali che corrispondono all'oggetto podSelector non superano i controlli di integrità. Questo selettore include quanto segue:namespaceSelector: determina in quali spazi dei nomi GKE esegue la ricerca per trovare questi pod di backup. Puoi limitare la ricerca a spazi dei nomi specifici utilizzando i selettori di etichette. Se questo campo viene omesso o è vuoto, GKE cerca i pod di backup in tutti gli spazi dei nomi del cluster.podSelector: abbina i pod di backup in base alle etichette. Queste etichette devono essere diverse da quelle utilizzate nell'oggetto podSelector principale.
Per maggiori dettagli sugli altri campi di questo manifest, consulta Crea l'oggetto GKEIPRoute.
Passaggio 6: utilizza gli indirizzi IP assegnati all'interno del pod
L'assegnazione di un indirizzo IP a un pod GKE utilizzando un oggetto GKEIPRoute non rende automaticamente utilizzabili gli indirizzi IP dalla tua applicazione. Gli indirizzi IP vengono gestiti a livello di routing di rete, ma la configurazione predefinita del pod non li rileva. Devi configurare la specifica del pod per riconoscere e utilizzare l'indirizzo all'interno del pod. Per farlo, il tuo Pod richiede autorizzazioni con privilegi.
Puoi configurare la specifica del pod utilizzando una delle seguenti opzioni:
Modifica
net.ipv4.ip_nonlocal_bindsysctlPuoi modificare le impostazioni di sistema per consentire alla tua applicazione di utilizzare indirizzi IP non assegnati direttamente alla sua interfaccia impostando
net.ipv4.ip_nonlocal_bindsysctl nel tuo podsecurityContext. Questa opzione è utile se la tua applicazione può essere associata a un indirizzo IP che non si trova su un'interfaccia.Aggiungi quanto segue alla specifica YAML di Deployment o StatefulSet in
spec.template.spec:securityContext: sysctls: - name: net.ipv4.ip_nonlocal_bind value: "1"Aggiungi l'indirizzo IP assegnato all'interfaccia del pod
Puoi aggiungere manualmente l'indirizzo IP rivendicato dall'oggetto GKEIPRoute a una delle interfacce del pod utilizzando un init container. In questo modo, l'indirizzo IP è visibile al pod come se fosse assegnato direttamente. Per questo è necessaria la funzionalità
NET_ADMIN.Aggiungi quanto segue alla specifica YAML di Deployment o StatefulSet in
spec.template.spec:initContainers: - name: configure-ips image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim command: ['sh', '-c', 'ip address add ASSIGNED_IP/32 dev eth0'] securityContext: capabilities: add: - NET_ADMINSostituisci
ASSIGNED_IPcon uno degli indirizzi IP assegnati all'oggetto GKEIPRoute.Socket non elaborati:per un controllo ancora maggiore, la tua applicazione può interagire direttamente con lo stack di rete (avanzato).
Stack di indirizzi IP userspace:in casi particolari, un'applicazione separata potrebbe essere eseguita all'interno del pod per gestire l'indirizzo IP (molto avanzato).
Passaggio 7: attiva ARP per gli indirizzi IP assegnati (solo rete predefinita)
Per generare richieste e risposte ARP (Address Resolution Protocol) valide e
per stabilire una nuova connessione a un pod utilizzando l'indirizzo IP assegnato dall'oggetto
GKEIPRoute sulla rete predefinita, devi configurare la variabile arp_announce.
Per impostare la variabile arp_announce, esegui il seguente comando sul pod:
echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce
dove la variabile arp_announce controlla la gestione degli annunci ARP. Se lo imposti su "2", gli annunci ARP vengono effettuati per l'indirizzo IP persistente, consentendo ad altri dispositivi sulla rete di conoscere la nuova associazione.
Passaggio 8: visualizza gli endpoint corrispondenti
Per gestire la distribuzione del traffico, GKE crea EndpointSlice per ogni oggetto GKEIPRoute. Queste sezioni fungono da registro di tutti i pod designati come destinazioni di routing per quella route specifica.
GKE genera EndpointSlice separati per gli endpoint attivi e di backup. Il sistema scala automaticamente il numero di EndpointSlice in base
al tuo carico di lavoro. Sebbene un singolo EndpointSlice supporti fino a 1000 endpoint, GKE crea slice aggiuntive se il numero di pod corrispondenti supera questo limite.
Per visualizzare tutte le EndpointSlice per un oggetto GKEIPRoute specifico, esegui questo comando:
kubectl get endpointslices --all-namespaces -l \
networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,\
networking.gke.io/gkeiproute-namespace=GKEIPROUTE_NAMESPACE
Sostituisci quanto segue:
GKEIPROUTE_NAME: il nome del manifest GKEIPRoute.GKEIPROUTE_NAMESPACE: lo spazio dei nomi del manifest GKEIPRoute.
L'output seguente mostra un esempio di EndpointSlice:
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: {gkeiproute_name-truncated}-{gkeiproute_namespace-truncated}-backup-{unique_hash}
namespace: {gkeiproute_namespace}
labels:
endpointslice.kubernetes.io/managed-by: gkeiproute-controller
networking.gke.io/gkeiproute-name: {gkeiproute_name}
networking.gke.io/gkeiproute-namespace: {gkeiproute_namespace}
networking.gke.io/pip-es-role: backup
ownerReferences:
- kind: GKEIPRoute
name: {gkeiproute_name}
apiVersion: networking.gke.io/v1
uid: {uid}
controller: true
addressType: IPv4
endpoints:
- addresses:
- "{pod_ip_address}"
targetRef:
Name: {pod_name}
nodeName: {node_name}
Per visualizzare EndpointSlice specifici per gli endpoint attivi o di backup,
filtra i risultati utilizzando l'etichetta pip-eps-role. Ad esempio:
kubectl get endpointslices --all-namespaces -l \
networking.gke.io/pip-eps-role=ROLE \
networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,
Sostituisci quanto segue:
ROLE: il tipo di endpoint che vuoi visualizzare,activeobackup.GKEIPROUTE_NAME: il nome dell'oggetto GKEIPRoute specifico.
Risolvere i problemi di bilanciamento del carico basato sui controlli di integrità
Questa sezione mostra come risolvere i problemi relativi al bilanciamento del carico basato sul controllo di integrità.
Alcuni pod attivi non sono integri, ma i pod di backup non ricevono traffico
Sintomo
Lo stato di GKEIPRoute mostra Ready, il che indica che la configurazione dell'indirizzo IP per i pod corrispondenti è completata. I controlli di integrità o altre diagnostiche
mostrano che alcuni pod attivi non sono integri. Tuttavia, i pod di backup non ricevono
traffico.
Causa
I pod di backup non ricevono traffico finché tutti i pod attivi non sono in stato non integro. Fino ad allora, tutto il traffico viene distribuito tra i pod attivi e integri rimanenti.
Risoluzione
Se necessario, aggiorna le etichette dei campi podSelector in modo che non corrispondano più a nessun pod attivo. GKE instrada automaticamente il traffico al gruppo di backend.
GKEIPRoute è configurato, ma non tutti i pod ricevono traffico
Sintomo
Lo stato GKEIPRoute mostra Ready, il che indica che la configurazione dell'indirizzo IP per i pod corrispondenti è completa, ma alcuni dei pod corrispondenti non ricevono traffico.
Causa
I pod che non ricevono traffico potrebbero non essere integri o potrebbero non rispondere correttamente ai controlli di integrità. Tieni presente che se tutti i pod corrispondenti non sono integri, GKE distribuisce il traffico tra tutti i pod, indipendentemente dal loro stato di integrità.
Risoluzione
- Verifica che il pod sia integro: utilizza Google Cloud CLI o la consoleGoogle Cloud per verificare che il pod risponda correttamente ai controlli di integrità.
- Esegui ulteriori indagini, se necessario: se il pod non è integro, verifica di aver configurato correttamente i firewall per i controlli di integrità e che il pod risponda.
Errori di configurazione del bilanciatore del carico non valida
Questa sezione ti aiuta a risolvere i problemi relativi agli errori di stato di GKEIPRoute.
Backup pod and active pod are on the same node
Sintomo
Lo stato GKEIPRoute segnala il seguente errore:
invalid LB configuration: Backup pod %s and active pod %s are on the same node %s. Active and backup pods must reside on different nodes.
Causa
Un pod attivo e un pod di backup corrispondenti allo stesso oggetto GKEIPRoute vengono pianificati sullo stesso nodo. In altre parole, esistono pod che corrispondono sia agli oggetti podSelector attivi sia a quelli di backup sullo stesso nodo.
Risoluzione
Assicurati che i pod attivi e di backup si trovino su nodi diversi. Aggiorna la configurazione di GKEIPRoute e modifica le etichette podSelector o backupPodSelector in modo che due pod sullo stesso nodo non corrispondano allo stesso oggetto GKEIPRoute.
Pod cannot be selected as both an active and a backup pod
Sintomo
Lo stato GKEIPRoute segnala il seguente errore:
invalid LB configuration: pod %s cannot be selected as both an active and a backup pod. Active and backup pod sets must be mutually exclusive
Causa
Uno o più pod corrispondono ai selettori di etichette sia per il campo podSelector (attivo)
sia per il campo backupPodSelector (standby). GKE richiede che questi
due gruppi si escludano a vicenda. Un singolo pod non può fungere da backup.
Risoluzione
Assicurati che i pod attivi e di backup siano univoci. Modifica il campo podSelector o il campo backupPodSelector nel manifest GKEIPRoute per utilizzare chiavi e valori di etichetta più specifici o distinti.
Stato di NoPodsFound
Sintomo
Il manifest GKEIPRoute mostra lo stato NoPodsFound, che indica che non ci sono pod all'interno degli spazi dei nomi con etichette corrispondenti.
Possibili cause
- Etichette errate: il pod con cui intendi utilizzare l'indirizzo IP configurato potrebbe avere etichette errate o nessuna etichetta.
- Non esistono pod: se il
reactionMode == Exists, controlla se il pod è assegnato a un nodo controllando il campopod.Spec.nodeName. Potrebbe non essere in esecuzione alcun pod nello spazio dei nomi di GKEIPRoute che corrisponda al selettore. - Pod non pronto: se
reactionMode == ReadyCondition, controlla se lo stato del pod èREADY. Se esiste un pod corrispondente, ma non si trova in uno statoREADY, il pod non può gestire il traffico e non viene selezionato.
Risoluzione
- Controlla le etichette: verifica che le etichette nel campo
podSelectordell'oggetto GKEIPRoute corrispondano alle etichette che hai applicato al pod di destinazione. - Verifica l'esistenza del pod: assicurati che un pod con le etichette corrette esista effettivamente negli spazi dei nomi dell'oggetto GKEIPRoute specificati dai listener del gateway.
Se
reactionMode == Exists, controlla se il pod è assegnato a un nodo controllando il campopod.Spec.nodeName. Conferma l'idoneità del pod: se
reactionMode == ReadyCondition, controlla se lo stato del pod èREADY. Assicurati che il pod sia nello statoReadyutilizzando il comando seguente:kubectl get pods -n NAMESPACEI pod in altri stati (ad esempio
Pending,Error) non sono selezionati.
Stato Mutated quando è stato trovato un pod corrispondente ed è in corso la programmazione dell'indirizzo IP GKEIPRoute
Sintomo
Lo stato GKEIPRoute mostra Mutated, il che indica che la configurazione dell'indirizzo IP per un pod corrispondente è in corso.
Possibile causa
Durante la configurazione, puoi aspettarti lo stato Mutated mentre il sistema
configura il percorso dati GKE e le risorse Google Cloud per l'indirizzo IP configurato.
Risoluzione
- Attendi e riprova: nella maggior parte dei casi, la procedura di configurazione viene completata
automaticamente in breve tempo. Controlla lo stato dopo l'attesa. Diventerà
Readyin caso di esito positivo. Esegui ulteriori indagini (se necessario): se lo stato
Mutatedpersiste per un periodo prolungato, potrebbe indicare un errore di configurazione. Esamina le altre condizioni di stato dell'oggetto GKEIPRoute:- Accettato: indica se la configurazione di GKEIPRoute è valida.
- GCPReady: indica se le risorse Google Cloud sono configurate come previsto.
Cerca i messaggi di errore in queste condizioni per risolvere il problema.
Passaggi successivi
- Scopri di più sugli indirizzi IP permanenti per i pod GKE