La mise à l’échelle manuelle devient lentement une chose du passé. Actuellement, l’autoscaling est la norme, et les organisations qui se déploient dans des clusters Kubernetes bénéficient de fonctionnalités d’autoscaling intégrées telles que HPA (Horizontal Pod Autoscaling) et VPA (Vertical Pod Autoscaling). Mais ces solutions ont des limites. Par exemple, il est difficile pour HPA de réduire le nombre de pods à zéro ou de (dé)dimensionner les pods en fonction de mesures autres que la mémoire ou l’utilisation du processeur. En conséquence, KEDA (Kubernetes Event-Driven Autoscaling) a été introduit pour relever certains de ces défis dans la mise à l’échelle automatique des charges de travail K8.
Dans ce blog, nous allons nous plonger dans KEDA et discuter des points suivants :
Qu’est-ce que KEDA ?
Architecture et composants KEDA
Installation et démonstration de KEDA
Intégrer KEDA dans les pipelines CI/CD
Qu’est-ce que KEDA ?
KEDA est un autoscaler Kubernetes léger et open source basé sur les événements que les équipes DevOps, SRE et Ops utilisent pour faire évoluer les pods horizontalement en fonction d’événements ou de déclencheurs externes. KEDA aide à étendre la capacité des solutions d’autoscaling natives de Kubernetes, qui s’appuient sur des métriques de ressources standard telles que le processeur ou la mémoire. Vous pouvez déployer KEDA dans un cluster Kubernetes et gérer la mise à l’échelle des pods à l’aide de définitions de ressources personnalisées (CRD).
Quels problèmes KEDA résout-il ?
KEDA aide les équipes SRE et DevOps à résoudre quelques problèmes importants :
Libérer des ressources et réduire les coûts du cloud
KEDA réduit le nombre de pods à zéro s’il n’y a aucun événement à traiter. C’est plus difficile à faire avec le HPA standard, et cela permet d’assurer une utilisation efficace des ressources et une optimisation des coûts, réduisant ainsi les factures du cloud.
Interopérabilité avec la chaîne d’outils DevOps
À l’heure actuelle, KEDA prend en charge 59 détartreurs intégrés et quatre détartreurs externes. Les scalers externes incluent KEDA HTTP, KEDA Scaler pour Oracle DB, etc. L’utilisation d’événements externes comme déclencheurs facilite une mise à l’échelle automatique efficace, en particulier pour les microservices basés sur des messages tels que les passerelles de paiement ou les systèmes de commande. De plus, comme KEDA peut être étendu en développant des intégrations avec n’importe quelle source de données, il peut facilement s’intégrer dans n’importe quelle chaîne d’outils DevOps.
Architecture et composants KEDA
Comme mentionné au début, KEDA et HPA travaillent ensemble pour réaliser l’autoscaling. Pour cette raison, KEDA n’a besoin que de quelques composants pour démarrer.
Composants KEDA
Reportez-vous à la figure A et laissez-nous explorer certains des composants de KEDA.
Sources d’événements
Ce sont les sources externes d’événements/déclencheurs par lesquelles KEDA modifie le nombre de pods. Prometheus, RabbitMQ et Apache Pulsar sont quelques exemples de sources d’événements.
Détartreurs
Les sources d’événements sont surveillées à l’aide de scalers, qui récupèrent les métriques et déclenchent la mise à l’échelle des déploiements ou des tâches en fonction des événements.
Adaptateur de métriques
L’adaptateur de métriques prend les métriques des scalers et les traduit ou les adapte sous une forme que le composant HPA/contrôleur peut comprendre.
Manette
Le contrôleur/opérateur agit sur les métriques fournies par l’adaptateur et provoque l’état de déploiement souhaité spécifié dans le ScaledObject (voir ci-dessous).
CRD KEDA
KEDA propose quatre ressources personnalisées pour exécuter les fonctions de mise à l’échelle automatique : ScaledObject, ScaledJob, TriggerAuthentication et ClusterTriggerAuthentication.
ScaledObject et ScaledJob
ScaledObject représente le mappage entre les sources d’événements et les objets et spécifie les règles de mise à l’échelle pour un déploiement, un StatefulSet, des travaux ou toute ressource personnalisée dans un cluster K8s. De même, ScaledJob est utilisé pour spécifier des règles de mise à l’échelle pour les tâches Kubernetes.
Vous trouverez ci-dessous un exemple de ScaledObject qui configure la mise à l’échelle automatique KEDA en fonction des métriques Prometheus. Ici, l’objet de déploiement « keda-test-demo3 » est mis à l’échelle en fonction du seuil de déclenchement (50) des métriques Prometheus. KEDA mettra à l’échelle le nombre de répliques entre un minimum de 1 et un maximum de 10 et redimensionnera jusqu’à 0 répliques si la valeur de la métrique tombe en dessous du seuil.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: prometheus-scaledobject
namespace: demo3
spec:
scaleTargetRef:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
name: keda-test-demo3
triggers:
- type: prometheus
metadata:
serverAddress: http://<prometheus-host>:9090
metricName: http_request_total
query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy", namespace="demo3", response_code="200" }
threshold: "50"
idleReplicaCount: 0
minReplicaCount: 1
maxReplicaCount: 10TriggerAuthentication et ClusterTriggerAuthentication
Ils gèrent l’authentification ou les secrets pour surveiller les sources d’événements.
Voyons maintenant comment tous ces composants KEDA fonctionnent ensemble et font évoluer les charges de travail K8.
Comment fonctionnent les composants KEDA ?
Il est facile de déployer KEDA sur n’importe quel cluster Kubernetes, car il n’a pas besoin d’écraser ou de dupliquer les fonctionnalités existantes. Une fois déployés et les composants prêts, la mise à l’échelle basée sur les événements commence avec la source d’événement externe (voir Fig. A). Le scaler surveillera en permanence les événements basés sur l’ensemble source dans ScaledObject et transmettra les métriques à l’adaptateur de métriques en cas d’événements déclencheurs. L’adaptateur de métriques adapte ensuite les métriques et les fournit au composant de contrôleur, qui adapte ensuite le déploiement à la hausse ou à la baisse en fonction des règles de mise à l’échelle définies dans ScaledObject.
Notez que KEDA active ou désactive un déploiement en mettant à l’échelle le nombre de répliques à zéro ou à une. Il déclenche ensuite HPA pour faire passer le nombre de charges de travail de un à n en fonction des ressources du cluster.
Déploiement et démonstration de KEDA
KEDA peut être déployé dans un cluster Kubernetes via des chartes Helm, un hub d’opérateur ou des déclarations YAML. Par exemple, la méthode suivante utilise Helm pour déployer KEDA.
#Adding the Helm repo
helm repo add kedacore https://kedacore.github.io/charts
#Update the Helm repo
helm repo update
#Install Keda helm chart
kubectl create namespace keda
helm install keda kedacore/keda --namespace kedaPour vérifier si l’opérateur KEDA et le serveur de l’API Metrics sont opérationnels ou non après le déploiement, vous pouvez utiliser la commande suivante :
Maintenant, regardez la vidéo ci-dessous pour voir une démonstration pratique de l’autoscaling à l’aide de KEDA. La démo utilise une petite application appelée TechTalks et utilise RabbitMQ comme courtier de messages.
Intégrer KEDA dans les pipelines CI/CD
KEDA rend la mise à l’échelle automatique des charges de travail K8 très simple et efficace. De plus, l’approche indépendante des fournisseurs de KEDA garantit une flexibilité en ce qui concerne les sources d’événements. Par conséquent, il peut aider les équipes DevOps et SRE à optimiser le coût et l’utilisation des ressources de leur cluster Kubernetes en augmentant ou en réduisant en fonction des sources d’événements et des métriques de leur choix.
L’intégration de KEDA dans les pipelines CI/CD permet aux équipes DevOps de réagir rapidement aux événements déclencheurs dans les besoins en ressources de leur application, rationalisant davantage le processus de livraison continue. Et KEDA prend en charge les événements générés par différentes charges de travail telles que StatefulSet, Job, Custom Resource et Job. Tous ces éléments contribuent à réduire les temps d’arrêt et à améliorer l’efficacité des applications et l’expérience utilisateur.