Pods, Deployments, Jobs et patterns multi-conteneurs CKAD 2026

📍 Article principal du cluster : CKAD Certified Kubernetes Application Developer — guide pratique 2026

Ce tutoriel fait partie du cluster certification CKAD. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Les domaines 1 et 2 du syllabus CKAD pèsent à eux seuls 40 % de l’examen. Ils couvrent ce qu’un développeur fait au quotidien sur Kubernetes : créer un Pod, le déployer en plusieurs réplicas via Deployment, lancer une tâche unique avec Job, planifier des tâches récurrentes avec CronJob, et combiner plusieurs conteneurs dans un même Pod via les patterns sidecar et init container. Ce tutoriel pratique chaque pattern sur un cluster kind 1.35, avec génération de manifests par dry-run, edit live, et debug systématique. Toutes les commandes sont chronométrées pour vous donner une référence du temps à passer sur chaque type de tâche à l’examen.

Prérequis

• Cluster kind 1.35 fonctionnel issu du tutoriel précédent
• Alias `k=kubectl` et `$do=–dry-run=client -o yaml` configurés
• 40 minutes

Étape 1 — Créer un Pod simple par dry-run

La règle d’or de l’examen CKAD : ne jamais écrire un manifest YAML à la main. Toujours partir d’un dry-run, sauvegarder dans un fichier, puis éditer si besoin. Cette discipline sauve 30-40 secondes par tâche, soit potentiellement 10 minutes sur l’ensemble de l’examen.

k run nginx-pod --image=nginx:1.27 $do > pod.yaml
cat pod.yaml
k apply -f pod.yaml
k get pod nginx-pod
k describe pod nginx-pod | grep -E "Image|Status|Node"

La sortie de `k describe` doit montrer Status: Running, Image: nginx:1.27, et un Node assigné. Cette séquence — generate, apply, verify — est le cœur du flow CKAD. Internalisez-la jusqu’à pouvoir l’exécuter sans réfléchir.

Étape 2 — Créer un Deployment avec 3 réplicas

Le Deployment est le workload le plus utilisé en pratique. Il maintient un nombre désiré de réplicas via un ReplicaSet sous-jacent, et gère les rolling updates automatiquement.

k create deployment web --image=nginx:1.27 --replicas=3 $do > deploy.yaml
k apply -f deploy.yaml
k get deploy,rs,pods -l app=web
k rollout status deployment/web

Vous devez voir 1 Deployment, 1 ReplicaSet, et 3 Pods, tous étiquetés `app=web`. La commande `kubectl rollout status` attend que tous les Pods soient prêts — utile pour scripts CI/CD.

Étape 3 — Pratiquer un rolling update et un rollback

L’examen pose régulièrement des questions sur la stratégie de déploiement et le rollback. La pratique est essentielle pour ne pas hésiter sous pression.

k set image deployment/web nginx=nginx:1.28
k rollout status deployment/web
k rollout history deployment/web
k rollout undo deployment/web --to-revision=1
k describe deployment web | grep Image:

Vous devez voir l’image revenir à nginx:1.27 après le rollback. Le `–to-revision=N` est précieux : sans lui, `rollout undo` revient à la révision précédente uniquement.

Étape 4 — Pod multi-conteneurs avec sidecar

Le pattern sidecar est central en CKAD : un conteneur principal et un conteneur secondaire qui l’enrichit (logging, proxy, mise à jour de fichiers). Les deux partagent le même volume.

cat > sidecar-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: web-with-logger
spec:
  volumes:
  - name: shared-logs
    emptyDir: {}
  containers:
  - name: web
    image: nginx:1.27
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx
  - name: log-shipper
    image: busybox:1.37
    command: ["sh","-c","tail -F /logs/access.log"]
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
EOF

k apply -f sidecar-pod.yaml
k get pod web-with-logger
k logs web-with-logger -c log-shipper

Le conteneur log-shipper tourne en parallèle de nginx et lit le fichier d’accès via le volume partagé `shared-logs`. C’est exactement ce que font Fluent Bit ou Vector en production. À l’examen, vous serez probablement testé sur la lecture multi-conteneurs avec `-c `.

Étape 5 — Init container pour préparation

L’init container s’exécute avant les conteneurs principaux et doit se terminer avec exit 0 pour que les autres démarrent. Pattern classique : attendre une dépendance externe ou télécharger des données.

cat > init-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
  - name: wait-for-db
    image: busybox:1.37
    command: ["sh","-c","until nslookup my-db; do echo waiting; sleep 2; done"]
  containers:
  - name: app
    image: nginx:1.27
EOF

k apply -f init-pod.yaml
k get pod app-with-init -w

Le Pod restera en état `Init:0/1` tant que le service `my-db` n’existe pas — c’est volontaire pour démontrer le mécanisme. Tuez la commande avec Ctrl+C et nettoyez avec `k delete pod app-with-init $now`.

Étape 6 — Job pour exécution unique

Le Job exécute un Pod jusqu’à ce qu’il termine avec succès. Utilisé pour des batches : migration de base de données, import de données initiales, calcul ponctuel.

k create job pi-calc --image=perl:5.40 -- perl -Mbignum=bpi -wle "print bpi(200)" $do > job.yaml
k apply -f job.yaml
k get jobs
k logs job/pi-calc

