KEDA est un composant pour Kubernetes. Il a été lancé en 2019, et il prend rapidement de l’ampleur. Tout le monde s’y est mis, y compris Google.
D’accord. Mais pourquoi ? À première vue, Cloud Run et d’autres services de Google Cloud font au moins aussi bien que KEDA. Alors, pourquoi Google l’ajoute à son écosystème ?
Gouverner, c’est prévoir
Et ne rien prévoir, c’est courir à sa perte (Emile de Girardin, 1852, dont on n’a pas vu passer le profil LinkedIn à l’époque, et maintenant on regrette…)
Le principal rôle de KEDA, c’est d’aider à prévoir.
Le plus souvent, dans Kubernetes, on utilise le composant Horizontal Pod Autoscaler (HPA). Ce composant surveille les indicateurs techniques des applications (pods) : mémoire, processeur. Lorsque ces indicateurs indiquent que les pods commencent à saturer, le HPA demande à Kubernetes d’en démarrer d’autres. Un peu comme la chef de secteur fait ouvrir des caisses au supermarché quand la file de clients augmente.
Mais un peu seulement. En fait, les mesures techniques, c’est plutôt l’état de saturation de chaque hôtesse de caisse. Quand elles enchaînent pratiquement s’en s’arrêter (le processeur est utilisé à 80%), on ouvre une nouvelle caisse. Quand elles passent la moitié de leur temps à attendre un client, on ferme une caisse. Voilà ce que fait le HPA.
Ce qu’il ne fait pas, c’est regarder s’il y a des clients qui attendent devant les caisses. Il ne regarde pas non plus combien de clients circulent dans les rayons. Et encore moins le nombre de voitures sur le parking. Et ça, c’est ce que fait KEDA.
Concrètement, KEDA récupère différentes mesures (on dit métriques, pour faire croire qu’on parle anglais), et les envoie au HPA. Ensuite le HPA fait son travail normalement, et ajuste le nombre de pods à partir de ces informations. Il suffit d’avoir des mesures dans les outils d’observabilité : nombre de messages à traiter, nombre d’utilisateurs connectés, taille du carnet de commande, nombre de voitures détectées par la boucle magnétique à l’entrée du parking… Tout ce qui ressemble à des événements pouvant déclencher un traitement. D’où le nom. KEDA signifie Kubernetes Event-Driven Autoscaling.
En bonus, KEDA permet de réduire le nombre de pods à 0 quand il n’y a pas d’activité. Il est capable de désactiver une application, et de la réactiver quand des événements arrivent. Cela permet, entre autres, d’exécuter un traitement en réaction à l’arrivée d’un événement. Le reste du temps, les machines sont disponibles pour d’autres applications.
Mais… Google avait tout prévu, non ?
Oui, évidemment que oui ! (Disclaimer : Daveo est partenaire Google Cloud)
Depuis des années, on peut représenter les événements comme des messages dans Google Pub/Sub, et faire traiter ces messages par Cloud Run. C’est encore plus facile à mettre en place aujourd’hui, avec Google Eventarc. En quelques clics, on lance un traitement sur l’arrivée d’un fichier, ou parce qu’il est midi, ou parce qu’un grand méchant est en train d’attaquer notre réseau.
Si ces événements sont rares, le coût peut être très, très faible. De l’ordre de quelques euros par mois.
Et faut-il vraiment voir venir la file de clients quand on peut ouvrir une caisse en quelques millisecondes ? Parce que Cloud Run est capable d’augmenter ou de diminuer le nombre d’instances d’une application en un temps record.
Vraiment, KEDA n’a pas l’air très utile sur Google Cloud.
Et pourtant, Google propose KEDA
C’est un fait. Google documente comment installer et utiliser KEDA sur Google Kubernetes Engine (GKE). Effet de mode ? Lobbying d’une communauté Open Source ?
Pour comprendre, il faut revenir au besoin de Kubernetes. On ne déploie pas un cluster Kubernetes pour lancer quelques jobs à l’arrivée d’un événement. Ce qu’on recherche, c’est une automatisation des opérations quand on a des contraintes qui interdisent les solutions serverless comme Cloud Run.
On peut avoir un usage très intensif, et pourtant variable dans le temps. Dans ce cas, le serverless coûte plus cher qu’une infrastructure plus classique. Surtout si on peut utiliser le modèle spot. Par exemple, pour un besoin de 32 CPU et 64 Go de RAM sur un mois, la solution Cloud Run peut être autour de 1500 € par mois, et la solution GKE autour de 400 € par mois.
On peut aussi vouloir utiliser un matériel très spécifique, comme des GPU pour exécuter des modèles d’IA analytique. GKE offre des options que Cloud Run n’offre pas.
On peut encore vouloir renforcer la sécurité avec des machines physiquement isolées de celles des autres clients de Google, ou avec un chemin réseau bien particulier vers une usine.
Dans ces cas-là, GKE est la meilleure option. Et on a toujours le besoin d’affiner le dimensionnement selon les événements qui se produisent : KEDA va finalement servir !
Le fin mot de l’histoire
Dans certains clouds publics (on ne citera pas de noms !), Kubernetes et KEDA sont utiles pour implémenter ce que Cloud Run, Pub/Sub et Eventarc font très bien. Transposer ces approches à Google Cloud n’est pas très fécond : cela augmente inutilement le coût et la charge d’administration.
Dans l’environnement Google Cloud, KEDA prend toute sa valeur lorsque Google Kubernetes Engine est le meilleur choix, et qu’il existe des mesures, notamment liées à des événements métier, qui permettent de piloter au mieux le dimensionnement des applications. Donc, prochaine étape : mettre en place l’observabilité métier !
