Migrer vers Kubernetes depuis Docker Compose, VMs ou monolithes

Migrer vers Kubernetes depuis Docker Compose, VMs ou monolithes représente un investissement stratégique : 82% des utilisateurs de conteneurs exécutent Kubernetes en production, contre 66% en 2023. Cette migration n'est plus optionnelle pour les équipes qui visent l'échelle.

TL;DR : La migration vers Kubernetes suit un parcours en 5 phases : audit de l'existant, conteneurisation, adaptation des manifestes, déploiement progressif, validation. Comptez 2 à 6 mois selon la complexité. Les erreurs les plus coûteuses surviennent en phase de préparation, pas pendant le déploiement.

Pour maîtriser l'administration Kubernetes nécessaire à une migration réussie, découvrez la formation LFS458 Administration Kubernetes.

Pourquoi migrer vers Kubernetes en 2026 ?

Kubernetes est devenu le standard de facto. 96% des organisations utilisent ou évaluent Kubernetes, tandis que Docker Swarm plafonne à 24% d'adoption. Cette disparité s'explique par des différences fondamentales de capacités.

À retenir : Kubernetes scale jusqu'à des milliers de conteneurs. Docker Swarm convient aux workloads plus modestes (PhoenixNAP).

Le marché Kubernetes représentera 8,41 milliards USD d'ici 2031, avec une croissance annuelle de 21,85%. Les compétences de migration deviennent critiques pour les bonnes pratiques Kubernetes en production.

Avant/Après : qu'est-ce qui change concrètement ?

Docker Compose se configure en une commande (docker-compose up). Kubernetes nécessite une installation multi-étapes plus complexe, mais offre des capacités d'orchestration supérieures.

Pour les équipes venant de VMs traditionnelles, le changement de paradigme est plus profond : passage d'un modèle impératif (scripts de provisioning) à un modèle déclaratif (manifestes YAML). Consultez le guide Kubernetes vs Docker : comprendre les différences essentielles pour approfondir cette distinction.

Quels prérequis techniques avant de commencer ?

Infrastructure minimale

Configurez un cluster de développement avant toute migration de production :

# Option 1 : Kind (Kubernetes in Docker)
kind create cluster --name migration-test

# Option 2 : Minikube
minikube start --cpus=4 --memory=8192

# Vérification
kubectl cluster-info
kubectl get nodes

Compétences requises de l'équipe

Les certifications Kubernetes CKA CKAD CKS structurent cet apprentissage.

Audit de l'existant

Inventoriez vos applications avec ce template :

À retenir : Les applications stateless migrent en quelques jours. Les applications stateful avec stockage persistant nécessitent une planification de plusieurs semaines.

Comment migrer depuis Docker Compose vers Kubernetes ?

Étape 1 : Optimiser les images Docker

Avant la migration, réduisez la taille de vos images. Les images Alpine pèsent ~3 MB contre ~70 MB pour Ubuntu.

# AVANT : 800 MB
FROM node:18
COPY . /app
RUN npm install
CMD ["npm", "start"]

# APRÈS : 25 MB avec multi-stage
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:22-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node
CMD ["npm", "start"]

Les builds multi-stage réduisent la taille de 800 MB à 15-30 MB. Le guide Optimiser un Dockerfile pour Kubernetes détaille ces techniques.

Étape 2 : Convertir docker-compose.yml en manifestes Kubernetes

Utilisez Kompose pour la conversion initiale, puis affinez manuellement :

# Conversion automatique
kompose convert -f docker-compose.yml

# Fichiers générés
ls *.yaml
# api-deployment.yaml
# api-service.yaml
# redis-deployment.yaml
# redis-service.yaml

Exemple de conversion manuelle (recommandé pour la production) :

# docker-compose.yml original
services:
  api:
    image: myapp:1.0
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://db:5432
    depends_on:
      - db

# deployment.yaml Kubernetes équivalent
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myapp:1.0
        ports:
        - containerPort: 8080
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: url
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
  - port: 8080
    targetPort: 8080
  type: ClusterIP

À retenir : Ne déployez jamais sans resources (limits/requests) ni probes de santé. Ces éléments sont optionnels dans Docker Compose mais essentiels dans Kubernetes.

Étape 3 : Gérer les ConfigMaps et Secrets

Extrayez les variables d'environnement vers des objets Kubernetes dédiés :

# Créer un Secret depuis un fichier .env
kubectl create secret generic app-secrets \
  --from-env-file=.env.production

# Créer une ConfigMap pour la configuration non-sensible
kubectl create configmap app-config \
  --from-file=config.json

Consultez l'aide-mémoire Docker et Kubernetes pour les commandes complètes.

Comment migrer des VMs vers Kubernetes ?

La migration depuis des VMs suit un processus différent qui commence par la conteneurisation.

Phase 1 : Conteneuriser l'application

Analysez les dépendances système de votre VM :

