Risolvi 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 sulla stessa subnet. Ad esempio, un altro È in corso la creazione di un cluster nativo di VPC oppure un intervallo secondario è aggiungere o eliminare sulla 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'
Potenziali 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 nello stesso rete VPC.

Risoluzione

Se questo errore viene restituito durante la creazione del cluster quando non erano presenti intervalli secondari specificato, 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 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' is exhausted.
Possibili cause

Esaurimento degli indirizzi IP del nodo: l'intervallo di indirizzi IP principali della subnet assegnati al cluster esauriscono gli 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, piano di controllo la versione, la modalità di funzionamento, il nome del VPC associato, il nome della subnet e CIDR. 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 del loro indirizzo IP del pod IPv4 specifico e il numero massimo di configurazioni di pod per nodo se diversi a livello di cluster. Registra anche i valori predefiniti e personalizzati (se presenti) per il numero massimo di pod per nodo nella configurazione del pool di nodi.

Conferma il problema di esaurimento dell'indirizzo 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 un tasso di allocazione degli indirizzi IP elevato negli intervalli di pod entro Network Intelligence Center, l'intervallo di indirizzi IP del pod è esaurito.

    Se gli intervalli di indirizzi IP del pod mostrano tassi di allocazione normali, ma i tuoi indirizzi IP sono ancora in esaurimento, probabilmente l'IP del tuo nodo l'intervallo di indirizzi è 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.

  • Controlla se l'intervallo di indirizzi IP esaurito è l'intervallo di indirizzi IP del nodo o il pod Intervallo di indirizzi IP.

    Per verificare se l'intervallo di indirizzi IP esaurito è l'intervallo di indirizzi IP del nodo oppure nell'intervallo di indirizzi IP del pod, verifica se il valore resourceName nella La parte ipSpaceExhausted di una voce di log IP_SPACE_EXHAUSTED è correlata con il nome della subnet o il nome dell'intervallo di indirizzi IPv4 secondario per i pod utilizzati in sul 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'indirizzo IP del pod attuale intervallo. 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 i pod per nodo liberare gli 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 ufficialmente supportato. Puoi utilizzare lo strumento gcpdiag per identificare e risolvere i problemi relativi a Google Cloud per risolvere i problemi del progetto. Per maggiori informazioni, consulta il progetto gcpdiag su GitHub.

esaminare le cause dell'esaurimento degli indirizzi IP su Autopilot e Nei cluster GKE standard, considera quanto segue:
  • Stato del cluster: controlla lo stato del cluster se si tratta dell'indirizzo IP esaurimento scorte.
  • Network Analyzer:query nei log di Stackdriver per la rete dell'analizzatore sintattico per confermare 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.

Console Google Cloud

  1. Completa e poi copia il seguente comando. 
    2. gcpdiag runbook gke/ip-exhaustion --project=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, ed esegue i controlli diagnostici. Se applicabile, segui le istruzioni dell'output per correggere i controlli non superati.

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 --project=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 è presente il cluster in cui viene localizzato.
  • start_time: l'ora in cui è iniziato il problema.
  • end_time: data e ora in cui è terminato il problema. Imposta l'ora corrente se il problema persiste.

Flag utili:

  • --project: PROJECT_ID
  • --universe-domain: se applicabile, il dominio Trusted Partner Sovereign Cloud che ospita la risorsa
  • --parameter o -p: parametri del runbook

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

Conferma se la SNAT predefinita è disabilitata

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.

Debug di Cloud NAT con SNAT predefinita disabilitata

Se hai creato un cluster privato con il flag --disable-default-snat hai configurato Cloud NAT per l'accesso a internet e non visualizzi connesso a internet dai tuoi pod, assicurati che l'intervallo di pod sia incluso nella configurazione 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 da iptables le regole del caso.

Per ulteriori informazioni, consulta Documentazione relativa al mascheramento 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 viene configurato un agente di mascheramento IP, 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 indirizzi IPv6 assegnati.
Risoluzione
Per convalidare la regola firewall, segui questi passaggi:

  1. Verifica il contenuto della regola firewall:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    Sostituisci FIREWALL_RULE_NAME con il nome della regola firewall.

    Ogni cluster a doppio stack crea una regola firewall che consente a nodi e 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.

L'endpoint Private Service Connect potrebbe perdere durante l'eliminazione del cluster

Sintomi

Non puoi visualizzare un endpoint connesso in Private Service Connect nel tuo Cluster basato su Private Service Connect.

Non puoi eliminare la subnet o la rete VPC in cui l'endpoint è allocato Private Service Connect. Un messaggio di errore simile appare quanto segue:

projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
Possibili cause

Nei cluster GKE che utilizzano Private Service Connect, GKE esegue il deployment Endpoint Private Service Connect utilizzando una regola di forwarding che alloca un indirizzo IP interno per accedere al piano di controllo del cluster la rete di un piano di controllo. Per proteggere la comunicazione tra il gruppo di controllo il piano e i nodi utilizzando Private Service Connect, GKE mantiene l'endpoint invisibile e non visibile console Google Cloud o gcloud CLI.

Risoluzione

Per evitare la perdita dell'endpoint Private Service Connect prima dell'eliminazione del cluster, completa questi passaggi:

  1. Assegna Kubernetes Engine Service Agent role all'account di servizio GKE.
  2. Assicurati che le autorizzazioni compute.forwardingRules.* e compute.addresses.* siano non è stato negato in modo esplicito dall'account di servizio GKE.

Se noti una fuga di dati dell'endpoint Private Service Connect, contatta l'assistenza.

Passaggi successivi