Risolvere i problemi relativi ai tiri delle immagini

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina ti aiuta a risolvere i problemi relativi al processo di estrazione 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 recuperi di immagini standard.

Questa pagina è rivolta agli sviluppatori di applicazioni che vogliono assicurarsi che le loro app siano di cui è stato eseguito il deployment e agli amministratori e agli operatori della piattaforma che vogliono comprendere la causa principale degli errori di estrazione delle immagini e verificare la configurazione della piattaforma. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

La procedura di estrazione delle immagini è il modo in cui Kubernetes e quindi GKE recuperano le immagini dei container da un registry. Quando un recupero di immagini non va a buon fine, potresti notare rallentamenti nell'app o che l'app non funziona affatto.

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

• Impostazioni di autenticazione: il cluster non dispone delle autorizzazioni necessarie per accedere al registry delle immagini del contenitore.
• Connettività di rete: il cluster non riesce a connettersi al registry 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 registry: il nome o il tag dell'immagine specificato è scorretto, l'immagine è stata eliminata o il registry non è disponibile.
• Limitazioni delle prestazioni: dimensioni delle immagini elevate, I/O del disco lento o congestione della rete possono causare pull lenti o timeout.
• Architettura dell'immagine incompatibile: l'immagine è stata creata per un'architettura CPU diversa da quella del tuo node pool GKE.
• Versioni dello schema incompatibili: potresti utilizzare containerd 2.0 o versioni successive con uno schema Docker 1.0, che non è supportato.

Se hai già visualizzato un messaggio relativo a un evento specifico, cercalo in questa pagina e segui i passaggi per la risoluzione dei problemi elencati. Se non hai visualizzato un messaggio, consulta le sezioni seguenti 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 conoscere 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 contenitore in base all'immagine. Prima di estrarre l'immagine, kubelet controlla il tempo di esecuzione del container per verificare se l'immagine è presente. Kubelet controlla anche il criterio di pull delle immagini del pod. Se l'immagine non è nella cache del runtime del contenitore o se il criterio di estrazione dell'immagine lo richiede, kubelet indica al runtime del contenitore (containerd) di estrarre l'immagine specificata dal registry. Un pull dell'immagine non riuscito impedisce l'avvio del container nel pod.

Dopo un estrazione dell'immagine riuscita, il runtime del container estrae l'immagine per creare un file system di base di sola lettura per il container. Il runtime del contenitore archivia questa immagine, che rimane presente finché i container in esecuzione la fanno riferimento. Se nessun contenitore in esecuzione fa riferimento a un'immagine, quest'ultima diventa idonea per la garbage collection e alla fine viene rimossa da kubelet.

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 Google Cloud servizi e offre un controllo dell'accesso granulare. Per scoprire di più, consulta Utilizzare le immagini container nella documentazione di Artifact Registry.

• Registry self-hosted: un registry self-hosted offre un maggiore controllo, ma richiede anche di gestirlo. Valuta questa opzione se hai esigenze specifiche di conformità o sicurezza che Artifact Registry non può soddisfare.

Diagnostica l'errore di pull dell'immagine

Per diagnosticare i problemi di estrazione delle immagini, esegui le indagini dettagliate nelle seguenti sezioni:

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

Visualizzare lo stato e gli eventi del pod

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

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

ImagePullBackOff e ErrImagePull sono i più comuni di questi stati.

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

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

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 non recuperabile durante il processo di recupero delle immagini.
• ImageInspectError: il runtime del container ha riscontrato un problema durante il tentativo di ispezionare l'immagine del container.
• InvalidImageName: il nome dell'immagine del contenitore specificato nella definizione del pod non è valido.
• RegistryUnavailable: il registry non è accessibile. Di solito si tratta di un problema di connettività di rete.
• SignatureValidationFailed: impossibile verificare la firma digitale dell'immagine del contenitore.

Utilizzare i messaggi di evento per trovare la causa dell'errore di estrazione delle immagini

Nella tabella seguente sono elencati i messaggi relativi agli errori di estrazione delle immagini e i passaggi per la risoluzione dei problemi da seguire se ne trovi uno.

I messaggi relativi agli errori di estrazione delle immagini hanno spesso 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.

Per alcune cause di errori di estrazione delle immagini non è disponibile un messaggio di evento correlato. Se non visualizzi nessuno dei messaggi di evento nella tabella seguente, ma continui a riscontrare problemi di estrazione delle immagini, ti consigliamo di continuare a leggere il resto della pagina.

Visualizzare i log di Esplora log

Per esaminare gli eventi di estrazione di immagini storici o correlare gli errori di estrazione di immagini con altre attività dei componenti, visualizza i log con Esplora log:

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

   Vai a Esplora log

2. Nel riquadro delle 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 estrazione 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 abbia le impostazioni di autenticazione appropriate per estrarre le immagini dal repository.

Per verificare se hai problemi di autenticazione che causano un problema di estrazione delle immagini, esegui le indagini dettagliate nelle sezioni seguenti:

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

