K8S Master Course — Terminal Edition

🏠

// Introduction

Kubernetes — Pourquoi ?

Comprendre le problème avant la solution

💡 C'est quoi Kubernetes ?

Imagine que tu gères une flotte de serveurs qui font tourner des applications. Sans outil, c'est du chaos : un serveur tombe ? L'app est morte. Le trafic monte ? Tu dois manuellement en ajouter.

Kubernetes (K8S) est un système qui orchestre automatiquement tout ça. Il sait où déployer chaque composant, le redémarre si ça plante, et adapte les ressources à la demande. C'est le "chef d'orchestre" de tes containers.

🎯 Analogie : Kubernetes, c'est comme un manager d'hôtel. Il assigne les chambres (serveurs) aux clients (applications), sait combien de chambres sont disponibles, en ouvre de nouvelles si l'hôtel est plein, et remplace une chambre hors service automatiquement.

🐳

Container Runtime

K8S utilise Docker ou containerd pour faire tourner tes apps dans des containers isolés.

🔄

Auto-guérison

Un app crash ? K8S la relance automatiquement. Zéro intervention manuelle.

📈

Scale auto

Trop de trafic ? K8S duplique ton app. Trafic faible ? Il réduit les ressources.

🌍

Multi-cloud

AWS, GCP, Azure, ou ton datacenter : K8S fonctionne partout de la même façon.

💡 K8S pour les développeurs

En tant que dev, K8S te permet de définir l'état désiré de ton application en YAML. Le cluster s'occupe de maintenir cet état. Tu décris ce que tu veux, pas comment le faire — c'est le paradigme déclaratif.

deployment.yaml

# Tu décris l'état désiré :
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3 # 3 instances
template:
spec:
containers:
- name: app
image: my-app:v2.0
# K8S fait le reste ✓

🔑 Paradigme déclaratif : Tu ne dis pas "lance 3 containers sur ces 2 serveurs". Tu dis "je veux 3 replicas de cette app". K8S réconcilie en permanence l'état réel avec l'état désiré.

💡 K8S en production — vision Ops

K8S remplace des années de scripts Ansible + systemd + load balancers manuels. Son control plane (API server, etcd, scheduler, controller manager) supervise le data plane (nœuds worker + kubelet + kube-proxy). La séparation control/data est fondamentale pour la haute disponibilité.

🧠

etcd

Base de données distribuée clé/valeur. Source of truth du cluster. HA critique.

🔌

API Server

Point d'entrée de tout le control plane. Expose l'API REST K8S. Authentification TLS.

📅

Scheduler

Décide sur quel nœud placer chaque Pod selon les ressources et contraintes.

⚙️

Controller Manager

Boucle de contrôle qui réconcilie l'état réel → état désiré en continu.

🏗️

// Module 02

Architecture K8S

Control Plane · Worker Nodes · Composants

🏗️ Vue d'ensemble du cluster

Un cluster K8S est composé de deux types de nœuds : le Control Plane (cerveau) et les Worker Nodes (muscles). Chaque composant a un rôle précis.

🔷 Control Plane

API Server
:6443

etcd
state store

Scheduler
pod placement

Controller Mgr
reconciliation

↕ kubectl / kubelet

🟢 Worker Nodes

Node-1

Pod
nginx

Pod
api

kubelet · kube-proxy

Node-2

Pod
api

Pod
db

kubelet · kube-proxy

Node-3

Pod
api

Pod
cache

kubelet · kube-proxy

🧠

kube-apiserver

Frontend du control plane. Valide et configure les objets (pods, services…). Toutes les commandes kubectl passent par là.

🗃️

etcd

Stockage distribué clé/valeur consistant et hautement disponible. Contient tout l'état du cluster. Sauvegarder etcd = sauvegarder le cluster.

📅

kube-scheduler

Surveille les Pods sans nœud assigné et sélectionne le meilleur nœud selon CPU, RAM, affinités, taints.

⚙️

kube-controller-manager

Exécute les boucles de contrôle : Node Controller, Replication Controller, Endpoints, Service Account…

🤖

kubelet

Agent sur chaque nœud. S'assure que les containers décrits dans les PodSpecs tournent et sont sains.

🔀

kube-proxy

Maintient les règles réseau sur les nœuds pour router le trafic vers les bons Pods (iptables/IPVS).

kubectl — explorer le cluster

$kubectl get nodes

NAME STATUS ROLES AGE VERSION
node-1 Ready master 10d v1.29.0
node-2 Ready worker 10d v1.29.0
node-3 Ready worker 10d v1.29.0

$kubectl get nodes -o wide

# Affiche IPs, OS, container runtime...

$kubectl cluster-info

Kubernetes control plane running at https://192.168.1.10:6443
CoreDNS running at https://192.168.1.10:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

$kubectl get componentstatuses

scheduler Healthy
controller-manager Healthy
etcd-0 Healthy

⚡

// Module 03

Features Explorer

Clique sur une feature pour l'explorer

