Planification de capacité Docker Swarm : guide pratique pour dimensionner votre cluster

Découvrez comment estimer la capacité de votre cluster Docker Swarm, éviter l'épuisement des ressources et évoluer en toute sécurité. Ce guide comprend un dimensionnement étape par étape, la surveillance et des listes de contrôle opérationnelles, avec des commandes pratiques et des exemples concrets.

Introduction

Les clusters Docker Swarm tombent souvent en panne au pire moment : un pic de trafic survient, un service fuit de la mémoire et soudain les nœuds manquent de CPU ou de RAM. Les conteneurs sont évincés, le planificateur ne peut plus placer de nouvelles tâches et les utilisateurs sont confrontés à des délais d'attente. La planification de capacité consiste à estimer la quantité de CPU, de mémoire, de disque et de réseau dont vos services auront besoin, puis à surveiller l'utilisation réelle pour ajuster avant que des problèmes ne surviennent. Bien faite, elle évite à la fois le gaspillage dû au surprovisionnement et les pannes dues au sous-provisionnement.

Ce guide propose une approche pratique pour dimensionner votre cluster Swarm. Vous ferez l'inventaire de votre environnement actuel, définirez des réservations et des limites de ressources sûres, vérifierez les configurations, diagnostiquerez les pannes et suivrez une liste de contrôle opérationnelle reproductible. Chaque étape inclut des commandes concrètes et les sorties attendues afin que vous puissiez l'appliquer directement à votre propre cluster.

Inventoriez votre environnement

Avant de pouvoir planifier la capacité, vous devez avoir une idée claire de ce que vous exécutez. Notez les versions de Docker Engine et de Swarm, les spécifications matérielles des nœuds et les services que vous prévoyez d'exécuter. Utilisez les commandes suivantes pour recueillir les détails.

Tout d'abord, vérifiez la version de Docker et l'état de Swarm :

docker version --format '{{.Server.Version}}'
docker info --format '{{.Swarm.LocalNodeState}} {{.Swarm.Nodes}}'

Exemple de sortie attendue :

20.10.12
active 5

Cela indique Docker Engine 20.10.12 et un Swarm actif avec cinq nœuds.

Listez tous les nœuds avec leurs rôles et leur disponibilité :

docker node ls

Colonnes de sortie : ID, HOSTNAME, STATUS, AVAILABILITY, MANAGER STATUS. Vérifiez que tous les nœuds sont Ready et Active.

Inspectez les ressources de chaque nœud :

docker node inspect --format '{{.Description.Hostname}} CPUs={{.Description.Resources.NanoCPUs}} Memory={{.Description.Resources.MemoryBytes}}' <node-id>

NanoCPUs sont des milliardièmes de CPU (1e9 = 1 CPU). MemoryBytes est en octets. Exemple :

worker-01 CPUs=4000000000 Memory=16777216000

Cela signifie 4 CPU et 16 Go de RAM.

Notez les versions du système d'exploitation et du noyau, car elles affectent les limites de ressources :

uname -a

Listez les services actuels et leurs réservations/limites de ressources :

docker service ls
docker service inspect --format '{{.Spec.Name}} Reservations: CPU={{.Spec.TaskTemplate.Resources.Reservations.NanoCPUs}} Mem={{.Spec.TaskTemplate.Resources.Reservations.MemoryBytes}} Limits: CPU={{.Spec.TaskTemplate.Resources.Limits.NanoCPUs}} Mem={{.Spec.TaskTemplate.Resources.Limits.MemoryBytes}}' <service-name>

Si les ressources ne sont pas définies, elles s'affichent comme 0. Cet inventaire constitue votre base de référence pour la planification.

Configurez des limites de ressources sûres

Après l'inventaire, configurez les réservations et les limites de ressources pour chaque service. Les réservations garantissent des ressources minimales ; les limites plafonnent l'utilisation maximale. Définissez-les dans la définition de votre service (fichier Compose ou commande docker service create). Exemple pour un service web :