Verificare l'accesso all'immagine

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

Il metodo per verificare e applicare i ruoli necessari per concedere l'accesso richiesto dipende dal 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 secret per il recupero delle immagini, assicurati di aver creato un secret che contenga le credenziali di autenticazione per il recupero delle immagini e che tutti i deployment specifichino il secret che hai definito. Per ulteriori informazioni, consulta Specificare imagePullSecrets in un pod nella documentazione di Kubernetes.

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

Se archivi l'immagine del contenitore in un repository Artifact Registry privato, il tuo nodo potrebbe non avere l'ambito di accesso corretto. In questi casi, potresti riscontrare un errore di estrazione delle immagini 401 Unauthorized.

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

1. Identifica il nodo su cui è in esecuzione 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 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 recupero dell'immagine non va a buon fine.

3. Ricrea il pool di nodi a cui appartiene il nodo con un ambito sufficiente. Poiché non puoi 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 solo per leggere i dati.

   gke-default

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

   gcloud container node-pools create NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --zone=COMPUTE_ZONE \
       --scopes="gke-default"
   

   Sostituisci quanto segue:

   • NODE_POOL_NAME: il nome del nuovo pool di nodi.
   • CLUSTER_NAME: il nome del cluster esistente.
   • COMPUTE_ZONE: la zona Compute Engine a cui deve appartenere il nuovo pool di nodi.

   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 \
       --zone=COMPUTE_ZONE \
       --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.
   • COMPUTE_ZONE: la zona Compute Engine a cui deve appartenere il nuovo pool di nodi.

Verifica le impostazioni di 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 stanno causando un problema di estrazione delle immagini, esegui le indagini dettagliate nelle sezioni seguenti:

1. Esamina la risoluzione DNS.
2. Esamina la configurazione del firewall.
3. Esamina la connettività a internet degli endpoint del registry esterno.
4. Verifica se si verifica un timeout della connessione alle API di Google.

Esaminare la risoluzione DNS

Se viene visualizzato un errore di estrazione delle immagini server misbehaving, la risoluzione DNS potrebbe essere la causa dell'errore.

