Migrer de Docker Compose à Kubernetes : guide de transition pas à pas

Vous utilisez Docker Compose en développement et vous devez migrer de Docker Compose à Kubernetes pour la production. Cette transition représente un changement fondamental dans la gestion de vos conteneurs.

Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent désormais Kubernetes en production. Ce guide vous accompagne étape par étape, du fichier docker-compose.yml vers des manifestes Kubernetes fonctionnels.

TL;DR : La migration Docker Compose vers Kubernetes suit 5 phases : audit de l'existant, conversion des services, adaptation du stockage, configuration réseau, et validation. Prévoyez 2 à 4 semaines pour une application de taille moyenne. Les développeurs Backend et Full-Stack qui maîtrisent cette transition deviennent des profils recherchés sur le marché.

Cette compétence est au cœur de la formation LFD459 Kubernetes pour les développeurs d'applications.

Pourquoi migrer de Docker Compose vers Kubernetes ?

Docker Compose excelle pour le développement local et les environnements de test. Kubernetes répond aux exigences de production : haute disponibilité, scaling automatique, rolling updates sans interruption.

À retenir : Docker Compose convient au développement. Kubernetes s'impose pour la production avec ses garanties de disponibilité et son scaling natif.

Le comparatif complet des alternatives Kubernetes détaille les différences architecturales entre ces orchestrateurs.

Quels prérequis avant de commencer la migration ?

Environnement technique requis

Installez ces outils avant de démarrer :

# kubectl - CLI Kubernetes
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl && sudo mv kubectl /usr/local/bin/

# Kompose - convertisseur Docker Compose vers Kubernetes
curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-linux-amd64 -o kompose
chmod +x kompose && sudo mv kompose /usr/local/bin/

# Vérification des versions
kubectl version --client
kompose version

Cluster Kubernetes de test

Utilisez Minikube, Kind ou k3s pour vos tests locaux :

# Installation Minikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# Démarrage du cluster
minikube start --driver=docker --memory=4096 --cpus=2

Compétences préalables

La migration requiert une compréhension des concepts Kubernetes fondamentaux. Consultez la formation Kubernetes les fondamentaux pour administrateur système si ces notions vous sont nouvelles :

• Pod : unité de déploiement minimale (un ou plusieurs conteneurs)
• Deployment : gestion déclarative des ReplicaSets
• Service : exposition réseau et load balancing
• ConfigMap : configuration externalisée
• Secret : données sensibles chiffrées

Comment analyser votre docker-compose.yml existant ?

Audit des services

Listez chaque service de votre fichier Compose et identifiez :

# Exemple docker-compose.yml à migrer
version: '3.8'
services:
  api:
    build: ./api
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/app
    depends_on:
      - db
    volumes:
      - ./api:/app
    
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Matrice de correspondance

À retenir : Les bind mounts de développement (./api:/app) ne migrent pas vers Kubernetes. Construisez des images immutables contenant votre code.

Quelle méthode pour convertir vos services ?

Conversion automatique avec Kompose

Kompose génère des manifestes Kubernetes à partir de votre docker-compose.yml :

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

# Conversion avec options avancées
kompose convert -f docker-compose.yml \
  --out ./k8s-manifests \
  --with-kompose-annotation=false \
  --controller=deployment

Cette commande produit plusieurs fichiers YAML. Examinez chaque fichier généré : Kompose crée une base fonctionnelle mais rarement optimale pour la production.

Adaptation manuelle des manifestes

Le Deployment généré nécessite des ajustements. Voici un exemple optimisé :

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: registry.example.com/api:v1.2.3
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3
        envFrom:
        - configMapRef:
            name: api-config
        - secretRef:
            name: api-secrets

Les bonnes pratiques pour structurer vos manifestes YAML Kubernetes détaillent chaque section de ce fichier.

Externalisation des configurations

Séparez les variables d'environnement en ConfigMaps et Secrets :

# api-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: api-config
data:
  LOG_LEVEL: "info"
  API_PORT: "8080"
  FEATURE_FLAGS: "new-ui=true,beta-api=false"

---
# api-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: api-secrets
type: Opaque
stringData:
  DATABASE_URL: "postgres://user:pass@db-service:5432/app"

La formation LFD459 Kubernetes pour les développeurs d'applications couvre en profondeur la gestion des ConfigMaps et Secrets en 3 jours intensifs.

Comment gérer le stockage persistant ?

Conversion des volumes Docker

Les volumes Docker nommés deviennent des PersistentVolumeClaims (PVC) :

# postgres-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 10Gi

StatefulSet pour les bases de données

Utilisez un StatefulSet au lieu d'un Deployment pour PostgreSQL :

# postgres-statefulset.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:16
        ports:
        - containerPort: 5432
        envFrom:
        - secretRef:
            name: postgres-secrets
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: standard
      resources:
        requests:
          storage: 20Gi

À retenir : Les StatefulSets garantissent des noms de pods stables et un stockage persistant par replica. Indispensables pour les bases de données.

Comment configurer le réseau Kubernetes ?

