1. Leer un mensaje de la cola             ~2 ms de CPU
2. Consultar los datos de la reserva      ~5 ms de CPU + 8 ms esperando a PostgreSQL
3. Renderizar la plantilla del correo     ~12 ms de CPU
4. Conectar con el servidor SMTP y enviar ~3 ms de CPU + 450 ms ESPERANDO
5. Confirmar el mensaje en la cola        ~1 ms de CPU

Total: ~23 ms de CPU y ~458 ms de espera.
Proporcion CPU/tiempo total: 23 / 481 = 4,8 %

ratio = 60 / 210 = 0,286
replicasDeseadas = techo(2 x 0,286) = 1

El HPA quiere BAJAR a 1 replica.

Cola: 40.000 mensajes.
Un worker procesa ~2 mensajes/segundo (limitado por el SMTP).
Objetivo: vaciar la cola en 20 minutos = 1.200 segundos.

Mensajes por segundo necesarios: 40.000 / 1.200 = 33,3
Workers necesarios: 33,3 / 2 = 17 workers.

Conditions:
  Type           Status  Reason                 Message
  ----           ------  ------                 -------
  ScalingActive  False   FailedGetExternalMetric  unable to get external metric
                         rutas-norte-pro/longitud_cola_correos/nil:
                         no custom metrics API (external.metrics.k8s.io/v1beta1)
                         registered

- type: Pods
  pods:
    metric:
      name: peticiones_por_segundo
    target:
      type: AverageValue
      averageValue: "85"

- type: Object
  object:
    describedObject:
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      name: rutas-norte-publico
    metric:
      name: peticiones_por_segundo
    target:
      type: Value
      value: "5000"

- type: External
  external:
    metric:
      name: longitud_cola_correos
      selector:
        matchLabels:
          cola: notificaciones-confirmacion
    target:
      type: AverageValue
      averageValue: "2500"

kubectl get apiservices | grep metrics

NAME                                    SERVICE                              AVAILABLE   AGE
v1beta1.metrics.k8s.io                  kube-system/metrics-server           True        41d
v1beta1.external.metrics.k8s.io         keda/keda-operator-metrics-apiserver  True        12d

