Risolvi i problemi di gestione degli indirizzi IP nei cluster VPC

Una gestione efficace degli indirizzi IP è fondamentale per la stabilità e la scalabilità dei cluster nativi di VPC di Google Kubernetes Engine (GKE). I problemi possono impedire la scalabilità o causare errori del workload, ad esempio la mancata pianificazione dei pod.

Utilizza questo documento per risolvere i problemi relativi all'allocazione degli indirizzi IP, alla stabilità della rete e alle funzionalità di networking avanzate nei cluster GKE nativi di VPC.

Queste informazioni sono rivolte principalmente agli amministratori e agli operatori della piattaforma che gestiscono l'infrastruttura di rete del cluster. Inoltre, aiuta gli sviluppatori di applicazioni a capire in che modo le limitazioni della rete sottostante, come lo spazio degli indirizzi IP esaurito, possono influire sui loro workload. Anche se gli sviluppatori potrebbero non configurare direttamente i VPC, comprendere questi problemi comuni li aiuta a collaborare meglio con gli amministratori e gli operatori della piattaforma per una risoluzione più rapida. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Diagnostica l'esaurimento degli indirizzi IP

L'esaurimento degli indirizzi IP nel cluster può impedire la scalabilità dei nodi e interrompere i workload. Questa sezione spiega come utilizzare il monitoraggio dell'utilizzo degli indirizzi IP in GKE per rilevare e risolvere potenziali problemi di esaurimento.

GKE calcola l'utilizzo degli indirizzi IP utilizzando i dati degli insight di Network Analyzer e di altre origini dati GKE. Questo monitoraggio è disponibile per tutti i cluster nativi di VPC.

Per visualizzare l'utilizzo degli indirizzi IP di un cluster, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Cluster Kubernetes.

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster che vuoi esaminare. Questa azione apre la pagina Dettagli del cluster.

  3. Vai alla pagina Utilizzo IP utilizzando uno dei seguenti metodi:

    • Seleziona la scheda Osservabilità, quindi nel menu di navigazione di Osservabilità fai clic su Utilizzo IP.

    • Nella sezione Networking, individua la riga Intervallo IPv4 pod del cluster (predefinito) e fai clic su Visualizza utilizzo IP.

  4. Controlla la colonna Stato dell'allocazione IP. Questa colonna mostra la percentuale di indirizzi IP allocati nell'intervallo di indirizzi IP del pod. GKE considera allocati tutti gli indirizzi IP nell'intervallo CIDR assegnato a un nodo, indipendentemente dal fatto che i singoli indirizzi IP siano assegnati ai pod. Questo comportamento significa che la percentuale riflette l'intero intervallo di pod per un nodo, non solo gli indirizzi IP in uso. Se i cluster condividono gli stessi intervalli di indirizzi IP, la percentuale di utilizzo mostra il totale combinato.

  5. Per una visualizzazione dettagliata dell'utilizzo degli indirizzi IP, inclusi gli intervalli CIDR, le informazioni sulle subnet e i suggerimenti, fai clic su Mostra dettagli.

Se l'utilizzo degli indirizzi IP è elevato (prossimo al 100%), prendi in considerazione queste soluzioni per evitare l'esaurimento degli indirizzi IP:

  • Aggiungi altri intervalli di indirizzi IPv4 dei pod utilizzando il CIDR multi-pod non contiguo. Questa funzionalità ti consente di aggiungere altri indirizzi IPv4 per i tuoi pod senza dover ricreare il cluster o configurare nuove subnet.
  • Aggiungi più subnet con intervalli di indirizzi IPv4 aggiuntivi nel cluster. Questa funzionalità consente ai nuovi pool di nodi di utilizzare gli indirizzi IP delle subnet appena aggiunte.
  • Crea un nuovo cluster con un valore inferiore per il numero massimo di pod. Questo approccio prenota meno indirizzi IP per ogni nodo, il che può aiutarti a gestire il consumo complessivo di indirizzi IP nell'intervallo di rete del cluster. Per saperne di più, consulta Configura il numero massimo di pod per nodo.
  • Se non hai un numero sufficiente di intervalli di indirizzi IP o di spazio di indirizzi RFC 1918, prendi in considerazione gli intervalli non RFC 1918 (incluso lo spazio di indirizzi di classe E).

Comprendi i calcoli per l'allocazione del CIDR dei pod GKE

