Analyse des statuts des Pods Kubernetes dans un déploiement SAS Viya 4

Dans un environnement Kubernetes, comme celui utilisé pour SAS Viya 4, les statuts des pods peuvent prêter à confusion. Certains peuvent sembler critiques alors qu’ils sont en réalité temporaires ou attendus. Ce guide propose une lecture technique et synthétique des statuts les plus courants.

✅ Statuts normaux ou transitoires

Completed (0/1)

Pod terminé avec succès, typiquement pour un job batch.

kubectl logs 

Utilisez cette commande pour consulter les journaux post-exécution, si nécessaire.

Running (0/1)

Le pod est actif, mais le ou les conteneurs ne sont pas encore prêts. Rien d’anormal, surtout juste après le lancement.

Running (1/1), Running (4/4)

Tous les conteneurs du pod sont prêts. C’est le statut idéal.

Init:1/4

Phase d’initialisation : 1 conteneur init (sur 4) est lancé. C’est normal au démarrage, la progression est en cours.

kubectl get pods

Permet de visualiser l’état général et les étapes d'initialisation.

CrashLoopBackOff (au démarrage)

Statut fréquent au boot de l’environnement si une dépendance (service, volume, base de données, etc.) n’est pas encore disponible. Pas de panique dans les 20 premières minutes.

kubectl describe pod 

Pour identifier la ressource manquante ou les erreurs dans les événements.

⚠️ Statuts problématiques

ImagePullBackOff

Erreur critique : l’image du conteneur ne peut pas être récupérée.

Causes possibles :

• Nom d’image incorrect
• Aucun accès réseau au registre (problèmes DNS, pare-feu)
• Identifiants invalides
• Image absente du registre

Vérification :

kubectl describe pod

• Test manuel (si accès au nœud) :

docker pull

CrashLoopBackOff (persistant)

Indique que le conteneur plante en boucle. Si cela persiste au-delà du démarrage, une dépendance reste injoignable ou un bug logique est présent.

Pending (persistant)

Le pod ne trouve pas de nœud compatible ou ne peut pas accéder à un volume.

Causes fréquentes :

• Trop de taints sur les nœuds
• PVC non bound
• Manque de ressources disponibles

Diagnostic :

kubectl describe pod

Actions possibles :

• Augmenter les ressources du cluster
• Réduire les requests/limits dans les manifests
• Vérifier la configuration des StorageClasses

🧰 Conseils pratiques

• Inspectez systématiquement les événements :

kubectl describe pod

• Lisez les journaux en cas de crash :

kubectl logs [-c ]

• Adaptez la taille du cluster à la charge SAS Viya

Prévoyez un temps d’initialisation de l’environnement (~20 minutes)