Rappel sur Kubernetes

Bienvenue ! 🎉 Ce chapitre vous permet de réviser les concepts essentiels de Docker et Kubernetes avant de plonger dans OKS. Prenez le temps de bien comprendre chaque notion : elles sont la fondation de tout ce qui suivra.

Partie 1 : Docker et la Conteneurisation

Avant Kubernetes, il faut comprendre Docker. Commençons par là !

🆚 Conteneur vs Machine Virtuelle

Imaginez que vous voulez faire tourner plusieurs applications sur un même serveur. Deux approches existent :

La Machine Virtuelle (VM) : C'est comme avoir plusieurs ordinateurs complets dans un seul. Chaque VM embarque son propre système d'exploitation (Windows, Linux...), ses propres drivers, tout ! C'est isolé, mais c'est lourd.

Le Conteneur : C'est plus malin. Au lieu de dupliquer tout l'OS, les conteneurs partagent le noyau (kernel) de la machine hôte. Ils n'emportent que ce dont l'application a besoin.

📄 Le Dockerfile : la recette de votre image

Vous voulez créer une image Docker ? Il vous faut un Dockerfile. C'est comme une recette de cuisine : des instructions étape par étape pour construire votre environnement.

# On part d'une image de base (l'ingrédient principal)
FROM node:18-alpine

# On se place dans le dossier de travail
WORKDIR /app

# On copie les fichiers de dépendances
COPY package*.json ./

# On installe les dépendances
RUN npm install

# On copie le reste du code
COPY . .

# On indique quel port l'app utilise
EXPOSE 3000

# La commande qui lance l'application
CMD ["npm", "start"]

🚀 La commande docker run décortiquée

C'est LA commande que vous utiliserez le plus. Analysons-la ensemble :

docker run -d --name web -p 8080:80 -v /data:/app nginx:alpine

Décomposons option par option :

💾 Que reste-t-il après suppression d'un conteneur ?

Question piège classique ! Quand vous faites docker rm mon-conteneur, que devient quoi ?

C'est pour ça qu'on utilise des volumes pour les bases de données ! Sans volume, vos données disparaissent avec le conteneur.

🔒 L'immutabilité des images

Une image Docker est immuable (on ne peut pas la modifier). C'est comme un CD gravé : une fois créé, c'est figé.

Pour "modifier" une image, vous devez :

1. Modifier le Dockerfile
2. Reconstruire une nouvelle image (docker build)
3. Cette nouvelle image a un nouveau tag ou hash

---

Partie 2 : Kubernetes, l'orchestrateur

Docker gère un conteneur. Mais comment gérer des centaines de conteneurs sur des dizaines de serveurs ? C'est là qu'intervient Kubernetes !

🎭 Le rôle de Kubernetes

Kubernetes (ou K8s, parce que 8 lettres entre K et S) est un orchestrateur de conteneurs. Imaginez un chef d'orchestre qui coordonne tous les musiciens.

Son rôle principal : orchestrer et gérer des conteneurs à grande échelle.

Ce que Kubernetes fait pour vous :

• 📦 Déploie vos conteneurs sur les bons serveurs
• 📈 Scale automatiquement selon la charge
• 🔄 Redémarre les conteneurs qui plantent
• 🌐 Gère le réseau entre les conteneurs
• 💾 Gère le stockage persistant

🏗️ L'architecture : qui fait quoi ?

Un cluster Kubernetes, c'est comme une entreprise avec deux types d'employés :

Le Control Plane : les managers 👔

Ce sont les "cerveaux" du cluster. Ils prennent les décisions mais n'exécutent pas les applications.

Les Worker Nodes : les exécutants 🔧

Ce sont les serveurs qui font vraiment tourner vos applications.

🫛 Le Pod : l'unité de base

*Attention, piège classique compose exec -T app npx tsx scripts/import-course.ts /app/exports/oks --clean --force 2>&1 | tail -15 L'unité de déploiement minimale dans Kubernetes, ce n'est PAS le conteneur. C'est le Pod.

Un Pod, c'est une "enveloppe" autour d'un ou plusieurs conteneurs. Pourquoi ?

Parce que parfois, deux conteneurs doivent être inséparables :

• Un conteneur principal (votre app)
• Un conteneur "sidecar" (pour les logs, le monitoring...)

Ces conteneurs dans le même Pod :

• Partagent la même adresse IP (communiquent via localhost)
• Partagent les mêmes volumes
• Sont déployés ensemble sur le même serveur
• Vivent et meurent ensemble

┌─────────────── Pod ───────────────┐
│  ┌─────────┐    ┌─────────┐      │
│  │  App    │    │  Logs   │      │
│  │  :8080  │◄──►│ sidecar │      │
│  └─────────┘    └─────────┘      │
│        └── localhost ──┘          │
│        └── Volume partagé ──┘     │
└───────────────────────────────────┘

📊 Deployments, ReplicaSets & Co