# Lister les packages installés (Debian/Ubuntu)
dpkg --get-selections | grep -v deinstall

# Lister les services actifs
systemctl list-units --type=service --state=running

# Identifier les ports ouverts
ss -tlnp

Créez un Dockerfile qui réplique l'environnement :

FROM ubuntu:22.04

# Reproduire les packages de la VM
RUN apt-get update && apt-get install -y \
    python3.10 \
    python3-pip \
    libpq-dev \
    && rm -rf /var/lib/apt/lists/*

# Copier l'application
COPY app/ /opt/app/
WORKDIR /opt/app

# Installer les dépendances Python
RUN pip3 install -r requirements.txt

# L'utilisateur non-root est obligatoire en production
RUN useradd -m appuser
USER appuser

EXPOSE 8000
CMD ["python3", "main.py"]

Phase 2 : Gérer le stockage persistant

Les VMs avec stockage local nécessitent des PersistentVolumeClaims :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 50Gi
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  serviceName: database
  replicas: 1
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      labels:
        app: database
    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: 50Gi

Pour les architectures complexes, la formation Kubernetes pour les développeurs d'applications couvre les patterns de migration stateful.

Comment décomposer un monolithe pour Kubernetes ?

Stratégie Strangler Fig Pattern

Migrez progressivement sans réécriture complète :

1. Identifiez un module faiblement couplé
2. Extrayez ce module en microservice
3. Routez le trafic via un API Gateway
4. Répétez jusqu'à extinction du monolithe

# Exemple : API Gateway avec Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-gateway
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      # Nouveau microservice
      - path: /users(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: users-service
            port:
              number: 8080
      # Monolithe legacy (fallback)
      - path: /(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: monolith
            port:
              number: 80

À retenir : 70% des organisations utilisent Helm pour packager leurs déploiements. Adoptez Helm dès le premier microservice extrait.

Quel plan de rollback prévoir ?

Documentez systématiquement les procédures de retour arrière :

Rollback rapide (< 5 minutes)

# Revenir à la version précédente du Deployment
kubectl rollout undo deployment/api

# Vérifier l'historique des révisions
kubectl rollout history deployment/api

# Revenir à une révision spécifique
kubectl rollout undo deployment/api --to-revision=2

Rollback complet vers l'ancien système

Conservez l'ancien système opérationnel pendant 2 à 4 semaines après migration complète. Cette période de cohabitation permet de gérer les cas limites.

Consultez le guide Dépannage Docker et Kubernetes pour diagnostiquer les problèmes courants de migration.

Checklist de validation post-migration

Tests fonctionnels

# Vérifier que tous les pods sont Running
kubectl get pods -n production

# Tester les endpoints
curl -I https://api.example.com/health

# Vérifier les logs
kubectl logs -l app=api -n production --tail=100

Tests de charge

# Exemple avec k6
k6 run --vus 100 --duration 5m load-test.js

# Vérifier l'autoscaling
kubectl get hpa -w

Validation sécurité

La formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes approfondit ces contrôles de sécurité post-migration.

Métriques à surveiller

• Latence P99 : doit rester stable (±10% vs baseline)
• Taux d'erreur : <0.1% sur 24h
• Utilisation ressources : requests alignés sur usage réel
• Temps de démarrage pods : <30s pour les applications critiques

Quels pièges éviter lors de la migration ?

Erreurs fréquentes :

1. Sous-estimer la courbe d'apprentissage : prévoir 3 mois minimum de montée en compétences
2. Ignorer les Network Policies : par défaut, tous les pods communiquent entre eux
3. Oublier les resource limits : un pod sans limits peut saturer un node entier
4. Négliger le monitoring : instrumenter dès le jour 1

Pour les équipes débutantes, la formation Kubernetes les fondamentaux offre une introduction structurée avant d'aborder la migration.

Ressources complémentaires pour votre migration

Explorez le hub Formation Kubernetes pour accéder à l'ensemble des guides et bonnes pratiques. La section Bonnes pratiques conteneurisation et Docker couvre les prérequis techniques essentiels.

---

Passez à l'action : formez votre équipe à la migration Kubernetes

71 % des entreprises Fortune 100 exécutent Kubernetes en production. Votre équipe doit maîtriser ces compétences pour réussir la transformation cloud-native.

SFEIR Institute propose des formations certifiantes adaptées à chaque profil :

• LFS458 Administration Kubernetes (4 jours) : pour les équipes Ops/SRE qui gèrent la migration et l'administration des clusters
• LFD459 Kubernetes pour les développeurs (3 jours) : pour les développeurs qui conteneurisent et déploient leurs applications
• LFS460 Sécurité Kubernetes (4 jours) : pour valider la conformité sécurité post-migration
• Kubernetes les fondamentaux (1 jour) : pour découvrir Kubernetes avant un projet de migration

Contactez nos conseillers pour définir le parcours de formation adapté à votre projet de migration.