Mise à l’échelle avec KEDA
Mise à l'échelle automatique basée sur les événements Kubernetes
Kubernetes Event-driven Autoscaling (KEDA) est un composant unique et léger qui simplifie la mise à l'échelle automatique de l’application. Vous pouvez ajouter KEDA à n’importe quel cluster Kubernetes et l’utiliser en même temps que les composants Kubernetes standard, comme HPA (outil de mise à l’échelle automatique de pods horizontal) ou l’outil de mise à l’échelle automatique de clusters, pour étendre leurs fonctionnalités. Grâce à KEDA, vous pouvez cibler les applications spécifiques pour lesquelles vous souhaitez tirer parti de la mise à l’échelle basée sur les événements et autoriser d’autres applications à utiliser différentes méthodes de mise à l’échelle. KEDA est une option flexible et sécurisée qui peut s’exécuter avec n’importe quel nombre de frameworks ou d’applications Kubernetes.
Capacités et fonctionnalités clés
- Générer des applications durables et rentables avec des fonctionnalités de mise à l’échelle à zéro
- Mettre à l’échelle des charges de travail d’applications pour répondre aux demandes en utilisant des utilitaires de mise à l’échelle KEDA
- Mise à l’échelle automatique d’applications avec
ScaledObjects - Mise à l’échelle automatique de travaux avec
ScaledJobs - Utiliser la sécurité de niveau production en découplant la mise à l’échelle automatique et l’authentification à partir de charges de travail
- Apporter votre propre utilitaire de mise à l’échelle externe pour utiliser des configurations de mise à l’échelle automatique personnalisées
Architecture
KEDA fournit deux composants principaux :
- Opérateur KEDA : permet aux utilisateurs finaux de mettre à l’échelle les charges de travail de zéro à N instances avec la prise en charge des déploiements Kubernetes, des travaux, des StatefulSets ou de toute ressource client définissant une
/scalesous-ressource. - Serveur de mesures : expose des mesures externes à l’HPA, comme des messages dans un sujet Kafka ou des événements dans Azure Event Hubs, pour conduire des actions de mise à l’échelle automatique. En raison des limitations en amont, le serveur de métriques KEDA doit être le seul adaptateur de métriques installé dans le cluster.
Le diagramme suivant montre comment KEDA s’intègre au HPA Kubernetes, aux sources d’événements externes et au serveur d’API de Kubernetes pour fournir une fonctionnalité de mise à l’échelle automatique :
Conseil
Pour plus d’informations, consultez la documentation officielle de KEDA.
Sources d’événements et utilitaires de mise à l’échelle
Les outils de mise à l’échelle KEDA peuvent détecter si un déploiement doit être activé ou désactivé, et alimenter des métriques personnalisées pour une source d’événement spécifique. Les Deployments et les StatefulSets sont les moyens les plus courants de mettre à l’échelle des charges de travail avec KEDA. Vous pouvez également mettre à l’échelle des ressources personnalisées qui implémentent la sous-ressource /scale. Vous pouvez définir le StatefulSet ou le déploiement Kubernetes que KEDA doit mettre à l’échelle en fonction d’un déclencheur de mise à l’échelle. KEDA surveille ces services et les met automatiquement à l’échelle en fonction des événements qui se produisent.
En arrière-plan, KEDA surveille la source d’événements et alimente ces données vers Kubernetes et HPA pour accélérer la mise à l’échelle des ressources. Chaque réplica d’une ressource extrait activement des éléments de la source de l’événement. Avec KEDA et Deployments/StatefulSets, vous pouvez mettre à l’échelle en fonction d’événements tout en conservant une sémantique de connexion et de traitement riche avec la source de l’événement (par exemple, un traitement dans l’ordre, de nouvelles tentatives, des lettres mortes ou des points de contrôle).
Spécification de l’objet mis à l’échelle
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: {scaled-object-name}
spec:
scaleTargetRef:
apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1
kind: {kind-of-target-resource} # Optional. Default: Deployment
name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject
envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0]
pollingInterval: 30 # Optional. Default: 30 seconds
cooldownPeriod: 300 # Optional. Default: 300 seconds
minReplicaCount: 0 # Optional. Default: 0
maxReplicaCount: 100 # Optional. Default: 100
advanced: # Optional. Section to specify advanced options
restoreToOriginalReplicaCount: true/false # Optional. Default: false
horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options
behavior: # Optional. Use to modify HPA's scaling behavior
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 100
periodSeconds: 15
triggers:
# {list of triggers to activate scaling of the target resource}
Spécification du travail mis à l’échelle
Au lieu de mettre à l’échelle le code piloté par les événements en tant que Deployments, vous pouvez également exécuter et mettre à l’échelle votre code en tant que travail Kubernetes. La nécessité de traiter des exécutions de longue durée constitue la principale raison pour laquelle vous utilisez cette option. Au lieu de traiter plusieurs événements au sein d’un déploiement, chaque événement détecté planifie son propre travail Kubernetes. Cette approche vous permet de traiter chaque événement séparément et de mettre à l’échelle le nombre d’exécutions simultanées en fonction du nombre d’événements dans la file d’attente.
apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
name: {scaled-job-name}
spec:
jobTargetRef:
parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#controlling-parallelism)
completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#controlling-parallelism)
activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer
backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6
template:
# describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/)
pollingInterval: 30 # Optional. Default: 30 seconds
successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept.
failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept.
envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]
maxReplicaCount: 100 # Optional. Default: 100
scalingStrategy:
strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use.
customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy.
customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy.
triggers:
# {list of triggers to create jobs}