Risoluzione dei problemi dei cluster privati in GKE

Questa pagina mostra come risolvere i problemi relativi ai cluster privati di Google Kubernetes Engine (GKE).

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

Cluster privato non in esecuzione

L'eliminazione del peering VPC tra il piano di controllo del cluster e i nodi del cluster, l'eliminazione delle regole firewall che consentono il traffico in entrata dal piano di controllo del cluster ai nodi sulla porta 10250 o la route predefinita verso il gateway internet predefinito determina l'interruzione del funzionamento di un cluster privato. Se elimini la route predefinita, devi assicurarti che il traffico verso i servizi Google Cloud necessari venga instradato. Per ulteriori informazioni, consulta la sezione relativa al routing personalizzato.

Timeout durante la creazione del cluster privato

Ogni cluster privato richiede una route di peering tra VPC, ma può essere eseguita una sola operazione di peering alla volta. Se tenti di creare più cluster privati contemporaneamente, la creazione del cluster potrebbe scadere. Per evitare che ciò accada, crea nuovi cluster privati in modo seriale in modo che esistano già route di peering VPC per ogni cluster privato successivo. Il tentativo di creare un singolo cluster privato potrebbe scadere anche se sono presenti operazioni in esecuzione sul VPC.

La connessione di peering di rete VPC su cluster privato è stata eliminata accidentalmente

Sintomi

Quando elimini accidentalmente una connessione di peering di rete VPC, il cluster entra in stato di riparazione e tutti i nodi mostrano lo stato UNKNOWN. Non potrai eseguire alcuna operazione sul cluster perché la connettività al piano di controllo è disconnessa. Quando esamini il piano di controllo, i log mostreranno un errore simile al seguente:

error checking if node NODE_NAME is shutdown: unimplemented
Potenziali cause

Hai eliminato accidentalmente la connessione di peering di rete VPC.

Risoluzione

Segui questi passaggi:

  • Crea un nuovo cluster di peering di rete VPC temporaneo. La creazione del cluster causa la ricreazione del peering di rete VPC e il ripristino del normale funzionamento del cluster precedente.

  • Elimina il cluster di peering di rete VPC creato temporaneamente dopo il ripristino del vecchio cluster al funzionamento normale.

Il cluster si sovrappone al peer attivo

Sintomi

Il tentativo di creare un cluster privato 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.
Potenziali cause

Hai scelto un CIDR del piano di controllo sovrapposto.

Risoluzione

Elimina e ricrea il cluster utilizzando un CIDR del piano di controllo diverso.

Impossibile raggiungere il piano di controllo di un cluster privato

Aumenta la probabilità che il piano di controllo del cluster sia raggiungibile implementando una qualsiasi configurazione di accesso agli endpoint cluster. Per ulteriori informazioni, consulta l'articolo sull'accesso agli endpoint del cluster.

Sintomi

Dopo aver creato un cluster privato, il tentativo di eseguire i 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.
Potenziali cause

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

Risoluzione

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 Generare voce kubeconfig.

Verifica che sia consentito l'accesso al piano di controllo tramite il relativo indirizzo IP esterno. La disabilitazione dell'accesso esterno al piano di controllo del cluster isola il cluster da internet.Questa configurazione è immutabile dopo la creazione del cluster. Con questa configurazione, solo gli intervalli CIDR della rete interna autorizzati o la rete riservata hanno accesso al piano di controllo.

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

      gcloud container clusters describe CLUSTER_NAME \
      --format="value(masterAuthorizedNetworksConfig)"\
      --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 l'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 accedere al piano di controllo.

Se esegui il comando kubectl da un ambiente on-premise o da una regione diversa dalla località del cluster, assicurati che l'accesso globale dell'endpoint privato del piano di controllo sia abilitato. Per maggiori informazioni, consulta la pagina relativa all'accesso globale all'endpoint privato del piano di controllo.

  1. Descrivi il cluster per visualizzare la risposta della configurazione di controllo dell'accesso:

    gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "privateClusterConfig.masterGlobalAccessConfig"

    Sostituisci quanto segue:

    Un output riuscito è simile al seguente:

      enabled: true

  2. Se viene restituito null, abilita l'accesso globale al piano di controllo.

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.
Potenziali 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 a causa dell'intervallo di servizi già utilizzato da un altro cluster

