Dans sa version initiale, Kubernetes Horizontal Pod Autoscaler (HPA) ne prend en charge que la mise à l'échelle basée sur l'utilisation du processeur et de la mémoire au niveau du conteneur. Cela ne convient pas à de nombreux cas d'utilisation. Par exemple, les consommateurs Kafka veulent généralement être dimensionnés en fonction du retard des événements, une mesure qui n'est pas prise en charge par l'HPA. Il existe des adaptateurs tiers qui peuvent intégrer les métriques externes de Kubernetes avec certains backend de métriques. Voici comment cela se passe :
Les HPA obtiennent des données du module Kubernetes External Metrics. Ce module ne stocke pas les métriques, il les récupère simplement à partir des backends de métriques, mais il ne supporte pas nativement l'interrogation des backends de métriques. Il a besoin d'un adaptateur qui peut récupérer et convertir les métriques. L'utilisateur doit installer et configurer cet adaptateur. Par exemple, Prometheus Adapter peut extraire des métriques Prometheus et les convertir pour une utilisation par Kubernetes External Metrics. La mise à l'échelle événementielle de KEDA consolide tout cela en une seule installation :
L'architecture de KEDA se compose de deux éléments principaux : l'opérateur et le serveur de métriques. L'Opérateur dicte comment les applications doivent évoluer en réponse aux événements via les ScaledObjects personnalisés de KEDA qui s'attachent aux déploiements. Le Metrics Server sert de pont entre Kubernetes et les sources d'événements externes. Ces composants travaillent ensemble pour recevoir des événements métriques de n'importe quel nombre de sources et les utiliser pour déclencher automatiquement une mise à l'échelle en fonction de ces événements. Cette conception permet à KEDA d'adapter dynamiquement les charges de travail Kubernetes en fonction d'événements provenant d'un large éventail de sources.
La capacité à s'intégrer à un large éventail de sources d'événements et de courtiers témoigne de la polyvalence de KEDA en tant que solution d'autoscaling. Son support étendu inclut des systèmes populaires comme Kafka, RabbitMQ, et des sources d'événements basées sur le cloud, faisant de KEDA un outil complet pour les développeurs travaillant dans un écosystème technologique diversifié. Pour illustrer cela, comparons la configuration de Kafka consumer lag autoscaling dans KEDA avec l'approche "adaptateur".
La configuration de KEDA pour l'autoscaling du consommateur Kafka implique la création d'un ScaledObject dans Kubernetes qui cible votre déploiement de consommateur Kafka.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: demo-kafka-scaledobject
spec:
scaleTargetRef:
name: demo
pollingInterval: 60
cooldownPeriod: 300
minReplicaCount: 0
maxReplicaCount: 10
triggers:
- type: kafka
metadata:
consumerGroup: demo.consumer-group.id
bootstrapServersFromEnv: KAFKA_BOOTSTRAP_SERVERS
# Lag must be higher than this to activate scaling
activationLagThreshold: 3000
# desiredReplicas = totalLag / lagThreshold
lagThreshold: 1000
sasl: plaintext
tls: enable
authenticationRef:
name: keda-kafka-credentials
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: keda-kafka-credentials
spec:
secretTargetRef:
- parameter: username
name: demo-kafka-secrets
key: demo.username
- parameter: password
name: demo-kafka-secrets
key: demo.password
Vous spécifierez Kafka comme type de déclencheur dans le ScaledObject et inclurez des détails tels que les serveurs Kafka bootstrap, le groupe de consommateurs et le sujet. En outre, vous définirez le seuil de retard qui déclenche la mise à l'échelle. L'authentification à Kafka peut être gérée via un objet TriggerAuthentication, référençant les secrets Kubernetes pour les paramètres de connexion sécurisée. Cette configuration permet à KEDA de surveiller le retard des consommateurs Kafka et d'adapter dynamiquement votre déploiement en fonction des critères définis.
La configuration de Prometheus Adapter pour la mise à l'échelle automatique du retard des consommateurs Kafka nécessite de configurer Prometheus pour collecter des métriques à partir de Kafka, puis d'utiliser Prometheus Adapter pour exposer ces métriques à l'Horizontal Pod Autoscaler (HPA) de Kubernetes. Vous devrez :
Configurer Prometheus pour récupérer les métriques Kafka, y compris le retard des consommateurs.
Installer Prometheus Adapter dans votre cluster Kubernetes, en veillant à ce qu'il soit configuré pour interroger Prometheus pour les métriques de décalage Kafka spécifiques.
Créez un objet HPA qui cible votre déploiement de consommateurs, en spécifiant la métrique Kafka lag de Prometheus comme base pour les décisions de mise à l'échelle.
Cette configuration permet à l'HPA de dimensionner vos consommateurs Kafka en fonction du décalage, ce qui garantit un traitement efficace des messages. Cependant, elle oblige l'utilisateur à maintenir une chaîne de composants distincts, chacun déployé séparément. Si le backend de métrologie change, toute la chaîne doit être modifiée. En revanche, KEDA réduit le nombre de composants car le déploiement unique de KEDA peut être réutilisé pour n'importe quel nombre de backends. De plus, les objets de mise à l'échelle automatique de KEDA sont découplés des backends dont ils obtiennent les métriques. Cela garantit que KEDA peut être adopté de manière transparente dans divers scénarios, servant de solution tout-en-un pour la mise à l'échelle pilotée par les événements. Cette adaptabilité renforce l'attrait de KEDA et en fait un outil essentiel dans les stratégies modernes de déploiement et de gestion d'applications.
L'une des principales caractéristiques de KEDA est sa capacité à réduire les charges de travail à zéro, ce qui le différencie des solutions traditionnelles de mise à l'échelle automatique. Cette fonctionnalité signifie que lorsqu'il n'y a pas de demande ou que la charge de travail événementielle est inactive, KEDA peut réduire le nombre de pods à zéro, mettant ainsi en pause l'utilisation des ressources. Cela permet d'optimiser l'utilisation des ressources et de réduire les coûts associés à la puissance de calcul inutilisée. En alignant la consommation des ressources sur la demande réelle, KEDA s'assure que l'efficacité et la rentabilité sont au premier plan.
Le statut de projet diplômé de la Cloud Native Computing Foundation (CNCF) renforce encore l'attrait de la KEDA. Ce statut signifie un niveau de stabilité, de maturité et de confiance de la communauté que peu de projets atteignent. Elle indique que KEDA a satisfait à des critères rigoureux en matière de gouvernance, d'engagement envers la communauté et d'adoption de l'écosystème. L'approbation de KEDA par la CNCF souligne son engagement en faveur de l'innovation et sa volonté de maintenir une solution qui réponde aux besoins évolutifs de ses utilisateurs.
KEDA représente un nouveau modèle de mise à l'échelle automatique de Kubernetes, répondant habilement à la nature dynamique des architectures modernes pilotées par les événements. Sa mise à l'échelle basée sur les événements, sa prise en charge complète de diverses sources d'événements, sa capacité à mettre à l'échelle les charges de travail jusqu'à zéro et sa reconnaissance en tant que projet diplômé de la CNCF soulignent collectivement ses capacités inégalées. Ces caractéristiques soulignent non seulement l'excellence technique de KEDA, mais aussi son rôle dans le déploiement d'applications rentables, efficaces et fiables. Grâce à son innovation et à son évolution soutenue par la communauté, KEDA se distingue clairement comme l'étalon-or pour l'autoscaling de Kubernetes, incarnant l'avenir des applications cloud-natives réactives et évolutives.
