Mon secret de mise à l’échelle Kubernetes pour des charges de travail d’agent imprévisibles

Salut, chers agents ! Maya Singh ici, de retour pour explorer les détails du déploiement des agents sur agntup.com. Aujourd’hui, je veux parler de quelque chose qui m’empêche de dormir presque autant que de décider quoi regarder en streaming : le dimensionnement de nos déploiements d’agents dans Kubernetes.

Plus précisément, je souhaite aborder les aspects souvent négligés mais critiques de l’autoscaling horizontal intelligent des pods pour des charges de travail d’agents imprévisibles. Nous savons tous que HPA est génial, mais quand vos agents font des choses radicalement différentes, ou lorsque des événements externes provoquent des pics soudains et massifs, les métriques CPU/mémoire par défaut ne suffisent tout simplement pas. C’est comme essayer de conduire une voiture de Formule 1 avec uniquement un compteur de vitesse – vous manquez d’un tas d’informations cruciales.

La date actuelle est le 18 mars 2026, et si vous vous fiez encore uniquement à l’utilisation CPU pour dimensionner votre flotte d’agents, vous dépensez probablement davantage pour des ressources inactives ou jouez constamment à rattraper votre retard, ce qui entraîne une performance dégradée et des utilisateurs mécontents. Corrigeons cela.

Le piège CPU/Mémoire : Pourquoi le HPA par défaut ne suffit pas pour des agents intelligents

Je me souviens d’une fois, il y a environ un an et demi, où nous venions de lancer une nouvelle fonctionnalité pour nos agents de surveillance. Ces agents étaient censés collecter des journaux et des métriques très spécifiques de l’infrastructure des clients, les traiter localement, puis les renvoyer à notre plateforme centrale. Ça semble simple, non ? Faux.

Le problème était que nous avions quelques clients d’entreprise avec des configurations de journalisation monstrueusement verbeuses. Un client particulier, une grande institution financière, a décidé d’activer la journalisation de débogage sur l’ensemble de sa flotte juste après notre mise à jour. Soudain, nos agents, qui tournaient tranquillement à 20 % de CPU pour la plupart des clients, ont commencé à grimper à 90 % et au-delà pour ce seul client. Notre HPA, configuré pour un objectif de CPU de 70 %, a été activé, ajoutant plus de pods. Mais voici le hic : le goulot d’étranglement n’était pas seulement CPU. C’était aussi le rythme auquel ils pouvaient traiter et envoyer des données, ce qui impliquait parfois des appels d’API externes avec des limites de taux.

Nous nous sommes retrouvés avec des dizaines de pods pour ce seul client, tous en surchauffe, n’améliorant guère la situation car le goulot d’étranglement externe demeurait. Nos coûts sont montés en flèche et l’expérience client était terrible. Nous avons dimensionné plus, mais nous n’avons pas dimensionné plus intelligemment.

Cette expérience a souligné une vérité fondamentale : les métriques de ressources génériques (CPU, mémoire) sont bonnes pour les applications à usage général, mais pour les agents avec des tâches spécifiques, en particulier ceux interagissant avec des systèmes externes ou traitant des charges de travail variables, il faut aller plus loin. Vous avez besoin de métriques personnalisées.

Au-delà des Bases : Des métriques personnalisées pour un autoscaling plus intelligent

C’est ici que la magie opère. Le HPA de Kubernetes vous permet de dimensionner en fonction de métriques personnalisées que vous définissez. Cela peut être tout ce qui reflète réellement la charge de travail que vos agents gèrent. Pensez à ce qui met réellement vos agents à l’épreuve ou indique un arriéré. Pour mes agents de traitement des journaux, ce n’était pas seulement le CPU ; c’était :

• Lignes de journaux traitées par seconde : Une mesure directe du volume d’entrée.
• Événements en attente dans la file d’attente interne : Un indicateur d’arriéré interne avant d’envoyer des données.
• Latence/taux d’erreur des appels d’API externes : Si votre agent communique avec des services externes, c’est crucial.