Una fonte comune di confusione è che GKE non alloca dinamicamente i singoli indirizzi IP dei pod da un pool centrale on demand. Invece, quando un nuovo nodo si unisce al cluster, GKE ritaglia un blocco CIDR contiguo dall'intervallo di pod secondario della subnet e lo assegna esclusivamente a quel nodo.

Per evitare collisioni di riciclo degli IP durante i rapidi rollout dei pod, GKE alloca una dimensione del blocco per nodo pari al blocco di potenza di due più piccolo che contiene almeno 2 × numero massimo di pod per nodo indirizzi:

Per-node Pod CIDR block size (addresses) = 2^(ceil(log2(2 * max_pods_per_node)))
  • Configurazione predefinita (--max-pods-per-node=110): richiede almeno 2 × 110 = 220 indirizzi. La potenza di due più vicina è 256 indirizzi, che assegna un blocco /24 (256 indirizzi IP) a ogni nodo.
  • Impatto sulla capacità dei nodi del cluster: poiché ogni nodo utilizza un blocco /24 (256 indirizzi IP dei pod) indipendentemente dal numero di pod in esecuzione su quel nodo, il numero massimo di nodi supportati da un intervallo di pod secondario dipende direttamente dall'impostazione --max-pods-per-node:
Numero massimo di pod per nodo Blocco per nodo allocato Numero massimo di nodi per intervallo di pod /19 (8192 indirizzi IP) Numero massimo di nodi per intervallo di pod /16 (65.536 indirizzi IP)
110 (predefinito) /24 (256 indirizzi IP) 32 nodi 256 nodi
64 /25 (128 indirizzi IP) 64 nodi 512 nodi
32 (valore predefinito di Autopilot) /26 (64 indirizzi IP) 128 nodi 1024 nodi
16 /27 (32 indirizzi IP) 256 nodi 2048 nodi
8 /28 (16 indirizzi IP) 512 nodi 4096 nodi

Risolvi problemi di rete specifici

Le sezioni seguenti forniscono indicazioni per la risoluzione dei problemi relativi ai cluster nativi di VPC. Puoi anche visualizzare gli insight sull'utilizzo degli indirizzi IP di GKE.

La risorsa di rete predefinita non è pronta

Sintomi

Ricevi un messaggio di errore simile al seguente:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
Potenziali cause

Sono in corso operazioni parallele sulla stessa subnet. Ad esempio, è in corso la creazione di un altro cluster nativo di VPC oppure l'aggiunta o l'eliminazione di un intervallo secondario nella subnet.

Risoluzione

Riprova a eseguire il comando.

Valore non valido per IPCidrRange

Sintomi

Ricevi un messaggio di errore simile al seguente:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
Potenziali cause

Un altro cluster nativo di VPC è in fase di creazione contemporaneamente e sta tentando di allocare gli stessi intervalli nella stessa rete VPC.

Lo stesso intervallo secondario viene aggiunto alla subnet nella stessa rete VPC.

Risoluzione

Se questo errore viene restituito durante la creazione del cluster quando non sono stati specificati intervalli secondari, riprova a eseguire il comando di creazione del cluster.

Spazio di indirizzi IP libero insufficiente per i pod

Sintomi

Il cluster è bloccato in uno stato di provisioning per un periodo di tempo prolungato.

La creazione del cluster restituisce un errore del gruppo di istanze gestite (MIG).

Quando aggiungi uno o più nodi a un cluster, viene visualizzato il seguente errore:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
Possibili cause

Esaurimento degli indirizzi IP dei nodi: l'intervallo di indirizzi IP principale della subnet assegnata al cluster esaurisce gli indirizzi IP disponibili. In genere, questo accade quando si scalano i node pool o si creano cluster di grandi dimensioni.

Numero iniziale elevato di nodi nei node pool ridotti: GKE prenota gli indirizzi IP per i pod in base alla capacità iniziale richiesta al momento della creazione di un pool di nodi. Se crei un pool di nodi con un valore initial_node_count elevato e poi fare lo scale down del numero di nodi, GKE continua a prenotare lo spazio degli indirizzi IP in base al valore initial_node_count del pool di nodi o al numero attuale di nodi nel node pool, a seconda di quale sia il valore maggiore. Questa situazione può portare a uno stato in cui il cluster segnala l'esaurimento degli indirizzi IP anche se il numero attuale di nodi attivi è basso.

