Risolvere i problemi relativi ai tiri delle immagini

Questa pagina ti aiuta a risolvere i problemi relativi al processo di pull delle immagini in Google Kubernetes Engine (GKE). Se utilizzi lo streaming di immagini, consulta la sezione Risolvere i problemi relativi allo streaming di immagini per ricevere consigli. Questa pagina è incentrata sui pull di immagini standard.

Questa pagina è dedicata agli sviluppatori di applicazioni che vogliono assicurarsi che le loro app vengano implementate correttamente e agli amministratori e agli operatori della piattaforma che vogliono comprendere la causa principale degli errori di pull delle immagini e verificare la configurazione della piattaforma. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Trusted Cloud by S3NS , consulta la pagina Ruoli e attività comuni degli utenti GKE.

Il processo di pull delle immagini è il modo in cui Kubernetes e quindi GKE recuperano le immagini container da un registry. Quando il pull di un'immagine non va a buon fine, potresti notare un rallentamento dell'app o un suo malfunzionamento.

Per determinare se i pull di immagini sono la causa del mancato funzionamento dell'app, questa pagina ti aiuta a diagnosticare l'errore di pull di immagini trovando e comprendendo i messaggi di errore pertinenti. Poi, imparerai ad affrontare le seguenti cause comuni di errori di pull delle immagini:

• Impostazioni di autenticazione: il cluster non dispone delle autorizzazioni necessarie per accedere al registro delle immagini container.
• Connettività di rete: il cluster non può connettersi al registro a causa di problemi DNS, regole firewall o mancanza di accesso a internet nei cluster che utilizzano l'isolamento di rete.
• Immagine non trovata nel registro: il nome o il tag dell'immagine specificato non è corretto, l'immagine è stata eliminata o il registro non è disponibile.
• Limitazioni delle prestazioni: le dimensioni elevate delle immagini, l'I/O del disco lento o la congestione della rete possono causare pull lenti o timeout.
• Architettura dell'immagine incompatibile: l'immagine è stata creata per un'architettura della CPU diversa da quella del tuo pool di nodi GKE.
• Versioni dello schema incompatibili: potresti utilizzare containerd 2.0 o versioni successive con uno schema Docker v1, che non è supportato.

Se hai già visualizzato un messaggio di evento specifico, cerca il messaggio in questa pagina e segui i passaggi per la risoluzione dei problemi elencati. Se non hai visto un messaggio, segui le sezioni riportate di seguito in ordine. Se il problema persiste, contatta l'assistenza clienti Google Cloud.

Informazioni sui pull delle immagini

Prima di iniziare la risoluzione dei problemi, è utile capire un po' di più sul ciclo di vita di un'immagine e su dove puoi ospitarle.

Ciclo di vita delle immagini

Quando crei un pod, kubelet riceve la definizione del pod, che include la specifica dell'immagine. Kubelet ha bisogno di questa immagine per poter eseguire un container basato sull'immagine. Prima di eseguire il pull dell'immagine, kubelet controlla il runtime del container per verificare se l'immagine è presente. kubelet controlla anche la policy di pull delle immagini del pod. Se l'immagine non è nella cache del runtime del container o se i criteri di pull dell'immagine lo richiedono, kubelet indica al runtime del container (containerd) di eseguire il pull dell'immagine specificata dal registro. Un pull dell'immagine non riuscito impedisce l'avvio del container nel pod.

Dopo un pull dell'immagine riuscito, il runtime del container decomprime l'immagine per creare un file system di base di sola lettura per il container. Il runtime del container archivia questa immagine e l'immagine rimane presente finché i container in esecuzione fanno riferimento a essa. Se nessun container in esecuzione fa riferimento a un'immagine, questa diventa idonea per la garbage collection e kubelet la rimuove definitivamente.

Opzioni di hosting delle immagini

Ti consigliamo di utilizzare una delle seguenti opzioni per ospitare le immagini:

• Artifact Registry: Artifact Registry è il gestore di pacchetti completamente gestito di Google. Artifact Registry si integra strettamente con altri Trusted Cloud by S3NS servizi e offre controllo dell'accesso granulare. Per saperne di più, consulta Utilizzare le immagini container nella documentazione di Artifact Registry.

