1. Le Pod #
L'unité d'exécution.
Anatomie d'un pod #
Un pod regroupe un ou plusieurs conteneurs qui partagent le même réseau (une IP) et les mêmes volumes. On ne crée presque jamais de pod seul : on passe par un contrôleur (Deployment, StatefulSet...) qui le recrée en cas de panne.
apiVersion: v1
kind: Pod
metadata:
name: web
labels: { app: web }
spec:
containers:
- name: nginx
image: nginx:1.27
ports: [{ containerPort: 80 }]
resources:
requests: { cpu: 100m, memory: 128Mi } # réservé pour le scheduling
limits: { cpu: 500m, memory: 256Mi } # plafond (OOMKill si dépassé pour la mémoire)
env:
- { name: APP_ENV, value: prod }kubectl apply -f pod.yaml
kubectl get pod web -o wide
kubectl describe pod web
kubectl delete pod web2. Deployment et ReplicaSet #
Réplicas et mises à jour progressives.
Un Deployment complet #
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
revisionHistoryLimit: 5
selector:
matchLabels: { app: web }
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 1 pod de plus que prévu pendant la mise à jour
maxUnavailable: 0 # jamais moins de 3 pods disponibles
template:
metadata:
labels: { app: web }
spec:
containers:
- name: nginx
image: nginx:1.27
readinessProbe: { httpGet: { path: /, port: 80 }, periodSeconds: 5 }
resources:
requests: { cpu: 100m, memory: 128Mi }
limits: { memory: 256Mi }kubectl apply -f deploy.yaml
kubectl rollout status deployment/web
kubectl set image deployment/web nginx=nginx:1.27.2 # déclenche une mise à jour progressive
kubectl get rs -l app=web # ancien et nouveau ReplicaSet
kubectl rollout undo deployment/webErreur Courante : Ne jamais déployer avec le tag latest : le même manifeste peut produire des déploiements différents et le retour arrière devient impossible. Utilisez des versions ou des digests.Stratégies de déploiement #
| Stratégie | Comportement | Quand l'utiliser |
|---|---|---|
| RollingUpdate | Remplace les pods progressivement | Par défaut, sans interruption |
| Recreate | Supprime tout puis recrée | Applications ne supportant pas deux versions en parallèle |
| Blue/Green, Canary | Via Service/Ingress ou Argo Rollouts / Flagger | Déploiements contrôlés |
3. Les autres contrôleurs #
StatefulSet, DaemonSet, Job.
Choisir le bon workload #
| Workload | Usage | Particularité |
|---|---|---|
| Deployment | Applications sans état | Pods interchangeables |
| StatefulSet | Bases de données, files | Identité stable (db-0), volume par pod, démarrage ordonné |
| DaemonSet | Agents (logs, métriques) | Un pod par nœud |
| Job / CronJob | Tâches finies ou planifiées | S'arrête à la fin |
kubectl create job migration --image=busybox -- sh -c "echo migration; sleep 5"
kubectl create cronjob sauvegarde --image=busybox --schedule="0 2 * * *" -- sh -c "echo backup"
kubectl get jobs,cronjobs
kubectl logs job/migration