CKAD - Applications et Workloads

🎯 Objectifs

Dans ce module, tu vas :

✅ Comprendre les différences entre Pods, Deployments et StatefulSets
✅ Créer et mettre à jour des Deployments
✅ Maîtriser les stratégies de rolling update
✅ Effectuer des rollbacks
✅ Configurer les health checks (liveness, readiness)
✅ Déboguer les applications qui ne marchent pas

📋 Prérequis

Module Kubernetes - Intermédiaire complété
Module CKAD - Préparation lu
À l'aise avec les commandes kubectl basiques

📖 Pourquoi ce module ?

La CKAD est une certification pour développeurs, pas administrateurs. Ce que tu dois maîtriser ce n'est pas comment installer Kubernetes, c'est comment y déployer tes applications de manière fiable et sécurisée.

Ce module couvre les Applications et Workloads - 20% de la note CKAD.

🔧 Pods vs Deployments vs StatefulSets

Pods

Un Pod est l'unité de base dans Kubernetes. C'est un conteneur (ou plusieurs) qui tournent ensemble.

Mais en production, tu ne crées jamais de Pod directement. Pourquoi ? Parce que les Pods sont éphémères - si un Pod crash, il disparaît.

bash

# Créer un Pod (plutôt pour des tests)
k run nginx --image=nginx

Deployments

Un Deployment est ce que tu utilises pour les applications sans état (stateless). Il gère les Pods pour toi :

Si un Pod crash, le Deployment en crée un nouveau
Tu peux changer l'image facilement
Il gère les mises à jour en douceur (rolling update)

bash

# Créer un Deployment
k create deployment webapp --image=myapp:1.0 --replicas=3

StatefulSets

Un StatefulSet est pour les applications qui ont besoin de persistance : bases de données, queues, caches.

Les StatefulSets garantissent :

Des noms stables (pod-0, pod-1, etc.)
Du stockage persistant
Un ordre de démarrage prévisible

yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

🚀 Créer et mettre à jour des Deployments

Créer un Deployment

Mode impératif (rapide) :

bash

# Déployer une app simple
k create deployment myapp --image=myapp:1.0 --replicas=3

# Générer le YAML
k create deployment myapp --image=myapp:1.0 --replicas=3 --dry-run=client -o yaml > deploy.yaml

Mode déclaratif (recommandé pour la CKAD) :

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        ports:
        - containerPort: 8080

Mettre à jour l'image

Quand tu déploies une nouvelle version, change l'image dans le Deployment. Kubernetes gère le reste.

bash

# Changer l'image
k set image deployment/myapp myapp=myapp:2.0

# Ou éditer directement
k edit deployment myapp
# Puis changer l'image dans l'éditeur

Voir l'historique et les mises à jour

bash

# Voir l'état du rollout (en cours)
k rollout status deployment/myapp
Waiting for deployment "myapp" to rollout.
Waiting for deployment "myapp" to rollout.
deployment "myapp" successfully rolled out

# Voir l'historique
k rollout history deployment/myapp
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

# Voir les détails d'une révision
k rollout history deployment/myapp --revision=1

# Revenir à la révision précédente
k rollout undo deployment/myapp
k rollout undo deployment/myapp --to-revision=1

🔄 Stratégies de mise à jour

Kubernetes offre deux stratégies pour mettre à jour les Deployments.

RollingUpdate (défaut)

Les anciens Pods sont arrêtés graduellement, et les nouveaux démarrent à leur place. Zéro downtime.

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # +1 pod temporaire pendant la mise à jour
      maxUnavailable: 0    # 0 pods en arrêt (zéro downtime)
  template:
    # ...

Avec ces paramètres :

Tu as au maximum 4 pods temporairement (3 + 1 en surge)
Toutes les requêtes continuent d'être servies

Recreate

Tous les anciens Pods sont arrêtés d'un coup, puis les nouveaux démarrent. Il y a un downtime.

yaml

strategy:
  type: Recreate

À utiliser seulement quand tu ne peux pas avoir deux versions en même temps (rare).

💓 Health Checks

Les health checks permettent à Kubernetes de savoir si ton application fonctionne correctement.

Readiness Probe

Dis à Kubernetes "this pod is ready to accept traffic". Tant qu'elle échoue, le pod n'est pas envoyé dans le Service.

yaml

spec:
  containers:
  - name: myapp
    image: myapp:1.0
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 3

Liveness Probe

Dis à Kubernetes "if this fails, restart the pod". C'est pour détecter les applications figées.

yaml

spec:
  containers:
  - name: myapp
    image: myapp:1.0
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Types de probes

bash

# HTTP GET
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