Prenons l’exemple des “événements en attente dans la file d’attente interne”. Imaginez que votre agent collecte des données, les met dans une file d’attente en mémoire, puis qu’une routine en arrière-plan les traite et les envoie. Si cette file d’attente commence à croître rapidement, cela signifie que votre agent ne suit pas. Dimensionner en fonction de la longueur de cette file d’attente s’attaque directement au goulot d’étranglement.

Comment intégrer des métriques personnalisées dans HPA

Cela implique généralement quelques composants :

1. Votre agent : Il doit exposer ces métriques. Le format d’expositions Prometheus est le standard ici. Instrumentez le code de votre agent à l’aide d’une bibliothèque cliente (Go, Python, Java, etc.) pour exposer des métriques comme agent_pending_events_total ou agent_log_lines_processed_per_second.
2. Prometheus : Scrape vos pods d’agents et stocke ces métriques.
3. Prometheus Adapter ou KEDA : C’est le pont.

Personnellement, je préfère KEDA (Kubernetes Event-driven Autoscaling) pour ce type de scénario, surtout lorsqu’il s’agit de gérer des files d’attente externes ou des sources d’événements. Bien que le Prometheus Adapter soit solide pour des métriques personnalisées simples exposées par votre application, KEDA excelle lorsque votre déclencheur de dimensionnement est un flux d’événements réel ou la longueur d’une file d’attente provenant de quelque chose comme Kafka, RabbitMQ, SQS, ou même une API externe personnalisée. Elle offre une manière plus déclarative et souvent plus simple de définir ces règles de dimensionnement.

Disons que notre agent expose une métrique Prometheus appelée agent_pending_events_total. Nous voulons augmenter le nombre de pods si la valeur moyenne de cette métrique sur tous les pods pour un déploiement donné dépasse 1000.

Tout d’abord, assurez-vous que votre agent expose cette métrique :

# Exemple de code Python utilisant la bibliothèque cliente Prometheus
from prometheus_client import Gauge, start_http_server
import time
import random

pending_events_gauge = Gauge('agent_pending_events_total', 'Nombre d\'événements en attente dans la file d\'attente interne')

def run_agent_loop():
 while True:
 # Simuler des travaux et des changements de file d'attente
 current_pending = random.randint(100, 1500) # Simuler un arriéré variable
 pending_events_gauge.set(current_pending)
 print(f"Événements en attente actuels : {current_pending}")
 time.sleep(5)

if __name__ == '__main__':
 start_http_server(8000) # Exposer les métriques sur le port 8000
 run_agent_loop()

Ensuite, vous devez configurer votre configuration Prometheus pour récupérer ces métriques de vos pods d’agents. En supposant que vos pods d’agents aient l’annotation prometheus.io/scrape: "true" et prometheus.io/port: "8000", Prometheus les récupérera.

Maintenant, examinons une définition de ScaledObject pour KEDA. Cela suppose que vous avez KEDA installé dans votre cluster.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: my-agent-scaler
 namespace: agents
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: my-agent-deployment # Le nom de votre déploiement d'agents
 minReplicaCount: 1
 maxReplicaCount: 10
 pollingInterval: 30 # Vérifier les métriques toutes les 30 secondes
 triggers:
 - type: prometheus
 metadata:
 serverAddress: http://prometheus-kube-prometheus-thanos-proxy.monitoring.svc.cluster.local:9090 # Votre point de service Prometheus
 metricName: agent_pending_events_total
 query: |
 avg(agent_pending_events_total) by (pod) # Événements en attente moyens par pod
 threshold: "1000" # Dimensionner si le nombre d'événements en attente moyens par pod dépasse 1000
 # Utilisez `query` au lieu de `metricName` et `threshold` pour des scénarios plus complexes
 # Par exemple, pour cibler une moyenne sur le déploiement plutôt que par pod :
 # query: |
 # sum(agent_pending_events_total) / count(agent_pending_events_total)
 # threshold: "1000"
 # Cet exemple cible la moyenne par pod, ce qui est souvent plus utile pour la capacité individuelle de l'agent.