Core Feature Extended Feature

▷ Clique sur une feature pour voir son explication détaillée

📦

// Module 04

Pods & Deployments

L'unité de base de Kubernetes

📦 Pod — L'unité de base

Un Pod est le plus petit objet déployable dans K8S. Il contient un ou plusieurs containers qui partagent le même réseau et le même stockage. Pense à un Pod comme à un "appartement" où vivent tes containers.

🏠 Analogie : Si le container est une personne, le Pod est l'appartement. Plusieurs personnes (containers) peuvent vivre dans le même appartement (Pod) et partager la cuisine (volumes) et l'adresse (IP). Le Deployment est l'immeuble qui gère plusieurs appartements identiques.

📦

Pod

1+ containers, IP partagée, volumes partagés. Éphémère par nature.

🔄

ReplicaSet

Maintient N copies identiques d'un Pod. Remplace les pods morts.

🚀

Deployment

Gère les ReplicaSets. Permet les rolling updates et rollbacks.

🗂️

Namespace

Isolation logique. Organise les ressources par équipe ou environnement.

🚀 Rolling Update & Rollback

Un Deployment gère les mises à jour sans downtime. La stratégie RollingUpdate remplace progressivement les anciens Pods par les nouveaux. En cas de problème, kubectl rollout undo revient à la version précédente instantanément.

Rolling Update workflow

# 1. Déployer une app

$kubectl create deployment my-app --image=nginx:1.19 --replicas=3

deployment.apps/my-app created

# 2. Mettre à jour l'image (rolling update)

$kubectl set image deployment/my-app nginx=nginx:1.21

deployment.apps/my-app image updated

# 3. Surveiller le déploiement

$kubectl rollout status deployment/my-app

Waiting for deployment "my-app" rollout to finish...
deployment "my-app" successfully rolled out

# 4. Rollback si problème

$kubectl rollout undo deployment/my-app

deployment.apps/my-app rolled back

⚙️ Resource Requests & Limits

En prod, toujours définir des requests (ressources garanties) et limits (plafond) pour chaque container. Sans ça, un pod peut consommer tous les CPUs d'un nœud et provoquer un noisy neighbor effect.

resources.yaml — production-grade

spec:
containers:
- name: app
image: my-app:v2
resources:
requests:
memory: "256Mi" # Garanti
cpu: "250m" # 0.25 CPU
limits:
memory: "512Mi" # Plafond
cpu: "500m" # OOMKill si dépassé
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
readinessProbe:
httpGet:
path: /ready
port: 8080

🌐

// Module 05

Services & Réseau

Exposer et connecter les Pods

🌐 Pourquoi les Services ?

Les Pods sont éphémères — leur IP change à chaque redémarrage. Un Service est une abstraction stable qui expose un ensemble de Pods via une IP virtuelle fixe (ClusterIP) et un nom DNS stable.

🔵

ClusterIP

IP interne uniquement. Communication entre Pods dans le cluster. Type par défaut.

🟡

NodePort

Expose un port sur chaque nœud (30000-32767). Accessible depuis l'extérieur.

🟢

LoadBalancer

Crée un load balancer cloud (AWS ELB, GCP LB). IP externe automatique.

🔀

Ingress

Routage HTTP/S. Règles par hostname et path. TLS termination. Un seul LB pour tout.

Services — commandes essentielles

# Exposer un deployment en ClusterIP

$kubectl expose deployment my-app --port=80 --target-port=8080

service/my-app exposed

# Exposer en NodePort (accès externe)

$kubectl expose deployment my-app --type=NodePort --port=80

# Lister les services

$kubectl get services

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-app NodePort 10.96.128.42 <none> 80:31245/TCP 2m

# DNS interne — chaque service a un nom résolvable

$kubectl exec -it my-pod -- curl http://my-app.default.svc.cluster.local

📞 Analogie : Le Service est comme un standard téléphonique. Tu appelles un seul numéro (ClusterIP) et le standard redirige l'appel vers le bon agent disponible (Pod). Peu importe si un agent est absent (Pod mort), les autres prennent le relais.

💾

// Module 06

Storage & Volumes

Persistence des données dans K8S

💾 Le problème de persistence

Les containers sont stateless par design — leur système de fichiers est effacé au redémarrage. Pour les bases de données, fichiers uploadés, etc., K8S propose un système de Volumes avec différents niveaux d'abstraction.

📁

Volume

Stockage attaché à un Pod. Survit aux redémarrages du container mais pas du Pod.

💽

PersistentVolume (PV)

Ressource de stockage dans le cluster, provisionnée par un admin ou dynamiquement.

📋

PersistentVolumeClaim (PVC)

Requête de stockage par un utilisateur. Lie un Pod à un PV.

⚡

StorageClass

Définit le type de stockage (SSD, HDD, NFS). Provisionnement dynamique automatique.

PVC — réclamer du stockage

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-storage
spec:
storageClassName: standard
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 10Gi

$kubectl apply -f pvc.yaml

