Autoescalado por eventos en Kubernetes: saca el máximo provecho de KEDA

Kubernetes Event-driven Autoscaling ( KEDA) es un componente open source para Kubernetes que amplía las capacidades de autoescalado al permitir que el escalado se dispare por eventos, a partir de métricas personalizadas y triggers externos. Extiende el Horizontal Pod Autoscaler ( HPA) estándar de Kubernetes para lograr un autoescalado más flexible y granular.

Estas son algunas de las características de KEDA:

• Autoescalado por eventos: KEDA escala las aplicaciones a partir de eventos externos, como la cantidad de mensajes en un topic de Kafka o la cantidad de eventos en un Azure Event Hub. Así puedes escalar tus aplicaciones en tiempo real para responder a la demanda.
• Scalers integrados: KEDA trae un catálogo de scalers para distintas plataformas en la nube, bases de datos, sistemas de mensajería, sistemas de telemetría, CI/CD y más. Eso facilita dar los primeros pasos con el autoescalado por eventos.
• Compatibilidad con varios tipos de workloads: KEDA admite distintos tipos de workloads, como Deployments, Jobs y recursos personalizados con el subrecurso /scale. Esto lo convierte en una solución flexible para una gran variedad de aplicaciones.
• Extensible: KEDA es extensible, así que puedes aportar tus propios scalers o usar los que mantiene la comunidad. Tienes la flexibilidad necesaria para cubrir las necesidades específicas de tus aplicaciones.
• Ahorro de costos: KEDA te ayuda a reducir el gasto en la nube al escalar tus aplicaciones a cero cuando no se utilizan. El ahorro puede ser considerable, sobre todo en aplicaciones con workloads variables.
• Independiente del proveedor: KEDA es vendor-agnostic, así que se integra con cualquier clúster de Kubernetes. Es una excelente opción para organizaciones que ejecutan Kubernetes on-premises, en la nube o en el edge.
• Configuración y administración simplificadas: KEDA propone un enfoque declarativo a través de manifiestos de Kubernetes. Puedes definir las reglas y los triggers de autoescalado con archivos YAML o JSON, lo que simplifica configurar y administrar el comportamiento del autoescalado en tus aplicaciones.

Veamos cómo usar KEDA en GKE para autoescalar a partir de métricas de mensajes de pub/sub. La aplicación de ejemplo y los manifiestos de Kubernetes están disponibles en este repositorio de GitHub.

Requisitos previos

• Un clúster de GKE con workload identity habilitado
• Helm y Kubectl

Ejecuta los siguientes comandos para crear un topic y una suscripción de pub/sub.

GCP_PROJECT_ID=$(gcloud config get-value project)
TOPIC_NAME=keda-demo-topic
SUBSCRIPTION_NAME=keda-demo-topic-subscription

# Create Topic
gcloud pubsub topics create $TOPIC_NAME --project $GCP_PROJECT_ID

# Create Subscription
gcloud pubsub subscriptions create $SUBSCRIPTION_NAME \
--topic $TOPIC_NAME \
--project $GCP_PROJECT_ID

GCP Workload Identity permite que los workloads en clústeres de GKE asuman la identidad de cuentas de servicio de Identity and Access Management ( IAM) para acceder a los servicios de Google Cloud. Workload Identity es la forma recomendada para que los workloads que corren en GKE accedan a los servicios de Google Cloud de manera segura y administrable.

Ejecuta los siguientes comandos para configurar workload identity en KEDA.

KEDA_GCP_SERVICE_ACCOUNT=keda-operator
KEDA_NAMESPACE=keda
KEDA_K8S_SERVICE_ACCOUNT=keda-operator

#Create GCP service account
gcloud iam service-accounts create $KEDA_GCP_SERVICE_ACCOUNT \
--project=$GCP_PROJECT_ID

#Create IAM role bindings
gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
--member "serviceAccount:$KEDA_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com" \
--role "roles/monitoring.viewer"

#Allow kubernetes service account to impersonate GCP service account
gcloud iam service-accounts add-iam-policy-binding $KEDA_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$GCP_PROJECT_ID.svc.id.goog[$KEDA_NAMESPACE/$KEDA_K8S_SERVICE_ACCOUNT]"

Estas son las distintas opciones para instalar KEDA en un clúster de Kubernetes.

• Helm charts
• Operator Hub
• Declaraciones YAML

Vamos a usar el Helm Chart para desplegar KEDA en el clúster de GKE.

• Agrega y actualiza el repositorio de Helm.

helm repo add kedacore https://kedacore.github.io/charts
helm repo update

• Instala la última versión del Helm chart de KEDA.

helm upgrade -install keda kedacore/keda \
--namespace keda \
--set 'serviceAccount.annotations.iam\.gke\.io\/gcp-service-account'="$KEDA_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com" \
--create-namespace \
--debug \
--wait

Revisa los logs de los pods de keda y confirma que la aplicación esté corriendo sin errores.

