Kubernetes pour la mise à l'échelle du commerce électronique : des pics de trafic à l'expansion mondiale

Les pics de trafic du Black Friday peuvent multiplier par 10 à 50 la charge du commerce électronique en quelques minutes. L'infrastructure de serveur traditionnelle ne peut pas répondre assez rapidement. Kubernetes fournit les capacités d'auto-évolutivité, d'auto-réparation et de gestion du trafic dont les plateformes de commerce électronique modernes ont besoin pour gérer une demande imprévisible sans surprovisionner pendant les périodes creuses.

Ce guide couvre l'architecture Kubernetes spécifiquement pour les charges de travail de commerce électronique, de la gestion des ventes flash à la création de vitrines multirégionales qui servent les clients en moins de 200 ms, quel que soit leur emplacement.

Points clés à retenir

• Horizontal Pod Autoscaler (HPA) peut faire évoluer les services de commerce électronique de 2 à 200 pods en moins de 90 secondes
• Les contrôleurs d'entrée avec limitation de débit protègent les services backend lors des pics de trafic
• Les charges de travail avec état (bases de données, index de recherche) nécessitent des stratégies de mise à l'échelle différentes de celles des services sans état
• Les déploiements Kubernetes multirégionaux réduisent la latence de 60 à 80 % pour les bases de clients mondiales

---

Quand Kubernetes prend tout son sens pour le commerce électronique

Kubernetes n'est pas toujours la bonne réponse. Cela ajoute une complexité opérationnelle qui doit être justifiée par les exigences d’évolutivité.

Matrice de décision

Si votre entreprise figure dans la colonne Docker Compose, consultez plutôt notre Guide de déploiement de production Docker.

---

Architecture Kubernetes pour le commerce électronique

Disposition des clusters

Un cluster Kubernetes de commerce électronique contient généralement ces espaces de noms :

