Kubernetes capacity planning avec exemples pratiques : guide d'implémentation

Introduction

Le Kubernetes capacity planning consiste à traduire la demande réelle en un ensemble cohérent de requests, limits, réplicas et types de nœuds, puis à démontrer la validité du résultat par des mesures. Ce guide, concret et orienté exemples, propose un flux de travail que vous pouvez appliquer à un service dès aujourd'hui, puis étendre à l'échelle du cluster.

Vous apprendrez à :

Définir des SLO et un baseline de charge.
Dimensionner les requests/limits CPU et mémoire à partir de mesures.
Choisir des signaux de scaling pour HPA et utiliser VPA en mode sécurisé.
Planifier les types de nœuds et la densité de pods avec des marges de sécurité.
Intégrer stockage et réseau dans les calculs.
Construire des tableaux de bord Prometheus liés au risque.

Thèmes connexes utilisés dans les exemples : images Docker, valeurs Helm, pics GitLab CI/CD, Nginx Ingress, stockage adossé à Ceph et métriques Prometheus.

Vue d'ensemble du workflow

Appliquez cette séquence réutilisable à chaque workload :

Fixer les SLO et prévoir la demande.
Mesurer un baseline sur une seule réplique.
Convertir les mesures en requests/limits.
Choisir le nombre de réplicas et les signaux HPA ; activer VPA en mode recommandation seule.
Planifier les nœuds et la densité de pods ; assurer de la marge.
Inclure budgets stockage et réseau.
Ajouter des dashboards et alertes liés aux SLO et à la saturation.
Lancer un pilote, analyser les résultats, puis élargir le périmètre.

Chaque étape produit des artefacts versionnables dans Git : values.yaml, Deployment, HPA et configurations de dashboards.

Définir SLO et baseline

Choisissez des cibles concrètes et des entrées sur lesquelles dimensionner :

SLO de disponibilité : 99,9 % mensuel pour le service.
SLO de latence : p95 HTTP ≤ 200 ms au pic.
Trafic : prévoir QPS de pointe, tailles de payload et traitements d'arrière‑plan.
Fenêtres batch : pics GitLab CI/CD en début d'heure ; jobs nocturnes.

Mesurez une seule réplique avec des données réalistes :

CPU par requête (ms CPU par requête sur un baseline 1 vCPU).
Working set mémoire (MiB) en régime et pendant les pointes (GC, compactions).
I/O : requêtes par seconde et octets pour stockage et réseau.

Exemples rapides :

kubectl top pods -n app
kubectl describe node <nodeName> | egrep -i "capacity|allocatable|pods"

Si le service est en frontal Nginx Ingress, activez les access logs et exportez QPS et histogrammes de latence vers Prometheus.

Dimensionnement des requests et limits

Traduisez les mesures en spécifications de ressources Kubernetes. L'objectif est d'éviter le CPU throttling et les OOMKills tout en préservant l'efficacité du bin packing.

Supposons une API stateless derrière Nginx avec ce baseline sur une réplique :

QPS de pointe : 200
CPU par requête : 2 ms sur 1 vCPU
Working set mémoire stable : 350 MiB, pic p95 : 500 MiB

CPU :

CPU nécessaire = QPS × CPU_par_requête = 200 × 0,002 = 0,4 vCPU
+20 % de marge pour la gigue et les lib : 0,48 vCPU
Arrondir requests.cpu à 600m ; fixer limits.cpu à 1200m pour permettre du burst sans famine

Mémoire :

Request = working set p95 × 1,2 = 500 MiB × 1,2 = 600 MiB
Limit = Request × 1,5 = 900 MiB (laisse de la place avant OOM et révèle les fuites)

Exemple Helm values (values.yaml) :

resources:
  requests:
    cpu: "600m"
    memory: "600Mi"
  limits:
    cpu: "1200m"
    memory: "900Mi"

Extrait de Deployment :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: api
        image: registry.local/api:1.2.3
        resources:
          requests:
            cpu: "600m"
            memory: "600Mi"
          limits:
            cpu: "1200m"
            memory: "900Mi"

Règles pratiques défendables :

Démarrez des requests proches du p95 observé ; gardez des limits 1,5× à 2× pour les services CPU‑bound.
Pour la mémoire, fixez les limits avec prudence. Trop serrés = OOMKills ; trop larges = fuites masquées. Surveillez les redémarrages.
Recalculez après chaque version modifiant les performances.

Réplicas et autoscaling

Choisissez d'abord le nombre de réplicas pour la disponibilité, puis ajoutez l'autoscaling.

Réplication pour la disponibilité :

Minimum 2 réplicas par zone pour la HA.
En mono‑zone : 3 réplicas sur des nœuds différents pour tolérer un drain de nœud.

HPA basé sur l'utilisation CPU :

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

Métriques personnalisées (recommandé si la latence ou un backlog priment sur le CPU) :

Utilisez le débit de requêtes par réplique, la profondeur de file, ou la latence p90 via Prometheus Adapter.

Exemple de métrique HPA "Pods" :

  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "150"

VPA en mode recommandation seule pour éviter les conflits avec HPA :

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: api
  updatePolicy:
    updateMode: "Off"

Lisez les recommandations, mettez à jour les requests dans Git, puis redéployez.

Scaling par fenêtre temporelle pour les pics batch :

Utilisez un CronJob qui patche le nombre de réplicas avant/après une fenêtre connue.
Ou alimentez le HPA avec une métrique de backlog pour une réaction automatique.

