KEDA a été annoncé peu avant la conférence Microsoft Build 2019. Sous cet acronyme obscure 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'utilisations.

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 conteneur à 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 toutes ces aspects que sont nées les orchestrateur de conteneurs dont le plus populaire est k8s. Au sein d'un cluster k8s ont trouve deux type de machines :

  • 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 maintient de l'état du cluster et est en charge de répartir les Pods en fonction de ce qui lui à é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 fournit à la machine Master. Cette machine se charge de déployer et répartir les différents Pods pour reproduire l'état qui lui à é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 :

Architecture macro d'un cluster k8s

Le but n'est pas d'entré dans le détails 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, seul la consommation de CPU des pods peut être observée mais dans de future version il sera possible d'automatiquement mettre à l'échelle en fonction de la consommation mémoire, du trafique réseaux, ...

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 misent à l'echelle automatiquement en fonction du nombre de messages à traiter, contenue dans la source d'événement à laquel elles sont rattachées. Autrement dit, plus il y a de message en attente de traitement dans la source d'évenement lié à la Function, plus il y aura d'instance de cette Function pour accélerer 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 messages à traiter dans une source d'évenement.

2. KEDA : on prem serverless

En plus de se baser sur des metriques prédéfinit 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 source d’événement puis réagir selon des ordres qui lui ont été donné pour indiquer au HPA de mettre à l'echelle 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'echelle 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'évenement sont appelées "Scaler". Pour l'instant, seul les "Scaler" suivants sont supportées :

  • 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é pour certaines sources exterieur 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 éxtrait de la documentation :

Schéma d'architecture de KEDA au sein d'un cluster Kubernetes

L'un des particularités de cette architecture est que bien que KEDA observe la source d'évenement, les pods sont tout de même directement connectés avec cette source et y consomme directement les événements. Cela permet de conserver les fonctionnalités offertent 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éecrire 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'évenement que l'on souhaite observer, ainsi que le comportment qu'il doit adopter pour mettre à l'echelle 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 prise en charge par KEDA pourrait par la suite devenir native. En tout cas c'est très promoteur et je vous invite à aller voir les exemple d'utilisation sur le repo officiel afin de vous faire votre propre idée sur le sujet.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.