El Helm chart de KEDA es la forma oficial de instalar KEDA, el Kubernetes Event-Driven Autoscaler, en tu clúster. Con un solo helm install se despliega todo lo que KEDA necesita para escalar tus workloads en función de eventos: el operador, el servidor de métricas, los admission webhooks y los recursos personalizados que usas para definir las reglas de escalado.
Esta guía cubre el chart a fondo. Aprenderás qué despliega, cómo instalarlo y verificarlo, los parámetros clave de values.yaml, cómo ejecutar KEDA en alta disponibilidad, cómo reforzarlo y monitorearlo, cómo gestionarlo con GitOps y cómo actualizarlo o desinstalarlo sin dejar recursos rotos.
¿Qué es el Helm chart de KEDA?
KEDA escala tus pods en función de eventos, como la longitud de una cola, el lag de un tópico de Kafka, la cantidad de solicitudes HTTP o una programación cron. El Horizontal Pod Autoscaler (HPA) integrado solo puede escalar según CPU y memoria. KEDA suma todas esas fuentes de eventos y, además, puede reducir un workload a cero pods cuando no hay nada que hacer.
KEDA no reemplaza al HPA. Lee tu fuente de eventos y crea un HPA que se encarga del escalado real, alimentándolo con métricas externas. Lo que quieres escalar se describe en un recurso personalizado llamado ScaledObject.
El Helm chart instala KEDA y sus componentes de soporte en un solo paso, y por eso es la forma recomendada de desplegarlo.
¿Qué despliega el chart en tu clúster?
Al instalar el Helm chart de KEDA en tu clúster, se instalan los siguientes componentes:
a. Operador de KEDA: el controlador principal de KEDA. Observa tus recursos ScaledObject y ScaledJob y gestiona el HPA que se encarga del escalado. Es la pieza central de KEDA.
b. Servidor de la API de métricas: pone tus métricas basadas en eventos a disposición de Kubernetes a través de la API external.metrics.k8s.io. Esto permite que el HPA escale según cosas como la longitud de una cola, y no solo CPU o memoria.
c. Admission webhooks: validan tus recursos de KEDA en el momento de crearlos. Detectan errores de configuración a tiempo, como dos recursos ScaledObject que intentan escalar el mismo workload.
Por último, el chart instala los CRDs, que agregan los tipos de recursos de KEDA con los que trabajas: ScaledObject, ScaledJob, TriggerAuthentication y ClusterTriggerAuthentication. También instala los permisos RBAC que estos componentes necesitan.
Requisitos previos y compatibilidad de versiones
Antes de instalar KEDA, revisa los siguientes requisitos previos y de versiones:
a. KEDA 2.20 requiere Kubernetes 1.30 o más reciente, así que primero verifica la versión de tu clúster con kubectl version. También necesitas Helm 3, ya que el chart de KEDA solo es compatible con Helm 3.
b. Asegúrate de que tu clúster tenga suficientes recursos disponibles para ejecutar los componentes de KEDA. El chart también descarga imágenes de contenedores desde ghcr.io, por lo que tus nodos necesitan acceso de red al registro de imágenes.
c. El servidor de métricas de KEDA crea además un APIService a nivel de clúster, así que cualquier política de red en el namespace keda debe permitir el tráfico que KEDA necesita. Si tu clúster está restringido o aislado (air-gapped), asegúrate de que el acceso de red y las imágenes requeridas estén disponibles antes de instalar.
Instalación del Helm chart de KEDA
Primero, agrega el repositorio oficial de KEDA y actualízalo:
helm repo add kedacore https://kedacore.github.io/chartshelm repo updateInstálalo en un namespace dedicado y fija la versión del chart en lugar de tomar la más reciente:
helm install keda kedacore/keda \ --namespace keda \ --create-namespace \ --version <chart-version>Fijar la versión importa porque la versión del chart corresponde a una versión específica de la aplicación KEDA, y quieres exactamente la versión que probaste. Puedes ver las versiones disponibles con helm search repo kedacore/keda --versions.
Después de instalar, verifica las tres partes que deben estar en buen estado. Comprueba que los pods estén en ejecución:
kubectl get pods -n kedaLuego confirma que los CRDs estén presentes y que el APIService de métricas externas esté registrado y disponible:
kubectl get crd | grep keda.shkubectl get apiservice v1beta1.external.metrics.k8s.ioSi los pods están en ejecución y ese APIService muestra True en Available, KEDA quedó instalado correctamente.
Otras formas de desplegar KEDA
El Helm chart es la forma recomendada de instalar KEDA, pero no es la única opción. La elección correcta depende de cómo gestiones tu clúster. Estas son las otras alternativas:
a. OpenShift: puedes instalar KEDA a través de OperatorHub y el Operator Lifecycle Manager (OLM). OLM gestiona el operador de KEDA y sus actualizaciones en lugar de Helm.
b. Manifiestos YAML sin procesar: si no puedes usar Helm, KEDA proporciona manifiestos YAML para cada versión, que puedes aplicar con kubectl apply. Con este enfoque, los CRDs y las actualizaciones quedan a tu cargo.
c. MicroK8s: KEDA está disponible como un add-on integrado que puedes habilitar con un solo comando.
Sea cual sea el método que elijas, los componentes principales de KEDA y los CRDs son los mismos. La diferencia principal está en cómo se empaqueta y gestiona KEDA.
Parámetros clave en values.yaml
Estos son los parámetros clave que debes conocer en values.yaml:
a. Registros, repositorios y tags de imágenes: cada componente de KEDA (image.keda, image.metricsApiServer e image.webhooks) tiene su propio registro, repositorio y tag. Si dejas el tag vacío, el chart usa la versión de la aplicación KEDA. En entornos restringidos, puedes configurar estos valores para usar tu propio registro de imágenes o un mirror.
b. crds.install y propiedad de los CRDs: por defecto, el chart instala y gestiona los CRDs. Si otra herramienta, como una herramienta de GitOps, ya los gestiona, configura crds.install: false para que ambos sistemas no intenten gestionar los mismos CRDs.
c. watchNamespace y alcance del namespace: por defecto, KEDA observa todos los namespaces. Al configurar watchNamespace, KEDA se limita a un namespace específico. Esto puede ser útil en un clúster compartido cuando quieres acotar dónde opera KEDA.
d. Requests y límites de recursos: puedes configurar los recursos por separado para el operador, el servidor de métricas y los webhooks con resources.operator, resources.metricServer y resources.webhooks. Define requests y límites adecuados para que KEDA tenga suficientes recursos y funcione de forma confiable, incluso cuando el clúster esté bajo presión.
Configurar KEDA en alta disponibilidad
En producción, no quieres que KEDA deje de funcionar si un nodo se cae. Sus componentes se ejecutan con múltiples réplicas y se distribuyen entre distintos nodos.
El operador admite múltiples réplicas mediante operator.replicaCount. Usa elección de líder, de modo que solo una instancia del operador está activa a la vez, mientras las demás quedan listas para tomar el relevo si hace falta.
El servidor de la API de métricas también puede ejecutar múltiples réplicas mediante metricsServer.replicaCount. Esto ayuda a mantener las métricas externas disponibles si una réplica falla.
También conviene usar pod anti-affinity para distribuir las réplicas entre distintos nodos y un PodDisruptionBudget (PDB) para asegurar que un drain de nodo no elimine todas las réplicas a la vez.
Un values.yaml de producción puede verse así:
operator: replicaCount: 2metricsServer: replicaCount: 2podDisruptionBudget: operator: minAvailable: 1 metricServer: minAvailable: 1affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: kubernetes.io/hostname labelSelector: matchLabels: app: keda-operatorAjustar la configuración de HTTP y TLS de los scalers
Muchos scalers de KEDA se conectan a sistemas externos mediante HTTP. En un entorno restringido, puede que necesites controlar cómo funcionan estas conexiones. KEDA ofrece parámetros para configurar las conexiones HTTP, TLS y de proxy:
a. Timeout de HTTP: KEDA_HTTP_DEFAULT_TIMEOUT define el timeout predeterminado para los scalers que usan el cliente HTTP integrado de KEDA. El valor se expresa en milisegundos. Algunos scalers usan sus propios SDKs del proveedor, por lo que este ajuste no aplica en esos casos.
b. Versión mínima de TLS: KEDA_HTTP_MIN_TLS_VERSION define la versión mínima de TLS para las conexiones HTTP salientes de KEDA. KEDA_SERVICE_MIN_TLS_VERSION define la versión mínima de TLS para los propios servicios TLS de KEDA, como los servicios de webhook y gRPC. El valor predeterminado es TLS 1.3.
c. Lista de cifrados TLS: KEDA_HTTP_TLS_CIPHER_LIST te permite restringir qué cifrados TLS puede usar KEDA. Sin embargo, este ajuste no afecta a TLS 1.3, porque la biblioteca TLS de Go no permite configurar esos cifrados para TLS 1.3.
d. Proxy HTTP y HTTPS: si KEDA necesita conectarse a sistemas externos a través de un proxy corporativo, configura las variables de entorno estándar HTTP_PROXY, HTTPS_PROXY y NO_PROXY en el operador de KEDA.
Reforzar la instalación
Hay dos configuraciones que pueden mejorar la seguridad de KEDA en producción: limitar el acceso a secretos y gestionar los certificados. Veámoslas:
a. Limitar el acceso a secretos: por defecto, KEDA puede leer secretos en todos los namespaces que observa. Los ajustes de permissions.operator te permiten restringir este acceso para que el operador solo lea secretos en su propio namespace de instalación o únicamente secretos específicos por nombre. Esto reduce lo que un operador comprometido podría alcanzar.
b. Gestionar los certificados: KEDA genera sus propios certificados autofirmados, los guarda en un secreto llamado kedaorg-certs y los monta en sus componentes. KEDA también rota estos certificados automáticamente y actualiza los recursos de Kubernetes necesarios para que sean de confianza.
c. Si tu organización requiere certificados de una autoridad certificadora gestionada, habilita certificates.certManager.enabled para que cert-manager emita y rote los certificados en lugar de KEDA. Para la mayoría de las instalaciones, los certificados generados automáticamente son suficientes.
Desplegar el chart mediante GitOps
Si gestionas tu clúster con Argo CD o Flux, puedes desplegar el chart de KEDA mediante GitOps. Lo principal que debes manejar con cuidado son los CRDs.
Los CRDs de KEDA son grandes, y un apply normal de Kubernetes puede fallar porque la anotación generada se vuelve demasiado grande. Para evitarlo, configura tu herramienta de GitOps para reemplazar los CRDs en lugar de fusionarlos. En Flux: configura crds: CreateReplace en el HelmRelease; en Argo CD: usa Replace=true o server-side apply para los CRDs, de modo que se apliquen correctamente.
Si los CRDs no están bien configurados, la instalación de KEDA gestionada por GitOps puede fallar.
También puedes usar helm template para renderizar el chart como archivos YAML normales de Kubernetes y subir esos archivos a Git, si tu flujo de trabajo prefiere gestionar manifiestos renderizados en lugar de un release de Helm en vivo.
Sea cual sea el enfoque que uses, mantén la etiqueta app.kubernetes.io/managed-by consistente para que tu herramienta de GitOps y Helm no entren en conflicto por la propiedad de los recursos.
Crear tu primer ScaledObject después de la instalación
Con KEDA instalado, un ScaledObject te permite verificar que KEDA realmente puede escalar un workload. El ejemplo siguiente usa un trigger de tipo cron, por lo que no necesita un sistema externo. Aumenta las réplicas de un Deployment durante un horario programado y las reduce cuando el horario termina.
Primero, crea un Deployment para escalar y luego aplica el ScaledObject:
apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetadata: name: nginx-cron namespace: defaultspec: scaleTargetRef: name: nginx pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 5 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 9 * * * end: 0 17 * * * desiredReplicas: "5"pollingInterval le indica a KEDA con qué frecuencia, en segundos, debe revisar el trigger. minReplicaCount: 0 habilita el escalado a cero. Fuera de la ventana de 9 a 17, el Deployment puede reducirse a cero pods. Durante la ventana programada, escala hasta cinco réplicas.
Aplica el ScaledObject y revisa lo que creó KEDA:
kubectl get scaledobjectkubectl get hpaDeberías ver un HPA llamado keda-hpa-nginx-cron. KEDA crea y gestiona este HPA para encargarse del escalado real. Esto confirma que KEDA está conectado al workload y que la configuración de escalado programado funciona.
Monitorear la instalación de KEDA
Una vez que KEDA está en ejecución, conviene verificar que esté en buen estado y funcione como se espera.
KEDA proporciona métricas de Prometheus tanto para el operador como para el servidor de métricas. Estas métricas muestran la actividad de los scalers, los errores y los valores que reporta KEDA.
Si usas el Prometheus Operator, el chart de KEDA puede crear un ServiceMonitor para el servidor de métricas y un PodMonitor para el operador. Puedes habilitarlos mediante los ajustes de prometheus en values.yaml, para que Prometheus recopile las métricas automáticamente.
Los logs del operador también son útiles cuando un ScaledObject específico no funciona como se espera. Muestran cómo el scaler está leyendo su trigger y cualquier error que encuentre.
Puedes ver los logs del operador con:
kubectl logs -n keda deploy/keda-operatorRight-sizing de los workloads que KEDA escala
KEDA escala bien la cantidad de pods según la demanda. Pero no decide cuánta CPU y memoria debe solicitar cada pod.
Agregar más réplicas no corrige requests de recursos mal configurados. Si cada pod solicita mucha más CPU o memoria de la que realmente usa, KEDA puede multiplicar esa pérdida a medida que agrega réplicas. Si cada pod solicita muy poco, las nuevas réplicas pueden terminar en OOMKilled o con throttling de CPU cuando el tráfico aumenta.
Aquí es donde las herramientas de optimización de recursos pueden ayudar. PerfectScale monitorea cómo los workloads usan realmente la CPU y la memoria y propone recomendaciones automatizadas de right-sizing que puedes aplicar de forma manual o automática.
En combinación con KEDA, obtienes las dos caras del autoescalado: KEDA ajusta la cantidad de pods según la demanda, mientras que PerfectScale ayuda a garantizar que cada pod tenga la cantidad correcta de CPU y memoria. Esto puede ayudar a prevenir el sobreaprovisionamiento sin sacrificar la confiabilidad de los workloads. Puedes probarlo o agendar una sesión técnica.
Otras herramientas como el Vertical Pod Autoscaler (VPA), que puede ajustar los requests de recursos según el uso, Goldilocks, que ayuda a visualizar las recomendaciones del VPA, y Karpenter se enfocan en elegir y gestionar los nodos que ejecutan tus workloads.
Actualizar y desinstalar el chart
Hay algunos puntos importantes que revisar al actualizar o desinstalar KEDA.
Para actualizar KEDA, primero refresca el repositorio de Helm y luego actualiza a una versión fija del chart:
helm repo updatehelm upgrade keda kedacore/keda --namespace keda --version <new-chart-version>Lo que hay que vigilar durante una actualización son los CRDs. Como el chart los gestiona, un helm upgrade los actualiza junto con todo lo demás, pero las versiones menores de KEDA ocasionalmente cambian campos de los CRDs o el comportamiento de los scalers, así que lee las notas de la versión antes de actualizar un clúster de producción y verifica que la nueva versión de KEDA siga siendo compatible con tu versión de Kubernetes.
Desinstalar KEDA también requiere cuidado, porque eliminarlo puede dejar recursos huérfanos.
Primero, elimina los recursos ScaledObject y ScaledJob:
kubectl delete scaledobject --all --all-namespaceskubectl delete scaledjob --all --all-namespacesLuego desinstala el release de Helm:
helm uninstall keda --namespace kedaEliminar primero los recursos ScaledObject y ScaledJob permite que KEDA limpie los HPAs que creó. También les da a los workloads que estaban escalados a cero la oportunidad de volver a su cantidad normal de réplicas antes de que KEDA sea eliminado.
Si un recurso se queda atascado al eliminarse por culpa de un finalizer, puedes quitar el finalizer con:
kubectl patch scaledobject <name> -p '{"metadata":{"finalizers":null}}' --type=mergeSolución de problemas comunes del chart
Hay dos problemas comunes que revisar cuando KEDA no escala como se espera:
a. La API de métricas externas no está disponible o falla la verificación TLS: si kubectl get apiservice v1beta1.external.metrics.k8s.io no muestra Available, el HPA no puede obtener métricas externas, por lo que los workloads no pueden escalar en función de ellas. Las causas comunes incluyen un servidor de métricas en mal estado, una NetworkPolicy que bloquea el tráfico o un proxy que interfiere con la conexión entre el servidor de la API de Kubernetes y el servidor de métricas. Revisa primero el pod del servidor de métricas. Si usas un proxy, asegúrate de que la IP de clúster del servidor de métricas esté incluida en la lista no_proxy del servidor de la API.
b. Se crea un ScaledObject pero las réplicas no cambian: empieza con kubectl describe scaledobject <name> y revisa su estado y eventos. Luego revisa los logs del operador de KEDA. Las causas pueden ser un trigger mal configurado, autenticación faltante para la fuente de eventos o un HPA existente que ya apunta al mismo workload. El HPA existente puede entrar en conflicto con el HPA que KEDA crea y gestiona.
Buenas prácticas para ejecutar el Helm chart de KEDA
Las siguientes prácticas pueden ayudar a mantener una instalación de KEDA estable y segura:
a. Fija la versión del chart y hazla coincidir con una versión probada de la aplicación KEDA: no instales ni actualices a la versión más reciente sin más. Fija el chart, prueba esa versión de KEDA y despliégala con cuidado para saber siempre qué está en ejecución.
b. Mantén KEDA en su propio namespace con su propia cuota de recursos: un namespace dedicado mantiene KEDA aislado y facilita aplicar una ResourceQuota y una NetworkPolicy específicas para KEDA.
c. Define requests y límites explícitos en los tres componentes de KEDA: debes configurar recursos adecuados para el operador, el servidor de métricas y los webhooks, de modo que el propio KEDA no sufra throttling ni sea desalojado cuando el clúster esté bajo presión.
d. Usa TriggerAuthentication en lugar de poner credenciales directamente en el ScaledObject: mantén las credenciales fuera de tus manifiestos de ScaledObject haciendo referencia a un TriggerAuthentication o ClusterTriggerAuthentication. Esto ayuda a mantener las credenciales fuera del control de versiones y te permite reutilizarlas.
e. Evita combinar un ScaledObject con un HPA creado manualmente en el mismo workload: dos controladores intentando escalar el mismo workload pueden entrar en conflicto. Deja que KEDA gestione el HPA de los workloads que KEDA escala.
f. Prueba las actualizaciones en un clúster que no sea de producción antes de desplegarlas: las versiones menores de KEDA pueden incluir cambios en los CRDs, así que prueba primero la actualización en un entorno seguro. Esto ayuda a detectar problemas de compatibilidad antes de que afecten a los workloads de producción.