Configura il bilanciamento del carico basato sul controllo di integrità

Questo documento mostra come implementare la disponibilità elevata 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 a 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à a livello di regione, GKE monitora i carichi di lavoro a livello di rete e indirizza 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 essere in esecuzione su 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 un solo 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 nodo. field to ensure proper distribution of Pods.
  • 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 dall'esterno del carico di lavoro. Il traffico avviato dall'interno del carico di lavoro all'indirizzo IP permanente non è supportato.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai installato in precedenza gcloud CLI, scarica la versione più recente eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

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à:

  1. Crea un controllo di integrità a livello di regione: definisci i parametri che GKE utilizza per monitorare lo stato dei pod. Questo oggetto indica al livello di rete quali endpoint sono integri e idonei a ricevere traffico dall'indirizzo IP permanente.
  2. Crea un cluster: configura un cluster GKE con GKE Dataplane V2 e l'API Gateway abilitati. Questi componenti forniscono l'infrastruttura sottostante necessaria per gestire il routing IP permanente e il bilanciamento del carico basato sul controllo di integrità.
  3. Prenota un indirizzo IP: seleziona e prenota un indirizzo IP statico interno o esterno indirizzo IP nella stessa regione del cluster. Questo indirizzo funge da punto di ingresso permanente che GKE distribuirà nel pool di pod attivi o di backup.
  4. Crea un gateway: configura un oggetto Gateway per gestire gli indirizzi IP permanenti prenotati. L'oggetto GKEIPRoute richiede e utilizza indirizzi IP specifici dal gateway per i carichi di lavoro.
  5. Crea un oggetto GKEIPRoute: definisci le regole di routing che mappano l'indirizzo IP permanente a un gruppo di pod utilizzando i selettori di etichette. All'interno di questo oggetto, fai riferimento al controllo di integrità a livello di regione e, facoltativamente, designa i pod di backup per gli scenari di failover.
  6. 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 per indirizzare il traffico.

Passaggio 1: crea un controllo di integrità a livello di regione 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 di 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 raggiungere i nodi, devi anche creare regole firewall. Google Cloud

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 multi-rete per i pod.

Passaggio 3: prenota gli indirizzi IP

Prenota gli indirizzi IP che vuoi utilizzare per i carichi di lavoro. Puoi scegliere di prenotare gli indirizzi IP forniti da Google o di utilizzare i tuoi (BYOIP).

Passaggio 3a: prenota gli indirizzi IP forniti da Google

Per prenotare gli indirizzi IP esterni, esegui il comando seguente:

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 a livello di regione. Per un corretto funzionamento del routing, l'indirizzo IP e il cluster GKE devono trovarsi nella stessa regione.

Per prenotare gli indirizzi IP interni, esegui il comando seguente:

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, specificali tutti come elenco separato 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 principali della subnet selezionata.

Per garantire che il traffico venga indirizzato correttamente all'interno della rete privata, gli indirizzi IP interni devono appartenere alla subnet predefinita del cluster o alla subnet di rete aggiuntiva.

Per ulteriori informazioni sugli indirizzi IP esterni e interni o per scoprire come prenotare gli indirizzi utilizzando la Google Cloud console, consulta Prenotare un indirizzo IP esterno statico e Prenotare un indirizzo IP interno statico.

Passaggio 3b: utilizza i tuoi indirizzi IP (BYOIP)

Puoi utilizzare i tuoi indirizzi IP (BYOIP) anziché affidarti agli indirizzi IP 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 tu sia il proprietario dell'intervallo di indirizzi IP e, dopo aver importato gli indirizzi IP in Google Cloud, puoi assegnarli come indirizzi IP per i pod GKE. Per ulteriori informazioni, vedi Utilizzare i tuoi indirizzi 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, tieni presente 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 i dettagli 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 principali 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 nello stesso spazio dei nomi della risorsa GKEIPRoute. GKE distribuisce il traffico a tutti i pod integri che corrispondono a questo selettore. Se più pod corrispondenti risiedono 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 campo backupPodSelector. 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 gli spazi dei nomi in cui 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: trova i pod di backup in base alle relative etichette. Queste etichette devono essere distinte da quelle utilizzate nell'oggetto podSelector principale.

Per ulteriori dettagli sugli altri campi di questo manifest, vedi Creare l'oggetto GKEIPRoute object.

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 dall'applicazione. Gli indirizzi IP vengono gestiti a livello di routing di rete, ma la configurazione predefinita del pod non li riconoscerà. Devi configurare la specifica del pod in modo che riconosca e utilizzi l'indirizzo all'interno del pod. Per farlo, il pod richiede autorizzazioni con privilegi.

