Gérer les images conteneurs dans Kubernetes

Dans Kubernetes, vous contrôlez quand et comment les images sont téléchargées via imagePullPolicy. Pour accéder à un registre privé, vous créez un Secret de type docker-registry et le référencez avec imagePullSecrets. Enfin, pour garantir que vos Pods utilisent toujours la même version d’image, préférez les digests aux tags mutables comme latest — un digest (ex: sha256:abc123...) identifie de façon unique et immuable une version précise de l’image.

Ce que vous allez apprendre

• Comprendre les trois valeurs d’ImagePullPolicy et leur comportement
• Distinguer tags et digests pour garantir la reproductibilité
• Configurer l’accès aux registres privés avec des Secrets
• Déboguer les erreurs ImagePullBackOff et ErrImagePull
• Appliquer des policies d’admission pour sécuriser vos déploiements

Prérequis : connaître les bases des Pods et avoir compris comment construire une image.

Les trois mécanismes clés

Avant d’entrer dans le détail, comprenons les trois mécanismes distincts qui interviennent :

Question	Mécanisme	Exemple
Quelle image exacte exécuter ?	Tag ou digest	nginx:1.25.3 ou nginx@sha256:...
Quand contacter le registre ?	imagePullPolicy	Always, IfNotPresent, Never
Comment s’authentifier ?	imagePullSecrets	Secret de type docker-registry

Glissez pour voir

Ces trois mécanismes sont indépendants : vous pouvez utiliser un digest avec n’importe quelle pull policy, et imagePullSecrets n’affecte que l’authentification, pas la décision de pull.

Anatomie d’une référence d’image

Avant de configurer le pull d’images, comprenons la structure d’une référence d’image complète :

[registre/][namespace/]nom[:tag][@digest]

Composant	Exemple	Description
Registre	registry.k8s.io, ghcr.io	Serveur hébergeant l’image. Par défaut : Docker Hub (docker.io)
Namespace	library, myorg	Organisation ou utilisateur. library pour les images officielles
Nom	nginx, myapp	Nom de l’image
Tag	:1.25.3, :latest	Version de l’image. Par défaut : latest
Digest	@sha256:abc123...	Hash unique et immuable de l’image

Glissez pour voir

Exemples concrets

• nginx → équivalent à docker.io/library/nginx:latest
• registry.k8s.io/pause:3.9 → image pause version 3.9 du registre Kubernetes
• myregistry.azurecr.io/myapp@sha256:1ff6c18f... → image avec digest (immuable)

ImagePullPolicy : contrôler le téléchargement

Le champ imagePullPolicy définit quand le kubelet tente de télécharger l’image depuis le registre.

Les trois valeurs possibles

Politique	Comportement	Cas d’usage typique
Always	Résout l’image auprès du registre à chaque démarrage du conteneur. Si l’image résolue existe déjà localement avec le même digest, les couches peuvent être réutilisées (pas de re-téléchargement complet).	Images avec tag latest, CI/CD
IfNotPresent	Utilise l’image locale si elle existe, sinon télécharge. Attention : en contexte supply chain strict, cette policy peut utiliser une image en cache sans vérifier si une version plus récente existe.	Production avec tags versionnés
Never	N’utilise que l’image locale, échoue si absente	Images pré-chargées, air-gapped

Glissez pour voir

Nuance importante sur Always

imagePullPolicy: Always ne signifie pas “retélécharger tous les octets à chaque fois”. Le kubelet interroge le registre pour résoudre le tag vers un digest, puis le runtime (containerd, CRI-O) peut réutiliser les couches déjà présentes si le digest correspond. C’est une vérification, pas forcément un téléchargement complet.

Comportement par défaut (important pour le CKAD)

Kubernetes applique une politique implicite selon le tag spécifié :

# imagePullPolicy NON spécifié
spec:
  containers:
  - name: app
    image: nginx:latest      # → Always (tag latest)
    image: nginx             # → Always (pas de tag = latest implicite)
    image: nginx:1.25.3      # → IfNotPresent (tag explicite)
    image: nginx@sha256:...  # → IfNotPresent (digest)

Piège CKAD classique

Si vous omettez imagePullPolicy avec un tag latest ou sans tag, Kubernetes applique Always. Cela peut causer des échecs si le registre est inaccessible, même si l’image est présente localement.

Piège de production : valeur figée à la création

La valeur implicite de imagePullPolicy est déterminée au moment de la création initiale de l’objet (Pod, Deployment…). Si vous modifiez ensuite l’image (par exemple de myapp:v1.0 vers myapp:latest), Kubernetes ne recalcule pas automatiquement la pull policy. Vous devez la spécifier explicitement si le nouveau tag nécessite un comportement différent.

Exemple complet avec imagePullPolicy

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
  namespace: production
spec:
  containers:
  - name: app
    image: myregistry.example.com/myapp:v2.1.0
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 8080