# Fragmento de la configuracion de prometheus-adapter
rules:
  - seriesQuery: 'peticiones_http_total{namespace!="",pod!=""}'
    resources:
      overrides:
        namespace: {resource: "namespace"}
        pod: {resource: "pod"}
    name:
      matches: "^peticiones_http_total$"
      as: "peticiones_por_segundo"
    metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/rutas-norte-pro/pods/*/peticiones_por_segundo" \
  | python3 -m json.tool

# Con Helm (lo veremos a fondo en 10-03)
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace

# Verificacion
kubectl get pods -n keda

NAME                                              READY   STATUS    RESTARTS   AGE
keda-admission-webhooks-6d8f7c9b4d-x2klm          1/1     Running   0          2m
keda-operator-7d9c5f8b6b-4mnpq                    1/1     Running   0          2m
keda-operator-metrics-apiserver-5f7b8c9d6a-9wrtz  1/1     Running   0          2m

kubectl get crd | grep keda

clustertriggerauthentications.keda.sh    2026-04-20T11:32:14Z
scaledjobs.keda.sh                       2026-04-20T11:32:14Z
scaledobjects.keda.sh                    2026-04-20T11:32:14Z
triggerauthentications.keda.sh           2026-04-20T11:32:14Z

kubectl get hpa -n rutas-norte-pro

NAME                                  REFERENCE                          TARGETS        MINPODS  MAXPODS  REPLICAS
keda-hpa-worker-notificaciones        Deployment/worker-notificaciones   1847/2500 (avg)  1        25       8

kubectl get hpa keda-hpa-worker-notificaciones -n rutas-norte-pro -o yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: keda-hpa-worker-notificaciones
  namespace: rutas-norte-pro
  labels:
    app.kubernetes.io/managed-by: keda-operator
    scaledobject.keda.sh/name: worker-notificaciones
  ownerReferences:
    - apiVersion: keda.sh/v1alpha1
      kind: ScaledObject
      name: worker-notificaciones
      controller: true
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-notificaciones
  minReplicas: 1
  maxReplicas: 25
  metrics:
    - type: External
      external:
        metric:
          name: s0-rabbitmq-notificaciones-confirmacion
          selector:
            matchLabels:
              scaledobject.keda.sh/name: worker-notificaciones
        target:
          type: AverageValue
          averageValue: "2500"

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-notificaciones
  namespace: rutas-norte-pro
spec:
  # A QUE carga se aplica.
  scaleTargetRef:
    apiVersion: apps/v1        # Opcional, por defecto apps/v1
    kind: Deployment           # Opcional, por defecto Deployment
    name: worker-notificaciones
    envSourceContainerName: worker   # De que contenedor leer variables de entorno

  # CADA CUANTO consulta KEDA la fuente externa.
  pollingInterval: 15

  # CUANTO espera sin actividad antes de bajar a CERO.
  cooldownPeriod: 300

  # Replicas cuando NO hay actividad. 0 = escalado a cero.
  minReplicaCount: 0
  maxReplicaCount: 25

  # Replicas en estado "inactivo" DISTINTO de cero.
  idleReplicaCount: 0

  # Que hacer si la fuente de metricas NO RESPONDE.
  fallback:
    failureThreshold: 3
    replicas: 6

  # Configuracion avanzada.
  advanced:
    restoreToOriginalReplicaCount: false
    horizontalPodAutoscalerConfig:
      name: hpa-worker-notificaciones
      behavior:
        scaleUp: {}
        scaleDown: {}

  # QUE observa. Es una lista: puede haber varios.
  triggers:
    - type: rabbitmq
      metadata:
        queueName: notificaciones-confirmacion
        mode: QueueLength
        value: "2500"
      authenticationRef:
        name: rabbitmq-credenciales

minReplicaCount: 3       # Cuando hay actividad, minimo 3
idleReplicaCount: 1      # Cuando NO hay actividad, baja a 1

fallback:
  failureThreshold: 3    # Tras 3 consultas fallidas consecutivas...
  replicas: 6            # ...fijar 6 replicas y mantenerlas

advanced:
  horizontalPodAutoscalerConfig:
    name: hpa-worker-notificaciones     # Nombre personalizado del HPA generado
    behavior:
      scaleUp:
        stabilizationWindowSeconds: 0
        selectPolicy: Max
        policies:
          - type: Percent
            value: 100
            periodSeconds: 30
          - type: Pods
            value: 5
            periodSeconds: 30
      scaleDown:
        stabilizationWindowSeconds: 300
        selectPolicy: Min
        policies:
          - type: Percent
            value: 25
            periodSeconds: 60

triggers:
  - type: rabbitmq        # Señal principal: la cola
    metadata: {...}
  - type: cpu             # Red de seguridad: si la CPU se dispara, escalar igual
    metricType: Utilization
    metadata:
      value: "80"

- type: prometheus
  metadata:
    serverAddress: http://prometheus-operated.monitorizacion.svc.cluster.local:9090
    query: |
      sum(rate(api_reservas_peticiones_total{namespace="rutas-norte-pro"}[2m]))
    threshold: "85"
    # Que valor usar si la consulta no devuelve nada (serie vacia)
    ignoreNullValues: "true"
    unsafeSsl: "false"

- type: rabbitmq
  metadata:
    protocol: amqp
    queueName: notificaciones-confirmacion
    mode: QueueLength        # QueueLength o MessageRate
    value: "2500"
    # activationValue: por debajo de esto, se considera INACTIVO (para el 0)
    activationValue: "10"
  authenticationRef:
    name: rabbitmq-credenciales

- type: cron
  metadata:
    timezone: Europe/Madrid
    start: "30 9 * * *"       # A las 9:30
    end: "0 14 * * *"         # Hasta las 14:00
    desiredReplicas: "25"

- type: postgresql
  metadata:
    query: "SELECT COUNT(*) FROM tareas_pendientes WHERE estado = 'pendiente'"
    targetQueryValue: "50"
    activationTargetQueryValue: "1"
  authenticationRef:
    name: postgres-credenciales

metadata:
  value: "2500"              # 1 replica por cada 2500 mensajes
  activationValue: "10"      # Con menos de 10 mensajes, se considera inactivo

# 1. El Secret con las credenciales (modulo 3 y 08-05)
apiVersion: v1
kind: Secret
metadata:
  name: rabbitmq-credenciales
  namespace: rutas-norte-pro
type: Opaque
stringData:
  # Cadena de conexion completa con usuario y contrasena.
  host: "amqp://keda_lector:[email protected]:5672/"
---
# 2. El TriggerAuthentication que la referencia
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: rabbitmq-credenciales
  namespace: rutas-norte-pro
spec:
  secretTargetRef:
    - parameter: host          # Nombre del parametro que espera el escalador
      name: rabbitmq-credenciales
      key: host                # Clave dentro del Secret

triggers:
  - type: rabbitmq
    metadata:
      queueName: notificaciones-confirmacion
      mode: QueueLength
      value: "2500"
    authenticationRef:
      name: rabbitmq-credenciales

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: aws-sqs-identidad
  namespace: rutas-norte-pro
spec:
  podIdentity:
    provider: aws
    roleArn: arn:aws:iam::000000000000:role/rutas-norte-keda-sqs

apiVersion: keda.sh/v1alpha1
kind: ClusterTriggerAuthentication
metadata:
  name: prometheus-lectura        # Sin namespace
spec:
  secretTargetRef:
    - parameter: bearerToken
      name: prometheus-token
      key: token

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: procesador-facturas
  namespace: rutas-norte-pro
spec:
  jobTargetRef:
    parallelism: 1
    completions: 1
    backoffLimit: 3
    template:
      spec:
        restartPolicy: Never
        containers:
          - name: procesador
            image: registry.rutasnorte.example/procesador-facturas:2.1.0
            resources:
              requests: {cpu: 500m, memory: 512Mi}
              limits: {cpu: "2", memory: 2Gi}

  pollingInterval: 30
  maxReplicaCount: 20
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 10

  # Como calcular cuantos Jobs crear a partir del valor de la metrica.
  scalingStrategy:
    strategy: "default"

  triggers:
    - type: rabbitmq
      metadata:
        queueName: facturas-pendientes
        mode: QueueLength
        value: "1"          # UN Job por mensaje
      authenticationRef:
        name: rabbitmq-credenciales

# k8s/entornos/pro/scaledobject-worker-notificaciones.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-notificaciones
  namespace: rutas-norte-pro
  labels:
    app: worker-notificaciones
    app.kubernetes.io/part-of: rutas-norte
    entorno: pro
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-notificaciones

  # Consulta a RabbitMQ cada 15 s. Suficientemente rapido para que la
  # reactivacion desde cero sea casi inmediata, y suficientemente lento para
  # no machacar la API de gestion de RabbitMQ.
  pollingInterval: 15

  # 10 minutos sin actividad antes de apagar del todo. Es generoso a proposito:
  # las reservas llegan a rafagas, y apagar y encender cada dos minutos costaria
  # mas (en arranques en frio) que mantener un pod.
  cooldownPeriod: 600

  # ESCALADO A CERO. Fuera de temporada no hay razon para mantener workers
  # encendidos las 24 horas esperando un correo cada varios minutos.
  minReplicaCount: 0

  # Techo: 25 workers x 2 correos/s = 50 correos/s = 3.000 correos/minuto.
  # Los 40.000 correos del puente se vacian en ~14 minutos. Suficiente.
  # Ademas: 25 x 120m = 3 nucleos, que caben en el plan de capacidad de 09-03.
  maxReplicaCount: 25

  # Si RabbitMQ deja de responder, no nos quedamos congelados: fijamos 6
  # replicas, que es el caudal de un dia normal con margen. Mejor un numero
  # seguro conocido que un numero congelado desconocido.
  fallback:
    failureThreshold: 3
    replicas: 6

  advanced:
    # Al borrar el ScaledObject, devolver el Deployment a sus replicas originales.
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-worker-notificaciones
      behavior:
        scaleUp:
          # Sin espera: si hay cola, hay trabajo pendiente AHORA.
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 5
              periodSeconds: 30
        scaleDown:
          # 5 minutos de calma. Menos conservador que api-reservas porque
          # arrancar un worker es barato (no tiene cache que calentar) y
          # porque no hay ningun usuario esperando una respuesta.
          stabilizationWindowSeconds: 300
          selectPolicy: Min
          policies:
            - type: Percent
              value: 30
              periodSeconds: 60

  triggers:
    # DISPARADOR PRINCIPAL: la longitud de la cola.
    - type: rabbitmq
      metadata:
        protocol: amqp
        queueName: notificaciones-confirmacion
        mode: QueueLength
        # 1 worker por cada 2.500 mensajes en cola.
        #
        # Calculo: queremos vaciar 40.000 mensajes en ~15 minutos.
        #   40.000 / 900 s = 44,4 mensajes/s necesarios
        #   44,4 / 2 (por worker) = 22,2 workers
        #   40.000 / 22,2 = 1.800 mensajes por worker
        # Redondeamos a 2.500 para no llegar al techo con margen justo:
        #   40.000 / 2.500 = 16 workers -> vacia en ~21 minutos. Aceptable.
        value: "2500"
        # Por debajo de 10 mensajes, se considera inactivo y puede bajar a cero.
        # No ponemos 0 porque siempre hay 1-2 mensajes residuales en transito.
        activationValue: "10"
      authenticationRef:
        name: rabbitmq-credenciales

    # DISPARADOR SECUNDARIO: red de seguridad por CPU.
    # Si por alguna razon imprevista los workers se saturan de CPU (una
    # plantilla de correo patologica, por ejemplo) escalamos igual, aunque
    # la cola este corta. Gana el disparador que pide MAS replicas.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "80"

kubectl apply -f k8s/entornos/pro/scaledobject-worker-notificaciones.yaml
kubectl get scaledobject -n rutas-norte-pro

NAME                    SCALETARGETKIND      SCALETARGETNAME         MIN  MAX  TRIGGERS   AUTHENTICATION          READY  ACTIVE  FALLBACK  AGE
worker-notificaciones   apps/v1.Deployment   worker-notificaciones   0    25   rabbitmq   rabbitmq-credenciales   True   False   False     34s

kubectl get deployment worker-notificaciones -n rutas-norte-pro

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
worker-notificaciones   0/0     0            0           89d

kubectl get deployment worker-notificaciones -n rutas-norte-pro --watch

# Simular 30.000 correos de confirmacion (apertura de la venta)
kubectl exec -n rutas-norte-pro rabbitmq-0 -- \
  rabbitmqadmin publish routing_key=notificaciones-confirmacion \
  payload='{"reserva":"RN-2026-054321","destinatario":"[email protected]"}' \
  --count=30000

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
worker-notificaciones   0/0     0            0           89d
worker-notificaciones   0/1     0            0           89d     <- KEDA activa: 0 -> 1
worker-notificaciones   1/1     1            1           89d
worker-notificaciones   1/6     1            1           89d     <- El HPA toma el mando
worker-notificaciones   6/6     6            6           89d
worker-notificaciones   6/12    6            6           89d
worker-notificaciones   12/12   12           12          89d
worker-notificaciones   12/12   12           12          89d     <- Estable: 30000/2500 = 12

kubectl get hpa hpa-worker-notificaciones -n rutas-norte-pro

NAME                        REFERENCE                          TARGETS            MINPODS  MAXPODS  REPLICAS
hpa-worker-notificaciones   Deployment/worker-notificaciones   2483/2500 (avg)    1        25       12

worker-notificaciones   12/12   12   12   89d
worker-notificaciones   12/8    12   12   89d     <- HPA baja (tras estabilizacion)
worker-notificaciones   8/3     8    8    89d
worker-notificaciones   3/1     3    3    89d
worker-notificaciones   1/1     1    1    89d     <- Se queda en 1 (minimo del HPA)
                                                     ...pasan 10 minutos de cooldownPeriod...
worker-notificaciones   0/0     0    0    89d     <- KEDA apaga: 1 -> 0

# HELP api_reservas_peticiones_total Total de peticiones HTTP atendidas
# TYPE api_reservas_peticiones_total counter
api_reservas_peticiones_total{metodo="GET",ruta="/rutas",codigo="200"} 1847293
api_reservas_peticiones_total{metodo="POST",ruta="/reservas",codigo="201"} 92841

# HELP api_reservas_duracion_segundos Duracion de las peticiones
# TYPE api_reservas_duracion_segundos histogram
api_reservas_duracion_segundos_bucket{ruta="/reservas",le="0.1"} 78201
api_reservas_duracion_segundos_bucket{ruta="/reservas",le="0.5"} 91043
...

# HELP api_reservas_confirmadas_total Reservas confirmadas
# TYPE api_reservas_confirmadas_total counter
api_reservas_confirmadas_total 92841

# k8s/entornos/pro/scaledobject-api-reservas.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-reservas
  namespace: rutas-norte-pro
  labels:
    app: api-reservas
    app.kubernetes.io/part-of: rutas-norte
    entorno: pro
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-reservas

  pollingInterval: 15
  cooldownPeriod: 300

  # NO escalamos a cero. api-reservas es la API que sostiene la venta: un
  # arranque en frio delante de un usuario que quiere comprar es inaceptable.
  # 4 replicas es el suelo de disponibilidad acordado (09-01, y 09-05).
  minReplicaCount: 4
  maxReplicaCount: 30

  fallback:
    failureThreshold: 3
    # Si Prometheus cae, fijamos 12 replicas: el triple del minimo. Es un
    # numero conservador que aguanta un dia normal con holgura y nos da tiempo
    # a arreglar Prometheus sin riesgo de caida.
    replicas: 12

  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-api-reservas
      behavior:
        # El MISMO behavior asimetrico de 09-01: subir en cero segundos,
        # bajar tras diez minutos de calma sostenida.
        scaleUp:
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 6
              periodSeconds: 30
        scaleDown:
          stabilizationWindowSeconds: 600
          selectPolicy: Min
          policies:
            - type: Percent
              value: 20
              periodSeconds: 120
            - type: Pods
              value: 3
              periodSeconds: 120

  triggers:
    # DISPARADOR PRINCIPAL: peticiones por segundo, medidas en Prometheus.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitorizacion.svc.cluster.local:9090
        # Nombre con el que aparecera la metrica en el HPA generado.
        metricName: api_reservas_peticiones_por_segundo
        query: |
          sum(
            rate(
              api_reservas_peticiones_total{
                namespace="rutas-norte-pro",
                app="api-reservas"
              }[2m]
            )
          )
        # 85 peticiones por segundo y replica.
        #
        # Calculo (de la prueba de carga de 09-06): una replica de api-reservas
        # con 412m de CPU sostiene ~120 rps antes de que la latencia p95 supere
        # los 300 ms. Dejamos un 30 % de margen para absorber el tiempo de
        # arranque de las replicas nuevas: 120 x 0,7 = 84 -> 85 rps.
        threshold: "85"
        activationThreshold: "5"
        ignoreNullValues: "true"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # RED DE SEGURIDAD 1: CPU. Si por lo que sea las peticiones son mucho mas
    # caras de lo habitual (una consulta patologica, un cliente abusivo), la
    # CPU lo detectara aunque el numero de peticiones sea normal.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "70"

sum(
  rate(
    api_reservas_peticiones_total{
      namespace="rutas-norte-pro",
      app="api-reservas"
    }[2m]
  )
)

kubectl get hpa hpa-api-reservas -n rutas-norte-pro

NAME               REFERENCE                 TARGETS                   MINPODS  MAXPODS  REPLICAS
hpa-api-reservas   Deployment/api-reservas   1247/85 (avg), 34%/70%    4        30       15

Valor total de la consulta: 1.247 rps (todas las replicas juntas)
Replicas actuales: 15
Valor por replica: 1.247 / 15 = 83,1 rps
Objetivo: 85 rps

ratio = 83,1 / 85 = 0,978  ->  dentro de la banda de tolerancia. Estable.

# 1. Borrar el HPA manual
kubectl delete hpa api-reservas -n rutas-norte-pro

# 2. Crear el ScaledObject
kubectl apply -f k8s/entornos/pro/scaledobject-api-reservas.yaml

# 3. Verificar que KEDA ha creado el suyo
kubectl get hpa -n rutas-norte-pro

Error from server: admission webhook "vscaledobject.kb.io" denied the request:
the workload 'api-reservas' of type 'apps/v1.Deployment' is already managed by
the hpa 'api-reservas'

09:59:50  4 replicas de api-reservas. Trafico normal: 180 rps.
10:00:00  Se abre la venta. El trafico salta a 2.400 rps en 40 segundos.
10:00:15  Prometheus recolecta. El rate[2m] aun refleja el promedio de
          los ultimos 2 minutos, que incluye 1m50s de calma: ~400 rps.
10:00:15  KEDA/HPA: 400/4 = 100 rps por replica. Ratio 1,18. Pide 5 replicas.
          <- MUY POR DEBAJO de lo necesario. El rate[2m] SUAVIZA el pico.
10:00:45  El rate ya refleja mejor la realidad: ~1.500 rps. Pide 18 replicas.
10:01:15  Los primeros pods nuevos estan Ready.
10:02:30  Se alcanzan las 28 replicas necesarias.

DEGRADACION: dos minutos y medio en el momento de mas valor del ano.

# k8s/entornos/pro/scaledobject-api-reservas.yaml (fragmento anadido)
  triggers:
    - type: prometheus
      # ... (el disparador principal de arriba, sin cambios)

    - type: cpu
      # ... (la red de seguridad, sin cambios)

    # DISPARADOR DE PRECALENTAMIENTO: el puente de mayo.
    #
    # La venta abre a las 10:00 del 25 de abril. A las 9:30 ya queremos
    # 25 replicas ARRANCADAS Y CALIENTES: pool de conexiones a PostgreSQL
    # establecido, cache de rutas poblada, JIT de Node.js calentado.
    #
    # Recuerda la regla del HPA: GANA EL DISPARADOR QUE PIDE MAS REPLICAS.
    # Entre las 9:30 y las 14:00, el suelo son 25 replicas. Si el trafico
    # real pide mas, el disparador de Prometheus sube hasta 30.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "30 9 25 4 *"        # 25 de abril a las 9:30
        end: "0 14 25 4 *"          # 25 de abril a las 14:00
        desiredReplicas: "25"

    # Precalentamiento diario de la franja de mas venta.
    # De lunes a domingo, de 9:30 a 13:00, suelo de 10 replicas.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "30 9 * * *"
        end: "0 13 * * *"
        desiredReplicas: "10"

    # Refuerzo de fin de semana: viernes tarde y sabado manana concentran
    # las reservas de escapada.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "0 16 * * 5"         # Viernes a las 16:00
        end: "0 22 * * 6"           # Sabado a las 22:00
        desiredReplicas: "15"

# k8s/entornos/pro/scaledobject-relleno-capacidad.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: relleno-capacidad
  namespace: rutas-norte-pro
spec:
  scaleTargetRef:
    name: relleno-capacidad
  minReplicaCount: 2
  maxReplicaCount: 10
  cooldownPeriod: 300
  triggers:
    # Ampliar el colchon UNA HORA ANTES que las replicas de api-reservas.
    # Asi el Cluster Autoscaler tiene tiempo de arrancar los nodos, y a las
    # 9:30, cuando el cron de api-reservas pida 25 replicas, hay sitio.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "30 8 25 4 *"        # 8:30, una hora antes
        end: "0 15 25 4 *"
        desiredReplicas: "10"

08:30  El cron amplia el relleno de 2 a 10 pods.
       8 pods de relleno pasan a Pending.
08:31  El Cluster Autoscaler detecta los pendientes, pide 3 nodos.
08:35  Los nodos estan Ready. El relleno se coloca.
       CAPACIDAD LISTA Y PAGADA, pero ocupada por pods que no hacen nada.
09:30  El cron de api-reservas pide 25 replicas.
       El planificador DESALOJA los pods de relleno (prioridad -10).
09:30  Las 25 replicas se colocan en SEGUNDOS. No hace falta esperar nodos.
09:31  Los pods de relleno pasan a Pending -> el CA arranca mas nodos ->
       el colchon se regenera para lo que venga.
09:32  25 replicas Ready y calientes.
10:00  APERTURA. Cero degradacion.

t=0     Llega un mensaje a la cola.
t=0-15  KEDA lo detecta en su siguiente ciclo (pollingInterval).
t=15    KEDA escala el Deployment de 0 a 1.
t=16    El planificador coloca el pod. Si NO hay sitio -> +3 min (09-03).
t=17    El kubelet descarga la imagen. Si esta cacheada, ~2 s; si no, 20-60 s.
t=20    El contenedor arranca. Node.js: ~15 s hasta estar listo.
t=35    Conexion a PostgreSQL y a RabbitMQ establecida.
t=36    Se procesa el primer mensaje.

RETRASO TOTAL: entre 35 segundos y 4 minutos.

# k8s/entornos/dev/scaledobject-apagado-nocturno.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-reservas-horario
  namespace: rutas-norte-dev
  labels:
    app: api-reservas
    entorno: dev
spec:
  scaleTargetRef:
    name: api-reservas
  # Fuera del horario laboral: CERO. El entorno se apaga solo.
  minReplicaCount: 0
  maxReplicaCount: 3
  cooldownPeriod: 300
  triggers:
    # De lunes a viernes, de 7:45 a 19:30: 1 replica encendida.
    # 7:45 para que este caliente cuando llegue el equipo a las 8:00.
    - type: cron
      metadata:
        timezone: Europe/Madrid
        start: "45 7 * * 1-5"
        end: "30 19 * * 1-5"
        desiredReplicas: "1"

spec:
  # Cuando HAY actividad: minimo 4 replicas.
  minReplicaCount: 4
  # Cuando NO hay actividad: 1 replica encendida.
  idleReplicaCount: 1

kubectl get scaledobject -n rutas-norte-pro

NAME                    SCALETARGETKIND      SCALETARGETNAME         MIN  MAX  READY  ACTIVE  FALLBACK  AGE
worker-notificaciones   apps/v1.Deployment   worker-notificaciones   0    25   False  False   False     4m

kubectl describe scaledobject worker-notificaciones -n rutas-norte-pro

Status:
  Conditions:
    Type:     Ready
    Status:   False
    Reason:   ScalerFailed
    Message:  error creating scaler for trigger 0: error parsing rabbitmq metadata:
              no host setting given
Events:
  Type     Reason         Age   From           Message
  ----     ------         ----  ----           -------
  Warning  ScalerFailed   4m    keda-operator  error creating scaler for trigger 0

kubectl describe hpa keda-hpa-worker-notificaciones -n rutas-norte-pro

Conditions:
  Type           Status  Reason                   Message
  ----           ------  ------                   -------
  AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
  ScalingActive  False   FailedGetExternalMetric  unable to get external metric
                         rutas-norte-pro/s0-rabbitmq-notificaciones-confirmacion/&LabelSelector{...}:
                         unable to fetch metrics from external metrics API:
                         rpc error: code = Unknown desc = error inspecting rabbitMQ:
                         Object Not Found

kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/rutas-norte-pro/s0-rabbitmq-notificaciones-confirmacion?labelSelector=scaledobject.keda.sh%2Fname%3Dworker-notificaciones" \
  | python3 -m json.tool

{
    "kind": "ExternalMetricValueList",
    "apiVersion": "external.metrics.k8s.io/v1beta1",
    "items": [
        {
            "metricName": "s0-rabbitmq-notificaciones-confirmacion",
            "metricLabels": null,
            "timestamp": "2026-05-01T10:14:32Z",
            "value": "29800"
        }
    ]
}

kubectl logs -n keda deployment/keda-operator --tail=100 | grep -i "worker-notificaciones"

ERROR  scale_handler  error getting scale decision  {"scaledObject.Namespace": "rutas-norte-pro",
       "scaledObject.Name": "worker-notificaciones",
       "error": "dial tcp 10.96.42.17:5672: connect: connection refused"}

kubectl logs -n keda deployment/keda-operator-metrics-apiserver --tail=50

# ¿Puede KEDA llegar a RabbitMQ?
kubectl run prueba-conectividad --rm -it --restart=Never \
  -n keda --image=busybox:1.36 -- \
  wget -qO- --timeout=5 http://rabbitmq.rutas-norte-pro.svc.cluster.local:15672/api/overview

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: permitir-keda-a-rabbitmq
  namespace: rutas-norte-pro
spec:
  podSelector:
    matchLabels:
      app: rabbitmq
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: keda
      ports:
        - protocol: TCP
          port: 5672
        - protocol: TCP
          port: 15672

kubectl port-forward -n monitorizacion svc/prometheus-operated 9090:9090

# Errores del escalador: si sube, KEDA no puede consultar la fuente
sum(rate(keda_scaler_errors_total[5m])) by (scaledObject, scaler) > 0

# Valor de la metrica que KEDA esta reportando
keda_scaler_metrics_value{scaledObject="worker-notificaciones"}

# ScaledObjects en fallback: senal de que una fuente esta caida
keda_scaled_object_errors_total > 0

kubectl get scaledobject -n rutas-norte-pro

NAME                    SCALETARGETKIND      MIN  MAX  READY  ACTIVE  FALLBACK  AGE
worker-notificaciones   apps/v1.Deployment   0    25   True   True    True      3h

kubectl describe hpa keda-hpa-worker-notificaciones -n rutas-norte-pro

Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Metrics:
  ( current / target )
  "s0-rabbitmq-notificaciones-confirmacion" (target average value):  6 / 2500
Events: <none>

kubectl logs -n keda deployment/keda-operator --tail=20 | grep worker

ERROR  scale_handler  error getting metric for scaler  {"scaledObject.Name": "worker-notificaciones",
       "scaler": "rabbitmqScaler",
       "error": "Get \"https://rabbitmq.rutas-norte-pro.svc.cluster.local:15671/api/queues/%2F/notificaciones-confirmacion\":
       dial tcp 10.96.42.17:15671: i/o timeout"}

Cada factura: 8 segundos, procesadas de una en una.
Facturas por segundo por worker = 1 / 8 = 0,125 facturas/s

12.000 facturas en 4 horas = 12.000 / 14.400 s = 0,833 facturas/s de entrada.

Si el sistema procesara justo a la velocidad de entrada, la cola no crecería
pero tampoco se vaciaría, y una factura esperaria... depende de la cola
acumulada. Necesitamos procesar MAS RAPIDO que la entrada.

Enfoque por el objetivo de 30 minutos:
  En 30 minutos (1.800 s) entran 0,833 x 1.800 = 1.500 facturas.
  Para que ninguna espere mas de 30 min, hay que procesar 1.500 facturas
  en menos de 1.800 s: capacidad >= 1.500 / 1.800 = 0,833 facturas/s.

Con margen del 100 % (para absorber rafagas, que la entrada no es uniforme):
  Capacidad objetivo: 1,67 facturas/s

Workers = 1,67 / 0,125 = 13,3  ->  14 workers

Primera hora: 6.000 facturas = 1,67 facturas/s de entrada.
Con 14 workers: 14 x 0,125 = 1,75 facturas/s de capacidad.
Capacidad > entrada: la cola no crece de forma sostenida. Correcto.

Acumulacion maxima estimada: ~500 facturas.
Tiempo de vaciado de esas 500: 500 / 1,75 = 286 s = 4,8 minutos.
MUY por debajo de los 30 minutos. Sobrado.

14 workers x 250m = 3,5 nucleos
Cuota libre: 8 nucleos.

Caben. Y hay margen para subir el maxReplicaCount a 25:
  25 x 250m = 6,25 nucleos < 8. Tambien cabe.

Memoria: 14 x 512Mi = 7 GiB. Sin problema.

En el pico, ¿cuantos mensajes hay en cola?

La acumulacion maxima estimada es ~500 facturas (calculado arriba). Pero
si el escalado tarda en arrancar, la acumulacion inicial es mayor: en los
primeros 2 minutos con 1 sola replica, entran 1,67 x 120 = 200 facturas
y se procesan 0,125 x 120 = 15. Acumulacion: ~185.

Queremos que con ~500 mensajes en cola haya 14 workers:
  threshold = 500 / 14 = 35,7  ->  redondeamos a 35

Verificacion con otros valores de cola:
  100 mensajes -> techo(100/35) = 3 workers
  300 mensajes -> techo(300/35) = 9 workers
  500 mensajes -> techo(500/35) = 15 workers  (objetivo alcanzado)
  700 mensajes -> techo(700/35) = 20 workers  (techo)

Duracion de la tarea: 8 segundos.
Tiempo de arranque de un pod: ~15 segundos.

8 < 15: la tarea dura MENOS que el arranque.
-> ScaledObject. Un ScaledJob gastaria mas tiempo arrancando que trabajando.

# k8s/entornos/pro/scaledobject-worker-facturas.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-facturas
  namespace: rutas-norte-pro
  labels:
    app: worker-facturas
    app.kubernetes.io/part-of: rutas-norte
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-facturas

  pollingInterval: 20

  # 15 minutos sin actividad antes de apagar. Generoso porque las facturas
  # llegan a rafagas tras los cierres de venta, y apagar entre rafagas
  # costaria mas en arranques en frio que mantener un pod.
  cooldownPeriod: 900

  # ESCALADO A CERO. Nadie espera una factura en tiempo real: el objetivo
  # son 30 minutos, y el arranque en frio son 35 segundos. Sobra margen.
  # Fuera de temporada se generan pocas facturas al dia.
  minReplicaCount: 0

  # 20 workers = 5 nucleos, dentro de los 8 libres de la cuota.
  # 20 x 0,125 = 2,5 facturas/s = 9.000 facturas/hora. Muy por encima
  # de las 3.000/hora del pico del puente.
  maxReplicaCount: 20

  fallback:
    failureThreshold: 3
    # Si el almacen de la cola no responde, 5 workers: suficiente para el
    # caudal habitual mientras se investiga.
    replicas: 5

  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-worker-facturas
      behavior:
        scaleUp:
          # Sin espera: si hay cola, hay trabajo pendiente.
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 5
              periodSeconds: 30
        scaleDown:
          # 10 minutos: las facturas llegan a rafagas tras cada cierre de
          # venta, y no queremos destruir workers entre rafaga y rafaga.
          stabilizationWindowSeconds: 600
          selectPolicy: Min
          policies:
            - type: Percent
              value: 30
              periodSeconds: 120

  triggers:
    - type: rabbitmq
      metadata:
        protocol: amqp
        queueName: facturas-pendientes
        mode: QueueLength
        # 1 worker por cada 35 facturas en cola.
        #
        # Calculo: un worker procesa 1 factura cada 8 s = 0,125 facturas/s.
        # La entrada en el pico del puente es 0,833 facturas/s (12.000 en 4 h).
        # Con margen del 100 % para rafagas: capacidad objetivo 1,67 facturas/s.
        # Workers necesarios: 1,67 / 0,125 = 14.
        # Acumulacion de cola esperada en el pico: ~500 mensajes.
        # threshold = 500 / 14 = 35.
        #
        # Objetivo de negocio: ninguna factura espera mas de 30 minutos.
        # Con 14 workers, el tiempo de vaciado de 500 facturas es ~5 minutos.
        value: "35"
        # Por debajo de 3 facturas, se considera inactivo. Permite el
        # escalado a cero sin que 1-2 mensajes residuales lo impidan.
        activationValue: "3"
      authenticationRef:
        name: rabbitmq-credenciales

    # Red de seguridad: si el almacen de objetos se ralentiza y las facturas
    # tardan 30 s en lugar de 8, la cola crecera y el disparador principal
    # ya lo detectara. Pero si el problema es de CPU (un PDF patologico),
    # este disparador lo cubre.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "80"

Get "https://rabbitmq.rutas-norte-pro.svc.cluster.local:15671/api/queues/..."
dial tcp 10.96.42.17:15671: i/o timeout

KEDA quiere que el HPA calcule 6 replicas.
El HPA calcula: techo(replicasActuales x valor / threshold)

Pero como el HPA usa AverageValue, la mecanica del fallback de KEDA es
reportar un valor tal que el resultado sea las replicas del fallback.

En la salida vemos "6 / 2500", que es el valor de fallback reportado.
El HPA con 1 replica calcula techo(1 x 6/2500) = techo(0,0024) = 1.

# 1. ¿Existe el Service y responde?
kubectl get svc rabbitmq -n rutas-norte-pro
kubectl get endpoints rabbitmq -n rutas-norte-pro

# 2. ¿Hay una NetworkPolicy nueva?
kubectl get networkpolicy -n rutas-norte-pro
kubectl describe networkpolicy -n rutas-norte-pro

# 3. Probar la conectividad DESDE el namespace de KEDA
kubectl run prueba --rm -it --restart=Never -n keda --image=busybox:1.36 -- \
  wget -qO- --timeout=5 http://rabbitmq.rutas-norte-pro.svc.cluster.local:15672/api/overview

# k8s/entornos/pro/networkpolicy-keda-rabbitmq.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: permitir-keda-a-rabbitmq
  namespace: rutas-norte-pro
spec:
  podSelector:
    matchLabels:
      app: rabbitmq
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: keda
      ports:
        - protocol: TCP
          port: 15672      # API de gestion HTTP
        - protocol: TCP
          port: 5672       # AMQP

# Si RabbitMQ no tiene TLS configurado en el puerto de gestion, el
# TriggerAuthentication debe apuntar a http://...:15672, no https://...:15671
stringData:
  host: "amqp://keda_lector:[email protected]:5672/"

spec:
  # Durante la temporada alta, no escalamos a cero. El fallback funciona
  # de forma fiable y el arranque en frio no penaliza en el peor momento.
  minReplicaCount: 2
  idleReplicaCount: 1     # Fuera de actividad, 1 replica encendida
  fallback:
    failureThreshold: 3
    replicas: 8

# 1. LA MAS IMPORTANTE: KEDA en modo fallback.
#    Si esto se dispara, el escalado NO esta funcionando aunque todo parezca normal.
keda_scaled_object_errors_total > 0

# 2. Errores del escalador: KEDA no puede consultar la fuente.
sum(rate(keda_scaler_errors_total[5m])) by (scaledObject, scaler) > 0

# 3. Alerta de negocio: la cola crece sin que crezcan los workers.
#    Esta es la que habria detectado el problema en 2 minutos.
(
  rabbitmq_queue_messages{queue="notificaciones-confirmacion"} > 5000
)
and
(
  kube_deployment_status_replicas{deployment="worker-notificaciones"} < 5
)

# 4. Antiguedad del mensaje mas viejo en la cola: el indicador de negocio real.
rabbitmq_queue_head_message_timestamp_seconds > 600

motor-precios          -> Deployment + ScaledObject (API HTTP)
recalculo-precios      -> CronJob (proceso nocturno)

# k8s/entornos/pro/scaledobject-motor-precios.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: motor-precios
  namespace: rutas-norte-pro
  labels:
    app: motor-precios
    app.kubernetes.io/part-of: rutas-norte
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: motor-precios

  pollingInterval: 15
  cooldownPeriod: 300

  # NO escalamos a cero. Esta en el camino critico de cada busqueda de rutas:
  # su latencia entra directamente en la de api-reservas. Un arranque en frio
  # de 35 s con usuarios esperando es inaceptable, y ademas agotaria el pool
  # de conexiones salientes de api-reservas: degradacion en cascada.
  #
  # 3 replicas de suelo: 3 x 180 = 540 rps, muy por encima del minimo de 50.
  # El suelo lo marca la DISPONIBILIDAD (09-05), no la capacidad.
  minReplicaCount: 3

  # Techo: 2.500 rps / 180 rps por replica = 13,9 -> 14.
  # Con margen del 40 %: 20 replicas.
  maxReplicaCount: 20

  fallback:
    failureThreshold: 3
    # Si Prometheus cae, 8 replicas = 1.440 rps de capacidad. Cubre el
    # trafico habitual con holgura mientras se arregla.
    replicas: 8

  advanced:
    restoreToOriginalReplicaCount: true
    horizontalPodAutoscalerConfig:
      name: hpa-motor-precios
      behavior:
        scaleUp:
          # Sin espera. Es un servicio interno con latencia critica: cualquier
          # retraso se propaga a la busqueda de rutas del usuario final.
          stabilizationWindowSeconds: 0
          selectPolicy: Max
          policies:
            - type: Percent
              value: 100
              periodSeconds: 30
            - type: Pods
              value: 5
              periodSeconds: 30
        scaleDown:
          # 10 minutos. El trafico de busquedas es muy irregular (rafagas de
          # usuarios comparando rutas) y no queremos destruir capacidad entre
          # rafaga y rafaga.
          stabilizationWindowSeconds: 600
          selectPolicy: Min
          policies:
            - type: Percent
              value: 20
              periodSeconds: 120

  triggers:
    # DISPARADOR PRINCIPAL: peticiones por segundo.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitorizacion.svc.cluster.local:9090
        metricName: motor_precios_peticiones_por_segundo
        query: |
          sum(
            rate(
              motor_precios_peticiones_total{
                namespace="rutas-norte-pro",
                app="motor-precios"
              }[2m]
            )
          )
        # 125 rps por replica.
        #
        # Calculo: una replica sostiene 180 rps antes de que la latencia p95
        # supere los 80 ms. Aplicamos un margen del 30 % para cubrir el tiempo
        # de arranque de las replicas nuevas: 180 x 0,7 = 126 -> 125.
        #
        # Con 2.500 rps: techo(2500/125) = 20 replicas. Justo el maxReplicaCount.
        threshold: "125"
        activationThreshold: "10"
        ignoreNullValues: "true"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # DISPARADOR SECUNDARIO: la LATENCIA, que es lo que importa al negocio.
    #
    # Si el p95 supera los 60 ms (75 % del objetivo de 80 ms), escalamos
    # aunque las peticiones por segundo esten dentro de lo normal. Esto cubre
    # el caso de peticiones anormalmente CARAS: rutas con muchas combinaciones,
    # o una degradacion de una dependencia.
    #
    # NOTA IMPORTANTE: escalar por latencia es un arma de doble filo. Si la
    # latencia sube por una causa que NO se resuelve con mas replicas (por
    # ejemplo, PostgreSQL saturado), escalar empeora las cosas (09-01, el
    # cuello de botella real). Por eso el umbral es conservador y el
    # maxReplicaCount esta acotado.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitorizacion.svc.cluster.local:9090
        metricName: motor_precios_latencia_p95
        query: |
          histogram_quantile(0.95,
            sum(rate(motor_precios_duracion_segundos_bucket{
              namespace="rutas-norte-pro"
            }[2m])) by (le)
          ) * 1000
        threshold: "60"
        activationThreshold: "1"
        ignoreNullValues: "true"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # RED DE SEGURIDAD: CPU.
    - type: cpu
      metricType: Utilization
      metadata:
        value: "70"

# k8s/entornos/pro/cronjob-recalculo-precios.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: recalculo-precios
  namespace: rutas-norte-pro
  labels:
    app: recalculo-precios
    app.kubernetes.io/part-of: rutas-norte
spec:
  schedule: "0 3 * * *"
  timeZone: "Europe/Madrid"      # CronJob soporta timeZone desde 1.27
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 2
      # Si a las 2 horas no ha terminado, cortar. Evita que un proceso colgado
      # ancle un nodo (09-03) y se solape con el trafico de la manana.
      activeDeadlineSeconds: 7200
      ttlSecondsAfterFinished: 86400
      template:
        metadata:
          labels:
            app: recalculo-precios
          annotations:
            # NO desalojar durante la ejecucion: perderiamos 45 minutos de
            # trabajo. El Cluster Autoscaler respetara esta anotacion (09-03).
            cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
        spec:
          restartPolicy: OnFailure
          containers:
            - name: recalculo
              image: registry.rutasnorte.example/motor-precios:4.2.0
              command: ["node", "recalcular-matriz.js"]
              resources:
                requests:
                  cpu: "4"
                  memory: 4Gi
                limits:
                  cpu: "4"
                  memory: 4Gi
                  # requests == limits -> QoS Guaranteed. Se ejecuta a las 3:00
                  # con el cluster vacio: no le quitamos capacidad a nadie y
                  # garantizamos que no lo desalojen por presion de memoria.

# k8s/entornos/pro/vpa-recalculo-precios.yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: recalculo-precios
  namespace: rutas-norte-pro
spec:
  targetRef:
    apiVersion: batch/v1
    kind: CronJob
    name: recalculo-precios
  updatePolicy:
    # Initial: cada ejecucion nueva nace con los recursos aprendidos. Nunca
    # desalojamos un Job a mitad de camino.
    updateMode: "Initial"
  resourcePolicy:
    containerPolicies:
      - containerName: recalculo
        minAllowed:
          cpu: "2"
          memory: 2Gi
        maxAllowed:
          cpu: "8"
          memory: 8Gi
        controlledValues: RequestsAndLimits

# Latencia alta CON las replicas al maximo: el problema NO se resuelve escalando
(
  histogram_quantile(0.95, sum(rate(motor_precios_duracion_segundos_bucket[5m])) by (le)) * 1000 > 80
)
and
(
  kube_deployment_status_replicas{deployment="motor-precios"} >= 20
)