Risoluzione dei problemi dello strumento a riga di comando kubectl

Autopilot Standard

---

Questa pagina mostra come risolvere i problemi relativi allo strumento a riga di comando kubectl quando utilizzi Google Kubernetes Engine (GKE). Per consigli più generali, consulta la sezione Risoluzione dei problemi di kubectl nella documentazione di Kubernetes.

Errori di autenticazione e autorizzazione

Se si verificano errori relativi all'autenticazione e all'autorizzazione quando si utilizzano i comandi dello strumento a riga di comando kubectl, leggi le sezioni seguenti per ricevere consigli.

Errore: 401 (non autorizzato)

Quando ti connetti ai cluster GKE, puoi ricevere un errore di autenticazione e autorizzazione con il codice di stato HTTP 401 (Unauthorized). Questo problema potrebbe verificarsi quando provi a eseguire un comando kubectl in GKE da un ambiente locale. Per saperne di più, vedi Problema: errori di autenticazione e autorizzazione.

Errore: ambiti di autenticazione insufficienti

Quando esegui gcloud container clusters get-credentials, potresti ricevere il seguente errore:

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Request had insufficient authentication scopes.

Questo errore si verifica perché stai tentando di accedere all'API Kubernetes Engine da una VM Compute Engine che non ha l'ambito cloud-platform.

Per risolvere questo errore, concedi l'ambito cloud-platform mancante. Per per la modifica degli ambiti sull'istanza VM di Compute Engine, consulta Creazione e abilitazione degli account di servizio per le istanze nella documentazione di Compute Engine.

Errore: file eseguibile gke-gcloud-auth-plugin non trovato

Quando si tenta di eseguire comandi kubectl o client personalizzati che interagiscono con GKE, possono verificarsi messaggi di errore simili ai seguenti:

Unable to connect to the server: getting credentials: exec: executable gke-gcloud-auth-plugin not found

It looks like you are trying to use a client-go credential plugin that is not installed.

To learn more about this feature, consult the documentation available at:
      https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins

Visit cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#install_plugin to install gke-gcloud-auth-plugin.

Unable to connect to the server: getting credentials: exec: fork/exec /usr/lib/google-cloud-sdk/bin/gke-gcloud-auth-plugin: no such file or directory

Per risolvere il problema, installa gke-gcloud-auth-plugin come descritto in Installa i plug-in richiesti.

Errore: nessun provider di autenticazione trovato

Il seguente errore si verifica se i client kubectl o Kubernetes personalizzati sono stati compilati con Kubernetes client-go versione 1.26 o successive:

no Auth Provider found for name "gcp"

Per risolvere il problema, completa i seguenti passaggi:

1. Installa gke-gcloud-auth-plugin come descritto in Installare i plug-in richiesti.

2. Esegui l'aggiornamento all'ultima versione di gcloud CLI:

   gcloud components update
   

3. Aggiorna il file kubeconfig:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --region=COMPUTE_REGION
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del tuo cluster.
   • COMPUTE_REGION: la regione Compute Engine per il cluster. Per cluster di zona, usa --zone=COMPUTE_ZONE.

Errore: il plug-in di autenticazione Google Cloud è deprecato. Utilizza gcloud

Potresti visualizzare il seguente messaggio di avviso dopo aver installato il gke-gcloud-auth-plugin ed esegui un comando kubectl su un cluster GKE:

WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead.

Questo messaggio viene visualizzato se la versione del client è precedente alla 1.26.

Per risolvere il problema, chiedi al cliente di utilizzare il plug-in di autenticazione gke-gcloud-auth-plugin:

1. Apri lo script di accesso alla shell in un editor di testo:

   Bash

   vi ~/.bashrc

   Zsh

   vi ~/.zshrc

   Se utilizzi PowerShell, salta questo passaggio.

2. Imposta la seguente variabile di ambiente:

   Bash

   export USE_GKE_GCLOUD_AUTH_PLUGIN=True
   

   Zsh

   export USE_GKE_GCLOUD_AUTH_PLUGIN=True
   

   PowerShell

   [Environment]::SetEnvironmentVariable('USE_GKE_GCLOUD_AUTH_PLUGIN', True, 'Machine')
   

3. Applica la variabile nel tuo ambiente:

   Bash

   source ~/.bashrc

   Zsh

   source ~/.zshrc
   

   PowerShell

   Esci dal terminale e apri una nuova sessione.

4. Aggiorna gcloud CLI:

   gcloud components update
   

