Risoluzione dei problemi di isolamento della rete in GKE

Questa pagina mostra come risolvere i problemi di isolamento della rete di Google Kubernetes Engine (GKE).

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Cluster GKE non in esecuzione

L'eliminazione delle regole del firewall che consentono il traffico in entrata dal piano di controllo del cluster ai nodi sulla porta 10250 o l'eliminazione della route predefinita per il gateway internet predefinito causa l'interruzione del funzionamento di un cluster. Se elimini la route predefinita, devi assicurarti che il traffico verso i servizi Google Cloud necessari venga instradato. Per ulteriori informazioni, consulta Routing personalizzato.

Timeout durante la creazione di un cluster

Sintomi
I cluster creati nella versione 1.28 o precedente con nodi privati richiedono un percorso di peering tra le VPC. Tuttavia, è possibile eseguire una sola operazione di peering alla volta. Se provi a creare più cluster contemporaneamente con le caratteristiche riportate sopra, la creazione dei cluster potrebbe scadere.
Risoluzione

Utilizza una delle seguenti soluzioni:

  • Crea i cluster nella versione 1.28 o precedente in sequenza in modo che i route di peering VPC esistano già per ogni cluster successivo senza un endpoint esterno. Anche il tentativo di creare un singolo cluster potrebbe scadere se nel VPC sono in esecuzione operazioni.

  • Crea cluster nella versione 1.29 o successive.

La connessione di peering di rete VPC viene eliminata per errore

Sintomi

Se elimini accidentalmente una connessione di peering di reti VPC, il cluster entra in uno stato di riparazione e tutti i nodi mostrano uno stato UNKNOWN. Non potrai eseguire alcuna operazione sul cluster poiché la raggiungibilità del piano di controllo è disconnessa. Quando ispezioni il piano di controllo, nei log viene visualizzato un errore simile al seguente:

error checking if node NODE_NAME is shutdown: unimplemented
Possibili cause

Hai eliminato accidentalmente la connessione di peering di rete VPC.

Risoluzione

Segui questi passaggi:

  1. Crea un nuovo cluster di peering di rete VPC temporaneo. La creazione del cluster provoca la ricreazione del peering di rete VPC e il normale funzionamento del vecchio cluster viene ripristinato.

  2. Elimina il cluster di peering di rete VPC creato temporaneamente dopo aver ripristinato il normale funzionamento del vecchio cluster.

L'endpoint e regola di forwarding di Private Service Connect vengono eliminati per errore

Sintomi

Se elimini accidentalmente un endpoint o una regola di forwarding di Private Service Connect, il cluster entra in uno stato di riparazione e tutti i nodi mostrano lo stato UNKNOWN. Non potrai eseguire alcuna operazione sul cluster perché l'accesso al piano di controllo è disconnesso. Quando ispezioni il piano di controllo, nei log viene visualizzato un errore simile al seguente:

error checking if node NODE_NAME is shutdown: unimplemented
Possibili cause

Hai eliminato accidentalmente l'endpoint o la regola di forwarding di Private Service Connect. Entrambe le risorse sono denominate gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe e consentono al piano di controllo e ai nodi di connettersi in privato.

Risoluzione

Ruota l'indirizzo IP del piano di controllo.

Il cluster si sovrappone al peer attivo

Sintomi

Il tentativo di creare un cluster senza un endpoint esterno restituisce un errore simile al seguente:

Google Compute Engine: An IP range in the peer network overlaps with an IP
range in an active peer of the local network.
Possibili cause

Hai scelto un CIDR del piano di controllo sovrapposto.

Risoluzione

Utilizza una delle seguenti soluzioni:

  • Elimina e ricrea il cluster utilizzando un CIDR del piano di controllo diverso.
  • Ricrea il cluster nella versione 1.29 e includi il flag --enable-private-nodes.

Impossibile raggiungere il piano di controllo di un cluster senza endpoint esterno

Aumenta le probabilità che il control plane del cluster sia raggiungibile implementando una qualsiasi configurazione di accesso all'endpoint del cluster. Per maggiori informazioni, consulta Accedere agli endpoint del cluster.

Sintomi

Dopo aver creato un cluster senza endpoint esterno, il tentativo di eseguire comandi kubectl sul cluster restituisce un errore simile a uno dei seguenti:

Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection
timed out.

Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Possibili cause

kubectl non è in grado di comunicare con il piano di controllo del cluster.

Risoluzione