persistentvolumeclaim/my-storage created

$kubectl get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES
my-storage Bound pvc-abc123-xyz456 10Gi RWO

🔒

// Module 07

ConfigMaps & Secrets

Séparer la config du code

🔒 Principe de séparation config/code

Ne jamais hard-coder la configuration dans une image Docker. K8S propose deux objets : ConfigMap pour la config non-sensible (URLs, feature flags) et Secret pour les données sensibles (passwords, tokens, clés TLS).

📝

ConfigMap

Données de config en clair. Injectables comme env vars ou volumes. Pas pour les secrets.

🔐

Secret

Données encodées en base64. Stockées chiffrées dans etcd (avec EncryptionConfig). RBAC recommandé.

ConfigMap & Secret

# Créer un ConfigMap

$kubectl create configmap app-config --from-literal=DB_HOST=postgres --from-literal=LOG_LEVEL=info

configmap/app-config created

# Créer un Secret

$kubectl create secret generic db-secret --from-literal=DB_PASS=s3cur3!

secret/db-secret created

# Injecter en env vars dans un Pod env:
- name: DB_HOST
valueFrom:
configMapKeyRef:
name: app-config
key: DB_HOST
- name: DB_PASS
valueFrom:
secretKeyRef:
name: db-secret
key: DB_PASS

📦 Règle d'or : Si ça va sur GitHub → ConfigMap. Si ça ne doit JAMAIS aller sur GitHub → Secret. Les Secrets ne s'affichent pas dans les logs ni les describe par défaut.

⚖️

// Module 08

Scaling & Self-healing

Haute disponibilité & élasticité

⚖️ Les 3 dimensions du scaling K8S

HPA (Horizontal Pod Autoscaler) → plus de replicas selon la charge CPU/mémoire.
VPA (Vertical Pod Autoscaler) → ajuste requests/limits d'un Pod.
Cluster Autoscaler → ajoute/supprime des nœuds selon la pression du cluster.

📈

HPA

Scale le nombre de Pods. Déclenché par CPU, mémoire ou métriques custom (Prometheus).

🔄

Self-healing

Liveness probe échouée → Pod redémarré. Readiness probe échouée → retiré du LB.

🏥

Health Checks

livenessProbe, readinessProbe, startupProbe. HTTP, TCP, ou commande exec.

🔀

Bin Packing

Le scheduler optimise le placement des Pods pour maximiser l'utilisation des nœuds.

Scaling — commandes

# Scale manuel

$kubectl scale deployment my-app --replicas=5

deployment.apps/my-app scaled

# HPA — autoscale selon CPU

$kubectl autoscale deployment my-app --min=2 --max=10 --cpu-percent=70

horizontalpodautoscaler.autoscaling/my-app autoscaled

# Voir le HPA en action

$kubectl get hpa

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
my-app Deployment/my-app 45%/70% 2 10 3

# Vérifier un pod qui redémarre (self-healing)

$kubectl get pods --watch

my-app-abc CrashLoopBackOff 5 2m
my-app-abc Running 0 10s ← redémarré auto

⌨️

// Module 09

Terminal Kubectl

Simulateur interactif + Cheat Sheet complète

⌨️ kubectl simulator — cluster: minikube

Kubernetes Terminal Simulator v1.0
Tape une commande kubectl ci-dessous. Exemples : get pods, get nodes, get services
─────────────────────────────────────────

kubectl $

💡 Commandes supportées : get pods/nodes/services/deployments/hpa/pvc/namespaces/configmaps/secrets · describe · logs · version · cluster-info · apply · delete · scale · rollout · exec · top

📋 Cheat Sheet — Commandes essentielles

Commande	Description	Exemple
kubectl get <resource>	Lister des ressources	kubectl get pods -n prod
kubectl describe <type> <name>	Détails d'une ressource	kubectl describe pod my-pod
kubectl apply -f <file>	Créer/mettre à jour depuis YAML	kubectl apply -f deploy.yaml
kubectl delete -f <file>	Supprimer depuis YAML	kubectl delete -f svc.yaml
kubectl logs <pod>	Voir les logs d'un pod	kubectl logs my-pod -f
kubectl exec -it <pod> -- bash	Shell interactif dans un pod	kubectl exec -it my-pod -- sh
kubectl scale deployment <n>	Scaler un deployment	kubectl scale deploy/api --replicas=5
kubectl rollout undo <deploy>	Rollback d'un déploiement	kubectl rollout undo deploy/api
kubectl top pods	Utilisation CPU/RAM des pods	kubectl top pods --sort-by=cpu
kubectl port-forward <pod> <port>	Tunnel local vers un pod	kubectl port-forward pod/api 8080:8080
kubectl config use-context <ctx>	Changer de cluster/contexte	kubectl config use-context prod
kubectl get events --sort-by=.metadata.creationTimestamp	Historique des événements	-n kube-system

🧠

// Module 10

Quiz Final

Teste ta maîtrise de Kubernetes

Score actuel

0 / 10