Esaurimento degli indirizzi IP dei pod: l'intervallo CIDR dei pod assegnato al cluster è pieno. Questo accade quando il numero di pod supera la capacità del CIDR del pod, in particolare con un'elevata densità di pod per nodo o deployment di grandi dimensioni.

Convenzioni di denominazione specifiche per le subnet: il modo in cui una subnet viene denominata in un messaggio di errore può aiutarti a capire se il problema riguarda l'intervallo di indirizzi IP dei nodi (da cui i nodi stessi ottengono il proprio indirizzo IP) o l'intervallo di indirizzi IP dei pod (da cui i container all'interno dei pod ottengono i propri indirizzi IP).

Esaurimento degli intervalli secondari (Autopilot): nei cluster Autopilot, gli intervalli secondari assegnati agli indirizzi IP dei pod sono esauriti a causa della scalabilità o dell'elevata densità dei pod.

Soluzione

Raccogli le seguenti informazioni sul tuo cluster: nome, versione del control plane, modalità di funzionamento, nome del VPC associato, nome della subnet e CIDR. Inoltre, prendi nota degli intervalli IPv4 dei pod del cluster predefiniti e aggiuntivi (inclusi nomi e CIDR), se il routing del traffico VPC nativo è abilitato e l'impostazione del numero massimo di pod per nodo sia a livello di cluster che di pool di nodi (se applicabile). Prendi nota dei pool di nodi interessati e dei relativi intervalli di indirizzi IP dei pod IPv4 e delle configurazioni del numero massimo di pod per nodo, se diversi dalle impostazioni a livello di cluster. Inoltre, registra le configurazioni predefinite e personalizzate (se presenti) per il numero massimo di pod per nodo nella configurazione del pool di nodi.

Conferma il problema di esaurimento degli indirizzi IP

  • Network Intelligence Center: controlla se sono presenti frequenze di allocazione degli indirizzi IP elevate negli intervalli di indirizzi IP dei pod in Network Intelligence Center per il tuo cluster GKE.

    Se in Network Intelligence Center osservi una frequenza di allocazione degli indirizzi IP elevata negli intervalli di pod, l'intervallo di indirizzi IP dei pod è esaurito.

    Se gli intervalli di indirizzi IP dei pod mostrano tassi di allocazione normali, ma continui a riscontrare l'esaurimento degli indirizzi IP, è probabile che l'intervallo di indirizzi IP dei nodi sia esaurito.

  • Audit log: esamina il campo resourceName nelle voci IP_SPACE_EXHAUSTED, confrontandolo con i nomi delle subnet o con i nomi degli intervalli di indirizzi IP dei pod secondari.

  • Controlla se l'intervallo di indirizzi IP esaurito è l'intervallo di indirizzi IP dei nodi o l'intervallo di indirizzi IP dei pod.

    Per verificare se l'intervallo di indirizzi IP esaurito è l'intervallo di indirizzi IP del nodo o l'intervallo di indirizzi IP del pod, controlla se il valore di resourceName nella parte ipSpaceExhausted di una voce di log IP_SPACE_EXHAUSTED è correlato al nome della subnet o al nome dell'intervallo di indirizzi IPv4 secondario per i pod utilizzati nel cluster GKE interessato.

    Se il valore di resourceName è nel formato "[Subnet_name]", l'intervallo di indirizzi IP del nodo è esaurito. Se il valore di resourceName è nel formato "[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]", l'intervallo di indirizzi IP dei pod è esaurito.

Risolvi l'esaurimento degli indirizzi IP dei pod:

  • Ridimensiona il CIDR del pod esistente: aumenta le dimensioni dell'intervallo di indirizzi IP del pod attuale. Puoi aggiungere intervalli IP pod al cluster utilizzando il CIDR multi-pod non contiguo.
  • Crea subnet aggiuntive: aggiungi al cluster subnet con CIDR dei pod dedicati.

Riduci i pod per nodo per liberare indirizzi IP:

Risolvi l'esaurimento degli indirizzi IP dei nodi:

  • Esamina la pianificazione degli indirizzi IP: assicurati che l'intervallo di indirizzi IP dei nodi sia in linea con i tuoi requisiti di scalabilità.
  • Crea un nuovo cluster (se necessario): se l'intervallo di indirizzi IP dei nodi è molto limitato, crea un cluster sostitutivo con un intervallo di indirizzi IP di dimensioni appropriate. Consulta Intervalli IP per cluster nativi di VPC e Pianificazione degli intervalli IP.

Comandi di diagnostica aggiuntivi e playbook di risoluzione non invasivi

Per accelerare la risoluzione dei problemi e risolvere l'esaurimento degli indirizzi IP riducendo al minimo i tempi di inattività del cluster, applica i seguenti playbook diagnostici e operativi:

1. Bisezione della riga di comando utilizzando Cloud Logging e il motore per suggerimenti

Per individuare i problemi di esaurimento degli indirizzi IP dalla riga di comando, esegui le seguenti attività:

  • Esegui una query su Cloud Logging per individuare eventi espliciti di esaurimento degli indirizzi IP: logquery resource.type="k8s_cluster" logName:"logs/container.googleapis.com" ("IP_SPACE_EXHAUSTED" OR "ran out of IPs" OR "wouldn't fit if a new node is added")
  • Esegui una query sull'API Recommender per ottenere insight automatici di Network Analyzer (utilizzo superiore all'80%): sh gcloud recommender insights list \ --insight-type=google.networkanalyzer.container.ipAddressInsight \ --project=PROJECT_ID --location=GLOBAL
