## Introduction Les images Kubernetes sont au cœur de chaque charge de travail, et savoir les inspecter, les mettre à jour et les dépanner est essentiel pour les développeurs, les consultants DevOps et les équipes techniques de startups. Cet article passe d'un problème observé à un résultat vérifié en reliant des commandes de base, des exemples concrets, une antisèche et des pratiques opérationnelles. Nous mettons l'accent sur la sécurité pratique : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint. Chaque commande ci-dessous est versionnée (Kubernetes 1.24+ sauf indication contraire) et suppose que kubectl est installé, configuré avec un contexte actuel, et que vous avez un accès en lecture à l'espace de noms concerné. L'objectif de la sécurité opérationnelle n'est pas seulement d'exécuter des commandes, mais de comprendre ce qu'elles changent et comment revenir en arrière. Nous couvrirons l'inventaire des versions et de l'environnement, le chemin de configuration sûr pour les mises à jour d'images, la vérification et le diagnostic, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle réutilisable entre les clusters. ## Inventaire des versions et de l'environnement Avant de toucher aux images, établissez les versions du cluster et des composants. Cet inventaire est en lecture seule et forme la base de référence pour tout changement ultérieur. Composants clés à inventorier : - Versions du plan de contrôle Kubernetes et des nœuds - Runtime de conteneurs (containerd, CRI-O ou Docker via cri-dockerd) - Version du plugin CNI - Points de terminaison du registre d'images et authentification - Politiques de tirage d'image existantes sur les charges de travail Commencez par les commandes de découverte de version : kubectl version --short # Exemple de sortie attendue : # Client Version: v1.28.2 # Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 # Server Version: v1.28.2 Si kubectl version --short est déconseillé dans les versions plus récentes, utilisez : kubectl version Qui affiche le JSON complet, y compris les versions client et serveur. Consignez cette base de référence dans votre runbook. Vérifiez la version du runtime du nœud avec : kubectl get nodes -o wide # NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME # node1 Ready control-plane 10d v1.28.2 192.168.1.10 Ubuntu 22.04.3 LTS 5.15.0-91-generic containerd://1.7.8 # node2 Ready 10d v1.28.2 192.168.1.11 Ubuntu 22.04.3 LTS 5.15.0-91-generic containerd://1.7.8 La colonne CONTAINER-RUNTIME liste le runtime et sa version, ce qui importe pour la compatibilité des images (par exemple, certaines fonctionnalités nécessitent containerd 1.6+). Exemple : si vous devez utiliser le streaming d'images (par exemple, pour de grandes images), assurez-vous que le runtime le supporte. containerd 1.7 avec CRI 1.2 et KEP 3668 l'active ; les versions plus anciennes ne le font pas. Inventoriez l'utilisation actuelle des images dans tous les espaces de noms avec : kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}' Exemple de sortie : default nginx-deployment-6b474476c4-8g2kf nginx:1.25.3 default redis-cache-0 redis:7.2-alpine kube-system coredns-5d78c9869d-8h4wp registry.k8s.io/coredns/coredns:v1.11.1 Cet inventaire en lecture seule montre toutes les images en cours d'exécution. Comparez-le à votre liste d'images approuvées pour repérer les dérives. Prérequis pour des opérations d'image sûres : - Version de kubectl compatible avec le serveur (à une version mineure près) - Identifiants du registre configurés comme secret si vous tirez depuis des registres privés - Espace disque suffisant sur les nœuds pour les tirages d'images (vérifiez avec df -h sur les nœuds ou utilisez la surveillance) - Sortie réseau vers les points de terminaison du registre Une observation en lecture seule ciblée pour la santé des images : kubectl get events --all-namespaces --field-selector reason=FailedToPullImage Si aucun événement n'apparaît, les images se tirent normalement au cours de la dernière heure (TTL d'événement par défaut). Sinon, notez l'espace de noms, le pod et l'image en cause. Documentez l'état actuel avec l'horodatage et le contexte du cluster : date -u && kubectl config current-context && kubectl get pods -A -o wide > inventory-$(date +%Y%m%d-%H%M).txt Ce fichier texte est votre référence de restauration pour les changements ultérieurs.
Question rapide 1 sur 2 Quelle commande est utilisée pour mettre à jour l'image d'un conteneur dans un pod à l'aide d'un patch JSON ? - kubectl set image pod valid-pod kubernetes-serve-hostname=new image - kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' - kubectl edit pod valid-pod - kubectl apply -f pod.yaml
Le passage de référence fourni montre explicitement la commande pour mettre à jour l'image d'un conteneur à l'aide de kubectl patch avec un patch de fusion où spec.containers[*].name est requis comme clé de fusion.
## Chemin de configuration sûr Changer une image doit suivre le plus petit changement justifié : une image à la fois dans une charge de travail, avec une vérification observable. ### Mise à jour d'image dans un déploiement Supposons que vous ayez un déploiement web exécutant nginx:1.25.2 et que vous vouliez le mettre à jour vers nginx:1.25.3 . D'abord, confirmez l'image actuelle : kubectl get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}' # nginx:1.25.2 Observez l'état actuel du déploiement : kubectl rollout status deployment/web --timeout=60s # deployment "web" successfully rolled out Maintenant, mettez à jour l'image en utilisant la commande impérative (plus petit changement) : kubectl set image deployment/web nginx=nginx:1.25.3 # deployment.apps/web image updated Surveillez le déploiement et vérifiez : kubectl rollout status deployment/web --timeout=120s # Waiting for deployment "web" rollout to finish: 1 out of 2 new replicas have been updated... # deployment "web" successfully rolled out Confirmez que la nouvelle image est en place : kubectl get pods -l app=web -o jsonpath='{.items[*].spec.containers[0].image}{"\n"}' # nginx:1.25.3 nginx:1.25.3 Revenez en arrière si nécessaire (chemin de récupération) : kubectl rollout undo deployment/web # deployment.apps/web rolled back kubectl rollout status deployment/web # deployment "web" successfully rolled out Vérifiez l'image après le retour en arrière : kubectl get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}' # nginx:1.25.2 ### Politique de tirage d'image Par défaut, Kubernetes utilise IfNotPresent pour les images avec une étiquette explicite (comme nginx:1.25.3 ) et Always pour les images avec l'étiquette latest . Cela peut causer une mise en cache inattendue. Exemple : définissez la politique de tirage sur Always pour garantir la dernière image dans un espace de noms de développement. Modifiez le déploiement : kubectl patch deployment web -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","imagePullPolicy":"Always"}]}}}}' # deployment.apps/web patched Vérifiez avec : kubectl get deployment web -o jsonpath='{.spec.template.spec.containers[0].imagePullPolicy}' # Always Remarque : Always ajoute une charge sur le registre et peut ralentir le démarrage des pods. Pour la production, utilisez des étiquettes explicites et IfNotPresent (par défaut) ou un condensat. ### Utilisation de condensats d'image pour l'immuabilité Épingler à un condensat empêche les changements accidentels si l'étiquette est écrasée. Trouvez le condensat : docker buildx imagetools inspect nginx:1.25.3 --format '{{.Manifest.Digest}}' # sha256:... (hash réel) Ou utilisez skopeo inspect docker://nginx:1.25.3 | jq -r '.Digest' . Mettez à jour le déploiement pour utiliser le condensat : kubectl set image deployment/web nginx=nginx@sha256:abcdef1234567890... Vérifiez : kubectl get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}' # nginx@sha256:abcdef1234567890... Le retour en arrière fonctionne de la même manière via kubectl rollout undo . ### Identifiants de registre privé Si votre image est dans un registre privé, créez un secret et ajoutez-le à la spécification du pod. Créez le secret : kubectl create secret docker-registry my-registry-secret \ --docker-server=registry.example.com \ --docker-username=myuser \ --docker-password='s3cr3t' \ --docker-email=user@example.com # secret/my-registry-secret created Patchez le compte de service ou le déploiement pour l'utiliser (le compte de service est recommandé pour une valeur par défaut à l'échelle du cluster) : kubectl patch serviceaccount default -p '{"imagePullSecrets":[{"name":"my-registry-secret"}]}' Ou directement sur la spécification du pod : kubectl patch deployment web -p '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"my-registry-secret"}]}}}}' Ne stockez jamais de mots de passe en clair dans le YAML de déploiement ; utilisez des secrets et évitez de les commiter dans Git. ### Garder un test local petit pour une configuration sûre Avant de passer à un équilibreur de charge externe ou à une entrée, testez localement avec kubectl port-forward : kubectl port-forward deployment/web 8080:80 # Forwarding from 127.0.0.1:8080 -> 80 # Forwarding from [::1]:8080 -> 80 Puis testez avec curl http://localhost:8080 . Cela vérifie le pod directement sans l'exposer au réseau. ## Vérification et diagnostic Après un changement d'image, vérifiez que l'application est saine et que la bonne image s'exécute. ### État du pod et détails de l'image Listez les pods avec les images : kubectl get pods -o wide # NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES # web-5f6cf84df-8n2k5 1/1 Running 0 2m 10.244.2.5 node2 # web-5f6cf84df-v9xqt 1/1 Running 0 2m 10.244.1.7 node1 Obtenez des informations détaillées sur l'image : kubectl get pods -o jsonpath='{.items[*].spec.containers[0].image}' # nginx:1.25.3 nginx:1.25.3 Vérifiez l'image actuelle du déploiement : kubectl get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}' # nginx:1.25.3 ### Journaux et événements pour le diagnostic Si les pods sont en boucle de crash, obtenez les journaux : kubectl logs deployment/web --tail=50 # Exemple : 2024/01/15 error: image not found Pour l'instance de conteneur précédente : kubectl logs --previous Décrivez le pod pour les événements : kubectl describe pod # Events: # Type Reason Age From Message # ---- ------ ---- ---- ------- # Normal Scheduled 3m default-scheduler Successfully assigned default/web-5f6cf84df-8n2k5 to node2 # Normal Pulled 2m59s kubelet Container image "nginx:1.25.3" already present on machine # Normal Created 2m59s kubelet Created container nginx # Normal Started 2m58s kubelet Started container nginx Si le tirage d'image échoue, vous verrez Failed avec ErrImagePull ou ImagePullBackOff . ### Vérifier les erreurs de tirage d'image dans le cluster kubectl get events --all-namespaces --field-selector reason=FailedToPullImage,reason=ErrImagePull ### Vérification de l'image au moment de l'exécution Dans un pod en cours d'exécution, confirmez l'image du processus réel (nécessite sh) : kubectl exec -it -- cat /etc/os-release # NAME="Alpine Linux" # ID=alpine # VERSION_ID=3.19.0 Ou vérifiez les métadonnées de l'image du conteneur depuis le nœud : crictl images | grep nginx si vous avez accès au nœud. ### Historique des déploiements Vérifiez l'historique des déploiements pour les changements d'image : kubectl rollout history deployment/web # REVISION CHANGE-CAUSE # 1 # 2 Si vous avez utilisé --record (déconseillé en 1.27) ou annoté avec cause de changement, vous verrez des détails. Pour afficher l'image d'une révision : kubectl rollout history deployment/web --revision=2 ### Vérification des sondes de santé Si votre pod a des sondes de préparation, vérifiez qu'elles réussissent : kubectl get pods -l app=web -o jsonpath='{.items[*].status.conditions[?(@.type=="Ready")].status}{"\n"}' # True True Et les points de terminaison : kubectl get endpoints web # NAME ENDPOINTS AGE # web 10.244.1.7:80,10.244.2.5:80 5m ## Modes de défaillance et récupération Les défaillances liées aux images se répartissent généralement en échecs de tirage, mauvaise image, secrets manquants ou incompatibilité de runtime. Cette section couvre les modes de défaillance courants et les étapes de récupération explicites. ### ImagePullBackOff Cause : l'image n'existe pas, l'étiquette est incorrecte, le registre est inaccessible ou les identifiants du registre privé sont manquants. Observez : kubectl get pods # NAME READY STATUS RESTARTS AGE # web-7fd69d9c6-5k4j2 0/1 ImagePullBackOff 0 30s Obtenez les détails : kubectl describe pod web-7fd69d9c6-5k4j2 | tail -20 # Events: # Type Reason Age From Message # ---- ------ ---- ---- ------- # Normal Scheduled 35s default-scheduler Successfully assigned default/web-7fd69d9c6-5k4j2 to node1 # Normal Pulling 34s kubelet Pulling image "nginx:1.25.9" # Warning Failed 33s kubelet Failed to pull image "nginx:1.25.9": rpc error: code = NotFound desc = failed to pull and unpack image "docker.io/library/nginx:1.25.9": failed to resolve reference "docker.io/library/nginx:1.25.9": not found # Warning Failed 33s kubelet Error: ErrImagePull # Normal BackOff 32s kubelet Back-off pulling image "nginx:1.25.9" Récupération : - Corrigez l'étiquette de l'image dans le déploiement : kubectl set image deployment/web nginx=nginx:1.25.3 - Vérifiez le déploiement : kubectl rollout status deployment/web - Si registre privé, vérifiez que le secret existe et est correct : kubectl get secret my-registry-secret -o yaml Assurez-vous que .dockerconfigjson contient la bonne authentification. ### CrashLoopBackOff dû à une mauvaise architecture d'image Vous pouvez tirer une image ARM64 sur un nœud AMD64. Le pod démarre mais plante avec une erreur de format exec. Observez : kubectl logs # exec /entrypoint.sh: exec format error Récupération : - Vérifiez l'architecture du nœud : kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.architecture}' # amd64 amd64 - Utilisez une image multi-architecture ou une étiquette d'architecture correcte. Par exemple, utilisez nginx:1.25.3 qui supporte amd64 et arm64, ou spécifiez --platform=linux/amd64 lors de la construction. - Mettez à jour l'image et vérifiez. ### Secret de tirage d'image manquant Si le pod ne peut pas tirer depuis un registre privé, le statut montre ImagePullBackOff avec unauthorized: authentication required . Observez : kubectl describe pod | grep -A5 "Failed to pull image" # Warning Failed 10s (x3 over 30s) kubelet Failed to pull image "registry.example.com/myapp:1.0": rpc error: code = Unknown desc = failed to pull and unpack image "registry.example.com/myapp:1.0": failed to resolve reference "registry.example.com/myapp:1.0": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed Récupération : - Créez ou mettez à jour le secret comme montré précédemment. - Ajoutez imagePullSecrets au pod ou au compte de service. - Supprimez le pod pour forcer un nouveau tirage : kubectl delete pod Le nouveau pod devrait démarrer. ### La mise à jour de l'image a causé une défaillance de l'application Si la nouvelle image s'exécute mais que l'application échoue (par exemple, mauvais point d'entrée, configuration manquante), vous pouvez revenir en arrière. Retour rapide : kubectl rollout undo deployment/web Ou vers une révision spécifique : kubectl rollout undo deployment/web --to-revision=1 Puis vérifiez : kubectl rollout status deployment/web kubectl get pods -l app=web -o jsonpath='{.items[*].spec.containers[0].image}' ### Pression disque due à de grandes images Si les nœuds manquent de disque à cause de nombreuses images ou de grandes couches, les pods peuvent être évincés. Observez les conditions du nœud : kubectl describe node | grep -A5 "Conditions:" # Conditions: # Type Status LastHeartbeatTime LastTransitionTime Reason Message # ---- ------ ----------------- ------------------ ------ ------- # MemoryPressure False Tue, 16 Jan 2024 10:00:00 +0000 Tue, 16 Jan 2024 09:00:00 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available # DiskPressure True Tue, 16 Jan 2024 10:05:00 +0000 Tue, 16 Jan 2024 10:04:30 +0000 KubeletHasDiskPressure kubelet has disk pressure Récupération : - Supprimez les images inutilisées sur le nœud : crictl rmi --prune (si vous avez accès au nœud) - Définissez le seuil de collecte des ordures d'image : drapeau kubelet --image-gc-high-threshold=85 (par défaut 85%) - Utilisez des images plus petites ou le streaming d'images. ### Échec de tirage dû à un réseau ou une panne du registre Si le registre est indisponible, les pods montreront ImagePullBackOff avec connection refused ou timeout . Vérifiez la connectivité depuis le nœud : kubectl debug node/ -it --image=busybox -- sh # dans le pod de debug : wget -O- https://registry-1.docker.io/v2/ ; echo $? Récupération : - Réparez le point de terminaison du registre/DNS/pare-feu. - Utilisez un miroir local ou --registry-mirror dans le runtime de conteneurs. - Mettez à jour la source de l'image si vous utilisez un registre différent.
Question rapide 2 sur 2 Quel est l'objectif de l'utilisation d'un outil d'analyse d'images avant de déployer des conteneurs ? - Améliorer les performances des conteneurs - Analyser une image pour détecter les vulnérabilités avant le déploiement - Mettre à jour automatiquement les images - Créer des images de conteneurs
Le passage de référence cite « Utiliser un outil d'analyse d'images pour analyser une image avant de déployer des conteneurs » comme mesure de sécurité, ce qui implique que son objectif est d'identifier des vulnérabilités.
## Liste de contrôle opérationnelle Utilisez cette liste de contrôle avant, pendant et après toute opération liée aux images pour maintenir la sécurité et la récupérabilité. ### 1. Liste de contrôle avant changement - [ ] Enregistrez la version actuelle du cluster : kubectl version - [ ] Enregistrez l'image actuelle de la charge de travail : kubectl get deployment -o jsonpath='{.spec.template.spec.containers[0].image}' - [ ] Notez l'état du déploiement : kubectl rollout status deployment/ - [ ] Vérifiez la connectivité au registre : curl -I https://registry-1.docker.io/v2/ (ou votre registre) - [ ] Vérifiez l'espace disque sur les nœuds : kubectl describe nodes | grep -A5 DiskPressure - [ ] Sauvegardez le YAML du déploiement : kubectl get deployment -o yaml > backup--$(date +%F).yaml ### 2. Exécution du changement - [ ] Appliquez un changement d'image avec kubectl set image ou patch - [ ] Surveillez la progression du déploiement : kubectl rollout status deployment/ --timeout=90s - [ ] Si les nouveaux pods ne montent pas, vérifiez les événements : kubectl get events --field-selector reason=FailedToPullImage,reason=ErrImagePull ### 3. Vérification après changement - [ ] Confirmez que la nouvelle image s'exécute : kubectl get pods -l app=