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

Salut à tous, collègues gestionnaires d’agents ! Maya Singh ici, de retour pour explorer les subtilités du déploiement d’agents sur agntup.com. Aujourd’hui, je veux parler de quelque chose qui me garde éveillée la nuit presque autant que de trouver ma prochaine série à regarder sur mon service de streaming : l’évolutivité de nos déploiements d’agents dans Kubernetes.

Plus précisément, je veux aborder les aspects souvent négligés mais cruciaux 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 lorsque vos agents effectuent des tâches très différentes ou que des événements externes provoquent des pics soudains et massifs, les métriques de CPU/mémoire par défaut ne suffisent tout simplement pas. C’est comme essayer de conduire une voiture de Formule 1 avec seulement un compteur de vitesse – vous manquez une tonne d’informations critiques.

La date actuelle est le 18 mars 2026, et si vous vous fiez encore uniquement à l’utilisation du CPU pour faire évoluer votre flotte d’agents, vous dépensez probablement trop pour des ressources inactives ou jouez constamment à rattraper le coup, ce qui entraîne une dégradation de la performance et des utilisateurs mécontents. Corrigeons cela.

Le Piège CPU/Mémoire : Pourquoi le HPA Par Défaut N’est Pas Suffisant pour les Agents Intelligents

Je me souviens d’une fois, il y a environ un an et demi, nous avions lancé une nouvelle fonctionnalité pour nos agents de monitoring. Ces agents étaient censés collecter des journaux et des métriques très spécifiques de l’infrastructure client, les traiter localement, puis les renvoyer à notre plateforme centrale. Cela semble simple, non ? Mauvaise réponse.

Le problème était que nous avions quelques clients entreprises avec des configurations de journalisation incroyablement verbeuses. Un client en particulier, une grande institution financière, a décidé d’activer la journalisation de débogage sur toute sa flotte juste après notre sortie. Soudainement, nos agents, qui fonctionnaient tranquillement à 20 % de CPU pour la plupart des clients, ont commencé à flamber à 90 % et plus pour ce seul client. Notre HPA, configuré pour un objectif de 70 % CPU, s’est déclenché, ajoutant plus de pods. Mais voici le hic : le goulet d’étranglement n’était pas seulement le CPU. C’était aussi le taux auquel ils pouvaient traiter et envoyer des données, ce qui impliquait parfois des appels API externes avec des limites de taux.

Nous avons fini avec des dizaines de pods pour ce seul client, tous en surchauffe, n’améliorant pas vraiment la situation car le goulet d’étranglement externe demeurait. Nos coûts ont explosé, et l’expérience client était terrible. Nous avons évolué plus, mais pas évolué plus intelligemment.

Cette expérience a mis en lumière 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 des agents avec des tâches spécifiques, en particulier ceux interagissant avec des systèmes externes ou traitant des charges de travail variables, il est nécessaire d’aller plus loin. Vous avez besoin de métriques personnalisées.

Au-delà des Bases : Métriques Personnalisées pour un Autoscaling Plus Intelligent

C’est ici que la magie opère. Le HPA de Kubernetes vous permet de faire évoluer en fonction de métriques personnalisées que vous définissez. Celles-ci peuvent être n’importe quoi qui reflète véritablement la charge de travail que vos agents gèrent. Pensez à ce qui stresse réellement vos agents ou indique un arriéré. Pour mes agents de traitement de journaux, ce n’était pas juste 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 interne : Un indicateur d’arriéré interne avant d’envoyer des données.
• Latence/taux d’erreur des appels API externes : Si votre agent communique avec des services externes, c’est crucial.

Prenons l’« événements en attente dans la file interne » comme exemple. Imaginez que votre agent collecte des données, les met dans une file en mémoire, puis une routine en arrière-plan les traite et les envoie. Si cette file commence à croître rapidement, cela signifie que votre agent n’arrive pas à suivre. Faire évoluer en fonction de la longueur de cette file aborde directement le goulet 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’exposition de Prometheus est le standard ici. Instrumentez le code de votre agent en utilisant 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 : Récupère vos pods d’agents et stocke ces métriques.
3. Adaptateur Prometheus ou KEDA : C’est le pont.

Je penche personnellement pour KEDA (Autoscaling Événementiel Kubernetes) pour ce genre de scénario, surtout lorsqu’il s’agit de files externes ou de sources d’événements. Bien que l’adaptateur Prometheus soit solide pour des métriques personnalisées simples exposées par votre application, KEDA excelle lorsque votre déclencheur d’évolutivité est un véritable flux d’événements ou la longueur de la file d’attente d’un élément tel que Kafka, RabbitMQ, SQS, ou même une API externe personnalisée. Cela fournit une manière plus déclarative et souvent plus simple de définir ces règles d’évolutivité.

Disons que notre agent expose une métrique Prometheus appelée agent_pending_events_total. Nous voulons faire évoluer si la valeur moyenne de cette métrique à travers 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 snippet 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 interne')

