IBM Cloud Docs
Perché le immagini non riescono a eseguire il pull dal registro con ImagePullBackOff o errori di autorizzazione?

Perché le immagini non riescono a eseguire il pull dal registro con ImagePullBackOff o errori di autorizzazione?

Virtual Private Cloud Infrastruttura classica

Quando distribuisci un carico di lavoro che segue il pull di un'immagine da IBM Cloud Container Registry, si verifica un malfunzionamento dei tuoi pod con lo stato ImagePullBackOff.

kubectl get pods
NAME         READY     STATUS             RESTARTS   AGE
<pod_name>   0/1       ImagePullBackOff   0          2m

Quando descrivi il pod, vedi degli errori di autenticazione simili al seguente:

kubectl describe pod <pod_name>
Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... unauthorized: authentication required
Failed to pull image "<region>.icr.io/<namespace>/<image>:<tag>" ... 401 Unauthorized
Failed to pull image "registry.ng.bluemix.net/<namespace>/<image>:<tag>" ... unauthorized: authentication required
Failed to pull image "registry.ng.bluemix.net/<namespace>/<image>:<tag>" ... 401 Unauthorized
...
Failed to pull image "<image>:<tag>" ... Manifest for <image>:<tag> not found

Il tuo cluster utilizza una chiave API memorizzata in un segreto di pull dell'immagine per autorizzare il cluster a estrarre le immagini da IBM Cloud Container Registryoppure l'immagine con la tag specifica non esiste nel repository.

Per impostazione predefinita, i nuovi cluster hanno dei segreti di pull dell'immagine che utilizzano chiavi API per consentire al cluster di eseguire il pull di immagini da qualsiasi registro icr.io regionale per i contenitori distribuiti allo spazio dei nomi Kubernetes default.

  1. Verifica di utilizzare il nome e la tag corretti dell'immagine nel tuo file YAML di distribuzione.

    ibmcloud cr images
    
  2. Consulta il traffico di pull e la quota di archiviazione. Se viene raggiunto il limite, libera spazio di archiviazione utilizzato o chiedi al tuo amministratore del registro di aumentare la quota.

    ibmcloud cr quota
    
  3. Ottieni il file di configurazione di un pod in errore e cerca la sezione imagePullSecrets.

    kubectl get pod <pod_name> -o yaml
    

    Output di esempio

    ...
    imagePullSecrets:
    - name: all-icr-io
    ...
    
  4. Se non è elencato alcun segreto di pull dell'immagine, eseguine la configurazione nel tuo spazio dei nomi.

    1. Verifica che lo spazio dei nomi default disponga di segreti di pull dell'immagine icr-io per ogni registro regionale che vuoi utilizzare. Se nello spazio dei nomi non sono elencati segreti icr-io, utilizza il comando ibmcloud ks cluster pull-secret apply --cluster <cluster_name_or_ID> per creare i segreti di pull dell'immagine nello spazio dei nomi default.
      kubectl get secrets -n default | grep "icr-io"
      
    2. Copia il segreto di pull dell'immagine all-icr-io dallo spazio dei nomi KUbernetes default dove vuoi distribuire il tuo carico di lavoro.
    3. Aggiungi il segreto di pull dell'immagine all'account del servizio per questo spazio dei nomi Kubernetes in modo che tutti i pod nello spazio dei nomi possano utilizzare le credenziali del segreto di pull dell'immagine.
  5. Se i segreti di pull dell'immagine sono elencati nel pod, determina quale tipo di credenziali utilizzi per accedere a IBM Cloud Container Registry.

Risoluzione dei problemi relativi ai segreti di pull dell'immagine che utilizzano chiavi API

Se la tua configurazione dl pod ha un segreto di pull dell'immagine che utilizza una chiave API, controlla che le credenziali di chiave API siano configurate correttamente.

