Module 1 · Kubernetes - les fondamentaux¶

Objectifs

Comprendre ce que résout Kubernetes et comment un cluster est construit.
Connaître les objets de base : Pod, ReplicaSet, Deployment, Service, Namespace.
Faire ses premières commandes kubectl : créer, observer, supprimer.
Durée : ~45 min · Pré-requis : Module 0 (sandbox qui répond) - c'est tout.

Le problème que résout Kubernetes¶

Sans orchestrateur, exploiter des conteneurs en production, c'est répondre soi-même à : qui relance un conteneur qui meurt ? comment passer de 1 à 10 instances ? comment répartir le trafic ? comment déployer sans coupure ?

Kubernetes (k8s) répond à tout ça avec une idée centrale : tu déclares l'état voulu (« je veux 3 instances de cette image »), et le cluster converge en permanence vers cet état. Un pod meurt ? Il est recréé. Un nœud tombe ? Les charges sont replacées ailleurs.

À retenir

Kubernetes n'exécute pas des commandes, il réconcilie un état. C'est LA clé de compréhension : tout le reste (objets, YAML, contrôleurs) en découle.

Anatomie d'un cluster¶

graph TB
    subgraph "Control plane (le cerveau)"
        A[API server] --- E[(etcd)]
        A --- S[Scheduler]
        A --- C[Controller manager]
    end
    subgraph "Nœud (les muscles · idem sur chaque nœud)"
        K[kubelet] --> RT[runtime / containerd] --> P[pods]
        KP[kube-proxy]
    end
    A --> K

API server : la porte d'entrée unique - kubectl, k9s et les contrôleurs lui parlent.
etcd : la base où vit l'état du cluster.
Scheduler : choisit sur quel nœud placer chaque pod.
Controller manager : les boucles de contrôle qui réconcilient l'état - un pod manque ? un contrôleur le recrée. C'est le « qui recrée ? » au cœur de ce module.
Nœuds : les machines qui exécutent réellement les conteneurs. Sur chacun : le kubelet (l'agent qui lance les pods qu'on lui confie), un runtime de conteneurs (containerd…) qui les exécute concrètement, et kube-proxy qui programme les règles réseau faisant fonctionner les Services (on y revient au module 4r).

Dans ta sandbox, tout ça tourne déjà - kubectl get nodes te montre tes nœuds.

Les objets de base¶

Objet	Rôle	En une phrase
Pod	l'unité d'exécution	1 (ou plusieurs) conteneur(s) qui vivent et meurent ensemble
ReplicaSet	la quantité	maintient N copies identiques d'un pod
Deployment	le cycle de vie	gère le ReplicaSet + les mises à jour progressives
Service	le réseau	une adresse stable devant des pods éphémères
Namespace	le rangement	cloisonne les ressources (équipes, environnements)

graph LR
    D[Deployment] --> RS[ReplicaSet] --> P1[Pod] & P2[Pod] & P3[Pod]
    SVC[Service] -.sélectionne par labels.-> P1 & P2 & P3

Deux règles importantes se cachent dans ce schéma - plutôt que de te les donner, on les découvre ensemble : l'anatomie de la cascade (exercice 1.1), puis ce qui arrive quand un pod meurt selon qui l'a créé (TP 01-cascade) - on formule la règle à ce moment-là.

Premières commandes kubectl¶

kubectl est le couteau suisse officiel. Quatre verbes couvrent 90 % du quotidien :

kubectl run web --image nginx:1.27-alpine     # créer un pod (exploration)
kubectl get pods                              # lister (l'état actuel)
kubectl describe pod web                      # détailler (config + évènements)
kubectl delete pod web                        # supprimer

Et pour les objets « sérieux » :

kubectl create deployment app --image nginx:1.27-alpine --replicas 3
kubectl get deploy,rs,pods                    # la cascade Deployment → ReplicaSet → Pods
kubectl expose deployment app --port 80       # un Service devant les 3 pods
kubectl get svc

Le réflexe à prendre dès maintenant

Après chaque action : kubectl get … pour voir l'état, kubectl describe … si quelque chose cloche (la section Events en bas raconte ce qui s'est passé).

Gestes vus en séance

Quelques gestes du quotidien (poser un label, filtrer avec -l, faire parler un pod avec logs/exec…) se découvrent en séance, en démo live - l'aide-mémoire pour les retrouver ensuite est la cheat-sheet kubectl.

Pratique¶

Dans le terminal de ta sandbox (à droite), les TP auto-corrigés de ce module - une fois la lecture faite :

tp start 01-premier-pod   # en séance : créer un pod, lire ses logs, trier par labels
tp start 01-cascade       # en séance : Deployment → ReplicaSet → Pods + réconciliation
tp start ancrage-1        # en autonomie ensuite : mêmes gestes, contexte différent

fais la manip puis tp check (ou tp watch pour l'auto-validation) · tp hint pour un indice · tp solution si tu bloques.

En séance, on observe d'abord l'anatomie ensemble (ci-dessous, en partage d'écran) ; le TP te fait ensuite pratiquer le comportement, corrigé. En autonomie : déroule l'exercice, puis enchaîne le TP.

Exercice 1.1 - L'anatomie de la cascade (on l'observe ensemble)

kubectl create deployment site --image nginx:1.27-alpine --replicas 3

kubectl get deploy,rs,pods : repère les trois étages et le nommage site-<hash-rs>-<hash-pod>.
kubectl describe rs (le ReplicaSet de site) : trouve la ligne Controlled By: Deployment/site - qui possède qui.
Contraste avec un pod nu : kubectl run solo --image nginx:1.27-alpine, puis kubectl get pods - solo n'a aucun ReplicaSet au-dessus de lui.

On regarde, on ne casse rien. Ce qui se passe quand un pod meurt - selon qui l'a créé - c'est le TP 01-cascade qui te le fera vivre.

Exercice 1.2 - Le cloisonnement par namespace

kubectl create namespace essai
kubectl run web --image nginx:1.27-alpine -n essai
kubectl get pods            # rien ici…
kubectl get pods -n essai   # …car il est dans « essai »
kubectl delete namespace essai   # et tout part d'un coup

Le drill en autonomie (créer, étiqueter, ranger) est dans le TP ancrage-1.

Ce qu'il faut retenir¶

Kubernetes réconcilie un état déclaré, en continu - il n'« exécute » pas des ordres.
Control plane = cerveau (API server, etcd, scheduler) · nœuds = muscles (kubelet, pods).
La cascade Deployment → ReplicaSet → Pods : on pilote le sommet, jamais le bas.
Un Service sélectionne ses pods par labels - adresse stable devant des pods éphémères.
run / get / describe / delete : le quotidien de kubectl ; describe → Events dès qu'un truc cloche.

Quiz éclair¶

Teste-toi : réponds de tête, puis déplie.

1. Tu supprimes un pod créé par un Deployment. Que se passe-t-il ?

Il est recréé aussitôt : le ReplicaSet constate qu'il manque une copie par rapport à l'état déclaré et reconverge. (Un pod nu, lui, ne reviendrait pas.)

2. À quoi sert un Service, si les pods ont déjà une IP ?

Les IP de pods sont éphémères (chaque recréation en change). Le Service offre une adresse stable et répartit le trafic vers les pods sélectionnés par labels.

3. Qui décide sur quel nœud tourne un pod ?

Le scheduler (control plane). Le kubelet du nœud choisi se charge ensuite de lancer concrètement les conteneurs.

➡️ Suite : Module 2 - k9s, l'essentiel