Puoi configurare la specifica del pod utilizzando una delle seguenti opzioni:

  • Modifica il sysctlnet.ipv4.ip_nonlocal_bind

    Puoi modificare le impostazioni di sistema per consentire all'applicazione di utilizzare indirizzi IP non assegnati direttamente alla sua interfaccia impostando il sysctl net.ipv4.ip_nonlocal_bind in securityContext del pod. Questa opzione è utile se l'applicazione può eseguire il binding 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 richiesto dall'oggetto GKEIPRoute a una delle interfacce del pod utilizzando un container di inizializzazione. In questo modo, l'indirizzo IP diventa visibile al pod come se fosse assegnato direttamente. Per questa operazione è 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_ADMIN

    Sostituisci ASSIGNED_IP con uno degli indirizzi IP assegnati all'oggetto GKEIPRoute.

  • Socket non elaborati:per un controllo ancora maggiore, l'applicazione potrebbe interagire direttamente con lo stack di rete (avanzato).

  • Stack di indirizzi IP dello spazio utente:in casi specifici, all'interno del pod potrebbe essere in esecuzione un'applicazione separata per gestire l'indirizzo IP (molto avanzato).

Passaggio 7: abilita ARP per gli indirizzi IP assegnati (solo rete predefinita)

Per generare richieste e risposte ARP (Address Resolution Protocol) valide e 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 comando seguente sul pod:

echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce

dove la variabile arp_announce controlla la modalità di gestione degli annunci ARP. Se la imposti su "2", ti assicuri che gli annunci ARP vengano creati per l'indirizzo IP permanente, 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. Questi slice fungono da registro di tutti i pod designati come destinazioni di routing per la route specifica.

GKE genera EndpointSlice separati per gli endpoint attivi e di backup. Il sistema scala automaticamente il numero di EndpointSlice in base al carico di lavoro. Sebbene un singolo EndpointSlice supporti fino a 1000 endpoint, GKE crea slice aggiuntivi se il numero di pod corrispondenti supera questo limite.

Per visualizzare tutti gli EndpointSlice per un oggetto GKEIPRoute specifico, esegui il comando seguente:

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 gli EndpointSlice specificamente 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, active o backup.
  • GKEIPROUTE_NAME: il nome dell'oggetto GKEIPRoute specifico.

Risolvere i problemi relativi al bilanciamento del carico basato sul controllo 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 è completa. 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 integri. Fino ad allora, tutto il traffico viene distribuito tra i pod attivi integri rimanenti.

Risoluzione

Se necessario, aggiorna le etichette del campo podSelector in modo che non corrispondano più a nessun pod attivo. GKE indirizza automaticamente il traffico al gruppo di backend.

GKEIPRoute è configurato, ma non tutti i pod ricevono traffico

Sintomo

Lo stato di 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 a tutti i pod, indipendentemente dal loro stato di integrità.

Risoluzione

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 di 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 che corrispondono allo stesso oggetto GKEIPRoute sono pianificati sullo stesso nodo. In altre parole, sullo stesso nodo sono presenti pod che corrispondono agli oggetti podSelector attivo e di backup.

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 di 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 di se stesso.

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 NoPodsFound

Sintomo

Il manifest GKEIPRoute mostra lo stato NoPodsFound, il che indica che non sono presenti pod negli 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 non averne.
  • Non esistono pod: se reactionMode == Exists, controlla se il pod è assegnato a un nodo controllando il campo pod.Spec.nodeName. Potrebbe non essere in esecuzione alcun pod nello spazio dei nomi di GKEIPRoute che corrisponda al selettore.
  • Pod non pronti: se reactionMode == ReadyCondition, controlla se lo stato del pod è READY. Se esiste un pod corrispondente, ma non è nello stato READY, il pod non può gestire il traffico e non viene selezionato.

Risoluzione

  • Controlla le etichette: verifica che le etichette nel campo podSelector dell'oggetto GKEIPRoute corrispondano alle etichette che hai applicato al pod previsto.
  • Verifica l'esistenza del pod: assicurati che esista effettivamente un pod con le etichette corrette 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 campo pod.Spec.nodeName.

  • Verifica la preparazione del pod: se reactionMode == ReadyCondition, controlla se lo stato del pod è READY. Assicurati che il pod sia nello stato Ready utilizzando il comando seguente:

    kubectl get pods -n NAMESPACE

    I pod in altri stati (ad esempio, Pending, Error) non vengono selezionati.

Stato Mutated quando è stato trovato un pod corrispondente e la programmazione dell'indirizzo IP GKEIPRoute è in corso

Sintomo

Lo stato di GKEIPRoute mostra Mutated, il che indica che la configurazione dell'indirizzo IP per un pod corrispondente è in corso.

Possibile causa

Puoi prevedere lo stato Mutated durante la configurazione mentre il sistema configura il datapath GKE e Google Cloud le risorse per l'indirizzo IP configurato.

Risoluzione

  1. Attendi e riprova: nella maggior parte dei casi, la procedura di configurazione viene completata automaticamente in breve tempo. Controlla lo stato dopo l'attesa. Se l'operazione va a buon fine, lo stato diventa Ready.

  2. Se necessario, approfondisci: se lo stato Mutated persiste per un periodo prolungato, potrebbe indicare un errore di configurazione. Esamina le altre condizioni di stato dell'oggetto GKEIPRoute:

    • Accepted: indica se la configurazione di GKEIPRoute è valida.
    • GCPReady: indica se le Google Cloud risorse sono configurate come previsto.

Cerca i messaggi di errore in queste condizioni per risolvere il problema.

Passaggi successivi