Planification de capacité Kubernetes pour une croissance fiable

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

16 min de lecture

La planification de capacité pour Kubernetes est une discipline opérationnelle, et non une estimation ponctuelle du nombre de nœuds. Elle relie la demande attendue aux ressources et dépendances qui réalisent un travail utile : réplicas applicatifs, capacité du scheduler, nœuds, adresses réseau, stockage, bases de données, files d'attente, systèmes d'identité, API tierces et chemin de livraison devant le cluster.

Pour une entreprise qui exploite un point d'entrée intelligent unique devant son origine, cette discipline se cumule plutôt que de disparaître : une périphérie orchestrée peut absorber un pic, mais elle ne peut pas fabriquer des connexions de base de données ou des pods prêts que l'origine n'a jamais planifiés — elle ne fait que renvoyer plus vite la véritable limite de l'origine. Traitez le plan du cluster et le plan de routage et de cache de la périphérie comme un seul système mesuré, pas comme deux équipes qui devinent chacune la marge de l'autre.

Scénario : la campagne saisonnière du catalogue d'Acme Shop

Acme Shop prévoit 600 requêtes de catalogue par seconde au pic normal de campagne, puis un pic de 900 requêtes par seconde pendant 15 minutes après le lancement d'un email. Un pod catalog-api testé sert 75 requêtes par seconde à la latence p95 cible, donc le cluster a besoin de 12 réplicas pour absorber le pic (900 / 75 = 12). Acme prévoit 15 réplicas avec une marge de charge de travail de 25 % (12 × 1,25 = 15), avant même de tenir compte d'une panne de nœud. Chaque pod demande 500 m de CPU et 512 Mi de mémoire, si bien que ces 15 réplicas demandent au total 7,5 CPU et 7,5 Gi de mémoire — et la base de données, l'ingress, l'allocation d'IP et le registre d'images doivent, indépendamment les uns des autres, supporter ce même scénario.

L'objectif d'Acme : approuver cette campagne avec une capacité d'origine et de dépendances suffisante pour absorber le pic mesuré, la perte d'un pool de nœuds et un basculement régional borné de trafic, à partir d'un historique de demande par route, de données de test représentatives et des demandes/limites actuelles.

Le modèle de capacité suit la transaction du client à travers cinq couches : prévision de demande (lectures publiques, trafic authentifié, écritures, travail en arrière-plan), périphérie et ingress (cache-hit, capacité de connexion, pic de miss après invalidation), charge de travail Kubernetes (débit par pod traduit en réplicas et espace nœud), dépendances partagées (base de données, files, stockage, identité), et rôle de la défaillance — recalculer pour une perte de nœud avant de déclarer la capacité suffisante.

Planification de capacité Kubernetes : convertir la demande en engagements de ressources

La planification de capacité Kubernetes commence par des tests proches de la production qui identifient le débit réellement utile, pas seulement le débit synthétique maximal. Consignez le mélange de requêtes, la taille des payloads, l'état du cache et la distribution régionale. Un modèle fondé sur les seules moyennes quotidiennes masquera les pics courts et les pics de reprise : incluez une évacuation régionale ou une panne de dépendance, car les retries et l'accumulation de file peuvent rendre la demande de reprise plus importante que le pic initial.

Pour chaque service, cartographiez la première ressource susceptible de le contraindre : CPU et mémoire allocables des nœuds, densité de pods, adresses IP, débit du registre d'images, temps de démarrage des conteneurs, connexions d'ingress et activité de l'API du plan de contrôle. Un ResourceQuota de namespace — par exemple un plafond de bac à sable fixant 10 CPU et 10 Gi de mémoire en demandes pour au plus 20 pods — rend la capacité prévue visible et empêche un test sans rapport de consommer les ressources du namespace ; ce n'est qu'un garde-fou intentionnel, pas une recommandation de production. Dès qu'un namespace impose un quota, chaque pod doit déclarer ses demandes : associez-le à une valeur par défaut de type LimitRange, sinon la création du pod est rejetée.

Cartographiez ensuite les dépendances partagées : connexions de base de données, réplicas en lecture, débit de stockage, files, mémoire cache et quotas du fournisseur d'identité. Demandez-vous si un nouveau réplica ajoute du débit ou ne fait que déplacer le goulot d'étranglement en aval.