# docker-compose.yml
version: '3.8'
services:
  web:
    image: nginx:latest
    deploy:
      replicas: 3
      resources:
        reservations:
          cpus: '0.25'
          memory: 128M
        limits:
          cpus: '0.5'
          memory: 256M

Déployez avec :

docker stack deploy -c docker-compose.yml mystack

Vérifiez avec docker service inspect --pretty mystack_web pour voir la section des ressources.

Définissez des contraintes de placement pour placer les services sur des nœuds appropriés. Par exemple, uniquement sur des nœuds étiquetés avec SSD :

placement:
  constraints:
    - node.labels.storage == ssd

Ajoutez des étiquettes aux nœuds avec :

docker node update --label-add storage=ssd node1

Utilisez les configurations de mise à jour pour contrôler les mises à jour progressives et éviter les pics de capacité :

update_config:
  parallelism: 1
  delay: 10s
  failure_action: rollback
  max_failure_ratio: 0.2

Cela met à jour une tâche à la fois avec un délai de 10 secondes, et revient en arrière si plus de 20 % échouent.

Pour la planification de capacité, surveillez l'utilisation réelle et ajustez progressivement les limites. Commencez par des limites prudentes basées sur la charge de pointe attendue, puis ajustez à l'aide des données de surveillance. Par exemple, si votre service web utilise généralement 150 Mo de mémoire en charge, définissez la réservation à 128 Mo et la limite à 256 Mo pour laisser une marge de manœuvre.

Vérifiez les configurations de ressources

Après avoir défini les limites, vérifiez qu'elles fonctionnent comme prévu. Utilisez les commandes suivantes et les résultats attendus.

Vérifiez les tâches du service et leur utilisation des ressources :

docker stats --no-stream

La sortie affiche le pourcentage de CPU par conteneur, l'utilisation de la mémoire et la limite. Comparez avec vos paramètres.

Inspectez la disponibilité des ressources des nœuds :

docker node inspect --format '{{.Description.Hostname}} CPUs={{.Description.Resources.NanoCPUs}} Memory={{.Description.Resources.MemoryBytes}}' <node-id>

Simulez le retrait d'un nœud pour tester la capacité :

docker node update --availability drain <node-id>

Le drainage garantit que les tâches sont replanifiées ailleurs, ce qui vérifie la capacité.

Testez le retour en arrière en introduisant une limite de mémoire trop basse et en observant l'échec :

docker service update --limit-memory 32M mystack_web

Si le conteneur dépasse 32 Mo, Docker le tue et le service peut revenir en arrière s'il est configuré.

Vérifiez les événements pour les dépassements de mémoire (OOM) :

docker events --filter type=container --filter event=oom

Cela affiche les événements de mémoire insuffisante, indiquant des problèmes de capacité.

Utilisez docker service ps pour voir les tentatives de tâches et les erreurs :

docker service ps mystack_web

Recherchez les tâches REJECTED ou FAILED dues à des ressources insuffisantes. Résultats attendus : les services sains affichent des tâches en cours d'exécution, aucun événement OOM et une utilisation des ressources inférieure aux limites.

Diagnostiquez les pannes de capacité

Comprendre les modes de défaillance courants vous aide à récupérer rapidement.

Épuisement des ressources du nœud

Un nœud manque de mémoire ou de CPU. Les symptômes incluent des tâches évincées, des arrêts OOM ou l'impossibilité pour le planificateur de placer des tâches. Étapes de récupération :

1. Drainez le nœud pour déplacer les charges de travail :

   docker node update --availability drain nodeX

1. Enquêtez avec docker stats pour trouver le conteneur fautif.
2. Ajustez les limites ou ajoutez de la capacité. Par exemple, si un conteneur utilise systématiquement 90 % de sa limite de mémoire, augmentez la limite ou réduisez les réplicas.