Une note sur la requête Prometheus : j’ai utilisé avg(agent_pending_events_total) by (pod). KEDA (et HPA avec Prometheus Adapter) vont généralement agréger les métriques à travers les pods appartenant à la cible dimensionnée. Si vous ciblez une moyenne *par pod*, c’est une bonne manière de définir un seuil qui reflète véritablement la charge de chaque agent. Si vous voulez dimensionner en fonction de l’arriéré total sur l’ensemble du déploiement, vous ajusteriez la requête en conséquence.

Scénarios Avancés : Combiner les Métriques et le Dimensionnement Prédictif

Que faire si une métrique ne suffit pas ? Que faire si vous devez prendre en compte à la fois la profondeur de la file d’attente ET le CPU ? C’est ici que les choses deviennent vraiment intéressantes. KEDA vous permet de définir plusieurs déclencheurs. Le ScaledObject dimensionnera alors en fonction du déclencheur qui demande le plus de réplicas.

Imaginons que notre agent fasse également un traitement d’image lourd, rendant le CPU à nouveau un facteur pertinent. Nous pourrions ajouter un autre déclencheur :

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: my-agent-scaler
 namespace: agents
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: my-agent-deployment
 minReplicaCount: 1
 maxReplicaCount: 10
 pollingInterval: 30
 triggers:
 - type: prometheus # Déclencheur 1 : Événements en attente
 metadata:
 serverAddress: http://prometheus-kube-prometheus-thanos-proxy.monitoring.svc.cluster.local:9090
 metricName: agent_pending_events_total
 query: |
 avg(agent_pending_events_total) by (pod)
 threshold: "1000"
 - type: cpu # Déclencheur 2 : Utilisation du CPU
 metadata:
 value: "70" # Dimensionner si l'utilisation moyenne du CPU dépasse 70%

Maintenant, KEDA veillera à ce que votre déploiement augmente s’il y a soit plus de 1000 événements en attente par pod, soit si l’utilisation moyenne du CPU dépasse 70 %. Cela vous offre une stratégie d’autoscaling plus complète et solide.

Dimensionnement Prédictif : Regarder vers l’Avenir

Alors que KEDA et les métriques personnalisées répondent merveilleusement au dimensionnement réactif, parfois, même la réaction la plus rapide n’est pas suffisante. Pensez à des travaux batch planifiés qui frappent vos agents à 3 heures du matin chaque jour, ou à une campagne marketing connue qui va générer un pic d’inscriptions de nouveaux utilisateurs, chacun nécessitant une interaction avec l’agent. C’est là que le dimensionnement prédictif entre en jeu.

Le dimensionnement prédictif n’est pas quelque chose que KEDA ou HPA natif font directement, mais ils peuvent être intégrés à des systèmes externes. Vous auriez généralement besoin de :

• Données Historiques : Stockez vos métriques personnalisées et événements de mise à l’échelle au fil du temps.
• Modèle de Prévision : Utilisez l’apprentissage automatique (par exemple, ARIMA, Prophet) pour prédire les pointes de charge futures en fonction des schémas historiques.
• Élargisseur Externe : Un contrôleur ou un script personnalisé qui utilise ces prévisions pour ajuster votre minReplicaCount ou même mettre à l’échelle directement votre déploiement via l’API Kubernetes *avant* que la pointe ne se produise.

J’ai expérimenté avec une version basique de cela en utilisant un script Python qui extrait des données de Prometheus, exécute un simple modèle Prophet, puis utilise kubectl scale pour ajuster le déploiement. Ce n’est pas prêt pour la production pour tout le monde, mais pour des pointes prévisibles et récurrentes, cela peut vous éviter ces moments de panique « pourquoi tous nos agents tombent-ils ? ». L’essentiel est d’avoir une bonne boucle de rétroaction et de continuellement affiner vos prévisions.

Surveillance de l’Efficacité de Votre Autoscaling

Déployer un autoscaling intelligent n’est pas une opération « à configurer et à oublier ». Vous devez surveiller son efficacité. Je mets toujours en place des tableaux de bord dans Grafana pour suivre :