# TCP Socket
readinessProbe:
  tcpSocket:
    port: 5432

# Exec (commande)
readinessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - "curl localhost:8080/health"

🐛 Déboguer les applications

Quand quelque chose ne marche pas, Kubernetes te donne les outils pour investiguer.

Voir l'état des Pods

bash

# Voir les pods et leur statut
k get pods
k get pods -o wide

# Status courants
# Running : ok
# Pending : en attente (image pull, ressources)
# ImagePullBackOff : impossible de télécharger l'image
# CrashLoopBackOff : l'app crash au démarrage

Voir les événements et erreurs

bash

# Voir les événements pour un pod
k describe pod myapp-xyz

# Output intéressant :
# Events:
#   Type    Reason     Message
#   ----    ------     -------
#   Normal  Scheduled  Successfully assigned default/myapp-xyz
#   Normal  Pulled     Container image pulled
#   Normal  Started    Started container myapp

Lire les logs

bash

# Logs du pod
k logs pod/myapp-xyz

# Logs avec temps réel
k logs -f pod/myapp-xyz

# Logs des 100 dernières lignes
k logs pod/myapp-xyz --tail=100

# Logs d'un deployment (tous les pods)
k logs -l app=myapp --tail=50 -f

Exécuter une commande dans le pod

bash

# Ouvrir un shell
k exec -it pod/myapp-xyz -- /bin/sh

# Exécuter une commande unique
k exec pod/myapp-xyz -- curl localhost:8080

# Debugging réseau
k exec pod/myapp-xyz -- nslookup myservice.default.svc.cluster.local

🔧 Exemple complet : Déployer une app avec health checks

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  port: "8080"

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        ports:
        - containerPort: 8080
        env:
        - name: PORT
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: port
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 3
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi

---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

📊 Résumé

Concept	Utilisation	Quand
Pod	Unité de base	Tests, débugging
Deployment	Applications stateless	Presque toujours
StatefulSet	Applications avec état	Bases de données, queues
RollingUpdate	Mise à jour progressive	Par défaut
Recreate	Remplacer tout d'un coup	Jamais en prod
Readiness Probe	Application prête ?	Toujours
Liveness Probe	Application vivante ?	Seulement si nécessaire

🚀 Prochaines Étapes

CKAD : Configuration et Sécurité - ConfigMaps, Secrets et RBAC
CKAD : Services et Networking - Services, Ingress et DNS
CKAD : Volumes et Persistance - Stockage et données persistantes

CKAD - Applications et Workloads

🎯 Objectifs

Dans ce module, tu vas :

✅ Comprendre les différences entre Pods, Deployments et StatefulSets
✅ Créer et mettre à jour des Deployments
✅ Maîtriser les stratégies de rolling update
✅ Effectuer des rollbacks
✅ Configurer les health checks (liveness, readiness)
✅ Déboguer les applications qui ne marchent pas

📋 Prérequis

Module Kubernetes - Intermédiaire complété
Module CKAD - Préparation lu
À l'aise avec les commandes kubectl basiques

📖 Pourquoi ce module ?

Ce module couvre les Applications et Workloads - 20% de la note CKAD.

🔧 Pods vs Deployments vs StatefulSets

Pods

Un Pod est l'unité de base dans Kubernetes. C'est un conteneur (ou plusieurs) qui tournent ensemble.

Mais en production, tu ne crées jamais de Pod directement. Pourquoi ? Parce que les Pods sont éphémères - si un Pod crash, il disparaît.

bash

# Créer un Pod (plutôt pour des tests)
k run nginx --image=nginx

Deployments

Un Deployment est ce que tu utilises pour les applications sans état (stateless). Il gère les Pods pour toi :

Si un Pod crash, le Deployment en crée un nouveau
Tu peux changer l'image facilement
Il gère les mises à jour en douceur (rolling update)

bash

# Créer un Deployment
k create deployment webapp --image=myapp:1.0 --replicas=3

StatefulSets

Un StatefulSet est pour les applications qui ont besoin de persistance : bases de données, queues, caches.

Les StatefulSets garantissent :

Des noms stables (pod-0, pod-1, etc.)
Du stockage persistant
Un ordre de démarrage prévisible

yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

🚀 Créer et mettre à jour des Deployments

Créer un Deployment

Mode impératif (rapide) :

bash

# Déployer une app simple
k create deployment myapp --image=myapp:1.0 --replicas=3

# Générer le YAML
k create deployment myapp --image=myapp:1.0 --replicas=3 --dry-run=client -o yaml > deploy.yaml

Mode déclaratif (recommandé pour la CKAD) :

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        ports:
        - containerPort: 8080

Mettre à jour l'image