Échec de la mise à l'échelle du service

La mise à l'échelle entraîne des erreurs « aucun nœud approprié ». Vérifiez les contraintes et les ressources disponibles :

docker service scale mystack_web=10
docker service ps mystack_web

Les tâches en attente indiquent des ressources insuffisantes ou des contraintes non satisfaites. Ajustez les contraintes ou ajoutez des nœuds.

Croissance de mémoire non bornée

Un conteneur fuit de la mémoire et atteint sa limite, provoquant des redémarrages répétés. Limitez la mémoire avec :

docker service update --limit-memory 512M mystack_web

Mais assurez-vous que la surveillance alerte avant d'atteindre la limite. Revenez à la configuration précédente si nécessaire :

docker service rollback mystack_web

Réservations inadéquates

Les services sans réservations peuvent être planifiés sur des nœuds surchargés. Définissez des réservations pour garantir une capacité minimale à chaque service.

Saturation du réseau

La bande passante du réseau overlay est dépassée. Surveillez avec docker network inspect et utilisez des outils de trafic réseau. Envisagez un maillage de services ou des réseaux séparés.

Gardez toujours une marge de capacité : au moins 20 à 30 % de marge sur chaque nœud pour le basculement et les pics.

Pièges courants et comment les éviter

Les erreurs de planification de capacité sont fréquentes. Voici les pièges et comment les éviter :

Piège : aucune limite de ressources

Pourquoi cela arrive : Les équipes omettent les limites pour éviter la complexité ou supposent que les conteneurs se comporteront bien.

Comment l'éviter : Définissez des limites et des réservations pour chaque service en production. Utilisez un modèle dans vos fichiers Compose et révisez régulièrement. Par exemple :

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 256M

Piège : surprovisionnement

Pourquoi cela arrive : La peur des pannes conduit à des limites généreuses qui gaspillent la capacité du cluster et augmentent les coûts.

Comment l'éviter : Surveillez l'utilisation réelle avec docker stats et définissez les limites en fonction du 95e centile plus une marge de 20 %. Ajustez trimestriellement.

Piège : ignorer la marge de manœuvre des nœuds

Pourquoi cela arrive : Les équipes se concentrent sur les services individuels mais oublient de laisser de la marge sur les nœuds pour les processus système et le basculement.

Comment l'éviter : Assurez-vous que le total des ressources allouées à chaque nœud ne dépasse pas 70 à 80 % de la capacité. Utilisez docker node inspect pour additionner les réservations.

Piège : ne pas tester le basculement

Pourquoi cela arrive : Les hypothèses sur la replanification ne sont jamais validées.

Comment l'éviter : Drainez régulièrement un nœud dans un environnement de préproduction et vérifiez que tous les services se replanifient sans erreur. Documentez le processus.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle chaque semaine ou avant tout déploiement majeur. Attribuez un responsable à chaque élément et révisez mensuellement.

De plus :

• Configurez des alertes : utilisez des outils de surveillance (par exemple, Prometheus, cAdvisor) pour alerter lorsque le CPU du nœud > 80 % ou la mémoire > 85 %.
• Effectuez des tests de charge : avant la mise à l'échelle, simulez la charge de pointe pour valider la capacité.
• Révisez régulièrement les contraintes de placement et les étiquettes des nœuds pour les aligner sur la planification de capacité.

Conclusion

La planification de capacité pour Docker Swarm est un processus continu de mesure, d'ajustement et de vérification. En inventoriant votre environnement, en définissant des réservations et des limites de ressources explicites, en surveillant l'utilisation et en vous préparant aux pannes, vous maintenez un cluster stable. Les prochaines étapes consistent à établir une base de référence à l'aide des commandes de ce guide, à configurer des alertes de surveillance et à planifier des revues de capacité régulières. Commencez petit avec un service pilote, mesurez l'utilisation réelle et évoluez en toute confiance.