KEDA a été annoncé peu avant la conférence Microsoft Build 2019. Sous cet acronyme obscur se cache un outil très prometteur. Son objectif principal est de permettre de reproduire une architecture dite « serveless » au sein d’un cluster Kubernetes (alias k8s) on-premise ! Dans le premier chapitre de cet article, nous verrons un très bref rappel de k8s puis nous verrons l’intérêt et les possibilités offertes par KEDA ainsi que ses cas d’utilisation.

Disclaimer : KEDA est actuellement en phase expérimentale et il est donc très fortement déconseillé de l’utiliser pour des besoins de production.

1. Kurbenetes : possibilités et limitations.

Dans une architecture conteneurisée, il y a, très majoritairement, une multitude de conteneurs à gérer. Déployer, surveiller, mettre à jour, mettre à l’échelle, … l’ensemble de ces conteneurs peut s’avérer extrêmement compliqué. C’est afin de manager tous ces aspects que sont nés les orchestrateurs de conteneurs dont le plus populaire est k8s. Au sein d’un cluster k8s on trouve deux types de machine :

• Node : ce sont des machines physiques ou virtuelles hébergeant un ou plusieurs Pods. Un Pod encapsule une application conteneurisée (donc un ou plusieurs conteneurs) et est la plus petite unité déployable au sein d’un cluster k8s.

• Master : une machine physique ou virtuelle représentant le cerveau de k8s. Il est le garant du maintien de l’état du cluster et est en charge de répartir les Pods en fonction de ce qui lui a été demandé et des ressources dont il dispose.

Grosso-modo, il est possible de définir l’état souhaité du cluster à travers un fichier YAML qui sera fourni à la machine Master. Cette machine se charge de déployer et répartir les différents Pods pour reproduire l’état qui lui a été demandé. Si une machine Node tombe en panne pour x raison, la machine Master est alertée et se charge de répartir les Pods entre les différentes machines Node, afin que l’état devenu instable redevienne stable.

Voici un schéma résumant l’architecture macro d’un cluster k8s :

Le but n’est pas d’entrer dans le détail de l’architecture et du fonctionnement de k8s, nous allons directement nous intéresser à un composant déployable sur une machine Master, appelé l’Horizontal Pod Autoscaler (HPA). Il permet de mettre à l’échelle automatiquement des Pods du cluster en fonction de métriques observées. Dans sa première version, seule la consommation de CPU des pods peut être observée mais dans de futures versions il sera possible d’automatiquement mettre à l’échelle en fonction de la consommation mémoire, du trafic réseau, …

Dans le cadre d’une architecture serverless, la mise à l’échelle n’est pas faite selon la consommation des ressources mais en fonction de la saturation d’une source d’événement. Si l’on prend le cas des Azure Function, elles sont mises à l’échelle automatiquement en fonction du nombre de messages à traiter, contenues dans la source d’événement à laquelle elles sont rattachées. Autrement dit, plus il y a de message en attente de traitement dans la source d’évènement liée à la Function, plus il y aura d’instance de cette Function pour accélérer le traitement. C’est exactement la raison d’être de KEDA : pouvoir utiliser le composant HPA de kubernetes en lui fournissant une métrique qui correspond au nombre de message à traiter dans une source d’évènement.

2. KEDA : on prem serverless

En plus de se baser sur des métriques prédéfinies comme la consommation de CPU ou de mémoire, le composant HPA permet d’utiliser des métriques personnalisées. C’est cette particularité qui est exploitée par KEDA. KEDA peut observer différentes sources d’événement puis réagir selon des ordres qui lui ont été donnés pour indiquer au HPA de mettre à l’échelle les pods. Par exemple il est possible de définir que lorsque une file d’attente contient plus de 5 messages à traiter alors les pods seront mis à l’échelle en conséquence pour traiter ces messages. Il est évidemment possible de définir le nombre max d’instance possible pour un pod. Ces sources d’évènement sont appelées « Scaler ». Pour l’instant, seul les « Scaler » suivants sont supportés :

• Kafka
• RabbitMQ
• Azure Storage Queues
• Azure Service Bus Queues
• Azure Service Bus Topics

Il est indiqué sur le repo github officiel les futurs source qui seront prochainement supporté. Sur le repo, de l’aide est demandée pour certaines sources extérieures au cloud Azure comme : AWS SQS, Redis Cache, Google Cloud Pub/Sub, MongoDB,… Si vous avez des connaissances sur ces sujets produits, n’hésitez pas à aller leur donner un coup de main 🙂

A quoi ressemble KEDA d’un point de vue architecture ? Voici un schéma extrait de la documentation :

L’une des particularités de cette architecture est que bien que KEDA observe la source d’évènement, les pods sont tout de même directement connectés avec cette source et y consomment directement les événements. Cela permet de conserver les fonctionnalités offertes par les sources d’événement (comme l’abandon de message, placement d’un message en erreur dans une « dead lettering queue », …) sans tout réécrire pour les implémenter au sein de KEDA.

Toute la configuration de KEDA se fait au sein d’un fichier YAML où il est possible de lui indiquer la source d’évènement que l’on souhaite observer, ainsi que le comportement qu’il doit adopter pour mettre à l’échelle les pods de façon automatique. Voici un exemple dans le cas de l’utilisation d’une Azure Storage Queue :

triggers:
  - type: azure-queue
    metadata:
      queueName: functionsqueue
      queueLength: '5' # Optional. Queue length target for HPA. Default: 5 messages
      connection: STORAGE_CONNECTIONSTRING_ENV_NAME

Abordons maintenant les différents cas d’utilisation de KEDA :

• Utiliser des Azure Functions sur du on-premise ou sur un autre cloud provider (AWS, GCP, …)
• Avoir un contrôle plus fin sur l’instanciation de ses Functions
• Capitaliser sur la mise en place d’un cluster Kubernetes on-premise

Le HPA de k8s est encore très récent et certaines fonctionnalités actuellement prises en charge par KEDA pourraient par la suite devenir natives. En tout cas c’est très promoteur et je vous invite à aller voir les exemples d’utilisation sur le repo officiel afin de vous faire votre propre idée sur le sujet.