2. Espansione della subnet principale in tempo reale (per l'esaurimento degli indirizzi IP principali dei nodi)

A differenza degli intervalli secondari, puoi espandere l'intervallo di indirizzi host IP principali di una subnet in tempo reale in Compute Engine senza ricreare i cluster o interrompere i workload:

gcloud compute networks subnets expand-ip-range SUBNET_NAME \
    --region=REGION \
    --prefix-length=NEW_PREFIX_LENGTH

Ad esempio, l'espansione di una subnet principale da /24 a /22 aumenta la capacità degli indirizzi IP dell'host VM principale da 252 a 1020 nodi VM.

3. Playbook per la migrazione pool di nodi blu/verde (per l'esaurimento degli indirizzi IP dei pod)

Se un pool di nodi esistente è bloccato in intervalli secondari di piccole dimensioni o nell'allocazione di indirizzi IP di grandi dimensioni della configurazione predefinita di --max-pods-per-node=110, esegui la migrazione dei workload a un nuovo pool di nodi con CIDR di dimensioni adeguate:

# Step 1: Add a new secondary IPv4 range to your subnet
gcloud compute networks subnets update SUBNET_NAME \
    --region=REGION \
    --add-secondary-ranges=NEW_SECONDARY_RANGE_NAME=NEW_CIDR

# Step 2: Register the new Pod range with your GKE cluster
gcloud container clusters update CLUSTER_NAME \
    --region=REGION \
    --additional-pod-ipv4-ranges=NEW_SECONDARY_RANGE_NAME

# Step 3: Launch a replacement node pool with right-sized --max-pods-per-node
gcloud container node-pools create pool-blue-v2 \
    --cluster=CLUSTER_NAME \
    --region=REGION \
    --max-pods-per-node=32 \
    --pod-ipv4-range=NEW_SECONDARY_RANGE_NAME \
    --enable-autoscaling --min-nodes=2 --max-nodes=60

# Step 4: Gracefully cordon and drain old nodes
kubectl cordon -l cloud.google.com/gke-nodepool=OLD_POOL_NAME
kubectl drain -l cloud.google.com/gke-nodepool=OLD_POOL_NAME --ignore-daemonsets --delete-emptydir-data --force --grace-period=300

# Step 5: Delete old node pool after workloads migrate
gcloud container node-pools delete OLD_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --region=REGION
4. Design dell'intervallo di classe E (240.0.0.0/4) con IP masquerading

Se la tua rete aziendale ha poco spazio di indirizzi RFC 1918, alloca blocchi IPv4 di Classe E (240.0.0.0/4) agli intervalli di pod secondari (questi blocchi forniscono oltre 268 milioni di indirizzi). Attiva l'agente di IP masquerading di GKE in modo che il traffico in uscita verso i database on-premise o altri endpoint di rete esistenti venga mascherato utilizzando l'indirizzo host RFC 1918 principale del nodo.

Esegui il debug dei problemi di esaurimento degli indirizzi IP con gcpdiag

gcpdiag è uno strumento open source. Non è un prodotto Google Cloud ufficialmente supportato. Puoi utilizzare lo strumento gcpdiag per identificare e risolvere Google Cloud i problemi del progetto. Per saperne di più, consulta il progetto gcpdiag su GitHub.

Per esaminare le cause dell'esaurimento degli indirizzi IP sui cluster Autopilot e GKE Standard, tieni presente quanto segue:
  • Stato del cluster: controlla lo stato del cluster se viene segnalato l'esaurimento degli indirizzi IP.
  • Network Analyzer: esegue query sui log di Stackdriver per i log di Network Analyzer per verificare se l'esaurimento degli indirizzi IP dei pod o dei nodi.
  • Tipo di cluster: controlla il tipo di cluster e fornisce suggerimenti pertinenti in base al tipo di cluster.

ConsoleGoogle Cloud

  1. Completa e poi copia il seguente comando. 
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. Apri la console Google Cloud e attiva Cloud Shell.
    3. Apri la console Cloud
  3. Incolla il comando copiato.
  4. Esegui il comando gcpdiag, che scarica l'immagine Docker gcpdiag, quindi esegue i controlli diagnostici. Se applicabile, segui le istruzioni di output per correggere i controlli non riusciti.

Docker

Puoi eseguire gcpdiag utilizzando un wrapper che avvia gcpdiag in un container Docker. Docker o Podman devono essere installati.

  1. Copia ed esegui il seguente comando sulla tua workstation locale. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Esegui il comando gcpdiag. 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

Visualizza i parametri disponibili per questo runbook.

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto contenente la risorsa
  • CLUSTER_NAME: il nome del cluster GKE di destinazione all'interno del progetto.
  • LOCATION: la zona o la regione in cui si trova il cluster.
  • start_time: l'ora in cui è iniziato il problema.
  • end_time: l'ora di fine del problema. Imposta l'ora corrente se il problema persiste.

Flag utili:

Per un elenco e una descrizione di tutti i flag dello strumento gcpdiag, consulta le istruzioni per l'utilizzo di gcpdiag.

Verifica se SNAT predefinito è disabilitato

Utilizza il seguente comando per controllare lo stato di SNAT predefinito:

gcloud container clusters describe CLUSTER_NAME

Sostituisci CLUSTER_NAME con il nome del tuo cluster.

L'output è simile al seguente:

networkConfig:
  disableDefaultSnat: true
  network: ...

Impossibile utilizzare --disable-default-snat senza --enable-ip-alias

Questo messaggio di errore e must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster indicano che devi impostare esplicitamente il flag --disable-default-snat durante la creazione del cluster, poiché utilizzi indirizzi IP pubblici nel cluster privato.

Se visualizzi messaggi di errore come cannot disable default sNAT ... , significa che non è possibile disattivare SNAT predefinito nel tuo cluster. Per risolvere il problema, esamina la configurazione del cluster.

Debug di Cloud NAT con SNAT predefinita disabilitata

Se hai un cluster privato creato con il flag --disable-default-snat e hai configurato Cloud NAT per l'accesso a internet, ma non vedi traffico verso internet dai tuoi pod, assicurati che l'intervallo di pod sia incluso nella configurazione di Cloud NAT.

Se si verifica un problema con la comunicazione tra pod, esamina le regole iptables sui nodi per verificare che gli intervalli di pod non siano mascherati dalle regole iptables.

Per saperne di più, consulta la documentazione sull'IP masquerading di GKE.

Se non hai configurato un agente di IP masquerading per il cluster, GKE si assicura automaticamente che la comunicazione tra pod non venga mascherata. Tuttavia, se è configurato un agente di IP masquerading, questo sostituisce le regole di IP masquerading predefinite. Verifica che nell'agente di IP masquerading siano configurate regole aggiuntive per ignorare il masquerading degli intervalli di pod.

La comunicazione della rete del cluster dual-stack non funziona come previsto

Possibili cause
Le regole del firewall create dal cluster GKE non includono gli indirizzi IPv6 assegnati.
Risoluzione
Per convalidare la regola firewall, segui questi passaggi:

  1. Verifica i contenuti della regola firewall:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Sostituisci FIREWALL_RULE_NAME con il nome della regola firewall.

    Ogni cluster dual-stack crea una regola firewall che consente ai nodi e ai pod di comunicare tra loro. I contenuti della regola firewall sono simili ai seguenti:

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    Il valore sourceRanges deve essere uguale a subnetIpv6CidrBlock. Il valore targetTags deve essere lo stesso dei tag sui nodi GKE. Per risolvere il problema, aggiorna la regola firewall con le informazioni sul blocco ipAllocationPolicy del cluster.

Passaggi successivi