Services et exposition

Créez un Service pour chaque Deployment exposé :

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

---
# postgres-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: db-service
spec:
  selector:
    app: postgres
  ports:
  - port: 5432
    targetPort: 5432
  type: ClusterIP

Remplacement de depends_on

Docker Compose utilise depends_on pour l'ordre de démarrage. Kubernetes privilégie les InitContainers et les readiness probes :

# Dans le Deployment API
spec:
  template:
    spec:
      initContainers:
      - name: wait-for-db
        image: busybox:1.36
        command: ['sh', '-c', 
          'until nc -z db-service 5432; do echo "Waiting for DB..."; sleep 2; done']
      containers:
      - name: api
        # ... configuration principale

Cette approche est plus robuste : elle vérifie la disponibilité réelle du service, pas simplement le démarrage du conteneur.

Quelles étapes pour valider la migration ?

Déploiement progressif

Appliquez les manifestes dans l'ordre :

# 1. Namespace dédié
kubectl create namespace myapp

# 2. Secrets et ConfigMaps
kubectl apply -f k8s-manifests/secrets/ -n myapp
kubectl apply -f k8s-manifests/configmaps/ -n myapp

# 3. Stockage persistant
kubectl apply -f k8s-manifests/pvc/ -n myapp

# 4. Base de données (StatefulSet)
kubectl apply -f postgres-statefulset.yaml -n myapp
kubectl wait --for=condition=ready pod/postgres-0 -n myapp --timeout=120s

# 5. Application
kubectl apply -f api-deployment.yaml -n myapp
kubectl apply -f api-service.yaml -n myapp

# 6. Vérification
kubectl get all -n myapp

Checklist de validation

Consultez notre guide pour résoudre les 10 erreurs de déploiement Kubernetes les plus fréquentes si vous rencontrez des problèmes.

Tests de charge

# Port-forward pour accès local
kubectl port-forward svc/api-service 8080:80 -n myapp &

# Test de charge basique
hey -n 1000 -c 50 http://localhost:8080/api/health

Comment prévoir un plan de rollback ?

Sauvegarde avant migration

Conservez votre environnement Docker Compose fonctionnel :

# Export des données
docker compose exec db pg_dump -U postgres app > backup_pre_migration.sql

# Snapshot des volumes
docker run --rm -v postgres_data:/data -v $(pwd):/backup \
  alpine tar czf /backup/postgres_data_backup.tar.gz /data

Rollback Kubernetes

Si la migration échoue, revenez à la version précédente :

# Rollback d'un Deployment
kubectl rollout undo deployment/api -n myapp

# Vérification de l'historique
kubectl rollout history deployment/api -n myapp

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

À retenir : Kubernetes conserve l'historique des révisions. Testez la procédure de rollback avant la mise en production.

Quelles optimisations post-migration appliquer ?

Optimisation des images Docker

Selon Cloud Native Now, les builds multi-stage réduisent la taille des images de 800 Mo à 15-30 Mo. Utilisez des images Alpine (~3 Mo) plutôt qu'Ubuntu (~70 Mo).

# Dockerfile optimisé multi-stage
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o api .

FROM alpine:3.19
RUN apk add --no-cache ca-certificates
COPY --from=builder /app/api /usr/local/bin/
EXPOSE 8080
CMD ["api"]

Sécurisation des workloads

Appliquez les recommandations de sécurisation des workloads Kubernetes :

# Security context recommandé
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

Horizontal Pod Autoscaler

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

Quelle formation pour maîtriser cette transition ?

Comme l'affirme The Enterprisers Project : "Anybody can learn Kubernetes. With abundant documentation and development tools available online, teaching yourself Kubernetes is very much within reach." Cependant, une formation structurée accélère considérablement la montée en compétence.

La différence entre formation LFS458 et LFD459 tient au profil visé : administration cluster ou développement applicatif. Pour la migration Docker Compose vers Kubernetes, le parcours développeur d'applications s'avère le plus pertinent.

Les tutoriels et guides pratiques Kubernetes complètent cette formation avec des cas concrets. Le guide complet Formation Kubernetes présente l'ensemble des parcours disponibles.

Passez à l'action

La migration de Docker Compose vers Kubernetes transforme votre approche du déploiement. Les 96% d'organisations utilisant ou évaluant Kubernetes confirment cette tendance irréversible.

Prochaines étapes recommandées :

1. Évaluez votre projet : identifiez les services, volumes et dépendances
2. Testez la conversion : utilisez Kompose sur un environnement de développement
3. Formez-vous : acquérez les compétences avec une formation certifiante

Les formations SFEIR Institute accompagnent les développeurs Backend, Full-Stack et ingénieurs logiciels dans cette transition :

• LFD459 Kubernetes pour les développeurs d'applications : 3 jours pour maîtriser les Deployments, Services, ConfigMaps et préparer le CKAD
• Kubernetes, les fondamentaux : 1 journée pour découvrir les concepts essentiels
• LFS458 Administration Kubernetes : 4 jours pour la gestion complète des clusters et le CKA

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