La sortie affiche les 200 décimales de pi. Le Job reste en état Completed et n’est pas supprimé automatiquement — utile pour récupérer les logs. Pour nettoyer : `k delete job pi-calc`. Pour l’auto-cleanup, ajoutez `spec.ttlSecondsAfterFinished: 60` au manifest.

Étape 7 — CronJob pour planification récurrente

Le CronJob crée des Jobs selon une expression cron Linux. Indispensable pour les sauvegardes nocturnes, les rapports quotidiens, les nettoyages périodiques.

k create cronjob daily-report --image=busybox:1.37 --schedule="*/2 * * * *" -- echo "Daily report $(date)" $do > cron.yaml
k apply -f cron.yaml
k get cronjobs
sleep 130
k get jobs
k logs job/daily-report-XXXXX

Toutes les 2 minutes, un nouveau Job est créé. Le `schedule` suit la syntaxe cron classique : minutes, heures, jour du mois, mois, jour de la semaine. Le paramètre `successfulJobsHistoryLimit` (par défaut 3) contrôle combien de Jobs réussis sont conservés.

Étape 8 — Debug d’un Pod en erreur

Le debug est testé en domaine 5 mais c’est un réflexe à avoir dès le domaine 1. Les commandes essentielles à mémoriser sont `describe`, `logs`, `events`, `exec`.

k run broken --image=nginx:nonexistent-tag
sleep 10
k get pod broken
k describe pod broken | tail -20
k get events --sort-by=.lastTimestamp | tail -10
k delete pod broken $now

Vous verrez un Status: ImagePullBackOff dans `describe` et un événement « Failed to pull image » dans `events`. Cette procédure de debug systématique — describe d’abord, events ensuite — est ce qui vous fera gagner les questions de debug à l’examen.

Étape 9 — DaemonSet pour un Pod par nœud

Le DaemonSet déploie automatiquement un Pod sur chaque nœud du cluster. Cas d’usage : agents de logging (Fluent Bit), de monitoring (node-exporter), ou de réseau (CNI plugins).

cat > daemonset.yaml <<'EOF'
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
      - name: agent
        image: busybox:1.37
        command: ["sh","-c","while true; do echo collecting on $HOSTNAME; sleep 30; done"]
EOF

k apply -f daemonset.yaml
k get ds,pods -l app=log-agent -o wide

Sur le cluster kind à 3 nœuds, vous devez voir 3 Pods (1 par nœud) — sauf si la taint NoSchedule du control-plane bloque. Ajoutez les tolerations adéquates si vous voulez un Pod aussi sur le control-plane.

Comprendre la différence ReplicaSet vs Deployment vs StatefulSet

Une question récurrente à l’examen et un piège classique. ReplicaSet est la primitive de bas niveau qui maintient N réplicas — vous ne l’utilisez jamais directement, c’est le Deployment qui le gère. Deployment ajoute la stratégie de mise à jour rolling/recreate et le rollback historique. À utiliser pour 95 % des applications stateless. StatefulSet ajoute des identités stables (pod-0, pod-1, pod-2) et des PersistentVolumeClaims dédiés par réplica — indispensable pour bases de données, message queues, services qui requièrent un quorum.

Le piège : utiliser un Deployment pour MongoDB ou Postgres. Ça « marche » au démarrage, mais à la première mise à jour rolling, vous perdez l’identité de chaque réplica et le quorum casse. La règle simple : si vos Pods doivent connaître leur ordinal et conserver leur volume entre redémarrages, c’est un StatefulSet.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les développeurs Node.js et Python à Dakar et Abidjan qui passent au Kubernetes, le pattern le plus rentable est le couple Deployment + sidecar logging. Au lieu de gérer la stack ELK ou Loki dès le départ, vous packagez Fluent Bit en sidecar et envoyez les logs vers un service externe gratuit (BetterStack tier gratuit, Better Stack 1 Go/jour gratuit). Cette approche est compatible avec un cluster k3s sur Hostinger Cloud Startup à 9,99 USD/mois et permet d’opérer 8-12 microservices en production avec un budget infrastructure inférieur à 30 USD/mois.

Tutoriels frères

• Monter un cluster Kubernetes 1.35 CKAD avec kind
• ConfigMaps, Secrets et ServiceAccounts — sécuriser une application Kubernetes (à venir)

Pour aller plus loin

• 🔝 Retour au pilier : CKAD Certified Kubernetes Application Developer — guide pratique
• Documentation Workloads : kubernetes.io/docs/concepts/workloads
• Patterns sidecar / init / ambassador : kubernetes.io/docs/concepts/workloads/pods

FAQ

Quel est le délai entre Job et Pod ?
Aucun délai. Le Job crée immédiatement un ou plusieurs Pods selon `spec.parallelism`. Le Job reste en cours tant que les Pods n’ont pas tous terminé avec succès.

Peut-on changer le nombre de réplicas d’un Job ?
Oui via `spec.completions` (nombre total à atteindre) et `spec.parallelism` (nombre simultané). Pour les workloads parallélisables sans coordination, c’est très efficace.

Mots-clés secondaires : ckad pods workloads, deployment rolling update, sidecar pattern kubernetes, init container ckad, job cronjob examen, daemonset ckad