Un Pod tout seul, c'est fragile. Si le serveur plante, le Pod disparaît. On utilise donc des contrôleurs pour les gérer.

Le Deployment : votre meilleur ami

Un Deployment dit à Kubernetes : "Je veux toujours X réplicas de ce Pod en fonctionnement".

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3          # <- "Je veux 3 pods nginx"
  selector:
    matchLabels:
      app: nginx
  template:            # <- Le modèle de Pod à créer
    spec:
      containers:
      - name: nginx
        image: nginx:alpine

Si un Pod meurt, Kubernetes en recrée un automatiquement. Magie ! ✨

Quel contrôleur pour quel usage ?

🗂️ ConfigMaps et Secrets

Comment passer de la configuration à vos applications ?

ConfigMap : configuration non sensible

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "postgres.default.svc"
  LOG_LEVEL: "info"

Secret : données sensibles

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  password: cGFzc3dvcmQxMjM=  # base64 encoded

🌐 Exposer ses applications

Les Services : la carte de visite interne

Un Service donne une adresse stable à un groupe de Pods (qui eux changent d'IP tout le temps).

L'Ingress : le routeur HTTP intelligent

L'Ingress gère le routage HTTP/HTTPS. C'est comme un reverse proxy.

Internet → [Ingress] → api.example.com → Service API
                    → web.example.com → Service Web

📁 Les Namespaces : l'isolation logique

Les namespaces permettent de séparer les ressources dans un cluster. Comme des dossiers dans un système de fichiers.

Cas d'usage :

• Séparer les environnements : dev, staging, production
• Séparer les équipes : team-a, team-b
• Séparer les projets

Caractéristiques importantes :

• Un Pod appartient à un seul namespace (pas plusieurs !)
• On peut définir des quotas par namespace (CPU, mémoire)
• Certaines ressources sont globales (Nodes, PersistentVolumes)

---

Partie 3 : Les commandes kubectl

kubectl est votre télécommande pour Kubernetes. Voici les commandes essentielles.

📋 Lister les ressources

kubectl get pods -n production -l app=api --watch

Décortiquons :

• get pods : liste les pods
• -n production : dans le namespace "production"
• -l app=api : filtrés par le label app=api
• --watch : reste à l'écoute des changements (temps réel)

📜 Voir les logs

C'est la question piège du quiz !

kubectl logs <pod-name>

Variantes utiles :

kubectl logs my-pod                    # Logs basiques
kubectl logs my-pod -c my-container    # Si plusieurs conteneurs
kubectl logs -f my-pod                 # Follow (temps réel)
kubectl logs --tail=100 my-pod         # Les 100 dernières lignes

🔍 Autres commandes utiles

# Détails complets d'un pod (événements, erreurs...)
kubectl describe pod my-pod

# Ouvrir un shell dans un conteneur
kubectl exec -it my-pod -- /bin/sh

# Appliquer un fichier YAML
kubectl apply -f deployment.yaml

# Supprimer une ressource
kubectl delete pod my-pod

---

Partie 4 : Sécurité et bonnes pratiques

🛡️ Les bases de la sécurité

🔄 Stratégies de mise à jour

📊 Health Checks

Kubernetes peut vérifier automatiquement si votre app va bien :

livenessProbe:      # "Es-tu vivant ?" → sinon restart
  httpGet:
    path: /health
    port: 8080
readinessProbe:     # "Es-tu prêt ?" → sinon pas de trafic
  httpGet:
    path: /ready
    port: 8080

---

📋 Checklist avant le quiz

Cochez ce que vous maîtrisez :

Docker

• Je sais qu'un conteneur partage le noyau de l'hôte (vs VM avec son propre OS)
• Je sais que le Dockerfile définit comment construire une image
• Je comprends les options de docker run (-d, -p, -v, --name)
• Je sais que volumes et images persistent après suppression d'un conteneur
• Je sais qu'une image est immuable

Kubernetes Architecture

• Je sais que Kubernetes orchestre des conteneurs (ne les remplace pas)
• Je connais les composants du Control Plane : apiserver, etcd, scheduler
• Je sais que kubelet est sur les Worker Nodes, pas le Control Plane

Objets Kubernetes

• Je sais que le Pod est l'unité minimale (pas le conteneur)
• Je sais qu'un Pod peut avoir plusieurs conteneurs (réseau + stockage partagés)
• Je comprends qu'un Deployment maintient X réplicas
• Je distingue ConfigMap (non sensible) et Secret (sensible)
• Je sais exposer avec Service LoadBalancer ou Ingress
• Je comprends les namespaces (isolation, quotas, un seul par pod)

Commandes

• Je sais lire une commande kubectl get pods -n ... -l ... --watch
• Je connais kubectl logs <pod> pour voir les logs

---

🎯 Points clés (mémo rapide)

➡️ Prochaine étape

Vous êtes prêt ! Passez le quiz prérequis pour valider vos connaissances.

Bonne chance ! 🍀