Utilizza una delle seguenti soluzioni:

  • Abilita l'accesso DNS per accedere in modo sicuro al tuo cluster. Per ulteriori informazioni, consulta Endpoint basato su DNS.

  • Verifica che le credenziali per il cluster siano state generate per kubeconfig o che sia attivato il contesto corretto. Per ulteriori informazioni sull'impostazione delle credenziali del cluster, consulta Genera voce kubeconfig.

  • Verifica che l'accesso al control plane tramite l'indirizzo IP esterno sia consentito. La disattivazione dell'accesso esterno al piano di controllo del cluster isola il cluster da internet. Con questa configurazione, solo gli intervalli CIDR della rete interna autorizzata o la rete riservata hanno accesso al control plane.

    1. Verifica che l'indirizzo IP di origine sia autorizzato a raggiungere il piano di controllo:

        gcloud container clusters describe CLUSTER_NAME \
      --format="value(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetworksConfig)"\
      --location=COMPUTE_LOCATION

      Sostituisci quanto segue:

      Se il tuo indirizzo IP di origine non è autorizzato, l'output potrebbe restituire un risultato vuoto (solo parentesi graffe) o intervalli CIDR che non includono il tuo indirizzo IP di origine

      cidrBlocks:
  cidrBlock: 10.XXX.X.XX/32
  displayName: jumphost
  cidrBlock: 35.XXX.XXX.XX/32
  displayName: cloud shell
enabled: true

    2. Aggiungi reti autorizzate per controllo dell'accesso plane.

  • Se esegui il comando kubectl da un ambiente on-premise o da una regione diversa dalla posizione del cluster, assicurati che l'accesso globale all'endpoint privato del control plane sia abilitato. Per ulteriori informazioni, consulta Accedere mediante l'indirizzo IP interno del control plane da qualsiasi regione.

    1. Descrivi il cluster per visualizzare la risposta alla configurazione del controllo dell'accesso:

      gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"

      Sostituisci quanto segue:

      Un output corretto è simile al seguente:

        enabled: true

    2. Se viene restituito null, abilita l'accesso utilizzando l'indirizzo IP interno del control plane da qualsiasi regione.

Impossibile creare il cluster a causa della sovrapposizione del blocco CIDR IPv4

Sintomi

gcloud container clusters create restituisce un errore simile al seguente:

The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network
10.128.0.0/20.
Possibili cause

Hai specificato un blocco CIDR del piano di controllo che si sovrappone a una subnet esistente nel VPC.

Risoluzione

Specifica un blocco CIDR per --master-ipv4-cidr che non si sovrapponga a una subnet esistente.

Impossibile creare il cluster perché l'intervallo di servizi è già in uso da un altro cluster

Sintomi

Il tentativo di creare un cluster restituisce un errore simile al seguente:

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
Possibili cause

Le seguenti configurazioni potrebbero causare questo errore:

  • Hai scelto un intervallo di servizi ancora in uso da un altro cluster o il cluster non è stato eliminato.
  • Un cluster che utilizzava l'intervallo di servizi è stato eliminato, ma i metadati degli intervalli secondari non sono stati ripuliti correttamente. Gli intervalli secondari per un cluster GKE vengono salvati nei metadati di Compute Engine e devono essere rimossi dopo l'eliminazione del cluster. Anche se un cluster viene eliminato correttamente, i metadati potrebbero non essere rimossi.
Risoluzione

Segui questi passaggi:

  1. Controlla se l'intervallo di servizi è in uso da un cluster esistente. Puoi utilizzare il comando gcloud container clusters list con il flag filter per cercare il cluster. Se esiste un cluster che utilizza gli intervalli di servizi, devi eliminarlo o creare un nuovo intervallo di servizi.
  2. Se l'intervallo di servizi non è in uso da un cluster esistente, manualmente rimuovi la voce dei metadati corrispondente all'intervallo di servizi che vuoi utilizzare.

Impossibile creare una subnet

Sintomi

Quando provi a creare un cluster con una subnet automatica o a creare una subnet personalizzata, potresti riscontrare uno dei seguenti errori:

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.

Error: Error waiting for creating GKE cluster: Invalid value for field
PrivateClusterConfig.MasterIpv4CidrBlock: x.x.x.x/28 conflicts with an
existing subnet in one of the peered VPCs.
Possibili cause

L'intervallo CIDR del control plane specificato si sovrappone a un altro intervallo IP nel cluster. Questo errore di creazione della subnet può verificarsi anche se stai tentando di riutilizzare i CIDR master-ipv4-cidr utilizzati in un cluster eliminato di recente.