• Registry self-hosted: un registry self-hosted ti offre un maggiore controllo, ma richiede anche la gestione del registry. Prendi in considerazione questa opzione se hai esigenze specifiche di conformità o sicurezza che Artifact Registry non può soddisfare.

Diagnosticare l'errore di pull dell'immagine

Per diagnosticare gli errori di pull delle immagini, esegui le indagini descritte nelle sezioni seguenti:

1. Visualizza lo stato e gli eventi del pod.
2. Comprendere il significato dello stato.
3. Utilizza i messaggi di evento per trovare la causa dell'errore di pull dell'immagine.
4. Visualizza i log di Esplora log.

Visualizzare lo stato e gli eventi del pod

Per aiutarti a verificare che il pull di un'immagine non sia riuscito, GKE registra i seguenti stati per i pod:

• ImagePullBackOff
• ErrImagePull
• ImageInspectError
• InvalidImageName
• RegistryUnavailable
• SignatureValidationFailed

ImagePullBackOff e ErrImagePull sono gli stati più comuni.

Oltre a questi stati, gli eventi Kubernetes ti aiutano a trovare la causa degli errori di pull delle immagini.

Per verificare se il pull dell'immagine non va a buon fine, controlla i messaggi di stato e poi leggi i messaggi di evento selezionando una delle seguenti opzioni:

Informazioni sul significato dello stato

Per comprendere meglio il significato dei diversi stati, consulta le seguenti descrizioni:

• ImagePullBackOff: kubelet non è riuscito a estrarre l'immagine, ma continuerà a riprovare con un ritardo crescente (o backoff) fino a cinque minuti.
• ErrImagePull: un errore generale e non recuperabile durante il processo di pull dell'immagine.
• ImageInspectError: il runtime del container ha riscontrato un problema durante il tentativo di ispezionare l'immagine container.
• InvalidImageName: il nome dell'immagine container specificata nella definizione del pod non è valido.
• RegistryUnavailable: il registro non è accessibile. In genere si tratta di un problema di connettività di rete.
• SignatureValidationFailed: non è stato possibile verificare la firma digitale dell'immagine del container.

Utilizzare i messaggi di evento per trovare la causa dell'errore di pull dell'immagine

La tabella che segue elenca i messaggi di evento relativi agli errori di pull delle immagini e i passaggi per la risoluzione dei problemi da seguire se trovi uno di questi messaggi.

I messaggi relativi agli errori di pull delle immagini spesso hanno il seguente prefisso:

Failed to pull image "IMAGE_ADDRESS": rpc error: code = CODE = failed to pull and unpack image "IMAGE_ADDRESS": failed to resolve reference "IMAGE_ADDRESS":

Questo messaggio include i seguenti valori:

• IMAGE_ADDRESS: l'indirizzo completo dell'immagine. Ad esempio, us-west1-docker.pkg.dev/my-project/my-repo/test:staging.
• CODE: un codice di errore associato al messaggio di log. Ad esempio, NotFound o Unknown.

Alcune cause di errori di pull delle immagini non hanno un messaggio di evento correlato. Se non vedi nessuno dei messaggi relativi agli eventi nella tabella seguente, ma continui a riscontrare problemi di pull delle immagini, ti consigliamo di continuare a leggere il resto della pagina.

Visualizzare i log di Esplora log

Per esaminare gli eventi di pull delle immagini storici o correlare gli errori di pull delle immagini con l'attività di altri componenti, visualizza i log con Esplora log:

1. Nella console Trusted Cloud , vai alla pagina Esplora log.

   Vai a Esplora log

2. Nel riquadro della query, inserisci la seguente query:

   log_id("events")
   resource.type="k8s_pod"
   resource.labels.cluster_name="CLUSTER_NAME"
   jsonPayload.message=~"Failed to pull image"
   

   Sostituisci CLUSTER_NAME con il nome del cluster su cui viene eseguito il pod con errori di pull dell'immagine.

3. Fai clic su Esegui query ed esamina i risultati.

Esaminare le impostazioni di autenticazione

Le sezioni seguenti ti aiutano a verificare che il tuo ambiente GKE disponga delle impostazioni di autenticazione corrette per estrarre le immagini dal repository.

