Alcune o tutte le informazioni in questa pagina potrebbero non essere applicabili a Trusted Cloud by S3NS.

Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvere gli errori 4xx

Autopilot Standard

Questa pagina ti aiuta a risolvere gli errori 400, 401, 403 e 404 che potresti riscontrare quando utilizzi Google Kubernetes Engine (GKE).

Problema: errori di autenticazione e autorizzazione

Quando ti connetti ai cluster GKE, potresti 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 nel tuo cluster GKE da un ambiente locale.

La causa di questo problema potrebbe essere una delle seguenti:

Il plug-in di autenticazione gke-gcloud-auth-plugin non è installato o configurato correttamente.
Non disponi delle autorizzazioni per connetterti al server API del cluster ed eseguire i comandi kubectl.

Per diagnosticare la causa, completa i passaggi descritti nelle sezioni seguenti:

Connettiti al cluster utilizzando curl
Configurare il plug-in in kubeconfig

Connettiti al cluster utilizzando `curl`

Per diagnosticare la causa dell'errore di autenticazione e autorizzazione, connettiti al cluster utilizzando curl. L'utilizzo di curl bypassa lo strumento a riga di comando kubectl e il plug-in gke-gcloud-auth-plugin.

Imposta le variabili di ambiente:

APISERVER=https://$(gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION --format "value(endpoint)")
TOKEN=$(gcloud auth print-access-token)

Verifica che il token di accesso sia valido:
```
curl https://oauth2.googleapis.com/tokeninfo?access_token=$TOKEN
```
Quando hai un token di accesso valido, questo comando invia una richiesta al server OAuth 2.0 di Google e il server risponde con informazioni sul token.

Prova a connetterti all'endpoint API principale nel server API:

# Get cluster CA certificate
gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --format "value(masterAuth.clusterCaCertificate)" | \
    base64 -d > /tmp/ca.crt

# Make API call with authentication and CA certificate
curl -s -X GET "${APISERVER}/api/v1/namespaces" \
    --header "Authorization: Bearer $TOKEN" \
    --cacert /tmp/ca.crt

Se il comando curl ha esito positivo, viene visualizzato un elenco di spazi dei nomi. Procedi per verificare se il plug-in è la causa utilizzando i passaggi descritti nella sezione Configurare il plug-in in kubeconfig.

Se il comando curl non va a buon fine e restituisce un output simile al seguente, significa che non disponi delle autorizzazioni corrette per accedere al cluster:

{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}

Per risolvere il problema, consulta l'amministratore per ottenere le autorizzazioni corrette per accedere al cluster.

Configura l'utilizzo del plug-in in kubeconfig

Se ricevi errori di autenticazione e autorizzazione durante la connessione ai cluster, ma sei riuscito a connetterti al cluster utilizzando curl, assicurati di poter accedere al cluster senza bisogno del plug-in gke-gcloud-auth-plugin.

Per risolvere il problema, configura l'ambiente locale in modo da ignorare il file binario gke-gcloud-auth-plugin durante l'autenticazione al cluster. Nei client Kubernetes che eseguono la versione 1.25 e successive, il binario gke-gcloud-auth-plugin è obbligatorio, quindi devi utilizzare una versione 1.24 o precedente per lo strumento a riga di comando kubectl.

Per accedere al cluster senza bisogno del plug-in, segui questi passaggi:

Installa lo strumento a riga di comando kubectl con la versione 1.24 o precedente utilizzando curl. Il seguente esempio installa lo strumento con la versione 1.24:
```
curl -LO https://dl.k8s.io/release/v1.24.0/bin/linux/amd64/kubectl
```
Apri il file dello script di avvio della shell in un editor di testo. Ad esempio, apri .bashrc per la shell Bash:
```
vi ~/.bashrc
```
Se utilizzi macOS, usa ~/.bash_profile anziché .bashrc in queste istruzioni.
Aggiungi la seguente riga al file dello script di avvio e salvalo:
```
export USE_GKE_GCLOUD_AUTH_PLUGIN=False
```
Esegui lo script di avvio:
```
source ~/.bashrc
```
Recupera le credenziali per il tuo cluster, che configura il file .kube/config:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=COMPUTE_LOCATION
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster.
- COMPUTE_LOCATION: la posizione di Compute Engine.
Esegui un comando kubectl. Ad esempio:
```
kubectl cluster-info
```
Se ricevi un errore 401 o un errore di autorizzazione simile dopo aver eseguito questi comandi, assicurati di disporre delle autorizzazioni corrette, quindi esegui di nuovo il passaggio che ha restituito l'errore.

