Planification de capacité Kubernetes pour une croissance fiable

Publié le

14 juil. 2026

Temps de lecture

10 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.

L'autoscaling modifie la forme du plan ; il ne l'élimine pas. Un autoscaler ne peut réagir qu'à un signal qu'il peut voir et seulement après que la plateforme a fourni une capacité prête. Le plan doit tenir compte du taux de croissance, de la taille des pics, du délai de montée en charge, des domaines de défaillance, de la maintenance et d'une marge choisie délibérément.

Construire un modèle de demande à partir du travail réel

Commencez par les transactions critiques et les charges de travail en arrière-plan. Consignez le taux d'arrivée de référence et de pointe, le mélange de requêtes, les tailles de payload, les sessions simultanées, la distribution régionale et les variations saisonnières ou liées aux campagnes. Distinguez les lectures, les écritures, le contenu public pouvant être mis en cache, les flux authentifiés, les tâches batch et le trafic administratif, car ils consomment généralement des ressources différentes et ont des délais acceptables différents.

Traduisez le trafic en unités de travail que les ingénieurs peuvent tester : requêtes par seconde et par route, messages de file d'attente par minute, octets transférés, requêtes par transaction ou secondes CPU par tâche. Suivez à la fois la moyenne et la distribution. Un modèle de capacité fondé uniquement sur les moyennes quotidiennes masquera les pics courts qui provoquent saturation et mise en file d'attente.

Incluez la demande de défaillance et de rétablissement. Une panne de dépendance peut générer des retries, des reconnexions, une accumulation de file d'attente et un pic de reprise plus important que le pic initial. Modélisez séparément l'impact d'une évacuation régionale, de la perte d'un pool de nœuds, d'un rollback de déploiement ou d'un basculement de trafic par rapport à la croissance normale.

Inventorier chaque ressource limitante

Pour chaque service, cartographiez la première ressource susceptible de le contraindre et le chemin pour ajouter de la capacité. Les limites Kubernetes courantes comprennent le CPU et la mémoire allocables des nœuds, la densité de pods, les adresses IP, le débit du registre d'images, le temps de démarrage des conteneurs, les opérations de volumes persistants, les connexions d'ingress, le comportement DNS et l'activité de l'API du plan de contrôle. Les ResourceQuotas et LimitRanges de namespace peuvent également être des plafonds intentionnels.

Cartographiez ensuite les dépendances : calcul et connexions de base de données, réplicas en lecture, verrous, débit de stockage, partitions de messages, capacité des consommateurs, mémoire cache, quotas du fournisseur d'identité, API de paiement ou de cartographie et ingestion d'observabilité. Demandez-vous si un nouveau réplica ajoute du débit, ajoute de la contention ou ne fait que déplacer le goulot d'étranglement en aval.

Utilisez les demandes de ressources comme un engagement de planification fondé sur le comportement mesuré, et non comme une valeur de remplacement. Comparez les demandes à l'utilisation réelle et aux ressources requises pendant le démarrage, les pics de trafic, le garbage collection et la maintenance. Le surengagement peut sembler efficace jusqu'à ce qu'une éviction ou un effet de voisin bruyant survienne ; des demandes excessives peuvent immobiliser la capacité allouable et bloquer la montée en charge.

Définir la marge et le temps jusqu'à la capacité

La marge est une décision de risque. Définissez-la par niveau de service, volatilité de la demande, temps d'acquisition des nœuds 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 orienté client. Ne publiez pas un pourcentage universel comme s'il s'appliquait à tous les clusters.

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, initialisation, disponibilité et admission du trafic. Comparez ce temps à l'augmentation de demande crédible la plus rapide. Si la capacité arrive trop tard, les options incluent le maintien de réplicas ou de nœuds chauds, la réduction du coût des images et de l'initialisation, la planification du travail prévisible hors des pics, la limitation de l'admission ou l'ajustement de la livraison de trafic. Chaque option présente un compromis de coût et de mode de défaillance.

Tester le modèle, y compris la dégradation

Utilisez des tests proches de la production avec des jeux de données, un mélange de requêtes, une authentification, des dépendances et une configuration réseau représentatifs. Augmentez la charge graduellement, puis introduisez un pic. Enregistrez les indicateurs de niveau de service, les signaux de saturation, les événements de mise à l'échelle, les raisons des pods en attente, le comportement des nœuds et la réponse des dépendances. Arrêtez un test avant qu'il ne risque un impact client incontrôlé et utilisez un chemin de rollback défini.

Exécutez également des scénarios orientés défaillance : perdez un pool de nœuds, ralentissez un chemin de lecture de base de données, limitez une API externe, épuisez un pool de connexions, retardez le registre d'images ou désactivez un exporteur de télémétrie. Confirmez que les alertes identifient le goulot d'étranglement et que les mécanismes de protection, tels que la contre-pression, les limites de file d'attente et le délestage, préservent les transactions les plus importantes.

Anticiper les changements et les approvisionnements

Maintenez une cadence de revue de capacité liée aux lancements produits, aux campagnes marketing, à l'expansion géographique, aux publications logicielles 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, déploiement régional, modification d'egress, infrastructure réservée ou ajustement de routage de périphérie.

Le travail de capacité doit inclure le coût, mais ne doit pas optimiser le coût de manière isolée. Supprimer toute capacité disponible peut accroître 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, des prévisions de demande, un temps de mise à l'échelle mesuré et les contraintes des dépendances.

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, la politique de cache et l'origin shielding peuvent modifier la charge atteignant un cluster, mais n'éliminent pas les exigences de cohérence, de personnalisation 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, d'un événement d'invalidation ou d'un incident régional.

Testez le pilotage du trafic avec des contrôles de santé qui représentent le parcours utilisateur, une marge d'origine suffisante dans la région de réception et un plan de rollback. Mesurez ensemble la latence visible par le client, la réponse en périphérie, le timing de l'ingress, la saturation de l'origine et le comportement des dépendances. C'est ainsi qu'un plan de capacité évite de déplacer un goulot d'étranglement d'une couche à une autre.

Liste de contrôle de capacité

Avant un pic prévu, vérifiez les hypothèses de demande et le calendrier des changements ; les demandes et limites de ressources par service ; la marge des nœuds, pods et IP ; les bornes d'autoscaling et le temps de mise à l'échelle ; les limites des bases de données et services externes ; la configuration du chemin de livraison ; les résultats de tests de charge ; la capacité de failover régionale ; les seuils d'alerte ; 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
• Google SRE: Capacity Planning
• Kubernetes: Resource Quotas