Garantir l’identité de l’image

Selon votre objectif, différents mécanismes s’appliquent :

Vérifier le registre

imagePullPolicy: Always force le kubelet à contacter le registre à chaque démarrage pour résoudre le tag. Utile avec des tags mutables comme latest.

spec:
  containers:
  - name: app
    image: myapp:v1.0
    imagePullPolicy: Always

Garantir l'immuabilité

Un digest garantit que vous exécutez exactement l’image voulue, sans ambiguïté. Le digest ne force pas un re-pull — si l’image est déjà en cache avec le bon digest, Kubernetes la réutilise.

spec:
  containers:
  - name: app
    image: myapp@sha256:1ff6c18fbef2045...

Forcer au niveau cluster

L’admission controller AlwaysPullImages force tous les Pods du cluster à vérifier le registre. Utile en environnement multi-tenant pour empêcher un Pod de réutiliser une image privée déjà tirée par un autre workload.

# Dans les options kube-apiserver
--enable-admission-plugins=AlwaysPullImages

Tags vs Digests : garantir l’immutabilité

Le problème des tags mutables

Un tag est un alias vers une version d’image. Le problème : il peut être déplacé vers une autre version.

Jour 1 : myapp:latest → sha256:abc123  (version 1.0)
Jour 2 : myapp:latest → sha256:def456  (version 1.1)

Conséquence : deux Pods déployés à des moments différents avec myapp:latest peuvent exécuter du code différent.

La solution : les digests

Un digest est un hash SHA256 du contenu de l’image. Il est immuable par définition.

# ❌ Risqué en production
image: myapp:latest

# ✅ Reproductible et vérifiable
image: myapp@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07

Récupérer le digest d’une image

Crane (recommandé)

Crane est l’outil le plus fiable pour manipuler les registres OCI :

# Installer crane
go install github.com/google/go-containerregistry/cmd/crane@latest

# Récupérer le digest
crane digest nginx:1.25.3
# sha256:6926dd802f40...

Skopeo

skopeo inspect docker://nginx:1.25.3 | jq -r '.Digest'
# sha256:6926dd802f40...

Docker (local)

Si l’image est déjà pullée localement :

docker inspect --format='{{index .RepoDigests 0}}' nginx:1.25.3
# nginx@sha256:6926dd802f40...

Note : Cette commande retourne le digest du manifest, qui est celui à utiliser dans vos références d’image Kubernetes.

Bonnes pratiques production

1. Interdisez latest en production via une policy d’admission (voir section suivante)
2. Utilisez des tags sémantiques : v1.2.3, pas stable ou production
3. Épinglez les digests pour les workloads critiques
4. Signez vos images avec Cosign et vérifiez les signatures à l’admission

Digest ≠ Sécurité

Un digest garantit l’immutabilité (vous exécutez toujours la même image), mais pas la confiance. Une image malveillante peut avoir un digest parfaitement stable.

Pour la provenance et la confiance, utilisez des signatures (Cosign) et des attestations (SLSA). Le digest assure la reproductibilité, la signature assure l’authenticité.

Accéder aux registres privés

Par défaut, Kubernetes ne peut télécharger que les images publiques. Pour accéder à un registre privé, vous devez fournir des credentials.

Créer un Secret docker-registry

Sécurité des imagePullSecrets

Un imagePullSecret est un Secret Kubernetes standard, donc :

• Il est stocké dans etcd (activez le chiffrement au repos)
• Il est lisible par quiconque a les droits RBAC get secrets sur le namespace
• Les credentials doivent être rotés régulièrement

imagePullSecrets facilite l’authentification, mais ne remplace ni le chiffrement des Secrets, ni un RBAC strict, ni une stratégie de rotation.

1. Créez le Secret avec vos credentials

   kubectl create secret docker-registry regcred \
     --docker-server=myregistry.example.com \
     --docker-username=myuser \
     --docker-password=mypassword \
     --docker-email=myuser@example.com \
     -n production

   Sécurité

   En production, préférez créer le Secret depuis un fichier ou via un gestionnaire de secrets (Vault, External Secrets Operator) plutôt que de passer le mot de passe en ligne de commande.

2. Vérifiez le Secret créé

   kubectl get secret regcred -n production -o yaml

   Le champ .dockerconfigjson contient vos credentials encodés en base64.

3. Référencez le Secret dans votre Pod

   apiVersion: v1
   kind: Pod
   metadata:
     name: private-app
     namespace: production
   spec:
     containers:
     - name: app
       image: myregistry.example.com/myapp:v1.0
     imagePullSecrets:
     - name: regcred

Automatiser avec un ServiceAccount

Pour éviter d’ajouter imagePullSecrets à chaque Pod, attachez le Secret au ServiceAccount par défaut :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: production
imagePullSecrets:
- name: regcred

Tous les Pods du namespace utilisant ce ServiceAccount hériteront automatiquement du Secret.