• Nombre de Réplicas : Combien de pods sont en cours d’exécution pour chaque déploiement.
• Métriques Cibles : Les valeurs réelles des métriques personnalisées sur lesquelles vous vous basez pour mettre à l’échelle (par exemple, agent_pending_events_total, utilisation CPU).
• Utilisation des Ressources : Utilisation réelle du CPU et de la mémoire des pods.
• Latence/Erreurs des Agents : Métriques de performance de bout en bout pour s’assurer que la mise à l’échelle améliore réellement l’expérience utilisateur.

En corrélant ces éléments, vous pouvez voir si votre stratégie de mise à l’échelle fonctionne comme prévu. Êtes-vous en train de mettre à l’échelle assez rapidement ? Êtes-vous en sur-provisionnement ? La capacité ajoutée soulage-t-elle réellement le goulet d’étranglement ? Ces questions sont cruciales pour optimiser à la fois la performance et le coût.

Une chose spécifique que je surveille est le comportement « oscillant » – où le nombre de réplicas monte et descend rapidement. Cela indique souvent que vos seuils sont trop agressifs ou que votre intervalle de sondage est trop court, ce qui entraîne une instabilité. Vous voulez une mise à l’échelle fluide et réactive, pas des montagnes russes.

Prise de Parole Actionnable pour Votre Prochain Déploiement d’Agents

1. Identifier les Véritables Goulets d’Étranglement : Ne supposez pas que le CPU est toujours le problème. Pour les charges de travail des agents, pensez aux profondeurs de file d’attente, aux taux d’E/S, aux dépendances des API externes ou aux taux d’achèvement des tâches spécifiques.
2. Instrumenter Vos Agents : Assurez-vous que vos agents exposent des métriques personnalisées pertinentes dans un format standard (comme Prometheus). C’est fondamental.
3. Adopter KEDA : Pour une mise à l’échelle basée sur des événements ou des métriques personnalisées, KEDA est un outil puissant et flexible qui simplifie la configuration par rapport au HPA brut avec l’adaptateur Prometheus pour des scénarios complexes.
4. Combiner les Métriques : N’ayez pas peur d’utiliser plusieurs déclencheurs (CPU + métrique personnalisée) pour garantir une couverture complète de la mise à l’échelle. KEDA gère cela avec élégance en se mettant à l’échelle vers le nombre le plus élevé de réplicas demandés.
5. Surveiller et Itérer : L’autoscaling est un processus itératif. Surveillez continuellement votre comportement de mise à l’échelle, l’utilisation des ressources et la performance de l’application. Ajustez les seuils, les intervalles de sondage, et même vos métriques personnalisées au besoin.
6. Considérer la Mise à l’échelle Prédictive (avec Précaution) : Pour les charges de travail ayant des schémas hautement prévisibles, explorez l’intégration de modèles de prévision avec un contrôleur externe pour pré-mise à l’échelle de vos déploiements. Commencez simplement et validez rigoureusement.

Mettre à l’échelle les agents efficacement ne consiste pas simplement à ajouter plus de puissance de calcul au problème ; il s’agit de fournir la bonne quantité de puissance de calcul au bon moment, en fonction de ce qui entraîne réellement la charge de travail de votre agent. En allant au-delà des métriques génériques de CPU et de mémoire et en adoptant des signaux personnalisés et spécifiques à l’application, vous pouvez construire une flotte d’agents vraiment résiliente, rentable et performante. Et croyez-moi, votre emploi du temps de sommeil vous remerciera.

Jusqu’à la prochaine fois, gardez ces agents actifs !

Maya Singh, agntup.com

Articles Connexes

• Je Scale Mes Déploiements d’Agents Cloud Sans Perdre de Sommeil
• Comment Ajouter de l’Authentification avec Weaviate (Étape par Étape)
• Vérifications de la Santé des Agents : Une Plongée Profonde avec des Exemples Pratiques

🕒 Published: March 26, 2026