infra / kubernetes

Installer un cluster local et bases de kubectl

Leçon 21 exercice

Explication

Ce que vous allez apprendre

Créer un cluster Kubernetes local jetable avec kind ou minikube pour s'entraîner sans risque
Expliquer pourquoi kubectl n'exécute jamais rien directement, mais parle à l'API du control plane
Vérifier et changer de contexte kubectl pour éviter d'agir sur le mauvais cluster
Appliquer la grammaire commune kubectl <verbe> <type> <nom> à n'importe quel objet Kubernetes
Utiliser kubectl describe et kubectl explain comme premiers réflexes de diagnostic et de documentation

Dans quel contexte ?

Un développeur junior, encore en formation, exécute par erreur kubectl delete namespace production en pensant être connecté à son cluster local kind-demo. En réalité, son terminal était resté connecté au contexte prod-cluster d'une précédente session de debug. Ce genre d'incident, extrêmement fréquent chez les débutants, illustre pourquoi vérifier kubectl config current-context avant toute commande destructive n'est pas une simple recommandation théorique, mais un réflexe qui a évité — ou provoqué — de vraies pannes de production dans d'innombrables entreprises.

Le problème : un vrai cluster coûte cher pour apprendre

D'abord, un constat simple : provisionner un vrai cluster Kubernetes chez un fournisseur cloud coûte de l'argent et prend du temps à configurer. Pour apprendre, il faut un bac à sable gratuit, où casser des choses n'a aucune conséquence.

Une solution : simuler un cluster sur ta machine

C'est exactement ce que fait kind (Kubernetes IN Docker) : chaque "node" du cluster tourne dans un simple conteneur Docker, sur ton ordinateur, en quelques secondes. minikube est une alternative plus ancienne, historiquement basée sur une machine virtuelle, qui reste très utilisée aussi.

Outil	Techno sous-jacente	Démarrage	Cas d'usage
kind	Chaque node = un conteneur Docker	Quelques secondes	CI, tests rapides, multi-nœuds simulés
minikube	Machine virtuelle ou driver Docker	Un peu plus lent	Apprentissage, addons intégrés (dashboard, ingress)

kubectl : le seul outil pour parler au cluster

Une fois ton cluster local démarré, tu as besoin d'un moyen de lui parler. kubectl est l'outil en ligne de commande qui dialogue avec n'importe quel cluster Kubernetes, local ou dans le cloud, en envoyant des requêtes à son API.

kubectl ne "fait" rien lui-même

Il faut bien comprendre ce point : kubectl n'exécute jamais rien directement. Il envoie une requête à l'API du control plane, vu à la leçon précédente, qui décide et exécute réellement l'action demandée.

Un même outil, plusieurs clusters : le contexte

Une fois cette distinction claire, il reste un risque à connaître : un même poste peut être connecté à plusieurs clusters (local, staging, production). Le contexte dit à kubectl "à qui je parle en ce moment", et se tromper de contexte est l'une des erreurs les plus dangereuses de Kubernetes.

Piège fréquent

Se tromper de contexte kubectl est l'une des erreurs les plus dangereuses de Kubernetes : une commande destructrice (delete, apply avec un mauvais fichier) exécutée sur le mauvais cluster peut casser un environnement de production en une fraction de seconde. Le réflexe kubectl config current-context avant toute commande sensible n'est jamais du temps perdu.

Le réflexe à prendre avant toute commande sensible

Avant de supprimer ou modifier quoi que ce soit, tape kubectl config current-context pour vérifier à quel cluster tu es réellement connecté. Ce simple réflexe évite de supprimer un objet de production en pensant être en local.

Astuce

kubectl explain <type>.<champ> affiche la documentation intégrée de n'importe quel champ d'un manifest YAML, directement dans le terminal, sans avoir à quitter la ligne de commande pour chercher dans la documentation en ligne.

Une grammaire commune à toutes les commandes

Maintenant que le contexte est sous contrôle, apprends la structure des commandes : presque toutes suivent le schéma kubectl <verbe> <type> <nom>, par exemple kubectl get pods ou kubectl describe pod mon-pod. Une fois cette grammaire comprise, tu sais déjà "parler" Kubernetes pour n'importe quel objet que tu découvriras dans ce cours.

La prochaine leçon applique directement cette grammaire au premier objet fondamental de Kubernetes : le Pod.

Commandes & code

Cluster local & kubectl

# kind (Kubernetes IN Docker) : cluster local basé sur des conteneurs Docker
kind create cluster --name demo

# minikube : alternative avec VM ou driver Docker
minikube start --driver=docker

# Vérifier le contexte kubectl actif (à quel cluster on parle)
kubectl config current-context
kubectl config get-contexts
kubectl config use-context kind-demo

# Syntaxe générale : kubectl <verbe> <type> <nom> [flags]
kubectl get pods
kubectl get pods -A                     # -A = tous les namespaces (--all-namespaces)
kubectl get pods -n kube-system
kubectl describe pod mon-pod            # détails + événements (debug de premier réflexe)
kubectl explain pod.spec.containers     # documentation intégrée d'un champ de manifest

kubectl apply -f manifest.yaml          # crée ou met à jour (déclaratif, à privilégier)
kubectl delete -f manifest.yaml
kubectl delete pod mon-pod

kubectl logs mon-pod
kubectl logs mon-pod -c mon-conteneur -f    # -f = suivre en direct, -c pour un pod multi-conteneurs
kubectl exec -it mon-pod -- /bin/sh

# Alias et autocomplétion : gain de temps massif au quotidien
alias k=kubectl
source <(kubectl completion bash)   # ou zsh, selon le shell

# Formats de sortie utiles pour scripter ou débugger
kubectl get pods -o yaml
kubectl get pods -o json
kubectl get pods -o wide
kubectl get pods -o jsonpath='{.items[*].metadata.name}'

Commande	Usage
`kubectl get <type>`	Lister des objets
`kubectl describe <type> <nom>`	Détails + événements récents
`kubectl apply -f <fichier>`	Créer/mettre à jour depuis un manifest
`kubectl delete <type> <nom>`	Supprimer un objet
`kubectl logs <pod>`	Logs d'un conteneur
`kubectl exec -it <pod> -- <cmd>`	Shell interactif dans un conteneur

Résumé

kind/minikube : clusters locaux pour apprendre sans coût cloud.
kubectl apply -f (déclaratif) est préféré à kubectl create (impératif) en pratique.
describe + logs sont les deux premiers réflexes de debug.
kubectl explain documente n'importe quel champ de manifest directement en CLI.

Exercices pratiques

1 disponible

Mission : éviter la catastrophe du mauvais contexte

Objectif : Utiliser kubectl de façon sûre en vérifiant systématiquement le contexte actif avant toute commande destructrice, et diagnostiquer un objet via describe/explain.

Contexte

Un développeur junior de ton équipe s'apprête à taper kubectl delete namespace demo pour nettoyer son bac à sable local. Son terminal affiche pourtant un onglet resté ouvert depuis une session de debug sur prod-cluster la veille. Avant qu'il n'appuie sur Entrée, tu dois lui montrer le réflexe qui aurait évité l'incident, puis l'aider à utiliser correctement kubectl pour la suite de son diagnostic.

Résoudre l’exercice →