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 GKE.

La risorsa di rete predefinita non è pronta

Sintomi

Ricevi un messaggio di errore simile al seguente:

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

Esistono operazioni parallele sulla stessa subnet. Ad esempio, viene creato un altro cluster nativo di VPC oppure viene aggiunto o eliminato 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'
Possibili cause

Un altro cluster nativo di VPC viene creato contemporaneamente e 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 di 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 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. Ciò si verifica in genere quando si scalano i node pool o si creano cluster di grandi dimensioni.

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

Convenzioni di denominazione specifiche delle 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 (dove i nodi stessi ottengono il proprio indirizzo IP) o l'intervallo di indirizzi IP dei pod (dove i container all'interno dei pod ottengono i propri indirizzi IP).

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

Soluzione

Raccogli le seguenti informazioni sul tuo cluster: nome, versione del control plane, modalità di funzionamento, nome VPC associato e nome e CIDR della subnet. Inoltre, annota gli 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 a livello di cluster e di pool di nodi (se applicabile). Prendi nota di tutti i node pool interessati e dei relativi intervalli di indirizzi IP pod IPv4 specifici e delle configurazioni del numero massimo di pod per nodo, se differiscono 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 delpool di nodil.

Conferma il problema di esaurimento degli indirizzi IP

  • Network Intelligence Center: verifica 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 osservi un'elevata percentuale di allocazione degli indirizzi IP negli intervalli di pod all'interno di Network Intelligence Center, 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 dell'intervallo di indirizzi IP dei pod secondari.

  • Verifica se l'intervallo di indirizzi IP esaurito è l'intervallo di indirizzi IP del nodo o del pod.

    Per verificare se l'intervallo di indirizzi IP esaurito è l'intervallo di indirizzi IP dei nodi o l'intervallo di indirizzi IP dei 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 secondari 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 del 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 subnet con CIDR pod dedicati al cluster.

Riduci i pod per nodo per liberare indirizzi IP:

Esaurimento dell'indirizzo IP del nodo di indirizzo:

  • Rivedi 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 del nodo è fortemente vincolato, crea un cluster di sostituzione con un dimensionamento appropriato dell'intervallo di indirizzi IP. Consulta Intervalli IP per cluster VPC nativi e Pianificazione dell'intervallo IP.

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

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

Per esaminare le cause dell'esaurimento degli indirizzi IP nei cluster GKE Autopilot e Standard, considera quanto segue:
  • Stato del cluster:controlla lo stato del cluster se viene segnalato l'esaurimento degli indirizzi IP.
  • Analizzatore di rete:esegue query sui log di Stackdriver per i log dell'analizzatore di rete per verificare se si è verificato l'esaurimento dell'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.

Trusted Cloud console

  1. Completa e 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 Trusted 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 e poi 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. È 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 cluster.
  • start_time: l'ora in cui è iniziato il 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.

Conferma se SNAT predefinita è disabilitata

Utilizza il comando seguente 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 SNAT predefinito nel cluster. Per risolvere il problema, rivedi la configurazione del cluster.

Debug di Cloud NAT con SNAT predefinita disabilitata

Se hai creato un cluster privato con il flag --disable-default-snat e hai configurato Cloud NAT per l'accesso a internet e non vedi traffico diretto 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 da pod a 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 sul mascheramento IP di GKE.

Se non hai configurato un agente di mascheramento IP per il cluster, GKE garantisce automaticamente che la comunicazione da pod a pod non venga mascherata. Tuttavia, se è configurato un agente di mascheramento IP, questo sostituisce le regole di mascheramento IP predefinite. Verifica che siano configurate regole aggiuntive nell'agente di mascheramento IP 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
Puoi convalidare la regola firewall seguendo 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 di sourceRanges deve essere uguale a quello di subnetIpv6CidrBlock. Il valore di targetTags deve corrispondere ai tag sui nodi GKE. Per risolvere il problema, aggiorna la regola firewall con le informazioni del blocco ipAllocationPolicy del cluster.

Passaggi successivi