L'autoscaling modifie la forme du plan ; il ne l'élimine pas. Mesurez le temps jusqu'à la capacité de bout en bout : détection de métrique, décision de l'autoscaler, provisionnement de nœud, planification de pod, récupération d'image et admission du trafic. S'il est trop lent face à l'augmentation de demande la plus crédible, maintenez une capacité chaude mesurée, réduisez le coût de l'initialisation, ou utilisez une politique d'admission validée par le produit. Ne supposez jamais qu'un ratio de cache ou une règle de routage géographique survivra à une nouvelle publication ou un incident régional.

Le choix de l'autoscaler de nœuds change ce délai : Cluster Autoscaler se limite à ajouter des nœuds à partir de groupes déjà provisionnés, tandis que Karpenter peut provisionner de nouvelles formes à la demande — les deux prennent malgré tout de vraies minutes. La mise à l'échelle de la charge de travail (HPA/VPA) est traitée dans le guide Autoscaling Kubernetes. Traitez les demandes de ressources comme un engagement fondé sur le comportement mesuré : le surengagement semble efficace jusqu'à ce qu'une éviction survienne, et des demandes excessives immobilisent la capacité allouable.

Demandes de ressources et marge : ce que les requêtes achètent réellement

Les demandes de ressources et la marge sont deux leviers distincts. Une demande (request) est ce que le scheduler réserve : elle décide sur quel nœud un pod peut être placé. Une limite (limit) est ce que le kubelet impose une fois le conteneur en cours d'exécution — et CPU et mémoire échouent différemment sous cette limite : le CPU est bridé par le quota CFS du noyau, donc un conteneur surchargé ralentit simplement, tandis que la mémoire est sanctionnée par un OOM kill, donc le conteneur est terminé. Cette asymétrie explique pourquoi Acme garde la demande et la limite de mémoire de catalog-api proches l'une de l'autre, tout en laissant davantage de marge sur le CPU : une réponse lente se rétablit, un pod tué ne se rétablit pas.

La marge est l'écart séparé et délibéré entre ce qui est testé comme nécessaire et ce qui est réellement provisionné — les 25 % du modèle d'Acme sont une décision de risque, pas un paramètre Kubernetes. Définissez-la par niveau de service et conséquence d'une performance dégradée : une charge batch interne stable peut accepter une marge différente d'un parcours de paiement client. Ne publiez jamais un pourcentage universel valable pour tous les clusters. Des demandes sous-dimensionnées rendent la marge inutile ; des demandes surdimensionnées gaspillent la capacité qu'elle suppose disponible.

Deux mécanismes récents changent la donne. Le redimensionnement de pod en place (in-place Pod resize, stable depuis Kubernetes v1.35) permet au kubelet d'appliquer une nouvelle demande ou limite sans recréer le pod — mais cela ne peut toujours pas dépasser la capacité allouable du nœud. La sortie du Vertical Pod Autoscaler est une entrée utile pour fixer la demande de référence à partir de l'utilisation p95/p99 mesurée, mais Acme la traite comme une proposition à examiner, jamais comme une autorité à appliquer automatiquement en pleine campagne.

Test de charge de cluster : valider le modèle sous contrainte, y compris la dégradation

Le test de charge de cluster transforme l'arithmétique précédente en un plan validé. Utilisez des tests proches de la production, augmentez la charge graduellement, puis introduisez un pic borné unique. Enregistrez les indicateurs de niveau de service, les signaux de saturation, les raisons des pods en attente, le ratio de cache-hit et la réponse des dépendances, et arrêtez un test avant qu'il ne risque un impact client incontrôlé. Exécutez ensuite un scénario de perte contrôlée d'un pool de nœuds ou de ralentissement du chemin de lecture de base de données : un endpoint HTTP en bonne santé ne suffit pas si la base de données ne peut pas mener la transaction jusqu'au bout.

Un seul pic ne constitue pas un test de charge de cluster suffisant : exécutez trois formes de test, chacune répondant à une question différente. La montée progressive (ramp) passe de zéro au pic prévu sur plusieurs minutes et confirme que le chiffre de 75 requêtes par seconde par pod tient toujours. Le pic soudain (spike) saute directement à 900 requêtes par seconde sans montée — la forme qu'un vrai lancement d'email produit — et stresse le délai de l'autoscaler plutôt que le débit en régime stable. Le maintien prolongé (soak) tient le pic au-delà de toute fenêtre de TTL de cache ou de rotation de certificat : c'est là que la croissance lente de la mémoire et les fuites de connexions apparaissent, ce qu'un pic de 15 minutes ne révèle jamais.

