Pods et Deployments Kubernetes

Les Pods et Deployments sont les concepts les plus utilisés en Kubernetes. Ce guide explique comment ils fonctionnent et comment les utiliser.

Le Pod : Unité de Base

Qu'est-ce qu'un Pod ?

Un Pod est un groupe d'un ou plusieurs containers qui :

• Partagent le même réseau (même IP)
• Peuvent partager le même stockage
• Sont schedulés ensemble sur le même node

┌─────────────────────────────────────┐
│              POD                    │
│         IP: 10.244.1.5              │
│                                     │
│  ┌─────────────┐  ┌─────────────┐  │
│  │ Container 1 │  │ Container 2 │  │
│  │   (app)     │  │  (sidecar)  │  │
│  │  port 8080  │  │  port 9090  │  │
│  └─────────────┘  └─────────────┘  │
│         │              │           │
│         └──────┬───────┘           │
│                │                   │
│       localhost:8080               │
│       localhost:9090               │
│                                    │
│  ┌─────────────────────────────┐   │
│  │     Volume partagé          │   │
│  └─────────────────────────────┘   │
└─────────────────────────────────────┘

Créer un Pod (basique)

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  containers:
    - name: app
      image: nginx:1.25
      ports:
        - containerPort: 80

# Créer le pod
kubectl apply -f pod.yaml

# Vérifier
kubectl get pods
# NAME     READY   STATUS    RESTARTS   AGE
# my-app   1/1     Running   0          30s

# Supprimer
kubectl delete pod my-app

Pods Multi-Containers

Cas d'usage courants :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-logging
spec:
  containers:
    # Container principal
    - name: app
      image: my-app:v1
      volumeMounts:
        - name: logs
          mountPath: /var/log/app

    # Sidecar pour envoyer les logs
    - name: log-shipper
      image: fluentd:latest
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
          readOnly: true

  volumes:
    - name: logs
      emptyDir: {}

Pourquoi Ne Pas Créer des Pods Directement ?

Les Pods sont éphémères. Si un Pod meurt, il n'est pas recréé.

Scénario sans Deployment:

Pod my-app ──► Crash ──► DISPARU (pas de redémarrage auto)

Scénario avec Deployment:

Deployment (replicas: 1)
    │
    ▼
Pod my-app ──► Crash ──► Nouveau Pod créé automatiquement

Règle : En production, utilisez toujours un Deployment (ou StatefulSet) pour gérer vos Pods.

Le Deployment : Gestion Déclarative

Qu'est-ce qu'un Deployment ?

Un Deployment déclare l'état souhaité de votre application :

• Combien d'instances (replicas)
• Quelle image utiliser
• Comment faire les mises à jour

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3                    # 3 instances
  selector:
    matchLabels:
      app: my-app
  template:                      # Template du Pod
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          image: my-app:v1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Appliquer un Deployment

# Créer/Mettre à jour
kubectl apply -f deployment.yaml

# Vérifier le deployment
kubectl get deployments
# NAME     READY   UP-TO-DATE   AVAILABLE   AGE
# my-app   3/3     3            3           1m

# Voir les pods créés
kubectl get pods -l app=my-app
# NAME                      READY   STATUS    RESTARTS   AGE
# my-app-7d4f8b6c-abc12     1/1     Running   0          1m
# my-app-7d4f8b6c-def34     1/1     Running   0          1m
# my-app-7d4f8b6c-ghi56     1/1     Running   0          1m

Scaling : Ajuster le Nombre d'Instances

Scaling Manuel

# Scale à 5 replicas
kubectl scale deployment my-app --replicas=5

# Vérifier
kubectl get pods -l app=my-app
# 5 pods maintenant

Scaling Automatique (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

CPU < 70%: Garde le nombre actuel
CPU > 70%: Ajoute des pods (jusqu'à 10)
CPU très bas: Réduit les pods (minimum 2)

Mises à Jour : Rolling Updates

Stratégie par Défaut

Kubernetes met à jour les pods progressivement :

État initial: [v1] [v1] [v1]

Mise à jour vers v2:

Étape 1: [v1] [v1] [v1] [v2]  ← Nouveau pod v2 créé
Étape 2: [v1] [v1] [v2] [v2]  ← Un v1 supprimé, un v2 créé
Étape 3: [v1] [v2] [v2] [v2]
Étape 4: [v2] [v2] [v2]       ← Terminé, zéro downtime

Mettre à Jour l'Image

# Méthode 1: Modifier le YAML et apply
kubectl apply -f deployment.yaml

# Méthode 2: Commande directe
kubectl set image deployment/my-app app=my-app:v2.0

# Suivre le rollout
kubectl rollout status deployment/my-app
# Waiting for deployment "my-app" rollout to finish...
# deployment "my-app" successfully rolled out

Configuration du Rolling Update

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Max pods supplémentaires pendant update
      maxUnavailable: 0  # Aucun pod indisponible (zéro downtime)

Rollback : Revenir en Arrière

Voir l'Historique

kubectl rollout history deployment/my-app

# REVISION  CHANGE-CAUSE
# 1         Initial deployment
# 2         Update to v2.0
# 3         Update to v3.0 (buggy)

Rollback

# Revenir à la version précédente
kubectl rollout undo deployment/my-app

# Revenir à une version spécifique
kubectl rollout undo deployment/my-app --to-revision=1

# Vérifier
kubectl rollout status deployment/my-app

Bonnes Pratiques

1. Toujours Définir les Resources

resources:
  requests:
    cpu: "100m"      # Garanti
    memory: "128Mi"
  limits:
    cpu: "500m"      # Maximum
    memory: "512Mi"

2. Utiliser les Probes

livenessProbe:          # Le container est-il vivant ?
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

readinessProbe:         # Le container peut-il recevoir du trafic ?
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

3. Labels Cohérents

metadata:
  labels:
    app: my-app
    version: v1.0
    environment: production
    team: backend

Commandes Essentielles

# Deployments
kubectl get deployments
kubectl describe deployment my-app
kubectl delete deployment my-app

# Pods
kubectl get pods -l app=my-app
kubectl logs my-app-xxx
kubectl exec -it my-app-xxx -- /bin/sh

# Scaling
kubectl scale deployment my-app --replicas=5

# Rollout
kubectl rollout status deployment/my-app
kubectl rollout history deployment/my-app
kubectl rollout undo deployment/my-app

Résumé

Prochaine Étape

→ Services et Networking : Exposer vos applications et gérer le trafic.