Risoluzione

Prova a utilizzare un altro intervallo CIDR.

Impossibile eseguire il pull dell'immagine da Docker Hub pubblico

Sintomi

Un pod in esecuzione nel cluster mostra un avviso in kubectl describe:

Failed to pull image: rpc error: code = Unknown desc = Error response
from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
while waiting for connection (Client.Timeout exceeded while awaiting
headers)
Possibili cause

I nodi con indirizzi IP privati richiedono solo una configurazione aggiuntiva per soddisfare i requisiti di accesso a internet. Tuttavia, i nodi possono accedere alle API e ai servizi Google Cloud, tra cui Artifact Registry, se hai abilitato l'accesso privato Google e soddisfatto i relativi requisiti di rete.

Risoluzione

Utilizza una delle seguenti soluzioni:

  • Copia le immagini nel cluster da Docker Hub ad Artifact Registry. Per ulteriori informazioni, consulta la sezione Eseguire la migrazione di container da un registry di terze parti.

  • GKE controlla automaticamente mirror.gcr.io per verificare la presenza di copie memorizzate nella cache delle immagini Docker Hub a cui viene eseguito l'accesso di frequente.

  • Se devi estrarre le immagini da Docker Hub o da un altro repository pubblico, utilizza Cloud NAT o un proxy basato su istanze che sia la destinazione di una route 0.0.0.0/0 statica.

Richiesta API che attiva il timeout dell'admission webhook

Sintomi

Una richiesta API che attiva un webhook di ammissione configurato per utilizzare un servizio con un targetPort diverso da 443 scade, causando il fallimento della richiesta:

Error from server (Timeout): request did not complete within requested timeout 30s
Possibili cause

Per impostazione predefinita, il firewall non consente connessioni TCP ai nodi, ad eccezione delle porte 443 (HTTPS) e 10250 (kubelet). Un webhook di ammissione che tenta di comunicare con un pod su una porta diversa da 443 non andrà a buon fine se non esiste una regola firewall personalizzata che consenta il traffico.

Risoluzione

Aggiungi una regola firewall per il tuo caso d'uso specifico.

Impossibile creare il cluster a causa del fallimento del controllo di integrità

Sintomi

Dopo aver creato un cluster standard con pool di nodi privati, il processo si blocca al passaggio del controllo di integrità e viene visualizzato un errore simile a uno dei seguenti:

All cluster resources were brought up, but only 0 of 2 have registered.

All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
Possibili cause

Le seguenti configurazioni potrebbero causare questo errore:

  • I nodi del cluster non riescono a scaricare i binari richiesti dall'API Cloud Storage (storage.googleapis.com).
  • Regole firewall che limitano il traffico in uscita.
  • Le autorizzazioni IAM del VPC condiviso non sono corrette.
  • Per utilizzare l'accesso privato Google, devi configurare il DNS per *.gcr.io.
Risoluzione

Utilizza una delle seguenti soluzioni:

kubelet Failed to create pod sandbox

Sintomi

Dopo aver creato un cluster con nodi privati, viene segnalato un errore simile a uno dei seguenti:

Warning  FailedCreatePodSandBox  12s (x9 over 4m)      kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Possibili cause

Il pod calico-node o netd non riesce a raggiungere *.gcr.io.

Risoluzione

Assicurati di aver completato la configurazione richiesta per Container Registry o Artifact Registry.

Nodi privati creati, ma non che si uniscono al cluster

Per i cluster che utilizzano solo nodi con indirizzi IP privati, spesso quando si utilizzano routing personalizzati e appliance di rete di terze parti nella VPC, il route predefinito (0.0.0.0/0) viene reindirizzato all'appliance anziché al gateway internet predefinito. Oltre alla connettività del control plane, devi assicurarti che le seguenti destinazioni siano raggiungibili:

  • *.googleapis.com
  • *.gcr.io
  • gcr.io

Configura Accesso privato Google per tutti e tre i domini. Questa best practice consente ai nuovi nodi di avviarsi e di aggregarsi al cluster mantenendo limitato il traffico verso internet.

I carichi di lavoro sui cluster GKE non riescono ad accedere a internet

I pod in esecuzione in nodi con indirizzi IP privati non possono accedere a internet. Ad esempio, dopo aver eseguito il comando apt update dal pod exec shell, viene visualizzato un errore simile al seguente:

