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.