Per esaminare i problemi di 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 relativi a questo server possono interrompere la risoluzione dei nomi, impedendo la connessione al repository e causando il fallimento del recupero delle immagini.
2. Se utilizzi Cloud DNS per la risoluzione DNS, assicurati che le zone private, le zone di inoltro, le zone di peering e i criteri di risposta gestiti da Cloud DNS siano configurati correttamente. Le configurazioni errate in queste aree possono interrompere la risoluzione DNS. Per scoprire di più su Cloud DNS, consulta Utilizzare Cloud DNS per GKE. Per consigli 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 consigli 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 (cosa comune se utilizzi l'isolamento della rete), attiva Accesso privato Google sulla sottorete utilizzata dal cluster e assicurati di soddisfare i requisiti di rete. Se utilizzi Cloud NAT, Google Cloud l'accesso privato Google viene abilitato automaticamente.

Esamina la configurazione del firewall

Quando un problema con il firewall causa il fallimento del recupero delle immagini, potresti visualizzare il seguente messaggio di errore:

Failed to start Download and install k8s binaries and configurations

Diagnostica dei problemi relativi al firewall

Se utilizzi un cluster standard e vuoi verificare se un problema con il firewall sta causando problemi di estrazione 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 mancato recupero dell'immagine, 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.txte kube-node-configuration_status.txt. Se nell'output viene visualizzato i/o timeout, è probabile che il problema riguardi il firewall.

Risolvere i problemi di 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 registry che immagazzina l'immagine.

   1. Accedi ai log di flusso VPC:

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

         Vai a Esplora log

      2. Nel riquadro delle 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 progetto Google Cloud.
         • SUBNET_NAME: il nome della subnet.

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

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

2. Se i nodi del cluster non hanno indirizzi IP esterni (cosa comune se utilizzi l'isolamento della rete), attiva Accesso privato Google sulla sottorete utilizzata dal cluster e assicurati di soddisfare i requisiti di rete. Se utilizzi Cloud NAT, Google Cloud l'accesso privato Google viene abilitato automaticamente.

Esaminare la connettività a internet degli endpoint del registry esterno

Se la configurazione di rete indirizza il traffico tramite un endpoint del registry esterno, l'endpoint potrebbe non avere connettività a internet. Se l'endpoint manca di accesso, il pull delle immagini potrebbe non riuscire e viene visualizzato un i/o timeout errore di pull delle immagini.

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

ping REGISTRY_ENDPOINT

Oppure

traceroute REGISTRY_ENDPOINT

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

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

1. Nella console Google Cloud, vai a Route.

   Vai a Route

2. Esamina la colonna Priorità e assicurati che il percorso con la priorità più elevata vada a una sorgente che abbia accesso al registry. Le route con valori più bassi hanno la precedenza.

Verificare se si verifica un timeout della connessione alle API di Google

Se utilizzi l'isolamento della rete, potresti riscontrare un errore di timeout della connessione alle API e ai servizi Google, che causa un errore di estrazione delle immagini i/o timeout.

Questo errore si verifica perché i tuoi nodi non sono riusciti a raggiungere una delle seguenti API quando hanno provato a estrarre le immagini dal registry:

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

Per assicurarti di poter connetterti alle API richieste, prova le seguenti soluzioni:

1. Attiva Accesso privato Google. I nodi senza indirizzi IP esterni richiedono l'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 Google Cloud, vai a Policy firewall.

      Vai a Policy del firewall

   2. Verifica se sono presenti regole che bloccano il traffico TCP in uscita sulla porta 443 a 199.36.153.4/30, 199.36.153.8/30 o su 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 per questi intervalli è destinato all'accesso alle API e ai servizi Google.

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

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

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

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

      Vai a Reti VPC

   2. Nella colonna Nome, fai clic su predefinito.

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

   4. Esamina la tabella Routes.

      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 (Predefinito della rete), 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.

Scopri perché kubelet non riesce a trovare l'immagine

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

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 del tag immagine siano scritti correttamente. Eventuali errori di ortografia o formattazione fanno sì che il pull delle immagini non vada a buon fine.
2. Verifica che l'immagine esista ancora nel registry in cui l'hai archiviata. Se l'immagine ha un percorso del registry completo, verifica che esista nel registro Docker che utilizzi. Se fornisci solo il nome dell'immagine, controlla il registro Docker Hub.
3. Se il tuo cluster utilizza l'isolamento di rete, prova le seguenti soluzioni:
   1. Attiva l'accesso privato Google.
   2. Verifica che il perimetro del servizio sia configurato correttamente.

Scopri perché si verificano timeout o rilanci lenti per il pull delle immagini

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

Potresti anche notare che i recuperi delle immagini non falliscono, ma richiedono molto più tempo del solito. Se vuoi avere una linea di base dei tempi di estrazione delle immagini normali, esamina la voce di log Successfully pulled image. Ad esempio, il seguente messaggio di log mostra che il recupero dell'immagine ha richiesto 30,313387996 secondi:

Successfully pulled image "IMAGE_ADDRESS" in 30.313387996s.

I timeout e i recuperi delle immagini lenti 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 durante un determinato periodo di tempo, controlla se si sono verificate Google Cloud interruzioni.
2. Controlla le prestazioni del disco. Un'I/O lenta del disco può aumentare i tempi di estrazione delle immagini. Valuta la possibilità di eseguire l'upgrade a dischi permanenti con SSD (pd-ssd) o di utilizzare dischi di dimensioni maggiori per migliorare le prestazioni. Per ulteriori consigli, consulta la sezione Risolvere i problemi relativi al rendimento del disco.
3. Riduci le dimensioni delle immagini. Ad esempio, potresti riuscire a spostare alcuni dati dalle immagini dei contenitori ai volumi permanenti.
4. Sfrutta la memorizzazione nella cache delle immagini per tempi di avvio rapidi 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 già presenti nella cache. Per massimizzare l'efficacia di questo meccanismo di memorizzazione nella cache e ridurre al minimo i tempi di recupero delle immagini, struttura il Dockerfile in modo da posizionare 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. Attiva il flusso di immagini. Questa funzionalità può velocizzare l'avvio del pod e i download delle immagini. Per scoprire di più, consulta Utilizzare il flusso di immagini per eseguire il pull delle immagini container.
6. Assicurati che l'account di servizio predefinito disponga delle autorizzazioni necessarie. La modifica dei ruoli assegnati all'account di servizio predefinito può interrompere i carichi di lavoro, inclusi i tiri delle immagini. Per ulteriori consigli, consulta Identificare i cluster con service account dei nodi mancanti di autorizzazioni critiche.
7. Esamina le configurazioni proxy. Se esiste un proxy tra il tuo cluster GKE e un repository gestito non Google, potrebbe essere introdotta della latenza.
8. Controlla il software di terze parti. Alcuni software di terze parti possono interferire con i recuperi delle immagini. Verifica se gli 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 di computer diversa da quella utilizzata dai tuoi pool di nodi, il pull 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 l'immagine, visualizza il manifest corrispondente. 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 LOCATION
   

   Sostituisci quanto segue:

   • CLUSTER_NAME: il nome del cluster su cui viene eseguito il pod con errori di estrazione dell'immagine.
   • LOCATION: la zona o la regione Compute Engine in cui è stato creato il nodo. Ad esempio, us-central1-a o us-central1.

   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 siano compatibili. Ad esempio, se l'immagine ha un'architettura amd64, sarà compatibile con un pool di nodi che utilizza e2-standard-2 come tipo di macchina. Tuttavia, se il node pool utilizzasse 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, ricostruisci 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 schema Docker 1 causa l'errore del recupero delle immagini perché containerd 2.0 ha rimosso il supporto per il recupero delle immagini Docker Schema 1 in GKE 1.33. Quando questo problema è la causa del fallimento del recupero delle immagini, 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 hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.