Errore 400: è necessaria la ricreazione del node pool

Il seguente errore può verificarsi quando tenti di eseguire un'azione che ricrea il control plane e i nodi:

ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.

Ad esempio, questo errore può verificarsi quando completi una rotazione delle credenziali in corso.

Nel backend, i node pool vengono contrassegnati per la ricreazione, ma l'operazione di ricreazione effettiva potrebbe richiedere del tempo per iniziare. Per questo motivo, l'operazione non riesce perché GKE non ha ancora ricreato uno o più pool di nodi nel tuo cluster.

Per risolvere il problema, scegli una delle seguenti soluzioni:

Attendi la ricreazione. Questa operazione potrebbe richiedere ore, giorni o settimane, a seconda di fattori quali periodi di manutenzione ed esclusioni esistenti.
Avvia manualmente una ricreazione dei pool di nodi interessati avviando un upgrade della versione alla stessa versione del control plane.

Per avviare una ricreazione, esegui questo comando:
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=POOL_NAME
```
Al termine dell'upgrade, riprova l'operazione.

Errore 401: richiesta non autorizzata

Identifica i cluster con service account del nodo a cui mancano le autorizzazioni critiche

Per identificare i cluster con service account nodo a cui mancano autorizzazioni critiche, utilizza i consigli di GKE del NODE_SA_MISSING_PERMISSIONS sottotipo di suggeritore:

Utilizza la console Trusted Cloud . Vai alla pagina Cluster Kubernetes e controlla il suggerimento Concedi autorizzazioni critiche nella colonna Notifiche per cluster specifici.

Utilizza gcloud CLI o l'API Recommender specificando il sottotipo di motore per suggerimenti NODE_SA_MISSING_PERMISSIONS.

Per eseguire query sui consigli, esegui questo comando:

gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

Tieni presente che la visualizzazione del consiglio può richiedere fino a 24 ore. Per istruzioni dettagliate, scopri come visualizzare approfondimenti e consigli.

Per implementare questo consiglio, concedi il ruolo roles/container.defaultNodeServiceAccount al account di servizio del nodo.

Puoi eseguire uno script che cerca i node pool nei cluster Standard e Autopilot del tuo progetto per individuare eventuali service account dei nodi che non dispongono delle autorizzazioni richieste per GKE. Questo script utilizza gcloud CLI e l'utilità jq. Per visualizzare lo script, espandi la sezione seguente:

Visualizzare lo script

#!/bin/bash

# Set your project ID
project_id=PROJECT_ID
project_number=$(gcloud projects describe "$project_id" --format="value(projectNumber)")
declare -a all_service_accounts
declare -a sa_missing_permissions

# Function to check if a service account has a specific permission
# $1: project_id
# $2: service_account
# $3: permission
service_account_has_permission() {
  local project_id="$1"
  local service_account="$2"
  local permission="$3"

  local roles=$(gcloud projects get-iam-policy "$project_id" \
          --flatten="bindings[].members" \
          --format="table[no-heading](bindings.role)" \
          --filter="bindings.members:\"$service_account\"")

  for role in $roles; do
    if role_has_permission "$role" "$permission"; then
      echo "Yes" # Has permission
      return
    fi
  done

  echo "No" # Does not have permission
}

# Function to check if a role has the specific permission
# $1: role
# $2: permission
role_has_permission() {
  local role="$1"
  local permission="$2"
  gcloud iam roles describe "$role" --format="json" | \
  jq -r ".includedPermissions" | \
  grep -q "$permission"
}

# Function to add $1 into the service account array all_service_accounts
# $1: service account
add_service_account() {
  local service_account="$1"
  all_service_accounts+=( ${service_account} )
}

# Function to add service accounts into the global array all_service_accounts for a Standard GKE cluster
# $1: project_id
# $2: location
# $3: cluster_name
add_service_accounts_for_standard() {
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"

  while read nodepool; do
    nodepool_name=$(echo "$nodepool" | awk '{print $1}')
    if [[ "$nodepool_name" == "" ]]; then
      # skip the empty line which is from running `gcloud container node-pools list` in GCP console
      continue
    fi
    while read nodepool_details; do
      service_account=$(echo "$nodepool_details" | awk '{print $1}')

      if [[ "$service_account" == "default" ]]; then
        service_account="${project_number}-compute@developer.s3ns-system.iam.gserviceaccount.com"
      fi
      if [[ -n "$service_account" ]]; then
        printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" $service_account $project_id  $cluster_name $cluster_location $nodepool_name
        add_service_account "${service_account}"
      else
        echo "cannot find service account for node pool $project_id\t$cluster_name\t$cluster_location\t$nodepool_details"
      fi
    done <<< "$(gcloud container node-pools describe "$nodepool_name" --cluster "$cluster_name" --zone "$cluster_location" --project "$project_id" --format="table[no-heading](config.serviceAccount)")"
  done <<< "$(gcloud container node-pools list --cluster "$cluster_name" --zone "$cluster_location" --project "$project_id" --format="table[no-heading](name)")"

}

# Function to add service accounts into the global array all_service_accounts for an Autopilot GKE cluster
# Autopilot cluster only has one node service account.
# $1: project_id
# $2: location
# $3: cluster_name
add_service_account_for_autopilot(){
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"

  while read service_account; do
      if [[ "$service_account" == "default" ]]; then
        service_account="${project_number}-compute@developer.s3ns-system.iam.gserviceaccount.com"
      fi
      if [[ -n "$service_account" ]]; then
        printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" $service_account $project_id  $cluster_name $cluster_location $nodepool_name
        add_service_account "${service_account}"
      else
        echo "cannot find service account" for cluster  "$project_id\t$cluster_name\t$cluster_location\t"
      fi
  done <<< "$(gcloud container clusters describe "$cluster_name" --location "$cluster_location" --project "$project_id" --format="table[no-heading](autoscaling.autoprovisioningNodePoolDefaults.serviceAccount)")"
}


# Function to check whether the cluster is an Autopilot cluster or not
# $1: project_id
# $2: location
# $3: cluster_name
is_autopilot_cluster() {
  local project_id="$1"
  local cluster_location="$2"
  local cluster_name="$3"
  autopilot=$(gcloud container clusters describe "$cluster_name" --location "$cluster_location" --format="table[no-heading](autopilot.enabled)")
  echo "$autopilot"
}


echo "--- 1. List all service accounts in all GKE node pools"
printf "%-60s| %-40s| %-40s| %-10s| %-20s\n" "service_account" "project_id" "cluster_name" "cluster_location" "nodepool_name"
while read cluster; do
  cluster_name=$(echo "$cluster" | awk '{print $1}')
  cluster_location=$(echo "$cluster" | awk '{print $2}')
  # how to find a cluster is a Standard cluster or an Autopilot cluster
  autopilot=$(is_autopilot_cluster "$project_id" "$cluster_location" "$cluster_name")
  if [[ "$autopilot" == "True" ]]; then
    add_service_account_for_autopilot "$project_id" "$cluster_location"  "$cluster_name"
  else
    add_service_accounts_for_standard "$project_id" "$cluster_location"  "$cluster_name"
  fi
done <<< "$(gcloud container clusters list --project "$project_id" --format="value(name,location)")"

echo "--- 2. Check if service accounts have permissions"
unique_service_accounts=($(echo "${all_service_accounts[@]}" | tr ' ' '\n' | sort -u | tr '\n' ' '))

echo "Service accounts: ${unique_service_accounts[@]}"
printf "%-60s| %-40s| %-40s| %-20s\n" "service_account" "has_logging_permission" "has_monitoring_permission" "has_performance_hpa_metric_write_permission"
for sa in "${unique_service_accounts[@]}"; do
  logging_permission=$(service_account_has_permission "$project_id" "$sa" "logging.logEntries.create")
  time_series_create_permission=$(service_account_has_permission "$project_id" "$sa" "monitoring.timeSeries.create")
  metric_descriptors_create_permission=$(service_account_has_permission "$project_id" "$sa" "monitoring.metricDescriptors.create")
  if [[ "$time_series_create_permission" == "No" || "$metric_descriptors_create_permission" == "No" ]]; then
    monitoring_permission="No"
  else
    monitoring_permission="Yes"
  fi
  performance_hpa_metric_write_permission=$(service_account_has_permission "$project_id" "$sa" "autoscaling.sites.writeMetrics")
  printf "%-60s| %-40s| %-40s| %-20s\n" $sa $logging_permission $monitoring_permission $performance_hpa_metric_write_permission

  if [[ "$logging_permission" == "No" || "$monitoring_permission" == "No" || "$performance_hpa_metric_write_permission" == "No" ]]; then
    sa_missing_permissions+=( ${sa} )
  fi
done

echo "--- 3. List all service accounts that don't have the above permissions"
if [[ "${#sa_missing_permissions[@]}" -gt 0 ]]; then
  printf "Grant roles/container.defaultNodeServiceAccount to the following service accounts: %s\n" "${sa_missing_permissions[@]}"
else
  echo "All service accounts have the above permissions"
fi

Identificare i service account del nodo a cui mancano le autorizzazioni critiche in un cluster

GKE utilizza i service account IAM collegati ai nodi per eseguire attività di sistema come il logging e il monitoraggio. Come minimo, questi service account nodo devono avere il ruolo Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) sul tuo progetto. Per impostazione predefinita, GKE utilizza l'account di servizio predefinito di Compute Engine, che viene creato automaticamente nel tuo progetto, come service account del nodo.

Se la tua organizzazione applica il vincolo del criterio dell'organizzazione iam.automaticIamGrantsForDefaultServiceAccounts, il account di servizio Compute Engine predefinito nel tuo progetto potrebbe non ottenere automaticamente le autorizzazioni richieste per GKE.

Trova il nome del account di servizio utilizzato dai tuoi nodi:
console
1. Vai alla pagina Cluster Kubernetes:
  Vai ai cluster Kubernetes
2. Nell'elenco dei cluster, fai clic sul nome del cluster che vuoi controllare.
3. A seconda della modalità di funzionamento del cluster, esegui una delle seguenti operazioni:
  
  Per i cluster in modalità Autopilot, nella sezione Sicurezza, individua il campo Service account.
  
  Per i cluster in modalità Standard:
  
  Fai clic sulla scheda Nodi.
  
  Nella tabella Pool di nodi, fai clic sul nome di un node pool. Viene visualizzata la pagina Dettagli node pool.
  
  Nella sezione Sicurezza, trova il campo Service account.
Se il valore nel campo Service account è default, i nodi utilizzano il account di servizio predefinito di Compute Engine. Se il valore in questo campo non è default, i tuoi nodi utilizzano unaccount di serviziot personalizzato. Per concedere il ruolo richiesto a un account di servizio personalizzato, consulta Utilizzare i service account IAM con privilegio minimo minimi.
gcloud

Per i cluster in modalità Autopilot, esegui questo comando:
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --flatten=autoscaling.autoprovisioningNodePoolDefaults.serviceAccount
Per i cluster in modalità Standard, esegui questo comando:
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --format="table(nodePools.name,nodePools.config.serviceAccount)"
Se l'output è default, i nodi utilizzano il account di servizio predefinito di Compute Engine. Se l'output non è default, i tuoi nodi utilizzano un account di servizio personalizzato. Per concedere il ruolo richiesto a un account di servizio personalizzato, consulta Utilizzare i service account IAM con privilegio minimo minimi.
Per concedere il ruolo roles/container.defaultNodeServiceAccount al account di servizio predefinito di Compute Engine, completa i seguenti passaggi:
console
1. Vai alla pagina Benvenuto:
  Vai a Benvenuto
2. Nel campo Numero progetto, fai clic su Copia negli appunti.
3. Vai alla pagina IAM:
  Vai a IAM
4. Fai clic su Concedi l'accesso.
5. Nel campo Nuove entità, specifica il seguente valore:
  PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com
  Sostituisci PROJECT_NUMBER con il numero di progetto che hai copiato.
6. Nel menu Seleziona un ruolo, seleziona il ruolo Kubernetes Engine Default Node Service Account.
7. Fai clic su Salva.
gcloud
1. Trova il numero del tuo progetto Trusted Cloud :
  gcloud projects describe PROJECT_ID \ --format="value(projectNumber)"
  
  Sostituisci PROJECT_ID con l'ID progetto.
  
  L'output è simile al seguente:
  
  12345678901
2. Concedi il ruolo roles/container.defaultNodeServiceAccount all'account di servizio predefinito di Compute Engine:
  gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com" \ --role="roles/container.defaultNodeServiceAccount"
  
  Sostituisci PROJECT_NUMBER con il numero di progetto del passaggio precedente.

Errore 403: autorizzazioni insufficienti

Si verifica il seguente errore quando tenti di connetterti a un cluster GKE utilizzando gcloud container clusters get-credentials, ma l'account non dispone dell'autorizzazione per accedere al server API Kubernetes:

ERROR: (gcloud.container.clusters.get-credentials) ResponseError: code=403, message=Required "container.clusters.get" permission(s) for "projects/<your-project>/locations/<region>/clusters/<your-cluster>".

Per risolvere il problema, completa i seguenti passaggi:

Identifica l'account che presenta il problema di accesso:
```
gcloud auth list
```
Concedi l'accesso richiesto all'account seguendo le istruzioni riportate in Autenticazione nel server dell'API Kubernetes.

Errore 403: budget per i tentativi esaurito

Il seguente errore può verificarsi quando provi a creare un cluster GKE:

Error: googleapi: Error 403: Retry budget exhausted: Google Compute Engine:
Required permission 'PERMISSION_NAME' for 'RESOURCE_NAME'.

In questo messaggio di errore, si applicano le seguenti variabili:

PERMISSION_NAME: il nome di un'autorizzazione, ad esempio compute.regions.get.
RESOURCE_NAME: il percorso della risorsa Trusted Cloud a cui stavi tentando di accedere, ad esempio una regione Compute Engine.

Questo errore si verifica se il account di servizio IAM collegato al cluster non dispone delle autorizzazioni minime richieste per creare il cluster.

Per risolvere il problema:

Crea o modifica un account di servizio IAM in modo che disponga di tutte le autorizzazioni richieste per eseguire un cluster GKE. Per istruzioni, vedi Utilizzare i service account IAM con privilegio minimo minimi.
Specifica l'account di servizio IAM aggiornato nel comando di creazione del cluster utilizzando il flag --service-account. Per istruzioni, vedi Creazione di un cluster Autopilot.

In alternativa, ometti il flag --service-account per consentire a GKE di utilizzare il account di servizio predefinito di Compute Engine nel progetto, che dispone delle autorizzazioni richieste per impostazione predefinita.

Errore 404: risorsa non trovata

Se ricevi un errore 404, risorsa non trovata, quando chiami i comandi gcloud container, risolvi il problema eseguendo nuovamente l'autenticazione in Google Cloud CLI:

gcloud auth login

Errore 400/403: autorizzazioni di modifica mancanti nell'account

Un errore di autorizzazioni di modifica mancanti nell'account (errore 400 o 403) indica che uno dei seguenti elementi è stato eliminato o modificato manualmente:

Quando abiliti l'API Compute Engine o GKE, Trusted Cloud vengono creati i seguenti account di servizio e agenti:

Service account predefinito di Compute Engine nel tuo progetto. GKE collega questoaccount di serviziot ai nodi per impostazione predefinita per attività di sistema come il logging e il monitoraggio.
Agente di servizio delle API di Google in un progetto gestito da Google, con autorizzazioni di modifica sul tuo progetto.
Agente di servizio Google Kubernetes Engine in un progetto gestito da Google, con il ruolo Agente di servizio Kubernetes Engine sul tuo progetto.

La creazione del cluster e tutta la gestione non vanno a buon fine se, in qualsiasi momento, qualcuno modifica queste autorizzazioni, rimuove i binding dei ruoli nel progetto, rimuove completamente l'account di servizio o disabilita l'API.

Verifica le autorizzazioni per l'agente di servizio GKE

Per verificare se al account di servizio Google Kubernetes Engine è assegnato il ruolo Agente di servizio Kubernetes Engine nel progetto, completa i seguenti passaggi:

Determina il nome del tuo account di servizio Google Kubernetes Engine. Tutti i service account hanno il seguente formato:
```
service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com
```
Sostituisci PROJECT_NUMBER con il numero del tuo progetto.
Verifica che al tuo account di servizio Google Kubernetes Engine non sia assegnato il ruolo Agente di servizio Kubernetes Engine nel progetto:
```
gcloud projects get-iam-policy PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.

