Bug #17
Updated by UserName LastName 7 months ago
**Projet :** [Nom de votre projet, ex: API-Production] **Tracker :** Bogue **Sujet :** `ImagePullBackOff` sur le déploiement `[Nom du service]` en environnement `[Staging/Production]` ----- **Statut :** Nouveau **Priorité :** Élevée **Assigné à :** [Nom de l'équipe ou de la personne, ex: Équipe SRE] **Version cible :** [Version ou Sprint concerné, ex: Sprint 24.3] ----- ### **Description** Bonjour, Nous rencontrons une erreur de type `ImagePullBackOff` sur les pods du déploiement **`mon-application-backend`** en environnement de **Production**. Le déploiement est dans un état instable et les nouvelles versions du pod n'arrivent pas à démarrer. Ce problème est survenu suite à la tentative de déploiement de la version `v1.2.3` de notre image Docker. #### **Environnement** * **Cluster Kubernetes :** `gke-prod-europe-west1-a` * **Namespace :** `backend-services` * **Déploiement concerné :** `mon-application-backend` * **Image Docker :** `mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3` #### **Symptômes Observés** En utilisant la commande `kubectl get pods -n backend-services`, nous voyons les pods bloqués dans cet état : ```shell NAME READY STATUS RESTARTS AGE mon-application-backend-5f8f7f95f6-abcde 0/1 ImagePullBackOff 0 15m mon-application-backend-5f8f7f95f6-fghij 0/1 ImagePullBackOff 0 15m ``` #### **Logs et Diagnostics** Voici l'extrait pertinent de la commande `kubectl describe pod mon-application-backend-5f8f7f95f6-abcde -n backend-services` : ```shell Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 16m default-scheduler Successfully assigned backend-services/mon-application-backend-5f8f7f95f6-abcde to gke-prod-cluster-node-pool-1-xxxx Normal Pulling 15m (x4 over 16m) kubelet Pulling image "mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3" Warning Failed 15m (x4 over 16m) kubelet Failed to pull image "mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3": rpc error: code = Unknown desc = failed to pull and unpack image "mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3": failed to resolve reference "mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3": mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3: not found Warning Failed 15m (x6 over 16m) kubelet Error: ErrImagePull Normal BackOff 14m (x7 over 16m) kubelet Back-off pulling image "mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3" Warning Failed 1m (x25 over 16m) kubelet Error: ImagePullBackOff ``` L'erreur `not found` suggère que le tag `v1.2.3` de l'image n'existe pas dans notre registre d'images (Google Container Registry). #### **Comportement Attendu** Le déploiement `mon-application-backend` devrait réussir à télécharger l'image `v1.2.3` et les pods devraient passer au statut `Running`. #### **Étapes de Reproduction** 1. Mettre à jour le fichier de déploiement `deployment.yaml` pour utiliser l'image `mon-registre.gcr.io/mon-projet/mon-application-backend:v1.2.3`. 2. Appliquer la configuration avec `kubectl apply -f deployment.yaml -n backend-services`. 3. Observer l'état des pods avec `kubectl get pods -n backend-services --watch`. #### **Action Immédiate (si effectuée)** Pour restaurer le service, nous avons procédé à un rollback vers la version précédente (`v1.2.2`) en utilisant la commande `kubectl rollout undo deployment/mon-application-backend -n backend-services`. Le service est de nouveau opérationnel. #### **Question / Demande** Pouvez-vous s'il vous plaît vérifier pourquoi le pipeline CI/CD n'a pas publié le tag d'image `v1.2.3` ou s'il y a un problème de permissions ? ----- ### **Fichiers joints** * `deployment.v1.2.3.yaml` (le fichier de déploiement qui a échoué) ----- ### **Pourquoi ce modèle est efficace ?** 1. **Sujet Clair :** Il contient l'erreur (`ImagePullBackOff`), le service impacté, et l'environnement. On sait immédiatement de quoi il s'agit. 2. **Contexte Précis :** Fournit toutes les informations nécessaires (cluster, namespace, nom du déploiement, image Docker) pour que l'ingénieur n'ait pas à les chercher. 3. **Logs Pertinents :** Le résultat de `kubectl describe` est la source de vérité pour ce type de bogue. L'inclure fait gagner un temps précieux. 4. **Analyse Préliminaire :** Le ticket ne se contente pas de signaler l'erreur, il propose une hypothèse (`tag not found`), ce qui montre qu'une première investigation a été menée. 5. **Action et Attendu :** La section "Comportement Attendu" clarifie l'objectif, et la section "Action Immédiate" informe des mesures de contournement déjà prises, ce qui est crucial pour la gestion d'incident. 6. **Actionnable :** La demande finale est une question claire qui oriente la résolution du problème.