Structure d’un Secret docker-registry

apiVersion: v1
kind: Secret
metadata:
  name: regcred
  namespace: production
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: eyJhdXRocyI6eyJteXJlZ2lzdHJ5LmV4YW1wbGUuY29tIjp7InVzZXJuYW1lIjoibXl1c2VyIiwicGFzc3dvcmQiOiJteXBhc3N3b3JkIiwiZW1haWwiOiJteXVzZXJAZXhhbXBsZS5jb20iLCJhdXRoIjoiYlhsMWMyVnlPbTE1Y0dGemMzZHZjbVE9In19fQ==

Pour décoder et vérifier le contenu :

kubectl get secret regcred -o jsonpath='{.data.\.dockerconfigjson}' | base64 -d | jq

Déboguer les erreurs d’image

ImagePullBackOff et ErrImagePull

Ces erreurs indiquent que Kubernetes n’arrive pas à télécharger l’image.

kubectl describe pod my-pod

Mécanique de ImagePullBackOff

ImagePullBackOff signifie que Kubernetes continue d’essayer avec un délai croissant (backoff exponentiel), jusqu’à un maximum de 5 minutes (300 secondes). Si vous corrigez le problème (credentials, nom d’image), le Pod ne redémarre pas immédiatement — attendez le prochain retry ou supprimez/recréez le Pod.

Causes fréquentes :

Erreur	Cause probable	Solution
ImagePullBackOff	Échecs répétés de pull	Vérifiez les credentials et la connectivité
ErrImagePull	Image introuvable ou accès refusé	Vérifiez le nom de l’image et les droits
InvalidImageName	Syntaxe d’image incorrecte	Corrigez le format (registre/nom:tag)

Glissez pour voir

Checklist de diagnostic

1. Vérifiez que l’image existe

   # Depuis une machine avec accès au registre
   docker pull myregistry.example.com/myapp:v1.0
   # ou
   crane manifest myregistry.example.com/myapp:v1.0

2. Vérifiez le Secret imagePullSecrets

   # Le Secret existe-t-il dans le bon namespace ?
   kubectl get secret regcred -n production
   
   # Le Pod le référence-t-il ?
   kubectl get pod my-pod -o jsonpath='{.spec.imagePullSecrets}'

3. Testez les credentials

   # Décodez et testez manuellement
   kubectl get secret regcred -o jsonpath='{.data.\.dockerconfigjson}' | base64 -d

4. Consultez les events du Pod

   kubectl describe pod my-pod | grep -A 10 Events

Erreur FailedToRetrieveImagePullSecret

Events:
  Reason: FailedToRetrieveImagePullSecret
  Message: Unable to retrieve some image pull secrets (regcred)

Cette erreur signifie que le Secret référencé dans imagePullSecrets n’existe pas dans le namespace du Pod. Vérifiez :

• Le nom du Secret est correct
• Le Secret existe dans le même namespace que le Pod

Images multi-architecture

Les images modernes supportent plusieurs architectures (amd64, arm64) via un manifest index (ou “fat manifest”).

# Voir les architectures supportées
crane manifest nginx:1.25.3 | jq '.manifests[].platform'

Kubernetes sélectionne automatiquement la bonne architecture selon le node. Attention : le pull réussit automatiquement uniquement si l’image publiée supporte l’architecture du nœud cible. Si vous déployez une image amd64 sur un nœud arm64 sans manifest multi-arch, le conteneur échouera avec une erreur exec format error.

Commandes impératives CKAD

Pour l’examen CKAD, maîtrisez ces commandes :

# Créer un Pod avec une image spécifique
kubectl run nginx --image=nginx:1.25.3

# Générer le YAML sans créer le Pod
kubectl run nginx --image=nginx:1.25.3 --dry-run=client -o yaml > pod.yaml

# Changer l'image d'un Deployment
kubectl set image deployment/myapp myapp=myapp:v2.0

# Créer un Secret docker-registry
kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=user \
  --docker-password=pass

# Voir les événements d'un Pod en erreur
kubectl describe pod my-pod | tail -20

À retenir

Concept	Points clés
ImagePullPolicy	Always (latest), IfNotPresent (tags versionnés), Never (local only)
Tags	Mutables, pratiques pour le dev, risqués en prod
Digests	Immuables (sha256:...), garantissent la reproductibilité
imagePullSecrets	Secret de type docker-registry dans le même namespace
ImagePullBackOff	Vérifiez image, credentials, et connectivité réseau

Glissez pour voir

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

Pods multi-conteneurs Patterns sidecar, init containers et design multi-conteneurs

Sécuriser vos images Scanning de vulnérabilités, signature et supply chain

Stocker vos images Comparatif des registres Docker Hub, Quay, Harbor...

Optimiser vos images Réduire la taille et améliorer la sécurité de vos images

×

📖 Voir la documentation →