Questa documentazione si riferisce alla versione attuale di GKE su AWS, rilasciata a novembre 2021. Consulta le Note di rilascio per ulteriori informazioni.

Risolvere i problemi comuni

Questa pagina mostra come risolvere i problemi comuni di GKE su AWS.

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

Messaggi di errore comuni

Le seguenti sezioni spiegano le cause e le soluzioni di alcuni messaggi di errore più comuni.

Il server non contiene una risorsa

Errori come error: the server doesn't have a resource type "services" possono verificarsi quando un cluster non ha pool di nodi in esecuzione o quando il gateway Connect non può connettersi a un pool di nodi. Per controllare lo stato dei pool di nodi, esegui questo comando:

gcloud container aws node-pools list \
    --cluster-name CLUSTER_NAME \
    --location LOCATION

Sostituisci quanto segue:

CLUSTER_NAME: nome del cluster
LOCATION: la località Google Cloud che gestisce il cluster

L'output include lo stato dei pool di nodi del cluster. Se non è elencato un pool di nodi, crea un pool di nodi.

Utente non consentito

Il seguente errore si verifica quando il tuo nome utente non dispone dell'accesso amministrativo al cluster:

Error from server (Forbidden): users "administrator@example.com" is forbidden:
User "system:serviceaccount:gke-connect:connect-agent-sa" cannot impersonate
resource "users" in API group "" at the cluster scope

Puoi configurare utenti aggiuntivi passando il flag --admin-users quando crei un cluster.

Se utilizzi il gateway Connect e non riesci a connetterti al cluster, prova a svolgere i seguenti passaggi:

Recupera gli utenti autorizzati per il tuo cluster.
```
gcloud container aws clusters describe CLUSTER_NAME \
    --format 'value(authorization.admin_users)'
```
Sostituisci CLUSTER_NAME con il nome del cluster.

L'output include i nomi utente con accesso amministrativo al cluster. Ad esempio:
```
{'username': 'administrator@example.com'}
```
Ottieni il nome utente attualmente autenticato con Google Cloud CLI.
```
gcloud config get-value account
```
L'output include l'account autenticato con Google Cloud CLI. Se l'output di gcloud containers aws clusters describe e gcloud config get-value account non corrisponde, esegui gcloud auth login e autentica come nome utente con accesso amministrativo al cluster.

Problemi con i comandi kubectl

Le seguenti sezioni forniscono indicazioni su come risolvere i problemi relativi ai comandi kubectl che non rispondono o non funzionano.

I comandi kubectl non rispondono più

Se il tuo cluster esegue una versione di Kubernetes precedente alla 1.25 e i comandi kubectl non rispondono o scadono, il motivo più comune è che non hai ancora creato un pool di nodi. Per impostazione predefinita, GKE su AWS genera file kubeconfig che utilizzano Connect Gateway come endpoint raggiungibile da internet. Affinché questo comando funzioni, il deployment gke-connect-agent deve essere in esecuzione in un pool di nodi nel cluster.

Per ulteriori informazioni diagnostiche, esegui questo comando:

kubectl cluster-info -v=9

Se non sono presenti pool di nodi in esecuzione, le richieste a connectgateway.googleapis.com non vanno a buon fine e viene restituito un errore 404 cannot find active connections for cluster.

Per i cluster con una versione di Kubernetes 1.25 o successiva, gke-connect-agent viene eseguito sul piano di controllo e non è richiesto un pool di nodi. Se il comando kubectl non risponde, controlla i log dei componenti del piano di controllo con Cloud Logging.

I comandi kubectl exec,attach e port-forward hanno esito negativo

È possibile che i comandi kubectl exec, kubectl attach e kubectl port-forward non vadano a buon fine con il messaggio error: unable to upgrade connection quando utilizzi Connetti il gateway. Questa è una limitazione quando si utilizza Connetti a gateway come endpoint del server API Kubernetes.

Per risolvere il problema, utilizza un kubeconfig che specifichi l'endpoint privato del cluster. Per istruzioni su come accedere al cluster tramite il suo endpoint privato, consulta Configurare l'accesso al cluster per kubectl.

kubectl logs non riesce con errore remoto: tls: errore interno

Questo problema potrebbe verificarsi quando il ruolo API Control Plane non ha un'autorizzazione. Ad esempio, questo può accadere se nel tuo ruolo AWS manca l'autorizzazione ec2:DescribeDhcpOptions. In questo caso, le richieste di firma dei certificati provenienti dai nodi non possono essere approvate e il nodo worker non ha un certificato valido.

Per determinare se questo è il problema, puoi controllare se esistono richieste di firma del certificato in sospeso che non sono state approvate con questo comando:

kubectl get csr

Per risolvere il problema, verifica che il ruolo AWS soddisfi i requisiti.

Risoluzione dei problemi generici di kubectl

Se utilizzi Connect gateway:

Assicurati di aver abilitato Connect Gateway nel tuo progetto Google Cloud:
```
gcloud services enable connectgateway.googleapis.com
```
Per i cluster con una versione di Kubernetes precedente alla 1.25, assicurati di avere almeno un pool di nodi Linux in esecuzione e che gke-connect-agent sia in esecuzione. Per maggiori dettagli, consulta Risolvere i problemi di connessione ai cluster.
Per i cluster con Kubernetes versione 1.25 o successiva, controlla i log gke-connect-agent con Cloud Logging.

Il servizio Kubernetes (LoadBalancer) o Kubernetes Ingress non funzionano

Se sono stati creati i bilanciatori del carico AWS Elastic (ELB/NLB/ALB) ma non funzionano come previsto, ciò potrebbe essere dovuto a problemi con il tagging della subnet. Per ulteriori informazioni, consulta Subnet del bilanciatore del carico.

Arresto anomalo dei pod sui nodi ARM

Il seguente problema si verifica quando esegui il deployment di un pod su un nodo ARM, ma l'immagine del container non è creata per l'architettura ARM.

Per identificare il problema, completa le seguenti attività:

Ottieni lo stato dei tuoi pod:
```
kubectl get pods
```
Recupera i log del pod che si arresta in modo anomalo:
```
kubectl logs POD_NAME
```
Sostituisci POD_NAME con il nome del pod con arresto anomalo.

Il messaggio di errore nei log del pod è simile al seguente:
```
exec ./hello-app: exec format error
```

Per risolvere il problema, assicurati che l'immagine container supporti l'architettura ARM. Come best practice, crea più immagini di architettura.

Impossibile eliminare il cluster

Se ricevi un errore simile al seguente quando provi a eliminare un cluster, il tuo ruolo API GKE Multi-Cloud potrebbe non esistere:

ERROR: (gcloud.container.aws.clusters.delete) FAILED_PRECONDITION: Could not
assume role
"arn:aws:iam::ACCOUNT_NUMBER:role/gke123456-anthos-api-role"
through service account
"service-123456789@gcp-sa-gkemulticloud.iam.gserviceaccount.com".
Please make sure the role has a trust policy allowing the GCP service agent to
assume it: WebIdentityErr failed to retrieve credentials

Per risolvere il problema, segui i passaggi in Creazione del ruolo API GKE Multi-Cloud. Quando ricrei il ruolo con lo stesso nome e le stesse autorizzazioni, puoi riprovare a utilizzare il comando.

Passaggi successivi

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