• storefront : modules d'application frontend
• api : services API back-end
• workers : Processeurs de tâches en arrière-plan (traitement des commandes, envoi d'e-mails, synchronisation des stocks)
• data : Bases de données, caches et moteurs de recherche (ou services externes gérés)
• ingress : contrôleurs d'entrée et équilibreurs de charge
• monitoring : Prométhée, Grafana, alerte

Configuration du déploiement

# storefront-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: storefront
  namespace: storefront
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: storefront
  template:
    metadata:
      labels:
        app: storefront
    spec:
      containers:
        - name: storefront
          image: registry.example.com/storefront:v2.1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 1000m
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 20
          env:
            - name: API_URL
              value: "http://api-service.api.svc.cluster.local:3001"
            - name: NODE_ENV
              value: "production"

---

Configuration de mise à l'échelle automatique

Autoscaler de pods horizontaux

# storefront-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: storefront-hpa
  namespace: storefront
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: storefront
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

La politique scaleUp permet de doubler les pods toutes les 60 secondes, ce qui est essentiel pour gérer les pics soudains de trafic. La politique scaleDown est conservatrice (10 % par minute) pour éviter les raclées.

Autoscaler de cluster

HPA met à l'échelle les pods, mais les pods ont besoin de nœuds. Le Cluster Autoscaler ajoute et supprime des nœuds en fonction des demandes de pods en attente :

# cluster-autoscaler configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
data:
  balance-similar-node-groups: "true"
  skip-nodes-with-local-storage: "false"
  scale-down-delay-after-add: "10m"
  scale-down-unneeded-time: "10m"
  max-node-provision-time: "5m"

Pour AWS EKS, configurez les groupes de nœuds avec des tailles min/max :

eksctl create nodegroup \
  --cluster ecommerce-prod \
  --name workers \
  --node-type t3.large \
  --nodes-min 3 \
  --nodes-max 20 \
  --node-volume-size 50 \
  --managed

---

Gestion des entrées et du trafic

Contrôleur d'entrée Nginx

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/rate-limit-window: "1m"
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
    - hosts:
        - store.example.com
      secretName: store-tls
  rules:
    - host: store.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 3001
          - path: /
            pathType: Prefix
            backend:
              service:
                name: storefront-service
                port:
                  number: 3000

Gestion des ventes flash

Les ventes flash nécessitent une pré-mise à l'échelle. Ne comptez pas uniquement sur la mise à l'échelle automatique pour les événements connus à fort trafic :

# Pre-scale 2 hours before a flash sale
kubectl scale deployment storefront --replicas=20 -n storefront
kubectl scale deployment api --replicas=15 -n api
kubectl scale deployment order-worker --replicas=10 -n workers

# After the sale, let HPA scale down naturally

---

Mise à l'échelle de la base de données dans Kubernetes

Bases de données gérées ou auto-hébergées

Recommandation : Utilisez des bases de données gérées pour le commerce électronique de production. La surcharge opérationnelle liée à l'exécution de PostgreSQL dans Kubernetes n'est pas justifiée pour la plupart des entreprises.

Regroupement de connexions

# pgbouncer-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pgbouncer
  namespace: data
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: pgbouncer
          image: edoburu/pgbouncer:1.21.0
          ports:
            - containerPort: 5432
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
            - name: MAX_CLIENT_CONN
              value: "1000"
            - name: DEFAULT_POOL_SIZE
              value: "25"
            - name: POOL_MODE
              value: "transaction"

PgBouncer en mode pooling de transactions permet à des centaines de modules d'application de partager un pool limité de connexions à la base de données. Sans regroupement de connexions, la mise à l'échelle jusqu'à 50 pods API nécessiterait 50 x 20 = 1 000 connexions à la base de données, ce qui écraserait la plupart des instances PostgreSQL.

Pour plus de stratégies de mise à l'échelle de la base de données, consultez notre guide de mise à l'échelle de la base de données.

---

Déploiement multi-régions

Architecture

Un déploiement Kubernetes de commerce électronique multirégional utilise :

1. Clusters régionaux : clusters Kubernetes indépendants dans chaque région
2. Équilibreur de charge global : achemine les utilisateurs vers la région la plus proche (AWS Global Accelerator, Cloudflare)
3. Réplication de base de données : primaire dans une région, réplicas en lecture dans d'autres
4. CDN : actifs statiques servis depuis des emplacements périphériques dans le monde entier

Impact sur la latence

Le déploiement multirégional réduit la latence pour les clients internationaux de 60 à 90 %, améliorant directement les taux de conversion. Des études montrent que chaque tranche de 100 ms de réduction de latence augmente la conversion du commerce électronique de 1,1 %.

---

Surveillance du commerce électronique Kubernetes

Tableaux de bord essentiels

1. Mesures commerciales : commandes par minute, taux de conversion du panier, revenus par heure
2. Mesures d'application : latence des requêtes (P50, P95, P99), taux d'erreur, sessions actives
3. Mesures d'infrastructure : CPU/mémoire du pod, utilisation des nœuds, activité HPA
4. Mesures de base de données : nombre de connexions, latence des requêtes, délai de réplication

# prometheus-servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: api
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics

---

Questions fréquemment posées

Combien coûte Kubernetes par rapport à l'hébergement traditionnel ?

L'infrastructure Kubernetes coûte 20 à 40 % de plus que les instances équivalentes nues ou cloud simples en raison des coûts du plan de contrôle, des frais d'équilibrage de charge et de la surcharge des nœuds. Cependant, la mise à l'échelle automatique réduit généralement les dépenses totales de 30 à 50 %, car vous ne payez pas pour la capacité de pointe pendant les heures creuses. L'effet net pour la plupart des entreprises de commerce électronique à trafic variable est une réduction des coûts de 10 à 25 %.

Pouvons-nous exécuter Odoo sur Kubernetes ?

Oui, mais avec des réserves. Le magasin de fichiers d'Odoo nécessite un stockage persistant partagé (EFS, NFS) lors de l'exécution de plusieurs répliques. L'affinité de session est nécessaire, sauf si vous externalisez les sessions vers Redis. Les connexions à la base de données doivent être regroupées via PgBouncer. Pour la plupart des déploiements Odoo, Docker Compose ou ECS est plus simple et suffisant. Kubernetes est logique pour les grands déploiements Odoo avec plus de 200 utilisateurs simultanés.

Comment gérer les mises à niveau de Kubernetes sans temps d'arrêt ?

Utilisez un service Kubernetes géré (EKS, GKE, AKS) qui gère les mises à niveau du plan de contrôle. Pour les mises à niveau des nœuds, utilisez une stratégie continue : bouclez un nœud, videz ses pods (ils sont reprogrammés vers d'autres nœuds), mettez à niveau le nœud, débloquez-le. Avec des budgets de perturbation des pods appropriés, cela est entièrement automatisé et sans temps d'arrêt.

Quelle est la taille minimale d'un cluster pour le commerce électronique de production ?

Un cluster de production minimum pour une plateforme de commerce électronique de taille moyenne : 3 nœuds (t3.large ou équivalent) pour les charges de travail d'application, plus une instance de base de données gérée. Cela gère environ 500 utilisateurs simultanés avec une possibilité de mise à l'échelle automatique pendant les pics. Coût total de l'infrastructure : environ 500 à 800 $ par mois.

---

Ce qui vient ensuite

Kubernetes fournit la base de la mise à l’échelle, mais ce n’est qu’une pièce du puzzle de l’infrastructure. Combinez-le avec les meilleures pratiques CI/CD, l'optimisation CDN et les tests de charge pour une plate-forme complète d'opérations de commerce électronique.

Contactez ECOSIRE pour connaître la stratégie de conseil et de mise à l'échelle du commerce électronique Kubernetes, ou explorez nos services d'intégration Shopify pour le commerce sans tête géré sur Kubernetes.

---

Publié par ECOSIRE – aider les entreprises à faire évoluer leur infrastructure de commerce électronique à l'échelle mondiale.