kubectl : les commandes essentielles

kubectl, la porte d'entrée du cluster

kubectl est l'outil en ligne de commande qui communique avec l'API Kubernetes pour créer, inspecter et modifier les ressources du cluster.

Commandes de lecture

kubectl get pods                    # liste les Pods du namespace courant
kubectl get pods -n production      # liste les Pods d'un namespace précis
kubectl get all                     # liste tous les objets courants
kubectl describe pod mon-pod        # détail complet d'un Pod (événements inclus)
kubectl logs mon-pod                # logs du conteneur
kubectl logs mon-pod -f             # suit les logs en direct

Commandes d'action

kubectl apply -f deployment.yaml    # applique un fichier de configuration
kubectl delete pod mon-pod          # supprime un Pod (recréé si géré par un Deployment)
kubectl scale deployment mon-app --replicas=5   # change le nombre de répliques
kubectl exec -it mon-pod -- bash    # ouvre un shell dans le conteneur

Diagnostiquer un Pod qui ne démarre pas

flowchart TD
    A[kubectl get pods] --> B{Statut ?}
    B -- Pending --> C[kubectl describe pod\nvoir Events]
    B -- CrashLoopBackOff --> D[kubectl logs pod\nvoir l'erreur applicative]
    B -- ImagePullBackOff --> E[Vérifier le nom d'image\net les identifiants du registre]
    C --> F[Ressources insuffisantes\nou probleme de scheduling]

Cas concret

Un Pod reste bloqué en statut Pending. kubectl describe pod révèle dans la section Events : Insufficient cpu. Le cluster n'a pas assez de ressources CPU disponibles pour satisfaire la demande définie dans le manifeste du Pod. Solution : réduire la demande de ressources ou ajouter un nœud au cluster.

Erreurs fréquentes

• Ne jamais consulter describe : les Events en bas de la sortie expliquent presque toujours la cause exacte d'un blocage.
• Supprimer un Pod pour "réparer" un problème géré par un Deployment : le Pod revient identique, avec le même problème, tant que la cause racine (config, image) n'est pas corrigée.
• Confondre CrashLoopBackOff (l'application plante après démarrage) et ImagePullBackOff (l'image ne peut pas être téléchargée) : deux diagnostics différents.

À retenir

• kubectl describe est le premier réflexe de diagnostic, pas kubectl logs.
• CrashLoopBackOff = problème applicatif, ImagePullBackOff = problème d'image/registre.
• kubectl apply -f est idempotent : le réappliquer ne casse rien si rien n'a changé.

Mini-exercice

Un Pod affiche le statut ImagePullBackOff. Quelle commande lancer en premier, et que chercher dans le résultat ?

Réponse : kubectl describe pod <nom>, chercher dans la section Events le nom d'image exact utilisé et le message d'erreur (souvent une faute de frappe dans le tag, ou des identifiants de registre privé manquants).