Docker a changé la façon de construire et déployer les applications. Kubernetes a changé la façon de les faire tourner à l'échelle, et a ajouté beaucoup de surface opérationnelle au passage. Connaître les deux, et savoir quand vous n'avez pas besoin du second, fait aujourd'hui partie du métier de tout ingénieur backend sur des systèmes distribués.

Docker : construire une image petite et correcte

Un conteneur empaquette l'application avec ses dépendances dans une unité portable et reproductible, définie par le Dockerfile. Deux choses comptent pour une image de production : utiliser un build multi-stage pour que l'image finale ne contienne que le runtime et l'app construite, pas les outils de build, et tourner en utilisateur non-root. Ajoutez un .dockerignore pour ne pas copier .git, node_modules ou les fichiers d'env locaux dans le contexte de build.

# Stage 1 : build
FROM composer:2 AS vendor
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-scripts

# Stage 2 : runtime
FROM php:8.4-fpm-alpine
RUN docker-php-ext-install pdo_mysql opcache
WORKDIR /var/www
COPY --from=vendor /app/vendor ./vendor
COPY . .
RUN php artisan config:cache && php artisan route:cache \
    && addgroup -g 1000 app && adduser -u 1000 -G app -S app \
    && chown -R app:app /var/www
USER app
EXPOSE 9000
CMD ["php-fpm"]

Docker Compose : le local, et la petite production

Pour le développement local et pour une poignée de services sur un seul VPS, Docker Compose suffit. Un fichier décrit chaque service, son réseau, ses volumes et son environnement, et docker compose up monte toute la stack. Ne cherchez pas plus loin tant qu'un seul hôte ne peut réellement pas porter votre charge ou que vous n'avez pas besoin de bascule automatique.

Quand vous avez vraiment besoin de Kubernetes

• ✓Vous faites tourner plus qu'une poignée de services et un seul hôte ne peut pas les porter.
• ✓Vous avez besoin d'un scaling automatique en réponse au trafic, pas d'un nombre fixe de conteneurs.
• ✓Vous avez besoin de déploiements progressifs avec rollout conditionné à la santé et rollback automatique.
• ✓Vous avez besoin d'auto-guérison : un conteneur crashé redémarré, un noeud malsain drainé, sans réveiller personne.
• ✓Vous avez l'équipe pour l'opérer, ou vous utilisez un control plane managé (GKE, EKS, AKS).

Les objets de base

Un Deployment minimal avec health checks

L'erreur la plus fréquente dans un premier setup Kubernetes est de sauter les probes. Sans readiness probe, du trafic est envoyé à un Pod avant qu'il soit prêt ; sans liveness probe, un Pod bloqué n'est jamais redémarré. Les deux tiennent en quelques lignes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels: { app: api-service }
  template:
    metadata:
      labels: { app: api-service }
    spec:
      containers:
        - name: api
          image: my-registry/api-service:v1.2.0
          ports:
            - containerPort: 9000
          envFrom:
            - secretRef: { name: api-secrets }
          readinessProbe:
            httpGet: { path: /health, port: 9000 }
            initialDelaySeconds: 5
          livenessProbe:
            httpGet: { path: /health, port: 9000 }
            initialDelaySeconds: 15
          resources:
            requests: { cpu: 100m, memory: 256Mi }
            limits: { memory: 512Mi }

Config et secrets : jamais dans l'image

Une image doit être identique dans tous les environnements. Les valeurs spécifiques à un environnement viennent d'un ConfigMap, et les identifiants d'un Secret (idéalement adossé à un vrai gestionnaire de secrets, puisqu'un Secret Kubernetes brut n'est qu'encodé en base64). Injectez-les en variables d'environnement ou en fichiers montés au runtime, jamais au build.

Déploiements progressifs et rollback

Un Deployment déploie une nouvelle image en remplaçant les Pods progressivement, en attendant que chaque nouveau Pod passe sa readiness probe avant de continuer. Si la nouvelle version ne devient jamais prête, le rollout se bloque au lieu de faire tomber le service, et kubectl rollout undo vous ramène à la version précédente.

Les alternatives managées

Entre Docker Compose et Kubernetes complet, il y a les plateformes de conteneurs managées : Google Cloud Run, AWS App Runner ou ECS Fargate, Fly.io. Elles font tourner votre conteneur, le scalent, lui donnent HTTPS et des déploiements progressifs, et ne vous laissent presque aucune charge opérationnelle. Pour la plupart des services petits et moyens, c'est la bonne réponse, et vous passez à Kubernetes seulement quand vous les dépassez.

Docker est une compétence dont tout le monde dans une équipe backend a besoin. Kubernetes est un outil pour une échelle précise, et le sortir trop tôt échange un problème simple contre un problème dur. Construisez des images petites et correctes, faites-les tourner avec Compose ou une plateforme managée, et adoptez Kubernetes quand c'est la charge, pas le CV, qui l'exige.