L'outil retenu (k6, Locust ou équivalent) compte moins que le mélange de requêtes reproduit : respectez le vrai ratio de lectures en cache-hit, de lectures en cache-miss et d'écritures, afin qu'une saturation côté générateur de charge ne soit pas confondue avec une limite du cluster. Pour les services exposés à Internet, mesurez ensemble la latence client, la réponse en périphérie et la saturation de l'origine : un cache public réduit la charge en régime stable, mais les tests à cache froid et après purge doivent prouver que l'origine encaisse la charge de miss.

Soyez précis sur ce qu'une simulation de perte de nœud teste réellement. Un kubectl drain respecte les Pod Disruption Budgets et se met en pause plutôt que de violer un minAvailable — utile pour répéter une maintenance planifiée, mais ce n'est pas une vraie défaillance. Une perte involontaire (panne matérielle, reprise d'un nœud spot) ne consulte jamais le PDB : les pods disparaissent purement et simplement, et les remplacements doivent être planifiés et devenir prêts avant que la capacité ne soit rétablie.

Ces tests révèlent des schémas de diagnostic récurrents. Un cluster qui affiche du CPU disponible pendant que les requêtes s'accumulent en file signale un pool de base de données ou un quota externe saturé, pas un manque de nœuds. Si le HPA demande des réplicas qui ne deviennent jamais prêts, c'est en général le démarrage ou le provisionnement de nœud qui dépasse le rythme de la demande. Et des pods qui redémarrent en boucle sans erreur de planification visible trahissent une limite de mémoire sous-dimensionnée et un OOM kill du noyau, ce qui se corrige en relevant ensemble la demande et la limite.

Anticiper les changements et les approvisionnements

Maintenez une cadence de revue de capacité liée aux lancements produits, aux campagnes marketing et aux délais des fournisseurs. Comparez les prévisions à la demande réelle, révisez le modèle et conservez les preuves de test. Désignez un responsable de décision pour les actions qui prennent du temps : quota de pool de nœuds plus élevé, mise à niveau de base de données ou déploiement régional.

Le travail de capacité doit inclure le coût sans l'optimiser de manière isolée. Supprimer toute capacité disponible accroît le risque et la durée d'une panne ; acheter de la capacité sans prouver le goulot d'étranglement gaspille le budget. Rendez le compromis visible avec des objectifs de service et les contraintes de dépendances — y compris celles, comme l'identité, qu'une prévision centrée sur les lectures de catalogue peut omettre.

Inclure le comportement de périphérie et régional

Pour les services exposés à Internet, combinez la capacité d'origine avec la demande régionale réelle et les mesures de livraison. La politique DNS, la terminaison TLS, le routage des requêtes et l'origin shielding peuvent modifier la charge atteignant un cluster, mais n'éliminent pas les exigences de cohérence ou de chemin d'écriture. Ne supposez pas qu'un ratio de cache ou une règle de routage géographique tiendra lors d'une nouvelle publication ou d'un incident régional.

Testez le pilotage du trafic avec des contrôles de santé représentatifs du parcours utilisateur et une marge d'origine suffisante dans la région de réception. Mesurez ensemble la latence client, la réponse en périphérie et la saturation de l'origine — c'est ainsi qu'un plan de capacité évite de déplacer un goulot d'étranglement d'une couche à une autre, plutôt qu'un cache régional qui absorbe 80 % du trafic normal mais laisse une région de repli jamais dimensionnée pour le reste.

Liste de contrôle de capacité

Avant un pic prévu, vérifiez les hypothèses de demande ; les demandes et limites de ressources par service ; la marge des nœuds, pods et IP ; le temps de mise à l'échelle mesuré ; les limites des dépendances externes ; les résultats des trois formes de test de charge (montée, pic, maintien) ; la capacité de failover régionale ; et les contacts d'escalade. Attribuez un responsable et une date à chaque contrainte non résolue.

Références officielles

• Kubernetes: Resource Management for Pods and Containers
• Kubernetes: Node Autoscaling
• Kubernetes: Resource Quotas
• Kubernetes: Disruptions (Pod Disruption Budgets)
• Kubernetes: Resize CPU and Memory Resources Assigned to Containers
• Google SRE: Capacity Planning