Nœuds et bin packing

Calculez l'allocatable, limitez la densité, et évitez les voisins bruyants.

Exemple de type de nœud :

Instance : 4 vCPU, 16 GiB RAM
kube-reserved + système : 0,5 vCPU, 1,5 GiB
Allocatable : 3,5 vCPU, 14,5 GiB

Avec un pod api à 600m CPU et 600Mi de request :

Max pods CPU‑bound par nœud par CPU = floor(3,5 / 0,6) = 5
Par mémoire = floor(14,5 GiB / 0,6 GiB) = 24
Le CPU est le goulot ; planifiez 5 pods api par nœud maxi.

Bonnes pratiques :

Fixez un plafond de pods par nœud sous le maximum théorique (p. ex. 30) pour laisser de la place aux DaemonSets et aux surges de rollout.
Utilisez PodTopologySpread pour répartir les réplicas sur nœuds et zones.
Pour les workloads bruyants (builds, runners GitLab CI), isolez avec taints/tolerations ou des pools de nœuds dédiés.

Stockage et réseau

Ne négligez pas l'I/O ; de nombreux incidents viennent de la saturation disque ou lien alors que le CPU paraît sain.

Capacité Ceph :

Un facteur de réplication 3 donne une capacité effective d'environ brut × 0,33 avant métadonnées et overhead. Gardez les pools sous ~70 % pour éviter les falaises de latence.
Prévoyez le trafic de recovery lors d'une défaillance OSD ; gardez de la marge réseau.

Débit et IOPS :

Mesurez p95 IOPS lecture/écriture et MiB/s en régime et lors des fenêtres de maintenance (sauvegardes, compaction, réindexation).
Pour les services verbeux en logs, envisagez un NVMe local avec rétention bornée et expédition asynchrone vers un objet storage.

Ingress et egress :

Pour Nginx Ingress, suivez le nombre de requêtes/s, les tailles de réponse et les histogrammes de latence upstream. Dimensionnez le CPU pour la terminaison TLS et gzip.
Budgétez l'egress inter‑zone et inter‑cluster ; regroupez les services bavards dans la même zone si possible.

Observabilité

Reliez dashboards et alertes aux SLO et à la saturation, pas uniquement aux métriques hôtes.

Requêtes Prometheus de départ :

CPU par pod :

rate(container_cpu_usage_seconds_total{container!="",pod=~"api-.*"}[5m])

Working set mémoire par pod :

container_memory_working_set_bytes{container!="",pod=~"api-.*"}

Nginx : débit et latence (si exporté) :

sum(rate(nginx_ingress_controller_requests[1m])) by (ingress)
histogram_quantile(0.95, sum(rate(nginx_ingress_controller_request_duration_seconds_bucket[5m])) by (le, ingress))

Profondeur de file ou backlog applicatif comme métrique HPA.

Alertes :

Burn rate contre le SLO de latence.
CPU allocatable nœud > 80 % pendant 10 min.
Compte OOMKill de pods > 0 en 5 min.
Ceph pool fullness > 70 % et OSD nearfull.

Marges de sécurité et coût

Visez la résilience sans gaspillage.

Maintenez l'utilisation CPU et mémoire cluster‑wide sous 70 % en régime pour absorber pics et perturbations.
Pour les services critiques, gardez une capacité N+1 dans chaque domaine de défaillance.
Suivez le coût par requête : somme des coûts nœuds, stockage et egress divisée par les requêtes réussies. Servez‑vous‑en pour affiner requests et limits dans le temps.
Révisez la taille après tout changement majeur de code ou de dépendance.

Plan pilote local

Commencez petit, mesurez, puis élargissez.

Périmètre :

Une API stateless derrière Nginx Ingress.
Ajoutez des requests/limits, un HPA sur CPU à 70 % de cible, et un VPA en mode recommandation seule.
Dashboards pour CPU, mémoire, QPS, latence p95 et taux d'erreur.

Étapes :

Ajouter requests/limits et déployer dans un namespace de staging.
Lancer un test de charge contrôlé jusqu'au QPS cible de pointe.
Relever CPU/requête et working set mémoire ; recalculer les requests si besoin.
Activer HPA et vérifier la montée/descente et la stabilisation.
Valider la marge : gardez les nœuds sous 70 % CPU au pic.
Documenter les résultats et déployer en production dans une région/cluster.

Critères d'acceptation :

p95 de latence ≤ SLO à la charge cible.
Aucun OOMKill ni alerte de throttling.
HPA scale en moins de 2 minutes sur un saut de charge.
Taux d'éviction nœud/pod quasi nul pendant le test.

Plan de rollback :

Conserver la révision précédente du Deployment et un manifest HPA désactivé.
Si des alertes déclenchent, revenir au dernier nombre de réplicas stable et augmenter les requests.

Conclusion

Un plan de capacité Kubernetes efficace part de SLO clairs, transforme les mesures en requests et limits, choisit des signaux de scaling qui reflètent la charge réelle et conserve la marge nécessaire pour absorber pannes et pointes. Lancez un petit pilote sur un service, validez contre des critères explicites, puis étendez progressivement. À mesure que les workloads et le trafic évoluent, réexaminez vos hypothèses, gardez des dashboards honnêtes et ajustez requests, limits et pools de nœuds sur preuves. Intégrez des mots‑clés industriels tels que Kubernetes capacity planning, Kubernetes scaling, Kubernetes resources, Kubernetes limits et Kubernetes sizing de façon naturelle pour conserver la découvrabilité technique.