Risolvere i problemi di gestione degli indirizzi IP nei cluster VPC

Questa sezione fornisce indicazioni per la risoluzione dei problemi relativi ai cluster VPC nativi. Puoi anche visualizzare gli insight sull'utilizzo degli indirizzi IP di GKE.

La risorsa di rete predefinita non è pronta

Sintomi

Viene visualizzato un messaggio di errore simile al seguente:

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

Esistono operazioni parallele nella stessa subnet. Ad esempio, viene creato un altro cluster nativo di VPC o viene aggiunto o eliminato un intervallo secondario nella subnet.

Risoluzione

Riprova a eseguire il comando.

Valore non valido per IPCidrRange

Sintomi

Viene visualizzato un messaggio di errore simile al seguente:

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

Contemporaneamente viene creato un altro cluster nativo di VPC e si tenta 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 degli indirizzi IP liberi 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 relativo al 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 non dispone di indirizzi IP disponibili. Questo accade in genere quando esegui il ridimensionamento dei pool di nodi o crei cluster di grandi dimensioni.

Esaurimento degli indirizzi IP dei pod:l'intervallo CIDR del pod assegnato al cluster è pieno. Ciò si verifica quando il numero di pod supera la capacità del CIDR del pod, in particolare con una densità elevata di pod per nodo o con implementazioni di grandi dimensioni.

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

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

Soluzione

Raccogli le seguenti informazioni sul cluster: nome, versione del piano di controllo, modalità di funzionamento, nome della VPC associata, nome e CIDR della sottorete. Inoltre, prendi nota dell'intervallo IPv4 predefinito e di eventuali intervalli IPv4 dei pod del cluster aggiuntivi (inclusi nomi e CIDR), dell'eventuale attivazione del routing del traffico VPC nativo e dell'impostazione del numero massimo di pod per nodo sia a livello di cluster che di pool di nodi (se applicabile). Prendi nota di eventuali pool di nodi interessati e dei relativi intervalli di indirizzi IP IPv4 dei pod e delle configurazioni dei pod massimi per nodo, se sono 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 la presenza di tassi di allocazione degli indirizzi IP elevati negli intervalli di indirizzi IP dei pod in Network Intelligence Center per il tuo cluster GKE.

    Se noti una percentuale di allocazione degli indirizzi IP elevata negli intervalli di pod all'interno di Network Intelligence Center, significa che l'intervallo di indirizzi IP del pod è esaurito.

    Se gli intervalli di indirizzi IP dei pod mostrano tassi di allocazione normali, ma si verifica ancora un esaurimento degli indirizzi IP, è probabile che l'intervallo di indirizzi IP del nodo sia esaurito.

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

  • Verifica se l'intervallo di indirizzi IP esaurito è l'intervallo di indirizzi IP del nodo o l'intervallo di indirizzi IP del 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 del pod è esaurito.

Risolvi l'esaurimento degli indirizzi IP del pod:

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

Riduci il numero di 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 del nodo sia in linea con i tuoi requisiti di scalabilità.
  • Crea un nuovo cluster (se necessario): se l'intervallo di indirizzi IP del nodo è molto limitato, crea un cluster sostitutivo con le dimensioni appropriate dell'intervallo di indirizzi IP. Consulta Intervalli IP per i cluster VPC nativi e Pianificazione degli intervalli IP.

Risolvere i problemi di esaurimento degli indirizzi IP con gcpdiag

gcpdiag è uno strumento open source. Non è un prodotto Google Cloud supportato ufficialmente. Puoi utilizzare lo strumento gcpdiag per identificare e risolvere i problemi dei progetti Google Cloud. Per maggiori informazioni, consulta il progetto gcpdiag su GitHub.

Per esaminare le cause dell'esaurimento degli indirizzi IP nei cluster GKE Autopilot e standard, tieni presente quanto segue:
  • Stato del cluster:controlla lo stato del cluster se viene segnalato un esaurimento degli indirizzi IP.
  • Network Analyzer: esegue query sui log di Stackdriver per trovare i log di Network Analyzer al fine di verificare se è stato esaurito l'indirizzo IP del pod o del nodo.
  • Tipo di cluster:controlla il tipo di cluster e fornisce consigli pertinenti in base al tipo di cluster.

Console Google 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 Cloud Console
  3. Incolla il comando copiato.
  4. Esegui il comando gcpdiag, che scarica l'immagine Docker gcpdiag, quindi esegui i controlli diagnostici. Se applicabile, segui le istruzioni di output per risolvere i problemi relativi ai controlli non riusciti.

Docker

Puoi eseguire gcpdiag utilizzando un wrapper che avvia gcpdiag in un container Docker. È necessario installare Docker o Podman.

  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 tuo cluster.
  • start_time: l'ora di inizio del problema.
  • end_time: l'ora in cui il problema è terminato. 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.

Verificare se l'SNAT predefinito è disattivato

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

gcloud container clusters describe CLUSTER_NAME

Sostituisci CLUSTER_NAME con il nome del 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 l'SNAT predefinito nel cluster. Per risolvere il problema, esamina la configurazione del cluster.

Eseguire il debug di Cloud NAT con la SNAT predefinita disattivata

Se hai un cluster privato creato con il flag --disable-default-snat e hai configurato Cloud NAT per l'accesso a internet e non visualizzi il traffico destinato a 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 ulteriori informazioni, consulta la documentazione sulla maschera IP di GKE.

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

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

Possibili cause
Le regole firewall create dal cluster GKE non includono gli indirizzi IPv6 allocati.
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 uguale a quello dei tag sui nodi GKE. Per risolvere il problema, aggiorna la regola del firewall con le informazioni sul blocco del cluster ipAllocationPolicy.

Passaggi successivi