Escalado con KEDA
Escalado automático controlado por eventos de Kubernetes
El escalado automático controlado por eventos (KEDA) de Kubernetes es un componente ligero y de un solo propósito que simplifica el escalado automático de aplicaciones. Puede agregar KEDA a cualquier clúster de Kubernetes y usarlo junto con los componentes estándar de Kubernetes, como el escalador horizontal automático de pods (HPA) o el escalador automático de clústeres, para ampliar su funcionalidad. Con KEDA, puede seleccionar como destino aplicaciones concretas que quiera que aprovechen el escalado basado en eventos y permitir que otras aplicaciones usen métodos de escalado diferentes. KEDA es una opción flexible y segura para ejecutarse junto con cualquier número de aplicaciones o marcos Kubernetes.
Funcionalidades y características clave
- Cree aplicaciones sostenibles y rentables con funcionalidades de escala a cero
- Escale las cargas de trabajo de aplicaciones para satisfacer la demanda mediante escaladores KEDA
- Escalado automático de aplicaciones con
ScaledObjects - Escalado automático de trabajos con
ScaledJobs - Use la seguridad de nivel de producción desacoplando el escalado automático y la autenticación de cargas de trabajo
- Traiga su propio escalador externo para usar configuraciones de escalado automático personalizadas
Architecture
KEDA proporciona dos componentes principales:
- Operador KEDA: Permite a los usuarios finales escalar las cargas de trabajo dentro o fuera de cero a N instancias con compatibilidad para implementaciones de Kubernetes, trabajos, StatefulSets o cualquier recurso de cliente que defina un subrecurso
/scale. - Servidor de métricas: Expone métricas externas al HPA, como los mensajes de un tema de Kafka o eventos en Azure Event Hubs, para impulsar acciones de escalado automático. Debido a las limitaciones ascendentes, el servidor de métricas KEDA debe ser el único adaptador de métricas instalado en el clúster.
En el diagrama siguiente se muestra cómo se integra con KEDA el HPA de Kubernetes, orígenes de eventos externos y el servidor de API de Kubernetes para proporcionar la funcionalidad de escalado automático:
Sugerencia
Para más información, vea la documentación oficial de KEDA.
Orígenes de eventos y escaladores
Los escaladores de KEDA pueden detectar si una implementación se debe activar o desactivar, y proporcionan métricas personalizadas para un origen de eventos específico. Las implementaciones y los objetos StatefulSet son la manera más común de escalar cargas de trabajo con KEDA. También puede escalar recursos personalizados que implementen el subrecurso de /scale. Puede definir la implementación de Kubernetes o el objeto StatefulSet que quiere que KEDA escale en función de un desencadenador de escala. KEDA supervisa esos servicios y los reduce horizontalmente o los escala horizontalmente de forma automática en función de los eventos que se producen.
En segundo plano, KEDA supervisa el origen de los eventos y alimenta esos datos a Kubernetes y al HPA para impulsar el escalado rápido de recursos. Cada réplica de un recurso extrae elementos del origen del evento de forma activa. Con KEDA y Deployments/StatefulSets, puede modificar la escala en función de los eventos y, al mismo tiempo, conservar la semántica de procesamiento y conexión enriquecida con el origen del evento (por ejemplo, el procesamiento en orden, los reintentos, los mensajes fallidos o los puntos de control).
Especificación de objetos escalados
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}
Especificación del trabajo escalado
Como alternativa al escalado de código controlado por eventos como implementaciones, también puede ejecutar y escalar el código como un trabajo de Kubernetes. La razón principal para considerar esta opción es si necesita procesar ejecuciones de larga duración. En lugar de procesar varios eventos dentro de una implementación, cada evento detectado programa su propio trabajo de Kubernetes. Este enfoque permite procesar cada evento de forma aislada y escalar el número de ejecuciones simultáneas en función del número de eventos de la cola.
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}