0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]

Se l'intervallo di indirizzi IP secondari della subnet utilizzato per i pod nel cluster non è configurato sul gateway Cloud NAT, i pod non possono connettersi a internet perché non hanno un indirizzo IP esterno configurato per il gateway Cloud NAT.

Assicurati di configurare il gateway Cloud NAT in modo da applicare almeno i seguenti intervalli di indirizzi IP della subnet per la subnet utilizzata dal cluster:

  • Intervallo di indirizzi IP principale della subnet (utilizzato dai nodi)
  • Intervallo di indirizzi IP secondario della subnet utilizzato per i pod nel cluster
  • Intervallo di indirizzi IP secondario della subnet utilizzato per i servizi nel cluster

Per scoprire di più, consulta come aggiungere l'intervallo IP della subnet secondaria utilizzato per i pod.

L'accesso IP diretto non può essere disattivato per i cluster pubblici

Sintomi

Dopo aver disattivato l'endpoint dell'indirizzo IP, viene visualizzato un messaggio di errore simile al seguente:

Direct IP access can't be disabled for public clusters
Possibili cause

Il cluster utilizza una rete precedente.

Risoluzione

Esegui la migrazione dei tuoi cluster a Private Service Connect. Per ulteriori informazioni sullo stato della migrazione, contatta l'assistenza .

L'accesso IP diretto non può essere disattivato per i cluster in fase di migrazione PSC

Sintomi

Dopo aver disattivato l'endpoint dell'indirizzo IP, viene visualizzato un messaggio di errore simile al seguente:

Direct IP access can't be disabled for public clusters
Possibili cause

Il tuo cluster utilizza una rete precedente.

Risoluzione

Utilizza una delle seguenti soluzioni:

  • Ricrea manualmente tutti i pool di nodi in una versione diversa.
  • Attendi che GKE esegua l'upgrade automatico dei node pool durante un evento di manutenzione.

Impossibile attivare l'endpoint interno del piano di controllo

Sintomi

Quando provi ad attivare l'endpoint interno del piano di controllo del cluster, vengono visualizzati messaggi di errore simili al seguente:

private_endpoint_enforcement_enabled can't be enabled when envoy is disabled

private_endpoint_enforcement_enabled is unsupported. Please upgrade to the minimum support version
Possibili cause

Il cluster deve eseguire la rotazione degli indirizzi IP o un aggiornamento della versione.

Risoluzione

Utilizza una delle seguenti soluzioni:

La creazione del cluster non riesce quando sono definiti i criteri dell'organizzazione

Sintomi

Quando provi a creare un cluster, viene visualizzato un messaggio di errore simile al seguente:

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
Possibili cause

L'endpoint o il backend del cluster è bloccato da un criterio dell'organizzazione del consumatore.

Risoluzione

Consenti alle istanze di creare endpoint con il vincolo compute.restrictPrivateServiceConnectProducer completando i passaggi descritti in Criteri dell'organizzazione lato consumatore.

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

Sintomi

Dopo aver creato un cluster, potresti notare uno dei seguenti sintomi:

  • Non riesci a vedere un endpoint collegato in Private Service Connect nel tuo cluster basato su Private Service Connect.

  • Non puoi eliminare la subnet o la rete VPC allocata per l'endpoint interno in un cluster che utilizza Private Service Connect. Viene visualizzato un messaggio di errore simile al seguente:

    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 di un endpoint Private Service Connect utilizzando una regola di forwarding che alloca un indirizzo IP interno per accedere al piano di controllo del cluster nella rete di un piano di controllo. Per proteggere la comunicazione tra il piano di controllo e i nodi utilizzando Private Service Connect, GKE mantiene l'endpoint invisibile e non puoi vederlo nella console Google Cloud o nella gcloud CLI.

Risoluzione

Per evitare la fuga dell'endpoint Private Service Connect prima dell'eliminazione del cluster, completa i seguenti passaggi:

  1. Assegna Kubernetes Engine Service Agent role all'account di servizio GKE.
  2. Assicurati che le autorizzazioni compute.forwardingRules.* e compute.addresses.* non siano esplicitamente negate dall'account di servizio GKE.

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

Impossibile analizzare la rete autorizzata del cluster

Sintomi

Non puoi creare un cluster nella versione 1.29 o successive. Viene visualizzato un messaggio di errore simile al seguente:

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
Possibili cause