5. Esegui l'autenticazione sul cluster:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --region=COMPUTE_REGION
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del tuo cluster.
   • COMPUTE_REGION: il Compute Engine region per il tuo cluster. Per cluster di zona, usa --zone=COMPUTE_ZONE.

Problema: il comando kubectl non è stato trovato

Se ricevi un messaggio che ti informa che il comando kubectl non è stato trovato: reinstalla il programma binario kubectl e imposta la variabile di ambiente $PATH:

1. Installa il programma binario kubectl:

   gcloud components update kubectl
   

2. Quando il programma di installazione ti chiede di modificare l'ambiente $PATH inserisci y per continuare. La modifica di questa variabile ti consente di utilizzare i comandi kubectl senza digitare il percorso completo.

   In alternativa, aggiungi la riga seguente a ogni posizione in cui è archiviata la tua shell variabili di ambiente, come ~/.bashrc (o ~/.bash_profile in macOS):

   export PATH=$PATH:/usr/local/share/google/google-cloud-sdk/bin/
   

3. Esegui questo comando per caricare il file aggiornato. Nell'esempio riportato di seguito viene utilizzato .bashrc:

   source ~/.bashrc
   

   Se utilizzi macOS, usa ~/.bash_profile anziché .bashrc.

Problema: i comandi kubectl restituiscono "connessione rifiutata" errore

Se i comandi kubectl restituiscono un errore "connection refused", devi impostare il contesto del cluster con il seguente comando:

gcloud container clusters get-credentials CLUSTER_NAME

Sostituisci CLUSTER_NAME con il nome del cluster. Se non sei sicuro di cosa inserire come nome del cluster, usa il comando seguente per elencare i cluster:

gcloud container clusters list

Errore: timeout del comando kubectl

Se hai creato un cluster e hai tentato di eseguire un comando kubectl sul cluster, ma il comando kubectl ha superato il tempo di attesa, viene visualizzato un errore simile al seguente:

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

Questi errori indicano che kubectl non è in grado di comunicare con il dal piano di controllo del cluster.

Per risolvere il problema, verifica e imposta il contesto in cui è impostato il cluster e assicurati la connettività al cluster:

1. Vai a $HOME/.kube/config o esegui il comando kubectl config view per verifica che il file di configurazione contenga il contesto del cluster e l'IP esterno all'indirizzo del piano di controllo.

2. Imposta le credenziali del cluster:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=COMPUTE_LOCATION \
       --project=PROJECT_ID
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del tuo cluster.
   • COMPUTE_LOCATION: la posizione di Compute Engine.
   • PROJECT_ID: l'ID del progetto in cui è stato creato il cluster.

3. Se il cluster è un cluster GKE privato cluster, garantire che il suo elenco di reti autorizzate esistenti includa la rete IP della macchina da cui stai tentando di connetterti. Puoi trovare le nelle reti autorizzate esistenti nella console o eseguendo seguente comando:

   gcloud container clusters describe CLUSTER_NAME \
       --location=COMPUTE_LOCATION \
       --project=PROJECT_ID \
       --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
   

   Se l'IP in uscita della macchina non è incluso nell'elenco delle reti dall'output del comando precedente, quindi completa una delle seguenti passaggi:

   • Se utilizzi la console, aumenta la probabilità per rendere raggiungibile il piano di controllo del cluster implementando una delle configurazioni di accesso agli endpoint del cluster. Per ulteriori informazioni, vedi l'accesso agli endpoint del cluster.
   • Se ti connetti da Cloud Shell, segui le istruzioni in Utilizzo a Cloud Shell per accedere a un cluster cluster.

Errore: la restituzione dei comandi kubectl non è riuscita a negoziare una versione dell'API

Se i comandi kubectl restituiscono un errore failed to negotiate an API version, devi assicurarti che kubectl disponga delle credenziali di autenticazione:

gcloud auth application-default login

Problema: il comando kubectl logs, attach, exec o port-forward smette di rispondere

Se i comandi kubectl logs, attach, exec o port-forward si interrompono , in genere il server API non è in grado di comunicare con i nodi.

Innanzitutto, controlla se il tuo cluster ha nodi. Se hai ridotto a zero il numero di nodi nel cluster, i comandi non funzioneranno. Da risolvere questo problema, ridimensiona il cluster in modo da avere almeno un nodo.

Se il cluster ha almeno un nodo, verifica se stai utilizzando SSH o Proxy di notorietà tunnel per consentire una comunicazione sicura. Le sezioni seguenti descrivono i passaggi per la risoluzione dei problemi specifici di ciascun servizio:

• SSH
• Proxy di notorietà

Risolvere i problemi relativi a SSH

