Kubernetes (1/12) — Namespace & premier Pod

L’idée reçue

« Kubernetes, c’est surtout beaucoup de YAML à apprendre par cœur. »

On va faire l’inverse : lancer des choses réelles, observer, et n’expliquer que ce qu’on peut prouver. Dans ce module, un espace isolé, un premier Pod, ses logs, et une visite à l’intérieur — commande par commande.

Ton cluster K3s est en place : un nœud master et un nœud worker. Pour ces premiers pas, on travaille directement sur le master avec kubectl (la connexion depuis la machine mgmt viendra à la phase d’automatisation). On avance lentement, par la preuve.

À la fin de ce module, tu sauras…

Créer un namespace et le définir par défaut
Lancer un Pod et lire son statut
Consulter les logs d’un conteneur dans Kubernetes
Entrer dans un Pod, et y envoyer une requête HTTP (port-forward)

01Un espace de travail isolé

Expérience 1

Créer un namespace, et s’y installer

Manipule

kubectl create namespace lab-soria
kubectl get ns

Observe

namespace/lab-soria created
NAME              STATUS   AGE
lab-soria         Active   5s
...

Dis à kubectl de travailler dans ce namespace par défaut :

Manipule

kubectl config set-context --current --namespace=lab-soria
kubectl config view --minify | grep namespace

La sortie confirme namespace: lab-soria. Sans ça, il faudrait ajouter -n lab-soria à chaque commande.

Comprends un namespace, en une analogie

Créer le namespace, c’est mkdir lab-soria ; le définir par défaut, c’est cd lab-soria. Le namespace isole ton travail des autres : tu peux tout regrouper, et tout supprimer proprement plus tard, sans toucher au reste du cluster.

02Le premier Pod

Expérience 2

Lancer, puis attendre « Running »

Manipule

kubectl run demo-pod --image=nginx:stable
kubectl get pods

Observe

NAME       READY   STATUS              RESTARTS   AGE
demo-pod   0/1     ContainerCreating   0          3s
# puis, après quelques secondes :
demo-pod   1/1     Running             0          20s

Tu verras passer ContainerCreating (Kubernetes récupère l’image et prépare le Pod) puis Running. Règle du parcours : on ne passe à la suite que lorsque le Pod est Running — ou qu’on comprend pourquoi il ne l’est pas.

Comprends les statuts que tu peux croiser

Running = prêt. ImagePullBackOff = problème de récupération d’image (nom, accès registre). CrashLoopBackOff = le conteneur redémarre en boucle (l’appli plante au démarrage). Ces statuts sont ton premier outil de diagnostic.

03Vérifier, sans jamais supposer

Expérience 3

Dans quel namespace ce Pod vit-il ?

Manipule

kubectl get pod demo-pod -o jsonpath='{.metadata.namespace}{"\n"}'

Observe

lab-soria

On a configuré un namespace par défaut, mais on vérifie par les faits plutôt que par la mémoire. Le Pod vit bien dans lab-soria.

Comprends jsonpath, à quoi ça sert

-o jsonpath=… extrait un champ précis de l’objet Kubernetes. Ici .metadata.namespace lit le namespace réel stocké dans le Pod. C’est la manière fiable d’obtenir une information exacte, sans se fier à l’affichage.

04Lire les logs du conteneur

Expérience 4

Ce que fait vraiment le conteneur

Manipule

kubectl logs demo-pod

Observe

/docker-entrypoint.sh: Configuration complete; ready for start up
[notice] 1#1: nginx/1.28.0
[notice] 1#1: start worker processes

Les logs prouvent que l’entrypoint nginx s’est exécuté, que la configuration s’est appliquée, et que NGINX a démarré ses workers. Le conteneur est réellement opérationnel — pas seulement « lancé ».

Comprends même logique qu’en Docker

kubectl logs lit la sortie standard du conteneur — exactement comme docker logs (Phase 3). Kubernetes collecte ces flux. C’est ta première fenêtre d’observabilité dans le cluster.

05Entrer dans le Pod

Expérience 5

Inspection en direct

Manipule

kubectl exec -it demo-pod -- /bin/sh

Une fois à l’intérieur :

Manipule

hostname
ls /usr/share/nginx/html
exit

Observe

demo-pod
50x.html  index.html

hostname confirme qu’on est dans le conteneur ; on voit les fichiers web par défaut de nginx ; exit nous ramène sur l’hôte. Tu peux inspecter et déboguer un Pod vivant.

Comprends exec, comme en Docker

kubectl exec -it … – /bin/sh ouvre un shell dans le conteneur en marche, comme docker exec. C’est l’outil de diagnostic pour regarder « de l’intérieur » sans redémarrer quoi que ce soit.

06Une vraie requête HTTP (port-forward)

Expérience 6

Joindre le Pod, sans Service encore

Dans un premier terminal, ouvre un tunnel du port local 8080 vers le port 80 du Pod :

Manipule

kubectl port-forward pod/demo-pod 8080:80

Dans un second terminal, envoie une requête, puis regarde les logs du Pod :

Manipule

curl -I http://localhost:8080
kubectl logs demo-pod | tail -n 3

Observe

HTTP/1.1 200 OK
...
"GET / HTTP/1.1" 200

La requête aboutit, et NGINX l’a bien journalisée. Ctrl+C ferme le tunnel.

Comprends port-forward, un outil de debug

port-forward crée un tunnel temporaire depuis ta machine vers un Pod précis. Ce n’est pas une façon d’exposer un service en production (on verra les Services et Ingress plus loin), mais un outil de diagnostic très pratique pour tester un Pod directement.

✓Ce que tu retiens

Tu as isolé ton travail dans un namespace, lancé un Pod, lu son statut et ses logs, tu es entré dedans, et tu l’as joint en HTTP via port-forward. Le tout par la preuve, sans théorie inutile. Tu as un cycle de vie complet d’un Pod unique.

Mini-projet

Ton premier Pod, maîtrisé

À faire

Crée le namespace lab-soria et définis-le par défaut.
Lance demo-pod et attends Running.
Prouve son namespace avec jsonpath, lis ses logs, entre dedans.
Fais une requête via port-forward et retrouve-la dans les logs.
Documente dans BookStack : namespace, Pod, logs, exec, port-forward.

Fil rouge — Ce Pod est seul et fragile : si tu le supprimes, rien ne le recrée. Au module suivant, on voit pourquoi un Pod nu n’est pas prêt pour la production, et on passe au Deployment — l’objet qui maintient l’état voulu.

?Auto-évaluation

1. À quoi sert un namespace ?

À isoler et regrouper des ressources, pour éviter d’interférer avec le reste du cluster et tout gérer/supprimer proprement.

2. Que signifie CrashLoopBackOff ?

Le conteneur plante au démarrage et Kubernetes le redémarre en boucle. Il faut lire les logs pour comprendre pourquoi.

3. port-forward est-il une méthode d’exposition de production ?

Non : c’est un outil de debug temporaire. La production utilise Services et Ingress.