I cluster Kubernetes possono riscontrare diversi problemi durante il tentativo di estrarre le immagini del contenitore. Quando si verifica un errore, i tuoi Pod inseriranno un ImagePullBackOff stato. Ecco come eseguire il debug di questo messaggio comune ma criptico in modo da poter ottenere i tuoi servizi online.
Come funzionano i pull di immagini
Kubernetes deve recuperare un'immagine quando crei una nuova distribuzione o ne aggiorni una esistente con un riferimento di tag diverso. La responsabilità per il pull delle immagini è del processo Kubelet su ogni nodo di lavoro. Ogni immagine a cui fa riferimento il manifest di un Pod deve essere accessibile a tutti i nodi del cluster in modo che ognuno di essi possa soddisfare una richiesta di pianificazione del contenitore.
Il download potrebbe non riuscire se il percorso dell'immagine non è corretto, se sei autenticato in modo errato o se la rete si interrompe. Quando ciò accade, Kubernetes si "ritira" e pianifica un altro tentativo di download. Il ritardo prima del pull successivo aumenta esponenzialmente ogni volta che un tentativo fallisce, fino a un limite di cinque minuti.
Se il tuo Pod mostra il ImagePullBackOff stato, Kubernetes ha avuto più errori di pull di immagini successivi e ora sta aspettando prima di riprovare. Il contenitore non potrà essere avviato finché l'immagine non sarà disponibile.
Puoi lasciare il Pod in questo stato se sai che il problema è dovuto alle condizioni della rete o a un altro errore transitorio. Kubernetes alla fine completerà un altro tentativo e acquisirà correttamente l'immagine. In caso contrario, ecco come avviare il debug in modo da poter visualizzare il Pod.
Controlla le basi
Innanzitutto, vale la pena controllare le basi. Il tuo file manifest fa riferimento a un'immagine valida che esiste effettivamente? Controlla il percorso del registro e il tag immagine per errori di battitura semplici.
Puoi controllare lo stato interno di Kubernetes con il describe pod comando in Kubectl. Questo ti dà più informazioni rispetto a get pod e la dashboard di Kubernetes forniscono.
kubectl describe pod my-pod --namespace my-namespace
Le modifiche al ciclo di vita del Pod vengono visualizzate sotto l'intestazione "Eventi". Il primo evento sarà Scheduled; dovrebbe essere seguito da un Pulling evento per il primo tentativo di pull. Dopo questo, vedrai un Failed o BackOff evento se il pull non è riuscito. Questi verranno ripetuti più avanti nell'elenco se Kubernetes è ancora in un ciclo di arresto e riprova.
Lettura del Message associato a questi eventi spesso fornisce la causa principale del problema. Un manifest for image:tag not found messaggio significa che l'immagine è valida ma hai specificato un tag non valido. Se vedi does not exist or no pull access , controlla che il registro e i percorsi dell'immagine siano corretti. Quando sei sicuro che abbiano ragione, il problema sarà correlato a un'autenticazione errata.
Gestione degli accessi al registro
Devi essere loggato prima di estrarre immagini private. In Kubernetes, è un meccanismo in due passaggi:crea un segreto contenente le credenziali, quindi fai riferimento a quel segreto nelle definizioni del pod.
Il campo Pod si chiama imagePullSecrets . Deve indicare un segreto Kubernetes che fornisce un token di accesso per il registro. Questo segreto dovrebbe memorizzare un valore JSON compatibile con Docker.
apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
name: image-pull-secret
data:
.dockerconfigjson: {{ "{"auths": {"registry.example.com": {"username": "demo-user", "password": "my-password"}}}" | b64enc }}
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: registry.example.com/my-image:latest
imagePullSecrets:
- name: image-pull-secret
Questo manifest mostra come creare un segreto che ti acceda a registry.example.com come demo-user con la password my-password . Il Pod fa riferimento al segreto con il suo nome. I processi Kubelet sui nodi del tuo cluster includeranno il Docker config.json snippet quando estraggono le immagini dal registro.
Lo snippet deve essere codificato in Base64 per essere un valore segreto Kubernetes valido. Puoi utilizzare un valore precodificato o reindirizzare il testo normale tramite b64enc di YAML , come mostrato nel manifest sopra.
Il tipo di credenziali che utilizzi dipenderà dal tuo registro. In molti casi, password sarà effettivamente un token di accesso personale o una chiave API. Docker Hub richiede un token di accesso generato nelle impostazioni del tuo account se hai abilitato l'autenticazione a due fattori sul tuo account.
Limiti tariffari di registro
Se hai controllato l'URL del registro, il nome del tag immagine e le credenziali di accesso, potresti visualizzare ImagePullBackOff a causa dei limiti di tariffazione del registro. Docker Hub ora ti limita a 100 pull di container ogni sei ore. Questo aumenta a 200 pull ogni sei ore se fornisci le tue credenziali di accesso. Tale limite può essere raggiunto rapidamente in un cluster attivo con molti pod distribuiti di frequente.
Un errore di pull dovuto a un limite di velocità si manifesterà allo stesso modo di un problema di autenticazione. Dovrai attendere che trascorre abbastanza tempo per far scadere il limite. Kubernetes dovrebbe quindi estrarre correttamente l'immagine, facendo apparire i tuoi Pod.
Per una mitigazione a lungo termine, prendi in considerazione l'esecuzione del tuo registro o proxy in-cluster per memorizzare nella cache le tue immagini. Ciò può ridurre significativamente la frequenza con cui raggiungi i server Docker, aiutandoti a rimanere entro i limiti di velocità.
Riepilogo
I pod Kubernetes immettono un ImagePullBackOff stato quando un nodo non riesce a estrarre un'immagine. Kubelet riproverà periodicamente il pull in modo che gli errori transitori non richiedano alcun intervento manuale per essere affrontati.
Quando sei sicuro di un ImagePullBackOff non è solo un errore temporaneo, inizia assicurandoti che il percorso dell'immagine del Pod sia valido. Se si verifica, sospetta credenziali di accesso errate o un limite di tariffa esaurito. Usando kubectl describe esporrà la sequenza di eventi che hanno portato al fallimento.
Come opzione finale, puoi provare a estrarre l'immagine da un'altra macchina per assicurarti che il server di registro remoto sia effettivamente attivo. Se riesci a estrarre l'immagine ma il tuo cluster non può, potresti avere problemi di rete più generali che impediscono ai tuoi nodi di raggiungere il registro.