Questa pagina mostra come risolvere i problemi comuni di GKE su AWS.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.Messaggi di errore comuni
Le sezioni seguenti spiegano le cause e le soluzioni per alcuni messaggi di errore comuni.
Il server non ha una risorsa
Errori come error: the server doesn't have a resource type "services"
possono
verificarsi quando un cluster non ha node pool in esecuzione o il gateway di connessione non può
connettersi a un pool di nodi. Per controllare lo stato dei tuoi nodepool, esegui questo comando:
gcloud container aws node-pools list \
--cluster-name CLUSTER_NAME \
--location LOCATION
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del tuo clusterLOCATION
: la Google Cloud posizione che gestisce il tuo cluster
L'output include lo stato dei pool di nodi del cluster. Se non è elencato unpool di nodil, creane uno.
Utente vietato
Il seguente errore si verifica quando il tuo nome utente non dispone dell'accesso amministrativo al tuo 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 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'}
Recupera 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
egcloud config get-value account
non corrisponde, eseguigcloud auth login
e autenticati come nome utente con accesso amministrativo al cluster.
Problemi con i comandi kubectl
Le sezioni seguenti 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 cluster esegue una versione di Kubernetes precedente alla 1.25 e i comandi kubectl
non rispondono o vanno in timeout, il motivo più comune è che non hai ancora creato un pool di nodi. Per impostazione predefinita, GKE su AWS genera
file kubeconfig
che utilizzano il gateway Connect come endpoint raggiungibile da internet.
Affinché questa operazione funzioni, il deployment gke-connect-agent
deve essere in esecuzione in un pool di nodi del 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 visualizzato un errore
cannot find active connections for cluster
404.
Per i cluster con Kubernetes versione 1.25 o successive, gke-connect-agent
viene eseguito sul control plane e non è necessario unpool di nodil. Se il comando kubectl
non risponde, controlla i log dei componenti del control plane con
Cloud Logging.
I comandi kubectl exec, attach e port-forward non vanno a buon fine
I comandi kubectl exec
, kubectl attach
e kubectl port-forward
potrebbero
non riuscire con il messaggio error: unable to upgrade connection
quando utilizzi
il gateway di connessione. Si tratta di una limitazione quando utilizzi Connect Gateway come endpoint del server API Kubernetes.
Per risolvere il problema, utilizza un kubeconfig
che specifica l'endpoint privato del cluster. Per istruzioni su come accedere al cluster tramite il relativo endpoint privato, vedi Configurare l'accesso ai cluster per kubectl.
kubectl logs non riesce con l'errore remoto: tls: internal error
Questo problema può verificarsi quando al ruolo API Control Plane manca un'autorizzazione. Ad esempio, questo può verificarsi se al tuo ruolo AWS manca
l'autorizzazioneec2:DescribeDhcpOptions
. In questo caso, le richieste di firma del certificato
dai nodi non possono essere approvate e il nodo di lavoro non dispone di un certificato
valido.
Per determinare se questo è il problema, puoi verificare se sono presenti richieste di firma del certificato in attesa di approvazione con questo comando:
kubectl get csr
Per risolvere il problema, verifica che il tuo ruolo AWS soddisfi i requisiti.
Risoluzione dei problemi generici di kubectl
Se utilizzi Connect Gateway:
Assicurati di aver attivato il gateway Connect 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, vedi Risolvere i problemi relativi alle connessioni del cluster.Per i cluster con Kubernetes versione 1.25 o successive, controlla i log
gke-connect-agent
con Cloud Logging.
Il servizio Kubernetes (bilanciatore del carico) o Kubernetes Ingress non funziona
Se i tuoi AWS Elastic Load Balancers (ELB/NLB/ALB) sono stati creati ma non funzionano come previsto, il problema potrebbe essere dovuto a errori di tagging delle subnet. Per ulteriori informazioni, vedi 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 container non è creata per l'architettura Arm.
Per identificare il problema, completa le seguenti attività:
Recupera lo stato dei tuoi pod:
kubectl get pods
Recupera i log del pod che ha causato l'arresto anomalo:
kubectl logs POD_NAME
Sostituisci
POD_NAME
con il nome del pod che ha generato l'arresto anomalo.Il messaggio di errore nei log dei pod è simile al seguente:
exec ./hello-app: exec format error
Per risolvere il problema, assicurati che l'immagine del contenitore 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 descritti in Crea il ruolo API GKE Multi-Cloud. Quando ricrei il ruolo con lo stesso nome e le stesse autorizzazioni, puoi riprovare il comando.
Passaggi successivi
- Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.