Se utilizzi SSH, GKE salva un file di chiave pubblica SSH I metadati del progetto Compute Engine. Tutti Le VM di Compute Engine che utilizzano immagini fornite da Google controllano regolarmente dei metadati comuni del progetto e dei metadati della rispettiva istanza per le chiavi SSH da aggiungere l'elenco degli utenti autorizzati della VM. Inoltre, GKE aggiunge una regola firewall alla rete Compute Engine per consentire l'accesso SSH dal controllo l'indirizzo IP del piano su ciascun nodo nel cluster.

Le seguenti impostazioni possono causare problemi di comunicazione SSH:

• Le regole del firewall della tua rete non consentono l'accesso SSH dal piano di controllo.

  Tutte le reti Compute Engine vengono create con una regola firewall denominata default-allow-ssh che consente l'accesso SSH da tutti gli indirizzi IP (richiedendo una chiave privata valida). GKE inserisce anche una regola SSH per ogni cluster pubblico nel formato gke-CLUSTER_NAME-RANDOM_CHARACTERS-ssh che consente l'accesso SSH in modo specifico dal piano di controllo nei nodi del cluster.

  Se nessuna di queste regole esiste, il piano di controllo non può aprire i tunnel SSH.

  Per verificare che questa sia la causa del problema, controlla se la tua configurazione contiene queste regole.

  Per risolvere il problema, identifica il tag presente su tutti i nodi del cluster, quindi aggiungi di nuovo una regola firewall che consenta l'accesso alle VM con quel tag dall'indirizzo IP del piano di controllo.

• La voce di metadati comune del tuo progetto per ssh-keys è piena.

  Se la voce dei metadati del progetto denominata ssh-keys è vicina al suo limite di dimensione massimo, GKE non è in grado di aggiungere la propria chiave SSH per l'apertura dei tunnel SSH.

  Per verificare che il problema sia questo, controlla la lunghezza dell'elenco di ssh-keys. Puoi visualizzare i metadati del tuo progetto eseguendo il comando seguente, incluso facoltativamente il flag --project:

  gcloud compute project-info describe [--project=PROJECT_ID]
  

  Per risolvere il problema, elimina alcune chiavi SSH che non sono più necessari.

• Hai impostato un campo dei metadati con la chiave ssh-keys sulle VM del cluster.

  L'agente nodo sulle VM preferisce le chiavi SSH per istanza alle chiavi SSH a livello di progetto. Pertanto, se hai impostato chiavi SSH in modo specifico sui nodi del cluster, la chiave SSH del piano di controllo nei metadati di progetto non verrà rispettata nodi.

  Per verificare che si tratti del problema, esegui gcloud compute instances describe VM_NAME e cerca un campo ssh-keys nei metadati.

  Per risolvere il problema, elimina le chiavi SSH per istanza dai metadati dell'istanza.

Risolvere i problemi relativi al proxy Konnectivity

Puoi determinare se il tuo cluster utilizza il proxy Konnectivity controllando il seguente deployment di sistema:

kubectl get deployments konnectivity-agent --namespace kube-system

Le seguenti impostazioni possono causare problemi con il proxy Konnectivity:

• Le regole firewall della tua rete non consentono all'agente Konnectivity di accedere al piano di controllo.

  Durante la creazione del cluster, i pod dell'agente Konnectivity stabiliscono mantieni una connessione al piano di controllo sulla porta 8132. Quando uno dei I comandi kubectl vengono eseguiti, il server API utilizza questa connessione per comunicare con il cluster.

  Se le regole firewall della tua rete contengono regole di negazione in uscita, possono impedire la connessione dell'agente.

  Per verificare che questa sia la causa del problema, controlla il firewall della tua rete per vedere se contengono regole di negazione in uscita.

  Per risolvere questo problema, consenti il traffico in uscita verso il cluster sulla porta 8132. Per un confronto, il server API utilizza 443.

• Il criterio di rete del tuo cluster blocca il traffico in entrata dallo spazio dei nomi kube-system allo spazio dei nomi workload.

  Queste funzionalità non sono necessarie per il corretto funzionamento del cluster. Se preferisci mantenere la rete del cluster protetta da qualsiasi accesso esterno, tieni presente che funzionalità come queste non funzioneranno.

  Per verificare che questa sia la causa del problema, individua il i criteri di rete nello spazio dei nomi interessato eseguendo questo comando:

  kubectl get networkpolicy --namespace AFFECTED_NAMESPACE
  

  Per risolvere il problema, aggiungi quanto segue al file spec.ingress dei criteri di rete:

  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: konnectivity-agent
  

Passaggi successivi

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