def run_agent_loop():
 while True:
 # Simuler du travail et des changements de file
 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) # Expose les métriques sur le port 8000
 run_agent_loop()

Ensuite, vous devriez mettre en place votre configuration Prometheus pour récupérer ces métriques à partir de vos pods d’agents. En supposant que vos Pods d’agents ont l’annotation prometheus.io/scrape: "true" et prometheus.io/port: "8000", Prometheus les récupérera.

Maintenant, regardons une définition ScaledObject de 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 # Nom de votre déploiement d'agent
 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 terminaison 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" # Évoluer si les événements en attente moyens par pod dépassent 1000
 # Utilisez `query` au lieu de `metricName` et `threshold` pour des scénarios plus complexes
 # Par exemple, pour cibler une moyenne à travers 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é d'agent individuelle.

Une note sur la requête Prometheus : j’ai utilisé avg(agent_pending_events_total) by (pod). KEDA (et HPA avec l’adaptateur Prometheus) va généralement agréger les métriques à travers les pods appartenant à la cible évoluée. Si vous ciblez une moyenne *par pod*, c’est un bon moyen de définir un seuil qui reflète réellement la charge individuelle des agents. Si vous vouliez évoluer en fonction de l’arriéré total à travers l’ensemble du déploiement, vous ajusteriez la requête en conséquence.

Scénarios Avancés : Combiner Métriques et Autoscaling Prédictif

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

Imaginez que notre agent effectue é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" # Évoluer si l'utilisation moyenne du CPU dépasse 70 %

Maintenant, KEDA veillera à ce que votre déploiement évolue si soit les événements en attente par pod dépassent 1000, soit l’utilisation moyenne du CPU dépasse 70 %. Cela vous donne une stratégie d’autoscaling plus holistique et solide.

Autoscaling Prédictif : Regarder vers l’Avenir

Alors que KEDA et les métriques personnalisées traitent superbement l’évolutivité réactive, parfois, même la réaction la plus rapide n’est pas suffisante. Pensez aux tâches par lots programmées qui touchent vos agents à 3 heures du matin chaque jour, ou à une campagne de marketing connue qui générera une augmentation des inscriptions d’utilisateurs, chacune nécessitant une interaction avec un agent. C’est là que l’autoscaling prédictif entre en jeu.

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

• Données Historiques : Conservez 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 pics de charge de travail futurs en fonction des modèles historiques.
• Scaler Externe : Un contrôleur ou script personnalisé qui utilise ces prévisions pour ajuster votre minReplicaCount ou même directement mettre à l’échelle votre déploiement via l’API Kubernetes *avant* que le pic ne survienne.

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 modèle Prophet simple, 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 pics prévisibles et récurrents, cela peut vous éviter ces moments paniqués “pourquoi tous nos agents meurent ?!” L’important est d’avoir une bonne boucle de rétroaction et de continuellement affiner vos prévisions.

Surveiller l’Efficacité de Votre Autoscaling

Déployer un autoscaling intelligent n’est pas une opération “à mettre en place et à oublier”. Vous devez surveiller son efficacité. J’installe toujours 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 faites l’échelle (par exemple, agent_pending_events_total, utilisation du 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. Est-ce que vous mettez à l’échelle rapidement ? Êtes-vous en surprovisionnement ? La capacité ajoutée soulage-t-elle vraiment le goulet d’étranglement ? Ces questions sont cruciales pour optimiser à la fois la performance et le coût.

Une chose spécifique que je recherche est un 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, conduisant à de l’instabilité. Vous souhaitez une mise à l’échelle fluide et réactive, pas une montagne russe.

Conseils Pratiques pour Votre Prochain Déploiement d’Agent

1. Identifier les Véritables Goulets d’Étranglement : Ne partez pas du principe 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’I/O, aux dépendances API externes ou aux taux d’achèvement de 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 la 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 à un HPA brut avec Prometheus Adapter 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 montant à la plus haute demande de réplicas.
5. Surveiller et Itérer : L’autoscaling est un processus itératif. Surveillez continuellement le comportement de votre 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 selon les besoins.
6. Envisager la Mise à l’Échelle Prédictive (avec Précaution) : Pour les charges de travail avec des modèles très prévisibles, explorez l’intégration de modèles de prévision avec un contrôleur externe pour pré-scaler vos déploiements. Commencez simplement et validez rigoureusement.

Mise à l’échelle efficace des agents ne consiste pas simplement à ajouter plus de puissance de calcul au problème ; il s’agit de fournir la juste quantité de calcul au bon moment, en fonction de ce qui pilote 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, spécifiques à l’application, vous pouvez construire une flotte d’agents véritablement résiliente, économique et performante. Et croyez-moi, votre emploi du temps de sommeil vous en sera reconnaissant.

Au plaisir de vous revoir, gardez ces agents en activité !

Maya Singh, agntup.com

Articles Connexes

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

🕒 Published: March 26, 2026