Las llamadas al webhook de KEDA se atienden por el puerto 9443, así que asegúrate de que cualquier regla de firewall entre el plano de control y los nodos permita las solicitudes por ese puerto. En GKE, las reglas de firewall autogeneradas solo permiten la comunicación por los puertos 443 y 10250, por lo que tendrás que crear una nueva regla para habilitar el puerto 9443.

Ejemplo de comando gcloud para crear la regla de firewall.

gcloud compute firewall-rules create allow-api-server-to-keda-webhook \
--description="Allow kubernetes api server to keda webhook call on worker nodes TCP port 9443" \
--direction=INGRESS \
--priority=1000 \
--network=$VPC-NETWORK-NAME \
--action=ALLOW \
--rules=tcp:9443 \
--source-ranges=$CONTROL-PLANE-IP-RANGE \
--target-tags=$NETWORK-TAGS-ASSIGNED-TO-NODES

Configura workload identity para que la aplicación de ejemplo pueda consumir los mensajes de la suscripción de pub/sub.

SAMPLE_APP_GCP_SERVICE_ACCOUNT=keda-demo
SAMPLE_APP_NAMESPACE=default
SAMPLE_APP_K8S_SERVICE_ACCOUNT=keda-demo

#Create GCP service account
gcloud iam service-accounts create $SAMPLE_APP_GCP_SERVICE_ACCOUNT \
--project=$GCP_PROJECT_ID

#Create IAM role bindings
gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
--member "serviceAccount:$SAMPLE_APP_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com" \
--role "roles/pubsub.subscriber"

#Allow kubernetes service account to impersonate GCP service account
gcloud iam service-accounts add-iam-policy-binding $SAMPLE_APP_GCP_SERVICE_ACCOUNT@$GCP_PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$GCP_PROJECT_ID.svc.id.goog[$KEDA_NAMESPACE/$KEDA_SERVICE_ACCOUNT]"

Despliega la aplicación de ejemplo en el clúster de GKE.

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: keda-demo@$GCP_PROJECT_ID.iam.gserviceaccount.com
  name: keda-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: keda-demo
spec:
  selector:
    matchLabels:
      app: keda-demo
  replicas: 1
  template:
    metadata:
      labels:
        app: keda-demo
    spec:
      serviceAccountName: keda-demo
      containers:
      - image: simbu1290/keda-demo:v1
        name: consumer
        env:
        - name: PUB_SUB_PROJECT
          value: $GCP_PROJECT_ID
        - name: PUB_SUB_TOPIC
          value: "keda-demo-topic"
        - name: PUB_SUB_SUBSCRIPTION
          value: "keda-demo-topic-subscription"
EOF

Desplegar el Event Scaler de KEDA

KEDA se integra de forma nativa con distintos Scalers (fuentes de eventos) y se apoya en Custom Resources ( CRDs) para definir las acciones y los parámetros de escalado deseados. KEDA monitorea la fuente de eventos y entrega esos datos al Horizontal Pod Autoscaler ( HPA) para escalar un recurso de forma ágil.

Aquí vamos a usar el event scaler de Google Cloud Platform‎ Pub/Sub para mostrar el autoescalado en acción. La relación de escalado entre una fuente de eventos y un workload concreto (por ejemplo, un Deployment o un StatefulSet) se configura mediante la Custom Resource Definition ScaledObject.

TriggerAuthentication te permite describir los parámetros de autenticación por separado del ScaledObject y de los contenedores del deployment. También habilita métodos de autenticación más avanzados, como pod identity y la reutilización de credenciales.

Despliega los siguientes recursos para el autoescalado y KEDA escalará en función de la cantidad de mensajes sin confirmar en la suscripción.

cat <<EOF | kubectl apply -f -
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-demo-trigger-auth-gcp-credentials
spec:
  podIdentity:
    provider: gcp
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: keda-demo-pubsub-scaledobject
spec:
  scaleTargetRef:
    apiVersion: apps/v1 # Optional. Default: apps/v1
    kind: Deployment    # Optional. Default: Deployment
    name: keda-demo     # Mandatory. Must be in the same namespace as the ScaledObject
  pollingInterval: 5    # Optional. Default: 30 seconds
  minReplicaCount: 1    # Optional. Default: 0
  maxReplicaCount: 10   # Optional. Default: 100
  triggers:
  - type: gcp-pubsub
    authenticationRef:
      kind: TriggerAuthentication
      name: keda-demo-trigger-auth-gcp-credentials
    metadata:
      mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge
      value: "5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge
      subscriptionName: "keda-demo-topic-subscription" # Mandatory
EOF

Revisa el recurso HPA que creó KEDA.

Usa el siguiente script para publicar mensajes de prueba en el topic y observa cómo el HPA aplica las acciones de escalado a partir de las métricas que entrega KEDA.

#!/bin/bash

project_id=$GCP_PROJECT_ID
topic_name=$TOPIC_NAME

while true; do
    message="Hello, Pub/Sub!"
    gcloud pubsub topics publish ${topic_name} \
    --message "${message}" \
    --project ${project_id}
    sleep 1
done

Demo de escalado con KEDA