Il tuo progetto Google Cloud utilizza webhook basati su IP privati. Di conseguenza, non puoi creare un cluster con Private Service Connect. Il cluster utilizza invece il peering di rete VPC che analizza il flag master-ipv4-cidr.

Risoluzione

Utilizza una delle seguenti soluzioni:

  • Continua a creare il cluster di peering di reti VPC e includi il valore master-ipv4-cidr per definire CIDR validi. Questa soluzione presenta le seguenti limitazioni:

    • Il flag master-ipv4-cidr è stato ritirato nella console Google Cloud. Per aggiornare questo flag, puoi utilizzare solo Google Cloud CLI o Terraform.
    • Il peering di reti VPC è deprecato nella versione 1.29 o successive di GKE.

  • Esegui la migrazione dei tuoi webhook basati su IP privati completando i passaggi descritti in Limitazioni di Private Service Connect. Quindi, contatta l'assistenza per attivare l'utilizzo dei cluster con Private Service Connect.

Impossibile definire l'intervallo di indirizzi IP interni nei cluster con nodi pubblici

Sintomi

Non puoi definire un intervallo di indirizzi IP interni utilizzando il --master-ipv4-cidr flag. Viene visualizzato un messaggio di errore simile al seguente:

ERROR: (gcloud.container.clusters.create) Cannot specify --master-ipv4-cidr
  without --enable-private-nodes
Possibili cause

Stai definendo un intervallo di indirizzi IP interno per il piano di controllo con il flag master-ipv4-cidr in un cluster senza che sia attivato il flag enable-private-nodes. Per creare un cluster con master-ipv4-cidr definito, devi configurare il cluster per eseguire il provisioning dei nodi con indirizzi IP interni (nodi privati) utilizzando il flag enable-private-nodes.

Risoluzione

Utilizza una delle seguenti soluzioni:

  • Crea un cluster con il seguente comando:

    gcloud container clusters create-auto CLUSTER_NAME \
    --enable-private-nodes \
    --master-ipv4-cidr CP_IP_RANGE

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • CLUSTER_NAME: l'intervallo di indirizzi IP interno per il piano di controllo.

  • Aggiorna il cluster per eseguire il provisioning dei nodi utilizzando solo indirizzi IP. Per saperne di più, consulta Configurare il cluster.

Impossibile pianificare i carichi di lavoro pubblici sui cluster Autopilot

Sintomi
Nei cluster Autopilot, se il cluster utilizza solo nodi privati, non puoi pianificare i carichi di lavoro nei pod pubblici utilizzando il parametro cloud.google.com/private-node=false nodeSelector.
Possibili cause
La configurazione del flag private-node impostato su false nel nodeSelector del pod è disponibile solo nei cluster versione 1.30.3 o successive.
Risoluzione
Esegui l'upgrade del cluster alla versione 1.30 o successiva.

L'accesso all'endpoint basato su DNS è disattivato

Sintomi

Il tentativo di eseguire comandi kubectl sul cluster restituisce un errore simile al seguente:

couldn't get current server API group list:
control_plane_endpoints_config.dns_endpoint_config.allow_external_traffic is
disabled
Possibili cause

L'accesso basato su DNS è stato disattivato nel tuo cluster.

Risoluzione

Abilita l'accesso al control plane utilizzando l'endpoint basato su DNS del control plane. Per scoprire di più, consulta Modificare l'accesso al piano di controllo.

I nodi non riescono ad allocare l'indirizzo IP durante il ridimensionamento

Sintomi

Il tentativo di espandere l'intervallo di indirizzi IP principale della sottorete all'elenco delle reti autorizzate restituisce un errore simile al seguente:

 authorized networks fields cannot be mutated if direct IP access is disabled
Possibili cause

Hai disattivato l'endpoint basato su IP del cluster.

Risoluzione

Disattiva e abilita l'endpoint basato su IP del cluster utilizzando il flag enable-ip-access.

Troppi blocchi CIDR

gcloud restituisce il seguente errore durante il tentativo di creare o aggiornare un cluster con più di 50 blocchi CIDR:

ERROR: (gcloud.container.clusters.update) argument --master-authorized-networks: too many args

Per risolvere il problema, prova quanto segue:

Impossibile connettersi al server

I comandi kubectl hanno esaurito il tempo di attesa a causa di blocchi CIDR configurati in modo errato:

Unable to connect to the server: dial tcp MASTER_IP: getsockopt: connection timed out

Quando crei o aggiorni un cluster, assicurati di specificare i blocchi CIDR corretti.