Les métriques custom sont souvent plus précises et utiles que l'autoscaling basé sur le CPU et la RAM, mais le scaling fondé sur des métriques custom et externes reste un terrain encore peu balisé qui mériterait d'être amélioré.
Kubernetes est une plateforme en constante évolution. C'est pourquoi je prends régulièrement le temps de réexaminer des fonctionnalités que je n'ai pas utilisées depuis quelques années. Je viens de refaire l'exercice avec les Horizontal Pod Autoscalers (HPAs) et j'ai relevé des fonctionnalités intéressantes ainsi que certaines limitations utiles à connaître, mais peu documentées ou évidentes.
Un piège à signaler : l'apiVersion: autoscaling/v2 du HPA laisse penser qu'il s'agit d'une API mature. En réalité, le scaling fondé sur des métriques custom et externes reste un terrain encore peu balisé qui gagnerait à être amélioré. C'est dommage, car les métriques custom sont généralement plus précises et utiles que l'autoscaling basé sur le CPU et la RAM.
Passons en revue quelques cas d'usage où les métriques custom améliorent la scalabilité, ainsi que les outils permettant d'y parvenir.
Cas d'usage
Une fois les métriques custom configurées et exposées dans un format compatible HPA, les HPAs peuvent scaler à partir de plusieurs métriques. La documentation Kubernetes en donne un exemple partiel, où un HPA est configuré pour scaler en fonction de l'utilisation CPU, des paquets par seconde et des requêtes par seconde. L'idée : chaque métrique peut suggérer un nombre différent de répliques souhaitées, par exemple 3, 5 et 8. Le HPA scale alors au plus haut des nombres suggérés.
- Le Helm chart Kube Prometheus Stack est l'une des solutions cloud-agnostic les plus populaires et les mieux maintenues pour fournir des métriques custom. La stack regroupe plusieurs applications, et Prometheus Adapter for Kubernetes Metrics APIs est le composant qui convertit et publie les métriques Prometheus dans un format que les HPAs savent comprendre et exploiter.
Le nombre de requêtes entrantes par seconde et la durée/latence des requêtes sont des métriques solides pour scaler des services web.
Les architectures avec files d'attente ou storage buckets, où sont déposés les objets à traiter, peuvent autoscaler les services qui traitent ces objets en fonction du nombre d'éléments détectés.
- Kubernetes Event Driven Autoscaling (KEDA) propose des scalers capables de s'interfacer avec plusieurs files d'attente (comme Pub/Sub) et avec des storage buckets. Il prend également en charge l'exécution de requêtes sur des bases de métriques, de logs, SQL et NoSQL pour générer des métriques.
Le nombre minimum variable de répliques permet de concilier capacité à absorber les pics de trafic et maîtrise des coûts. Si vous avez déjà exploité une application dont les répliques démarrent lentement ou qui subit d'importants pics de trafic, vous avez sans doute eu besoin de relever le nombre minimum de répliques pour préserver la qualité de service.
- Par exemple : si une réplique peut absorber 100 req/s, on peut la configurer pour autoscaler dès 50 req/s afin d'éviter les erreurs ou la latence observées au-delà de 100 req/s. Un minimum de 10 répliques absorbera mieux les pics qu'un minimum de deux.
- Le seul bémol de cette approche, c'est la hausse des coûts, mais il est raisonnable de penser qu'une application connaisse des pics de trafic relativement prévisibles. Un minimum de deux peut convenir en dehors des heures ouvrables ; un minimum de 10 aux heures où les pics sont fréquents, et un minimum de cinq le reste du temps.
- KEDA a récemment intégré une option permettant d'injecter plusieurs métriques dans une formule personnalisée par l'utilisateur, afin de produire des métriques composites en combinant d'autres métriques via des formules mathématiques. Ainsi, nombre souhaité = métrique d'autoscaling + nombre souhaité basé sur cron permet de simuler un nombre minimum de répliques variable.
Les plateformes serverless et functions-as-a-service hébergées sur Kubernetes, par exemple :
- keda.sh
- knative.dev
- openfaas.com
Limitations et conséquences
Tout cela semble prometteur, et l'outillage est au rendez-vous. Alors, quelle est cette limitation qui empêche les HPAs d'être vraiment excellents ?
La limitation suivante a des conséquences importantes sur l'UX (expérience utilisateur) : https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70
En résumé : il ne peut y avoir qu'un seul serveur de métriques custom. Si vous installez le populaire kube-prometheus-stack avec les paramètres par défaut, vous obtiendrez Prometheus Adapter. Impossible alors d'utiliser en plus le keda-operator-metrics-apiserver de KEDA, le Knative Pod Autoscaler de Knative, l'autoscaler d'OpenFaaS Pro, celui de Datadog ou d'autres encore. Tous fonctionnent en effet en hébergeant leur propre serveur de métriques custom. C'est, je pense, la raison pour laquelle KEDA propose autant de scalers qu'il pourrait passer pour l'archétype du feature creep. KEDA dispose de plus de 60 scalers, dont des scalers pour Prometheus et Datadog. Cela paraît absurde tant qu'on n'a pas compris qu'il s'agit en partie de contourner cette limitation.
Pourquoi cette limitation dégrade-t-elle l'UX ? Partons d'un exemple de ce à quoi ressemble une bonne UX.
La Kube Prometheus Stack et Helm sont populaires pour une bonne raison. Ils offrent une excellente UX, et une partie de la recette tient au principe convention over configuration. Ils proposent des valeurs par défaut pertinentes et une configuration par défaut où des centaines, voire des milliers d'objets YAML sont pré-câblés selon des conventions, pour offrir une UX clé en main où l'essentiel fonctionne d'emblée.
Un prérequis pour qu'une telle UX devienne possible : pouvoir disposer d'un namespace qui n'entre pas en conflit avec d'autres éléments. On peut alors y établir des conventions et pré-câbler les composants sans avoir à rédiger de configuration sur mesure.
Plusieurs proofs-of-concept (PoCs) ont été menés sur ce problème courant, et une Kubernetes enhancement proposal avait même été ouverte pour le résoudre ; elle s'est essoufflée. J'espère que cet article mettra en lumière ce problème et suscitera un regain d'intérêt pour les APIs de scaling par métriques custom.