Deployments et ReplicaSets Kubernetes : guide pratique

Les deployments kubernetes constituent le mécanisme standard pour déployer et gérer des applications conteneurisées en production. Un Deployment crée et supervise des ReplicaSets, qui eux-mêmes gèrent les Pods. Cette hiérarchie garantit la disponibilité, le scaling et les mises à jour sans interruption de service.

TL;DR : Un Deployment définit l'état souhaité de votre application (image, replicas, ressources). Le ReplicaSet maintient le nombre de Pods spécifié. Kubernetes réconcilie automatiquement l'état réel avec l'état déclaré. Ce guide couvre la création, le scaling, les rolling updates et le rollback des deployments kubernetes.

Pour découvrir ces concepts, la formation Kubernetes, les fondamentaux (1 jour) vous donne les bases essentielles.

Qu'est-ce qu'un Deployment Kubernetes ?

Un Deployment est un objet Kubernetes qui déclare l'état désiré d'une application. Il répond à trois questions : quelle image exécuter, combien de replicas maintenir, et comment mettre à jour.

Les Deployments incarnent la philosophie Kubernetes en abstractant la complexité de gestion des Pods.

Caractéristiques essentielles :

À retenir : ne créez jamais de Pods isolés en production. Utilisez toujours un Deployment qui garantit leur disponibilité.

Avec 82% des utilisateurs de conteneurs sur Kubernetes, les Deployments représentent le pattern de déploiement dominant.

Comment les deployments kubernetes gèrent les ReplicaSets ?

Un ReplicaSet est un contrôleur qui maintient un nombre stable de Pods identiques. Le Deployment crée et gère automatiquement les ReplicaSets.

Voici la hiérarchie :

Deployment
    └── ReplicaSet (version actuelle)
         ├── Pod 1
         ├── Pod 2
         └── Pod 3
    └── ReplicaSet (version précédente, 0 replicas)

Les replicasets kubernetes assurent trois fonctions :

1. Création : démarrer le nombre de Pods spécifié
2. Monitoring : surveiller l'état des Pods
3. Réconciliation : recréer les Pods défaillants

# Voir les ReplicaSets d'un Deployment
kubectl get rs -l app=mon-app

# Observer le lien Deployment → ReplicaSet → Pods
kubectl get deploy,rs,pods -l app=mon-app

À retenir : manipulez toujours le Deployment, jamais directement le ReplicaSet. Le Deployment orchestre les transitions entre versions.

Consultez notre Formation Kubernetes : Guide Complet pour une vision d'ensemble.

Comment créer un Deployment Kubernetes ?

Créez un Deployment avec un manifest YAML structuré :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend
  labels:
    app: api-backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-backend
  template:
    metadata:
      labels:
        app: api-backend
    spec:
      containers:
      - name: api
        image: mon-registry/api:v1.2.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3

Appliquez le manifest :

kubectl apply -f deployment.yaml

# Vérifier le statut
kubectl rollout status deployment/api-backend

# Voir les détails
kubectl describe deployment api-backend

Les équipes IT consacrent 34 jours ouvrés par an à résoudre des problèmes Kubernetes. Des Deployments bien configurés avec probes réduisent ce temps.

Pour exposer ce Deployment, consultez notre guide sur les Services Kubernetes.

Comment scaler un Deployment ?

Le scaling ajuste le nombre de Pods en fonction de la charge. Deux méthodes existent.

Scaling manuel

# Passer à 5 replicas
kubectl scale deployment/api-backend --replicas=5

# Vérifier le scaling
kubectl get deployment api-backend

Scaling déclaratif

Modifiez le champ replicas dans le manifest et réappliquez :

spec:
  replicas: 5  # Modifié de 3 à 5

kubectl apply -f deployment.yaml

À retenir : le scaling déclaratif facilite le versioning et la revue de code. Préférez cette approche en production.

Pour un scaling automatique basé sur les métriques CPU/mémoire, configurez un HorizontalPodAutoscaler :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-backend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-backend
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Avec 80% des organisations utilisant Kubernetes en production, le scaling automatique devient critique.

Comment effectuer un rolling update des deployments kubernetes ?

Les rolling updates permettent de mettre à jour une application sans interruption. Kubernetes remplace progressivement les anciens Pods par les nouveaux.

Mettez à jour l'image du Deployment :

# Méthode impérative
kubectl set image deployment/api-backend api=mon-registry/api:v1.3.0

# Observer le rollout
kubectl rollout status deployment/api-backend

La stratégie par défaut RollingUpdate contrôle la transition :

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%  # Max pods indisponibles
      maxSurge: 25%        # Max pods supplémentaires

À retenir : configurez readinessProbe pour que Kubernetes attende que le nouveau Pod soit prêt avant de supprimer l'ancien.

Maîtrisez les commandes kubectl pour superviser vos rolling updates.

Comment effectuer un rollback ?

Si une mise à jour cause des problèmes, restaurez une version précédente instantanément.

# Voir l'historique des révisions
kubectl rollout history deployment/api-backend

# Détails d'une révision spécifique
kubectl rollout history deployment/api-backend --revision=2

# Rollback vers la révision précédente
kubectl rollout undo deployment/api-backend

# Rollback vers une révision spécifique
kubectl rollout undo deployment/api-backend --to-revision=3

Kubernetes conserve les anciens ReplicaSets (avec 0 replicas) pour permettre les rollbacks. Le paramètre revisionHistoryLimit contrôle ce nombre :

spec:
  revisionHistoryLimit: 5  # Conserver 5 versions

Selon TealHQ : « Don't let your knowledge remain theoretical - set up a real Kubernetes environment to solidify your skills. » Pratiquez les rollbacks sur un cluster de test.

Bonnes pratiques pour les deployments kubernetes

Labels et sélecteurs cohérents

metadata:
  labels:
    app: api-backend
    version: v1.2.0
    environment: production
spec:
  selector:
    matchLabels:
      app: api-backend

Resource requests et limits

Définissez toujours les ressources pour éviter la surcharge des nodes :

resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Probes de santé

À retenir : sans readinessProbe, Kubernetes envoie du trafic vers des Pods non prêts, causant des erreurs 5xx.

Annotations pour les rollouts

# Enregistrer la cause du changement
kubectl annotate deployment/api-backend \
  kubernetes.io/change-cause="Upgrade API vers v1.3.0"

Découvrez les bases dans Kubernetes les fondamentaux et pour débutants.

Tableau récapitulatif : commandes Deployment

Passez à l'action : formations Kubernetes SFEIR

Les Deployments et ReplicaSets forment le cœur de la gestion applicative Kubernetes. Pour approfondir :

• Initiez-vous en 1 jour avec Kubernetes, les fondamentaux : Pods, Deployments, Services, architecture
• Préparez le CKAD avec LFD459 Kubernetes pour les développeurs : 3 jours axés développement applicatif
• Administrez en production avec LFS458 Administration Kubernetes : 4 jours pour la certification CKA

Contactez nos conseillers pour construire votre parcours de certification.