Escalado automático de aplicaciones simplificado con complemento de escalado automático basado en eventos (KEDA) de Kubernetes en Azure Kubernetes Service (AKS)

Importante

El complemento KEDA para AKS no admite actualmente la modificación de las solicitudes o límites de CPU y otros valores de Helm para el Servidor de Métricas o el Operador. Tenga en cuenta esta limitación al usar el complemento. Si tiene alguna pregunta, no dude en ponerse en contacto aquí.

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 la aplicación. Es un proyecto de graduado de Cloud Native Computing Foundation (CNCF). KEDA usa el escalado automático controlado por eventos para escalar la aplicación para satisfacer la demanda de forma sostenible y rentable con escala a cero.

Para la mayoría de las cargas de trabajo de producción, AKS Automatic es la experiencia predeterminada de AKS recomendada. AKS Automatic está listo para producción de forma predeterminada e incluye KEDA preconfigurado en el clúster. Si usa AKS Standard, puede habilitar KEDA mediante el complemento KEDA administrado.

Para obtener más información sobre AKS Automatic, consulte ¿Qué es Azure Kubernetes Service (AKS) automático?

Nota:

La versión 2.15+ de KEDA presenta un cambio importante que quita la compatibilidad con la identidad del pod. Se recomienda pasar a la identidad de la carga de trabajo para la autenticación si usa la identidad de pod. Aunque el complemento administrado por KEDA no ejecuta actualmente la versión 2.15+, el complemento administrado comenzará a ejecutar KEDA 2.15+ en la versión preliminar 1.32 de AKS.

Para más información sobre cómo escalar de forma segura las aplicaciones con identidad de carga de trabajo, lea nuestro tutorial. Para ver la directiva de cambio importante o de desuso de KEDA, lea la documentación oficial.

KEDA en AKS Automatic y AKS Standard

KEDA está disponible en ambos modos de clúster de AKS, pero la ruta de instalación es diferente:

  • AKS Automatic: KEDA está preconfigurado y listo para su uso.
  • AKS Standard: habilite KEDA activando el complemento administrado de AKS.

Para la mayoría de los escenarios de producción, comience con AKS Automatic para usar los valores predeterminados listos para producción y reduzca la sobrecarga de administración de clústeres.

Arquitectura

KEDA proporciona dos componentes principales:

  • El operador KEDA permite a los usuarios finales escalar o reducir horizontalmente las cargas de trabajo de 0 a N instancias con compatibilidad con implementaciones, trabajos, StatefulSets, o cualquier recurso personalizado que defina el subrecurso /scale.
  • El servidor de métricas expone métricas externas a Horizontal Pod Autoscaler (HPA) en Kubernetes con fines de escalado automático, como mensajes en un tema de Kafka o el número de eventos de un centro de eventos de Azure. Debido a limitaciones de los proveedores, KEDA debe ser el único adaptador de métricas externo instalado.

Diagrama que muestra la arquitectura de KEDA y cómo extiende Kubernetes.

Obtenga más información sobre el funcionamiento de KEDA en la documentación oficial de KEDA.

Instalación y habilitación

AKS Automatic

KEDA está preconfigurado en AKS Automatic. No se requiere ningún paso de instalación de complemento KEDA independiente.

AKS Standard

Habilite KEDA en AKS Standard mediante uno de los métodos siguientes:

El complemento KEDA administrado proporciona una instalación KEDA totalmente compatible integrada con AKS.

Características y funcionalidades

KEDA proporciona las siguientes funcionalidades y características:

  • Escale las cargas de trabajo a cero cuando se baje la demanda.
  • Escale las cargas de trabajo de las aplicaciones para satisfacer la demanda mediante los escaladores KEDA de Azure.
  • Escala automáticamente aplicaciones usando ScaledObjects, como Deployments, StatefulSets, o cualquier recurso personalizado que defina el subrecurso /scale.
  • Autoescala cargas de trabajo similares a trabajos mediante ScaledJobs.
  • Utiliza seguridad de nivel de producción desacoplando la autenticación de la autoescalabilidad de las cargas de trabajo.
  • Traiga su propio escalador externo para la lógica de escalado automático personalizado.
  • Integración con Id. de carga de trabajo de Microsoft Entra para la autenticación.

En AKS Automatic, obtendrá estas funcionalidades de escalado automático controladas por eventos de forma predeterminada porque el clúster está preconfigurado con KEDA.

Nota:

Si planea usar la identidad de carga de trabajo en AKS Standard, habilite la identidad de carga de trabajo antes de habilitar el complemento KEDA.

Guía de producción

Use esta guía para elegir el modo de clúster:

  • Elija AKS Automatic cuando desee una experiencia por defecto lista para producción con KEDA preconfigurado.
  • Elija AKS Standard cuando necesite una personalización de nivel de clúster más profunda y una administración explícita de complementos.
  • Use KEDA en cualquier modo para cargas de trabajo de escalado automático controladas por eventos.

Limitaciones del complemento

El complemento AKS de KEDA tiene las siguientes limitaciones:

  • El complemento HTTP (versión preliminar) de KEDA que escala las cargas de trabajo HTTP no se instala con la extensión, pero se puede implementar por separado.
  • El escalador externo para Azure Cosmos DB de KEDA para escalar en función de la fuente de cambios de Azure Cosmos DB no se instala con la extensión, pero se puede implementar por separado.
  • Solo se permite un servidor de métricas externo en el clúster de Kubernetes. Debido a que el complemento KEDA debe ser el único servidor de métricas externos dentro del clúster.
    • No se admiten varias instalaciones de KEDA
  • No se recomienda combinar KEDA ScaledObject con un escalador automático horizontal de pods (HPA) para escalar la misma carga de trabajo. Compiten entre sí porque KEDA usa Horizontal Pod Autoscaler (HPA) en segundo plano y da como resultado un comportamiento impar de escalado.
    • Si se crea primero un HPA, se crea una KEDA ScaledObject y la KEDA ScaledObject no puede ser creado.
    • Si primero se crea una KEDA ScaledObject y, a continuación, se crea un HPA, no se bloquea la creación de HPA.

Para ver preguntas generales sobre KEDA, se recomienda visitar la introducción a las preguntas frecuentes.

Nota:

Si usa Id. de carga de trabajo de Microsoft Entra y habilita KEDA antes de Workload ID, debe reiniciar los pods del operador de KEDA para que se puedan inyectar las variables de entorno correctas:

  1. Para reiniciar los pods, ejecute kubectl rollout restart deployment keda-operator -n kube-system.

  2. Obtenga pods del operador KEDA mediante kubectl get pod -n kube-system y busque pods que comiencen por keda-operator.

  3. Compruebe la inserción correcta de las variables de entorno ejecutando kubectl describe pod <keda-operator-pod> -n kube-system. En Environment, debería ver los valores de AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE y AZURE_AUTHORITY_HOST.

Versiones de Kubernetes y KEDA admitidas

La versión de Kubernetes del clúster determina qué versión de KEDA está instalada en el clúster de AKS. Para ver qué versión de KEDA se asigna a cada versión de AKS, vea la columna de complementos administrados de AKS de la tabla de versiones de componentes de Kubernetes.

Para las versiones de Kubernetes disponibles de forma general, AKS ofrece soporte completo para la versión secundaria de KEDA correspondiente que se indica en la tabla. Las versiones preliminares de Kubernetes y el parche más reciente de KEDA están parcialmente cubiertos por el servicio de atención al cliente en régimen de mejor esfuerzo. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Contenido relacionado

  • Last updated on