Per verificare se i problemi di autenticazione causano un problema di pull dell'immagine, esegui le indagini descritte nelle sezioni seguenti:

1. Verifica l'accesso all'immagine.
2. Verifica la configurazione di imagePullSecret e la specifica del deployment.
3. Verifica lo stato attivo dell'account di servizio del nodo.
4. Verifica l'ambito di accesso del nodo per il repository Artifact Registry privato
5. Verifica le impostazioni dei Controlli di servizio VPC per accedere ad Artifact Registry.

Verificare l'accesso all'immagine

Se riscontri un errore di pull dell'immagine 403 Forbidden, verifica che i componenti richiesti possano accedere all'immagine container.

Il metodo per verificare e applicare i ruoli necessari per concedere l'accesso richiesto varia a seconda del tipo di repository in cui sono archiviate le immagini. Per verificare e concedere l'accesso, seleziona una delle seguenti opzioni:

Verifica la configurazione di imagePullSecret e la specifica del deployment

Se utilizzi un imagePullSecret, assicurati di aver creato un secret che contenga le credenziali di autenticazione per il pull delle immagini e che tutti i deployment specificano il secret che hai definito. Per ulteriori informazioni, consulta Specifica di imagePullSecrets in un pod nella documentazione di Kubernetes.

Verifica lo stato attivo dell'account di servizio del nodo

Se si verifica un errore di pull dell'immagine 401 Unauthorized, verifica che il account di servizio del nodo sia attivo. Anche se le autorizzazioni sono configurate correttamente, un account disattivato mostrerà questo errore. Per verificare lo stato attivo dell'account di servizio del nodo, seleziona una delle seguenti opzioni:

Se il account di servizio è disabilitato, abilita il service account del nodo.

Verifica l'ambito di accesso del nodo per il repository Artifact Registry privato

Se memorizzi l'immagine container in un repository Artifact Registry privato, il nodo potrebbe non avere l'ambito di accesso corretto. In questi casi, potresti notare un errore di pull dell'immagine 401 Unauthorized.

Per verificare l'ambito di accesso e concederlo, se necessario, segui questi passaggi:

1. Identifica il nodo che esegue il pod:

   kubectl describe pod POD_NAME | grep "Node:"
   

   Sostituisci POD_NAME con il nome del pod che riscontra un errore di pull dell'immagine.

2. Verifica che il nodo identificato nel passaggio precedente abbia l'ambito di archiviazione corretto:

   gcloud compute instances describe NODE_NAME \
       --zone="COMPUTE_ZONE" \
       --format="flattened(serviceAccounts[].scopes)"
   

   Sostituisci quanto segue:

   • NODE_NAME: il nome del nodo che hai identificato nel passaggio precedente.
   • COMPUTE_ZONE: la zona Compute Engine a cui appartiene il nodo.

   L'output deve contenere almeno uno dei seguenti ambiti di accesso:

   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
   • serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

   Se il nodo non contiene uno di questi ambiti, il pull dell'immagine non va a buon fine.

3. Ricrea il pool di nodi a cui appartiene il nodo con un ambito sufficiente. Poiché non è possibile modificare i nodi esistenti, devi ricrearli con l'ambito corretto.

   Ti consigliamo di creare il pool di nodi con l'ambito gke-default. Questo ambito fornisce l'accesso ai seguenti ambiti:

   • https://www.googleapis.com/auth/devstorage.read_only
   • https://www.googleapis.com/auth/logging.write
   • https://www.googleapis.com/auth/monitoring
   • https://www.googleapis.com/auth/service.management.readonly
   • https://www.googleapis.com/auth/servicecontrol
   • https://www.googleapis.com/auth/trace.append

   Se l'ambito gke-default non è adatto, concedi al pool di nodi l'ambito devstorage.read_only, che consente l'accesso ai dati di sola lettura.

   gke-default

   Crea un pool di nodi con l'ambito gke-default:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --scopes="gke-default"
   

   Sostituisci quanto segue:

   • NODE_POOL_NAME: il nome del nuovo pool di nodi.
   • CLUSTER_NAME: il nome del cluster esistente.
   • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

   devstorage.read_only

   Crea un pool di nodi con l'ambito devstorage.read_only:

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --scopes="https://www.googleapis.com/auth/devstorage.read_only"
   

   Sostituisci quanto segue:

   • NODE_POOL_NAME: il nome del nuovo pool di nodi.
   • CLUSTER_NAME: il nome del cluster esistente.
   • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

