Module 2 – Workloads fondamentaux et controllers

Nous attaquons maintenant le nerf du sujet : les workloads. Vous allez apprendre à choisir le bon controller, à gérer les mises à jour et à orchestrer du batch.

Objectifs

• Savoir quand utiliser Pod, ReplicaSet, Deployment, StatefulSet, DaemonSet ou Job.
• Maîtriser les opérations courantes : scaling, rolling update, rollback, pauses.
• Automatiser des traitements planifiés avec CronJob.

1. Pod vs controllers

Un Pod isolé ne redémarre pas tout seul si le nœud tombe. Utilisez toujours un controller pour gérer la disponibilité.

2. Déployer et mettre à jour

Créons un Deployment webapp avec trois réplicas.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: staging
spec:
  replicas: 3
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: webapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: web
          image: ghcr.io/acme/web:1.0.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 5
          resources:
            requests:
              cpu: 100m
              memory: 128Mi

Commandes indispensables :

kubectl apply -f deployment-webapp.yaml
kubectl rollout status deployment/webapp
kubectl set image deployment/webapp web=ghcr.io/acme/web:1.1.0
kubectl rollout history deployment/webapp
kubectl rollout undo deployment/webapp --to-revision=1
kubectl scale deployment/webapp --replicas=5

3. Cas spécifiques

• DaemonSet : idéal pour node-exporter, fluent-bit, CNI. Exemple minimal :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
        - name: exporter
          image: quay.io/prometheus/node-exporter:v1.6.1
          resources:
            requests:
              cpu: 50m
          securityContext:
            privileged: true

• StatefulSet : utilisez un Headless Service (clusterIP: None) et un volumeClaimTemplates. Voir module 4.

4. Jobs et CronJobs

Un Job s’assure qu’un Pod particulier termine avec succès.

apiVersion: batch/v1
kind: Job
metadata:
  name: report
spec:
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - name: report
          image: alpine
          command: ["/bin/sh", "-c", "generate-report.sh"]
  backoffLimit: 3
  ttlSecondsAfterFinished: 3600

CronJob (planification toutes les 15 minutes) :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup
spec:
  schedule: "*/15 * * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: cleanup
              image: alpine:3.19
              command:
                - /bin/sh
                - -c
                - kubectl delete jobs --all -n sandbox

Attention : ne dépassez pas 100 jobs simultanés (quota par défaut) et surveillez les CronJobs qui prennent plus de temps que leur période.

5. Laboratoire guidé

1. Appliquez le Deployment webapp. Vérifiez kubectl get rs pour voir le ReplicaSet sous-jacent.
2. Déployez la version 1.1.0 et introduisez un bug (ex. readinessProbe sur port 9999). Observez le comportement du rollingUpdate.
3. Lancez kubectl rollout undo et notez le temps de restauration.
4. Créez un DaemonSet node-exporter et validez qu’il tourne sur chaque nœud.
5. Planifiez un CronJob de sauvegarde (kubectl create cronjob backup --image=bitnami/kubectl --schedule="0 2 * * *" -- /bin/sh -c 'echo backup'), puis inspectez kubectl get jobs.

6. Challenge avancé

• Mettre en place une stratégie Blue/Green avec deux Deployments (webapp-blue, webapp-green) et un Service sélecteur.
• Utiliser kubectl diff pour prévisualiser les changements avant un déploiement.
• Écrire un script Bash qui vérifie l’état d’un rollout toutes les 5 secondes et arrête la pipeline si le temps dépasse 5 minutes.

Solution détaillée

1. Déploiement & rollout
   Après kubectl apply -f deployment-webapp.yaml, vérifiez :

   kubectl get deploy webapp
   kubectl get rs -l app=webapp
   

   kubectl rollout status deployment/webapp doit afficher deployment "webapp" successfully rolled out.

2. Rolling update avec erreur
   kubectl set image deployment/webapp web=ghcr.io/acme/web:1.1.0-bug + readiness invalide → kubectl get pods montre des Pods en CrashLoopBackOff ou 1/2. Undo : kubectl rollout undo deployment/webapp.
3. DaemonSet
   kubectl apply -f daemonset-node-exporter.yaml puis kubectl get pods -n monitoring -o wide : un Pod par nœud.
4. Jobs/CronJobs
   kubectl apply -f job-report.yaml → kubectl get jobs doit passer en Completed.
   Pour le CronJob, après 15 minutes : kubectl get jobs liste les exécutions ; kubectl logs job/cleanup-xxxx confirme l’action.
5. Challenge blue/green
   Un Service sélecteur app=webapp, Deployment blue label color=blue, green color=green. Changer le label du Service pour basculer.

Pour valider, conservez : sortie de kubectl get deploy,rs,po avant/après rollback, description du DaemonSet et captures du CronJob.

Pièges rencontrés

• Oublier revisionHistoryLimit et accumuler les ReplicaSets (consomme des ressources).
• Mettre un CronJob en restartPolicy: Always : provoque une création infinie de Pods.
• Ignorer ttlSecondsAfterFinished : les Jobs terminés encombrent l’API.

Ressources

• Controllers
• Rolling updates
• CronJobs

Checklist

• ✅ Vous savez choisir le controller adapté à votre workload.
• ✅ Vous maîtrisez les commandes de déploiement, scale, rollout et rollback.
• ✅ Vous pouvez planifier une tâche récurrente avec CronJob et surveiller son historique.