Per risolvere il problema, se qualcuno ha rimosso il ruolo Service agent Kubernetes Engine dal tuoaccount di serviziot Google Kubernetes Engine, aggiungilo di nuovo. In caso contrario, utilizza le seguenti istruzioni per riattivare l'API Kubernetes Engine, che ripristina gli account di servizio e le autorizzazioni:

Console

Vai alla pagina API e servizi nella console Trusted Cloud .

Vai ad API e servizi
Seleziona il progetto.
Fai clic su Abilita API e servizi.
Cerca Kubernetes, quindi seleziona l'API dai risultati di ricerca.
Fai clic su Attiva. Se hai già abilitato l'API, devi prima disattivarla e poi riattivarla. L'attivazione dell'API e dei servizi correlati può richiedere diversi minuti.

gcloud

Esegui questi comandi nell'interfaccia a riga di comando gcloud:

PROJECT_NUMBER=$(gcloud projects describe "PROJECT_ID"
    --format 'get(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:service-${PROJECT_NUMBER?}@container-engine-robot.s3ns-system.iam.gserviceaccount.com" \
    --role roles/container.serviceAgent

Passaggi successivi

Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta la sezione Richiedere assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:
- Aprire una richiesta di assistenza contattando l'assistenza clienti cloud.
- Ricevere assistenza dalla community ponendo domande su StackOverflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per ulteriore assistenza della community.
- Apertura di bug o richieste di funzionalità utilizzando lo strumento di monitoraggio dei problemi pubblico.

Risolvere gli errori 4xx

Problema: errori di autenticazione e autorizzazione

Connettiti al cluster utilizzando curl

Configura l'utilizzo del plug-in in kubeconfig

Errore 400: è necessaria la ricreazione del node pool

Errore 401: richiesta non autorizzata

Identifica i cluster con service account del nodo a cui mancano le autorizzazioni critiche

Identificare i service account del nodo a cui mancano le autorizzazioni critiche in un cluster

console

gcloud

console

gcloud

Errore 403: autorizzazioni insufficienti

Errore 403: budget per i tentativi esaurito

Errore 404: risorsa non trovata

Errore 400/403: autorizzazioni di modifica mancanti nell'account

Verifica le autorizzazioni per l'agente di servizio GKE

Console

gcloud

Passaggi successivi

Connettiti al cluster utilizzando `curl`