Sintomi

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

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

Una delle seguenti opzioni:

  • Hai scelto un intervallo di servizi che è ancora in uso da un altro cluster oppure il cluster non è stato eliminato.
  • Un cluster che utilizzava questo intervallo di servizi è stato eliminato, ma i metadati degli intervalli secondari non sono stati eliminati 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, i metadati potrebbero non essere rimossi.
Risoluzione

Segui questi passaggi:

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

Impossibile creare la subnet

Sintomi

Quando provi a creare un cluster privato con una subnet automatica o a creare una subnet personalizzata, potresti riscontrare il seguente errore:

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

L'intervallo CIDR del piano di controllo specificato si sovrappone a un altro intervallo IP nel cluster. Questo problema può verificarsi anche se di recente hai eliminato un cluster privato e stai tentando di crearne uno nuovo utilizzando lo stesso CIDR del piano di controllo.

Risoluzione

Prova a utilizzare un intervallo CIDR diverso.

Impossibile eseguire il pull dell'immagine dal 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)
Potenziali cause

I nodi in un cluster privato non hanno indirizzi IP esterni, quindi non soddisfano 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 tuo cluster privato da Docker Hub ad Artifact Registry. Per ulteriori informazioni, consulta Migrazione dei container da un registro di terze parti.

  • GKE controlla automaticamente in mirror.gcr.io la presenza di copie memorizzate nella cache di immagini Docker Hub a cui si accede di frequente.

  • Se devi eseguire il pull delle immagini da Docker Hub o un altro repository pubblico, utilizza Cloud NAT o un proxy basato su istanze che è la destinazione di una route 0.0.0.0/0 statica.

Richiesta API che attiva il timeout del webhook di ammissione

Sintomi

Una richiesta API che attiva un webhook di ammissione configurato per utilizzare un servizio con una porta target diversa da 443 timeout, causando la mancata riuscita della richiesta:

Error from server (Timeout): request did not complete within requested timeout 30s
Potenziali 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 dalla 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 di un controllo di integrità non riuscito

Sintomi

Dopo aver creato un cluster privato, questo si blocca nel passaggio del controllo di integrità e segnala 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
Potenziali cause

Una delle seguenti opzioni:

  • I nodi del cluster non possono scaricare i programmi 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.
  • L'accesso privato Google richiede la configurazione del DNS per *.gcr.io.
Risoluzione

Utilizza una delle seguenti soluzioni:

kubelet Impossibile creare la sandbox dei pod

Sintomi

Dopo aver creato un cluster privato, 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
Potenziali cause

Il pod calico-node o netd non può raggiungere *.gcr.io.

Risoluzione

Utilizza una delle seguenti soluzioni:

Nodi del cluster privato creati ma che non entrano a far parte del cluster

Spesso quando utilizzi il routing personalizzato e appliance di rete di terze parti sul VPC usato dal cluster privato, la route predefinita (0.0.0.0/0) viene reindirizzata all'appliance anziché al gateway internet predefinito. Oltre alla connettività del piano di controllo, devi assicurarti che le seguenti destinazioni siano raggiungibili:

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

Configura l'accesso privato Google per tutti e tre i domini. Questa best practice consente ai nuovi nodi di avviarsi e unirsi al cluster mantenendo limitato il traffico collegato a internet.

I carichi di lavoro su cluster GKE privati non sono in grado di accedere a internet

I pod nei cluster GKE privati non possono accedere a internet. Ad esempio, dopo aver eseguito il comando apt update dal pod exec shell, viene segnalato 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 principali della subnet (utilizzato dai nodi)
  • Intervallo di indirizzi IP secondari della subnet utilizzato per i pod nel cluster
  • Intervallo di indirizzi IP secondari della subnet utilizzato per i servizi nel cluster

Per saperne di più, consulta Come aggiungere un intervallo IP di subnet secondaria utilizzato per i pod.