Verifica le impostazioni dei Controlli di servizio VPC per accedere ad Artifact Registry

Se utilizzi Controlli di servizio VPC, assicurati che i perimetri di servizio consentano l'accesso ad Artifact Registry. Per scoprire di più, consulta Proteggere i repository in un perimetro di servizio nella documentazione di Artifact Registry.

Esaminare la connettività di rete

Durante il pull di un'immagine, la connettività di rete può impedire il completamento del processo.

Per verificare se i problemi di connettività di rete causano un problema di pull delle immagini, esegui le indagini descritte nelle sezioni seguenti:

1. Esamina la risoluzione DNS.
2. Esamina la configurazione del firewall.
3. Esamina la connettività a internet degli endpoint del registro esterno.
4. Verifica se la connessione alle API di Google è in timeout.

Esaminare la risoluzione DNS

Se viene visualizzato un errore di pull dell'immagine server misbehaving, la risoluzione DNS potrebbe essere la causa del mancato pull dell'immagine.

Per esaminare i problemi relativi alla risoluzione DNS, prova le seguenti soluzioni:

1. Risolvi i problemi del server di metadati. Il server di metadati del nodo risolve tutte le query DNS. Eventuali problemi che coinvolgono questo server possono interrompere la risoluzione dei nomi, impedendo la connessione al repository e causando il mancato pull dell'immagine.
2. Se utilizzi Cloud DNS per la risoluzione DNS, assicurati che le zone private gestite, le zone di forwarding, le zone di peering e i criteri di risposta di Cloud DNS siano configurati correttamente. Errori di configurazione in queste aree possono interrompere la risoluzione DNS. Per scoprire di più su Cloud DNS, consulta Utilizzo di Cloud DNS per GKE. Per suggerimenti su come risolvere i problemi di Cloud DNS in GKE, consulta Risolvere i problemi di Cloud DNS in GKE.
3. Se utilizzi kube-dns per la risoluzione DNS, assicurati che funzioni correttamente. Per suggerimenti sulla risoluzione dei problemi di kube-dns, consulta Risolvere i problemi di kube-dns in GKE.
4. Se i nodi del cluster non hanno indirizzi IP esterni (il che è comune se utilizzi l'isolamento di rete), abilita l'accesso privato Google nella subnet utilizzata dal cluster e assicurati di soddisfare i requisiti di rete. Se utilizzi Cloud NAT, Trusted Cloud by S3NS l'accesso privato Google viene abilitato automaticamente.

Esamina la configurazione del firewall

Quando un problema con il firewall causa l'errore di pull dell'immagine, potresti visualizzare il seguente messaggio di errore:

Failed to start Download and install k8s binaries and configurations

Diagnosticare i problemi relativi al firewall

Se utilizzi un cluster Standard e vuoi verificare se un problema con il firewall sta causando problemi con il pull delle immagini, segui questi passaggi:

1. Utilizza SSH per connetterti al nodo che presenta problemi:

   gcloud compute ssh NODE_NAME --zone=ZONE_NAME
   

   Sostituisci quanto segue:

   • NODE_NAME: il nome del nodo.
   • ZONE_NAME: la zona Compute Engine in cui è stato creato il nodo.

2. Invia i log più recenti per i servizi kube-node-installation.service e kube-node-configuration.service a file di testo denominati kube-node-installation_status.txt e kube-node-configuration_status.txt:

   systemctl status kube-node-installation.service > kube-node-installation_status.txt
   systemctl status kube-node-configuration.service > kube-node-configuration_status.txt
   

   Se questi log non includono informazioni relative al momento in cui il pull dell'immagine non è riuscito, genera una copia completa dei log:

   sudo journalctl -u kube-node-installation.service > kube-node-installation_logs.txt
   sudo journalctl -u kube-node-configuration.service > kube-node-configuration_logs.txt
   

3. Esamina i contenuti dei file kube-node-installation_status.txt e kube-node-configuration_status.txt. Se nell'output viene visualizzato i/o timeout, il problema riguarda probabilmente il firewall.

Risolvere i problemi relativi alla configurazione del firewall

Per risolvere i problemi relativi al firewall, prova le seguenti soluzioni:

1. Identifica e risolvi eventuali regole firewall che bloccano il traffico di rete. Ad esempio, potresti avere una regola che blocca il traffico verso il registro che memorizza l'immagine.

   1. Accedi ai log di flusso VPC:

      1. Nella console Trusted Cloud , vai alla pagina Esplora log.

         Vai a Esplora log

      2. Nel riquadro della query, inserisci la seguente query:

         resource.type="gce_subnetwork"
         logName="projects/PROJECT_ID/logs/[compute.googleapis.com%2Fvpc_flows](http://compute.googleapis.com%2Fvpc_flows)"
         resource.labels.subnetwork_name="SUBNET_NAME",
         

         Sostituisci quanto segue:

         • PROJECT_ID: l'ID del tuo Trusted Cloud progetto.
         • SUBNET_NAME: il nome della tua subnet.

         Per saperne di più, consulta la sezione Accedere ai log di flusso utilizzando le query nella documentazione di VPC.

   2. Se trovi regole firewall che bloccano il traffico richiesto, aggiornale.

2. Se i nodi del cluster non hanno indirizzi IP esterni (il che è comune se utilizzi l'isolamento di rete), abilita l'accesso privato Google nella subnet utilizzata dal cluster e assicurati di soddisfare i requisiti di rete. Se utilizzi Cloud NAT, Trusted Cloud by S3NS l'accesso privato Google viene abilitato automaticamente.

Esamina la connettività a internet degli endpoint del registro esterno

Se la configurazione di rete indirizza il traffico tramite un endpoint del registro esterno, questo endpoint potrebbe non avere connettività a internet. Quando l'endpoint non ha accesso, il pull dell'immagine potrebbe non riuscire e viene visualizzato un errore di pull dell'immagine i/o timeout.

Per controllare la connettività di rete dall'endpoint del registro esterno al registro, utilizza ping o traceroute:

ping REGISTRY_ENDPOINT

Oppure

traceroute REGISTRY_ENDPOINT

Sostituisci REGISTRY_ENDPOINT con l'endpoint del registro. Questo valore può essere un nome host o un indirizzo IP.

Se riscontri un errore di connettività, controlla le route VPC:

1. Nella console Trusted Cloud , vai a Route.

   Vai a Route

2. Esamina la colonna Priorità e assicurati che la route con la priorità più alta sia diretta a un'origine che ha accesso al registro. Le route con valori più bassi hanno la precedenza.

Verifica se la connessione alle API di Google va in timeout

Se utilizzi l'isolamento di rete, potresti riscontrare un errore in cui la connessione alle API e ai servizi Google scade, causando un errore di pull dell'immagine i/o timeout.

Questo errore si verifica perché i nodi non sono riusciti a raggiungere una delle seguenti API quando hanno tentato di estrarre immagini dal registro:

• containerregistry.googleapis.com
• artifactregistry.googleapis.com

Per assicurarti di poterti connettere alle API richieste, prova le seguenti soluzioni:

1. Attiva l'accesso privato Google. I nodi senza indirizzi IP esterni hanno bisogno dell'accesso privato Google per raggiungere gli indirizzi IP esterni delle API e dei servizi Google.
2. Utilizza un dominio supportato.

3. Esamina i criteri firewall:

   1. Nella console Trusted Cloud , vai a Policy firewall.

      Vai a Criteri firewall

   2. Verifica di avere regole che bloccano il traffico TCP in uscita sulla porta 443 a 199.36.153.4/30, 199.36.153.8/30 o a qualsiasi intervallo di indirizzi IP utilizzato dal dominio scelto per le API e i servizi Google. Gli intervalli di indirizzi IP 199.36.153.4/30 e 199.36.153.8/30 vengono utilizzati rispettivamente per l'accesso privato Google e l'accesso Google limitato. Il traffico TCP sulla porta 443 verso questi intervalli serve per accedere alle API e ai servizi Google.

      Se trovi una di queste regole, crea una regola firewall per il traffico in uscita per consentire questo traffico.

4. Se utilizzi Artifact Registry, assicurati che il tuo ambiente soddisfi i requisiti per l'utilizzo di Artifact Registry con l'isolamento di rete.

5. Verifica che gli indirizzi IP virtuali (VIP) (199.36.153.4/30 o 199.36.153.8/30) abbiano route VPC configurate:

   1. Nella console Trusted Cloud , vai a Reti VPC.

      Vai a Reti VPC

   2. Nella colonna Nome, fai clic su default.

   3. Nella pagina dei dettagli della rete VPC, fai clic sulla scheda Route.

   4. Esamina la tabella delle rotte.

      Se la tua rete VPC contiene una route predefinita (destinazione 0.0.0.0/0 o ::0/0) e l'hop successivo per questa route è il gateway internet predefinito (Rete predefinita), utilizza questa route per consentire ai VIP di accedere alle API e ai servizi Google.

      Se hai sostituito una route predefinita con una route personalizzata il cui hop successivo non è il gateway internet predefinito, soddisfa i requisiti di routing per le API e i servizi Google utilizzando il routing personalizzato.

Indaga sul motivo per cui kubelet non riesce a trovare l'immagine

Quando kubelet non riesce a trovare l'immagine, potresti visualizzare un errore image not found e riscontrare errori di pull dell'immagine.

Per aiutare kubelet a trovare l'immagine, prova le seguenti soluzioni:

1. Controlla il manifest del tuo pod e assicurati che il nome dell'immagine e il tag dell'immagine siano scritti correttamente. Eventuali errori di ortografia o formattazione causano il mancato pull dell'immagine.
2. Verifica che l'immagine esista ancora nel registro in cui l'hai archiviata. Se l'immagine ha un percorso del registro completo, verifica che esista nel registro Docker che utilizzi. Se fornisci solo il nome dell'immagine, controlla il registro Docker Hub.
3. Se il cluster utilizza l'isolamento di rete, prova le seguenti soluzioni:
   1. Abilita l'accesso privato Google.
   2. Verifica che il perimetro di servizio sia configurato correttamente.

Indaga sul motivo per cui si verificano timeout del pull delle immagini o pull lenti delle immagini

Se utilizzi un'immagine molto grande per il tuo carico di lavoro GKE, il pull dell'immagine potrebbe scadere e causare un errore context cancelled. Sebbene le immagini non abbiano un limite di dimensioni definito, l'errore context cancelled indica spesso che la causa è la dimensione dell'immagine.

Potresti anche notare estrazioni di immagini che non hanno esito negativo, ma richiedono molto più tempo del solito. Se vuoi avere una base di riferimento dei tempi di pull delle immagini regolari, controlla la voce di log Successfully pulled image. Ad esempio, il seguente messaggio di log mostra che il pull dell'immagine ha richiesto 30,313387996 secondi:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

I timeout e i pull lenti delle immagini condividono molte delle stesse cause. Per risolvere questi problemi, prova le seguenti soluzioni:

1. Controlla se si sono verificate interruzioni del servizio. Se hai notato questo problema solo in un determinato periodo di tempo, verifica se si sono verificate Trusted Cloud by S3NS interruzioni.
2. Controlla le prestazioni del disco. L'I/O del disco lento può aumentare i tempi di pull delle immagini. Valuta la possibilità di eseguire l'upgrade a dischi permanenti con SSD (pd-ssd) o di utilizzare dischi più grandi per migliorare le prestazioni. Per ulteriori suggerimenti, vedi Risoluzione dei problemi relativi alle prestazioni del disco.
3. Riduci le dimensioni dell'immagine. Ad esempio, potresti essere in grado di spostare alcuni dati dalle immagini container ai volumi permanenti.
4. Sfrutta la memorizzazione nella cache delle immagini per ridurre i tempi di avvio dei pod. GKE memorizza nella cache le immagini sui nodi. Durante il pull di un'immagine, il runtime del container scarica solo i livelli non ancora presenti nella cache. Per massimizzare l'efficacia di questo meccanismo di memorizzazione nella cache e ridurre al minimo i tempi di pull delle immagini, struttura il Dockerfile in modo da inserire le parti dell'immagine che cambiano di frequente (come il codice dell'applicazione) verso la fine del file e utilizza immagini di base più piccole.
5. Abilita flusso immagine. Questa funzionalità può accelerare l'avvio del pod e il download delle immagini. Per saperne di più, consulta Utilizzo del flusso di immagini per eseguire il pull delle immagini container.
6. Assicurati che il account di servizio predefinito disponga delle autorizzazioni necessarie. La modifica dei ruoli assegnati alaccount di serviziot predefinito può interrompere i carichi di lavoro, incluso il pull delle immagini. Per ulteriori suggerimenti, consulta Identificare i cluster con service account del nodo a cui mancano autorizzazioni critiche.
7. Esamina le configurazioni proxy. Se esiste un proxy tra il cluster GKE e un repository non gestito da Google, potrebbe verificarsi una latenza.
8. Controlla il software di terze parti. Alcuni software di terze parti possono interferire con il recupero delle immagini. Verifica se eventuali strumenti installati di recente potrebbero causare conflitti.

Verifica che il manifest dell'immagine utilizzi l'architettura corretta

Se l'immagine che stai tentando di estrarre è stata creata per un'architettura del computer diversa da quella utilizzata dai tuoi pool di nodi, l'estrazione dell'immagine non va a buon fine.

Per verificare se il manifest dell'immagine utilizza l'architettura corretta, segui questi passaggi:

1. Per verificare quale architettura utilizza la tua immagine, visualizza il manifest dell'immagine. Ad esempio, per visualizzare un'immagine Docker, esegui questo comando:

   docker manifest inspect --verbose IMAGE_NAME
   

   Sostituisci IMAGE_NAME con il nome dell'immagine che vuoi visualizzare.

   L'output è simile al seguente:

   ...
   "Platform": {
             "architecture": "amd64",
             "os": "linux"
     }
   ...
   

   In questo esempio, l'architettura supportata è amd64.

2. Controlla il tipo di macchina utilizzato dai pool di nodi:

   gcloud container node-pools list --cluster CLUSTER_NAME --location CONTROL_PLANE_LOCATION
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del cluster su cui viene eseguito il pod con errori di pull dell'immagine.
   • CONTROL_PLANE_LOCATION: la posizione di Compute Engine del control plane del tuo cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

   L'output è simile al seguente:

   NAME: example-node-pool
   MACHINE_TYPE: e2-standard-2
   DISK_SIZE_GB: 100
   NODE_VERSION: 1.30.8-gke.1162000
   

   In questo esempio, il tipo di macchina è e2-standard-2.

3. Confronta i valori nei campi architecture e MACHINE_TYPE e assicurati che entrambi i valori siano compatibili. Ad esempio, se l'immagine ha un'architettura amd64, sarebbe compatibile con un pool di nodi che utilizza e2-standard-2 come tipo di macchina. Tuttavia, se il pool di nodi utilizzato t2a-standard-1 (un tipo di macchina basato su Arm), questo tipo di macchina causerebbe un errore.

4. Se l'architettura dell'immagine non è compatibile con il tipo di macchina del pool di nodi, ricompila l'immagine in modo che abbia come target l'architettura richiesta.

Verifica la compatibilità della versione dello schema delle immagini

L'utilizzo di containerd 2.0 con un'immagine Docker schema v1 causa l'errore dei pull delle immagini perché containerd 2.0 ha rimosso il supporto per il pull delle immagini Docker schema 1 in GKE 1.33. Quando questo problema è la causa dell'errore di pull dell'immagine, potresti visualizzare il seguente messaggio di errore:

Failed to get converter for "IMAGE_ADDRESS": Pulling Schema 1 images have been deprecated and disabled by default since containerd v2.0. As a workaround you may set an environment variable `CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE=1`, but this will be completely removed in containerd v2.1.

Per risolvere il problema, identifica ed esegui la migrazione di queste immagini seguendo le istruzioni riportate in Eseguire la migrazione dalle immagini Docker Schema 1.

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.