La seguente procedura presume che la chiave API memorizzi le credenziali di un ID servizio. Se configuri il tuo segreto di pull dell'immagine per utilizzare una chiave API di un singolo utente, devi verificare le credenziali e le autorizzazioni IBM Cloud IAM di tale utente.

  1. Trova l'ID servizio utilizzato dalla chiave API per il segreto di pull dell'immagine esaminando la descrizione (Description). L'ID servizio creato con il cluster è denominato cluster-<cluster_ID> e viene utilizzato nello spazio dei nomi default Kubernetes. Se hai creato un altro ID servizio come ad esempio per accedere a uno spazio dei nomi Kubernetes differente o per modificare le autorizzazioni IBM Cloud IAM, hai personalizzato la descrizione.

    ibmcloud iam service-ids
    

    Output di esempio

    UUID                Name               Created At              Last Updated            Description                                                                                                                                                                                         Locked
    ServiceId-aa11...   <service_ID_name>  2019-02-01T19:01+0000   2019-02-01T19:01+0000   ID for <cluster_name>                                                                                                                                         false
    ServiceId-bb22...   <service_ID_name>  2019-02-01T19:01+0000   2019-02-01T19:01+0000   Service ID for IBM Cloud Container Registry in Kubernetes cluster <cluster_name> namespace <namespace>                                                                                                                                         false
    
  2. Verifica che all'ID servizio sia assegnato almeno una politica di ruolo di accesso al servizio per IBM Cloud di Lettore di IBM Cloud Container Registry IAM. Se l'ID del servizio non ha il ruolo di accesso al servizio Lettore, modifica le politiche IAM. Se le politiche sono corrette, continua con il passo successivo per appurare se le credenziali sono valide.

    ibmcloud iam service-policies <service_ID_name>
    

    Output di esempio

    Policy ID:   a111a111-b22b-333c-d4dd-e555555555e5
    Roles:       Reader
    Resources:
                  Service Name       container-registry
                  Service Instance
                  Region
                  Resource Type      namespace
                  Resource           <registry_namespace>
    
  3. Controlla se le credenziali del segreto di pull dell'immagine sono valide.

    1. Ottieni la configurazione del segreto di pull dell'immagine. Se il pod non si trova nello spazio dei nomi default, includi l'opzione -n.

      kubectl get secret <image_pull_secret_name> -o yaml [-n <namespace>]
      
    2. Nell'output, copia il valore con codifica base64 del campo .dockerconfigjson.

      apiVersion: v1
      kind: Secret
      data:
        .dockerconfigjson: eyJyZWdp...==
      ...
      
    3. Decodifica la stringa base64. Ad esempio, su OS X puoi eseguire il seguente comando.

      echo -n "<base64_string>" | base64 --decode
      

      Output di esempio

      {"auths":{"<region>.icr.io":{"username":"iamapikey","password":"<password_string>","email":"<name@abc.com>","auth":"<auth_string>"}}}
      
    4. Confronta il nome dominio del registro regionale del segreto di pull dell'immagine con il nome dominio che hai specificato nell'immagine del contenitore. Per impostazione predefinita, i nuovi cluster hanno dei segreti di pull dell'immagine per ogni nome dominio del registro regionale per i contenitori che vengono eseguiti nello spazio dei nomi Kubernetes default. Tuttavia, se hai modificato le impostazioni predefinite o se stai utilizzando uno spazio dei nomi Kubernetes differente, potresti non avere un segreto di pull dell'immagine per il registro regionale. Copia un segreto di pull dell'immagine per il nome dominio del registro regionale.

    5. Esegui l'accesso al registro dalla tua macchina locale utilizzando username e password dal tuo segreto di pull dell'immagine. Se non riesci ad accedere, potresti dover correggere l'ID servizio.

      docker login -u iamapikey -p <password_string> <region>.icr.io
      
      1. Crea nuovamente l'ID servizio del cluster, le politiche IBM Cloud IAM, la chiave API e i segreti di pull dell'immagine per i contenitori che vengono eseguiti nello spazio dei nomi Kubernetes default.
        ibmcloud ks cluster pull-secret apply --cluster <cluster_name_or_ID>
        
      2. Re-create your deployment in the default Kubernetes namespace. Se continui a vedere un messaggio di errore di autorizzazione, ripeti i passi da 1 a 5 con i nuovi segreti di pull dell'immagine. Se ancora non riesci ad accedere, apri un caso di supporto IBM Cloud.
    6. Se l'accesso riesce, esegui il pull di un'immagine localmente. Se il comando non riesce con un errore access denied, l'account del registro si trova in un account IBM Cloud differente da quello in cui si trova il tuo cluster. Crea un segreto di pull dell'immagine per accedere alle immagini nell'altro account. Se puoi eseguire il pull di un'immagine alla tua macchina locale, la tua chiave API ha le autorizzazioni corrette, ma la configurazione API nel tuo cluster non è corretta.

      docker pull <region>icr.io/<namespace>/<image>:<tag>
      
    7. Verifica che al segreto di pull si faccia riferimento direttamente dalla distribuzione o dall'account di servizi utilizzato dalla distribuzione. Se ancora non riesci a risolvere il problema, contatta il supporto.