Quand tu déploies une nouvelle version, change l'image dans le Deployment. Kubernetes gère le reste.

bash

# Changer l'image
k set image deployment/myapp myapp=myapp:2.0

# Ou éditer directement
k edit deployment myapp
# Puis changer l'image dans l'éditeur

Voir l'historique et les mises à jour

bash

# Voir l'état du rollout (en cours)
k rollout status deployment/myapp
Waiting for deployment "myapp" to rollout.
Waiting for deployment "myapp" to rollout.
deployment "myapp" successfully rolled out

# Voir l'historique
k rollout history deployment/myapp
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

# Voir les détails d'une révision
k rollout history deployment/myapp --revision=1

# Revenir à la révision précédente
k rollout undo deployment/myapp
k rollout undo deployment/myapp --to-revision=1

🔄 Stratégies de mise à jour

Kubernetes offre deux stratégies pour mettre à jour les Deployments.

RollingUpdate (défaut)

Les anciens Pods sont arrêtés graduellement, et les nouveaux démarrent à leur place. Zéro downtime.

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # +1 pod temporaire pendant la mise à jour
      maxUnavailable: 0    # 0 pods en arrêt (zéro downtime)
  template:
    # ...

Avec ces paramètres :

Tu as au maximum 4 pods temporairement (3 + 1 en surge)
Toutes les requêtes continuent d'être servies

Recreate

Tous les anciens Pods sont arrêtés d'un coup, puis les nouveaux démarrent. Il y a un downtime.

yaml

strategy:
  type: Recreate

À utiliser seulement quand tu ne peux pas avoir deux versions en même temps (rare).

💓 Health Checks

Les health checks permettent à Kubernetes de savoir si ton application fonctionne correctement.

Readiness Probe

Dis à Kubernetes "this pod is ready to accept traffic". Tant qu'elle échoue, le pod n'est pas envoyé dans le Service.

yaml

spec:
  containers:
  - name: myapp
    image: myapp:1.0
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 3

Liveness Probe

Dis à Kubernetes "if this fails, restart the pod". C'est pour détecter les applications figées.

yaml

spec:
  containers:
  - name: myapp
    image: myapp:1.0
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

Types de probes

bash

# HTTP GET
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

# TCP Socket
readinessProbe:
  tcpSocket:
    port: 5432

# Exec (commande)
readinessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - "curl localhost:8080/health"

🐛 Déboguer les applications

Quand quelque chose ne marche pas, Kubernetes te donne les outils pour investiguer.

Voir l'état des Pods

bash

# Voir les pods et leur statut
k get pods
k get pods -o wide

# Status courants
# Running : ok
# Pending : en attente (image pull, ressources)
# ImagePullBackOff : impossible de télécharger l'image
# CrashLoopBackOff : l'app crash au démarrage

Voir les événements et erreurs

bash

# Voir les événements pour un pod
k describe pod myapp-xyz

# Output intéressant :
# Events:
#   Type    Reason     Message
#   ----    ------     -------
#   Normal  Scheduled  Successfully assigned default/myapp-xyz
#   Normal  Pulled     Container image pulled
#   Normal  Started    Started container myapp

Lire les logs

bash

# Logs du pod
k logs pod/myapp-xyz

# Logs avec temps réel
k logs -f pod/myapp-xyz

# Logs des 100 dernières lignes
k logs pod/myapp-xyz --tail=100

# Logs d'un deployment (tous les pods)
k logs -l app=myapp --tail=50 -f

Exécuter une commande dans le pod

bash

# Ouvrir un shell
k exec -it pod/myapp-xyz -- /bin/sh

# Exécuter une commande unique
k exec pod/myapp-xyz -- curl localhost:8080

# Debugging réseau
k exec pod/myapp-xyz -- nslookup myservice.default.svc.cluster.local

🔧 Exemple complet : Déployer une app avec health checks

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  port: "8080"

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0
        ports:
        - containerPort: 8080
        env:
        - name: PORT
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: port
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 3
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi

---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

📊 Résumé

Concept	Utilisation	Quand
Pod	Unité de base	Tests, débugging
Deployment	Applications stateless	Presque toujours
StatefulSet	Applications avec état	Bases de données, queues
RollingUpdate	Mise à jour progressive	Par défaut
Recreate	Remplacer tout d'un coup	Jamais en prod
Readiness Probe	Application prête ?	Toujours
Liveness Probe	Application vivante ?	Seulement si nécessaire

🚀 Prochaines Étapes

CKAD : Configuration et Sécurité - ConfigMaps, Secrets et RBAC
CKAD : Services et Networking - Services, Ingress et DNS
CKAD : Volumes et Persistance - Stockage et données persistantes