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 assistenza, contatta Assistenza clienti Google Cloud.

Cluster privato non in esecuzione

Eliminazione del peering VPC tra il piano di controllo del cluster e il cluster nodi, eliminando le regole firewall che consentono il traffico in entrata dal cluster dal piano di controllo ai nodi sulla porta 10250 oppure eliminando la route predefinita come un gateway internet predefinito, provoca l'interruzione del funzionamento di un cluster privato. Se la route predefinita, devi assicurarti che il traffico viene instradato il routing dei servizi Google Cloud. Per ulteriori informazioni, consulta la guida introduttiva sugli di routing.

Timeout durante la creazione del cluster privato

Ogni cluster privato richiede una route di peering tra i VPC, ma può avvenire una sola operazione di peering alla volta. Se tenti di creare contemporaneamente più cluster privati, la creazione del cluster potrebbe fuori. Per evitare che ciò accada, crea nuovi cluster privati in serie in modo che Le route di peering VPC esistono già per ogni istanza privata successiva in un cluster Kubernetes. Il tentativo di creare un singolo cluster privato potrebbe anche scadere se sono in esecuzione operazioni sul tuo VPC.

La connessione in peering di rete VPC sul cluster privato viene eliminata per errore

Sintomi

Quando elimini accidentalmente un peering di rete VPC , il cluster si trova in una stato di riparazione e tutti i nodi mostrano uno stato UNKNOWN. Non potrai Eseguire qualsiasi operazione sul cluster, a partire dalla connettività al piano di controllo è disconnesso. Quando ispezioni 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 temporaneo di peering di rete VPC. Creazione del cluster causa la ricreazione del peering di rete VPC e il cluster precedente viene ripristinato alla sua il normale funzionamento.

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

Il cluster si sovrappone al peer attivo

Sintomi

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

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 sovrapposto del piano di controllo.

Risoluzione

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

Impossibile raggiungere il piano di controllo di un cluster privato

Aumenta la probabilità che il piano di controllo del cluster sia raggiungibile implementando una configurazione di accesso agli endpoint del cluster. Per ulteriori informazioni per ulteriori informazioni, consulta Accesso agli endpoint del cluster.

Sintomi

Dopo aver creato un cluster privato, hai tentato di eseguire kubectl rispetto al cluster restituiscono 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 sia attivato il contesto corretto. Per ulteriori informazioni sulla configurazione del cluster credenziali, consulta Generare voce kubeconfig.

Verifica che l'accesso al piano di controllo tramite l'indirizzo IP esterno sia consentito. La disabilitazione dell'accesso esterno al piano di controllo del cluster isola la da internet. Questa configurazione è immutabile dopo che il cluster per la creazione di contenuti. Con questa configurazione, solo CIDR della rete interna autorizzata o una 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 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. Aggiungere reti autorizzate per accedere al piano di controllo.

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

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

    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 di un blocco CIDR IPv4 sovrapposto

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 tuo VPC.

Risoluzione

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

Impossibile creare il cluster a causa dell'intervallo di servizi già in uso da un altro cluster

Sintomi

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

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 ancora in uso da un altro cluster, oppure cluster non è stato eliminato.
  • Un cluster che utilizzava quell'intervallo di servizi è stato eliminato, ma la pulizia dei metadati degli intervalli secondari non è stata eseguita correttamente. Intervalli secondari per di un cluster GKE vengono salvati nei metadati dopo l'eliminazione del cluster. Anche quando un cluster viene eliminati correttamente, i metadati potrebbero non essere rimossi.
Risoluzione

Segui questi passaggi:

  • Controlla se l'intervallo di servizi è utilizzato da un cluster esistente. Puoi utilizzare lo gcloud container clusters list con il flag filter per cercare il cluster. Se esiste un un cluster esistente utilizzando gli intervalli di servizi, devi eliminare il cluster oppure per creare un nuovo intervallo di servizi.
  • Se l'intervallo di servizi non è utilizzato da un cluster esistente, manualmente rimuovi la voce dei metadati che corrisponda all'intervallo di servizi che vuoi utilizzare.

Impossibile creare la subnet

Sintomi

Quando provi a creare un cluster privato con una subnet automatica, crea 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 nella in un cluster Kubernetes. Il problema può verificarsi anche se di recente hai eliminato un cluster privato Stai tentando di creare un nuovo cluster privato 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 tuo 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 hanno Soddisfare i requisiti di accesso a internet. Tuttavia, i nodi possono accedere alle API e ai servizi Google Cloud, tra cui Artifact Registry, se disponi l'accesso privato Google è stato abilitato e ha soddisfatto i requisiti di rete.

Risoluzione

Utilizza una delle seguenti soluzioni:

  • Copia le immagini nel tuo cluster privato da Docker Hub in Artifact Registry. Consulta: Eseguire la migrazione dei container da un registro di terze parti per ulteriori informazioni.

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

  • Se devi eseguire il pull delle immagini da Docker Hub o da un altro repository pubblico, utilizza Cloud NAT o un proxy basato su istanze che il target per 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, con conseguente 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, tranne che sulle porte 443 (HTTPS) e 10250 (kubelet). Un webhook di ammissione il tentativo di comunicare con un pod su una porta diversa da 443 avrà esito negativo se non esiste una regola firewall personalizzata che consenta il traffico.

Risoluzione

Aggiungere 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 la creazione di un cluster privato, si blocca al passaggio del controllo di integrità 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

Uno dei seguenti:

  • I nodi del cluster non possono scaricare i file binari richiesti dall'API Cloud Storage (storage.googleapis.com)
  • Regole firewall che limitano il traffico in uscita.
  • Le autorizzazioni IAM della rete VPC condivisa non sono corrette.
  • L'accesso privato Google richiede la configurazione del DNS per *.gcr.io.
Risoluzione

Utilizza una delle seguenti soluzioni:

Impossibile creare la sandbox dei pod

Sintomi

Dopo aver creato un cluster privato, segnala 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 non aggiunti al cluster

Spesso, quando si utilizzano appliance di rete personalizzate e di terze parti sulla rete, VPC utilizzato dal tuo cluster privato, la route predefinita (0.0.0.0/0) viene reindirizzato all'appliance anziché alla rete internet predefinita gateway VPN ad alta disponibilità. Oltre alla connettività del piano di controllo, devi assicurarti sono raggiungibili le seguenti destinazioni:

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

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

Carichi di lavoro su cluster GKE privati che non riescono ad accedere a internet

I pod in 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 è configurati sul gateway Cloud NAT, i pod non possono connettersi perché non hanno un indirizzo IP esterno configurato il gateway Cloud NAT.

Assicurati di configurare il gateway Cloud NAT in modo che applichi almeno i seguenti intervalli di indirizzi IP di 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ù, vedi come aggiungere un intervallo IP di subnet secondario utilizzato per i pod.