Todos los productos
Search
Centro de documentos

Container Service for Kubernetes:Habilitar el escalado automático para soportar fluctuaciones de tráfico

Última actualización: Sep 04, 2026

Configure Knative Pod Autoscaler (KPA) para escalar los pods de Knative Serving por concurrencia o RPS en ACK.

Requisitos previos

Antes de empezar, asegúrese de que:

Funcionamiento

Knative Serving inyecta un contenedor sidecar queue-proxy en cada pod. Este sidecar reporta métricas de concurrencia a KPA, que ajusta la cantidad de pods según dichas métricas y el algoritmo configurado.

image

Algoritmo de escalado

KPA calcula la cantidad objetivo de pods con esta fórmula:

Number of pods = Number of concurrent requests / (Pod maximum concurrency × Target utilization)

Ejemplo: Con containerConcurrency establecido en 10 y una utilización objetivo del 70 %, 100 solicitudes concurrentes producen: 100 / (10 × 0.7) = 15 pods (redondeado hacia arriba).

Modos estable y de pánico

KPA utiliza dos modos para responder a los patrones de tráfico:

Modo estable: es el modo predeterminado. KPA promedia la concurrencia entre los pods durante la ventana estable (predeterminado: 60 s) y ajusta la cantidad de pods para coincidir con dicho promedio.

Modo de pánico: se activa durante picos de tráfico. KPA usa una ventana de pánico más corta (predeterminado: 6 s; stable window × panic-window-percentage) para detectar aumentos repentinos. Cuando la cantidad de pods en modo de pánico ≥ panic-threshold-percentage / 100 × pods listos (predeterminado: 2×), KPA utiliza la cuenta de pánico en lugar de la cuenta estable.

Configurar el ConfigMap config-autoscaler

Los valores globales predeterminados de KPA se encuentran en el ConfigMap config-autoscaler dentro del namespace knative-serving. Las anotaciones por revisión anulan estos valores predeterminados.

Inspeccione la configuración actual:

kubectl -n knative-serving describe cm config-autoscaler

La siguiente tabla enumera los parámetros clave. Todos los valores son los predeterminados.

Parámetro

Valor predeterminado

Descripción

container-concurrency-target-default

100

Máximo de solicitudes concurrentes por pod (límite flexible, global)

container-concurrency-target-percentage

70

Porcentaje de utilización objetivo para el escalado basado en concurrencia

requests-per-second-target-default

200

RPS objetivo por pod

target-burst-capacity

211

Capacidad de ráfaga antes de que Activator almacene las solicitudes en búfer. 0: Activator solo al escalar a cero. Mayor que 0 con container-concurrency-target-percentage en 100: siempre usar Activator. -1: ilimitado.

stable-window

60s

Ventana de tiempo para el promedio en modo estable

panic-window-percentage

10.0

Ventana de pánico como porcentaje de la ventana estable (predeterminado: 6 s)

panic-threshold-percentage

200.0

El modo de pánico se activa cuando los pods deseados ≥ panic-threshold-percentage / 100 × pods listos

max-scale-up-rate

1000.0

Proporción máxima de pods deseados por evento de escalado horizontal: ceil(max-scale-up-rate × readyPodsCount)

max-scale-down-rate

2.0

Los pods se reducen como máximo a la mitad de la cantidad actual por actividad

enable-scale-to-zero

true

Indica si se deben escalar a cero los servicios inactivos

scale-to-zero-grace-period

30s

Tiempo máximo para la reconfiguración de red durante el escalado a cero

scale-to-zero-pod-retention-period

0s

Tiempo mínimo que se mantiene el último pod después de que cesa el tráfico

pod-autoscaler-class

kpa.autoscaling.knative.dev

Tipo de autoescalador. Valores compatibles: kpa.autoscaling.knative.dev, hpa.autoscaling.knative.dev, aha.autoscaling.knative.dev. Use mpa con MSE en clústeres ACK Serverless para escalar a cero.

activator-capacity

100.0

Capacidad de solicitudes del servicio Activator

initial-scale

1

Cantidad inicial de pods por revisión

allow-zero-initial-scale

false

Indica si una revisión puede iniciar con cero pods

min-scale

0

Mínimo de pods por revisión (0 = sin límite inferior)

max-scale

0

Máximo de pods por revisión (0 = ilimitado)

scale-down-delay

0s

Tiempo con concurrencia reducida antes de reducir la escala. A diferencia de min-scale, los pods eventualmente se reducen tras el retraso. Evita inicios en frío durante pausas breves de tráfico.

Importante

scale-to-zero-grace-period limita cuánto tiempo puede tardar la programación de red durante el escalado a cero. Ajústelo solo si observa solicitudes descartadas durante este proceso; este parámetro no controla cuánto tiempo permanece activo el último pod. Para mantener el último pod después de que finalice el tráfico, utilice scale-to-zero-pod-retention-period en su lugar.

Configurar métricas de escalado

Establezca la métrica de escalado por revisión mediante la anotación autoscaling.knative.dev/metric. Valor predeterminado: concurrency.

Métrica

Clase de autoescalador obligatoria

Descripción

concurrency

kpa.autoscaling.knative.dev (predeterminado)

Solicitudes simultáneas en curso por pod

rps

kpa.autoscaling.knative.dev (predeterminado)

Solicitudes por segundo por pod

cpu

hpa.autoscaling.knative.dev

Utilización de CPU

memory

hpa.autoscaling.knative.dev

Utilización de memoria

Métricas personalizadas

Variable

Métricas personalizadas según los requisitos de la aplicación

Métrica de concurrencia (predeterminada)

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "concurrency"

Métrica de RPS

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "rps"

Métrica de CPU

El escalado basado en CPU requiere la clase de autoescalador HPA.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "cpu"

Métrica de memoria

El escalado basado en memoria también requiere la clase de autoescalador HPA.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "memory"

Configurar objetivos de escalado

Los objetivos de escalado definen el valor de la métrica que KPA mantiene por pod. Puede configurarlos por revisión o de forma global.

Objetivo de concurrencia

Por revisión: use autoscaling.knative.dev/target:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "50"

Global: actualice el ConfigMap config-autoscaler:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  container-concurrency-target-default: "200"

Objetivo de RPS

Por revisión:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "150"
        autoscaling.knative.dev/metric: "rps"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Global:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  requests-per-second-target-default: "150"

Configurar límites de concurrencia

Los límites de concurrencia restringen las solicitudes simultáneas por pod. KPA admite dos tipos.

Límite de concurrencia flexible

Un límite flexible es el objetivo hacia el cual escala KPA. No se aplica de forma estricta; las ráfagas pueden superarlo momentáneamente.

Por revisión:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "200"

Global:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  container-concurrency-target-default: "200"

Límite de concurrencia estricto

Un límite estricto se aplica rigurosamente; las solicitudes excedentes se almacenan en búfer. Establezca un límite estricto solo cuando su aplicación tenga un límite superior firme de concurrencia; valores bajos reducen el throughput y aumentan la latencia.

Por revisión: use el campo de especificación containerConcurrency (no una anotación):

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 50

Utilización objetivo

La utilización objetivo controla qué tan ocupados operan los pods antes de que KPA escale horizontalmente. Con una utilización del 70 % y containerConcurrency: 10, KPA crea un nuevo pod cuando la concurrencia promedio entre los pods existentes alcanza 7. Valores más bajos hacen que KPA escale antes, lo que reduce la latencia de inicio en frío.

Por revisión:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Global:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  container-concurrency-target-percentage: "70"

Configurar el escalado a cero

Habilitar o deshabilitar el escalado a cero globalmente

Establezca enable-scale-to-zero en "false" para mantener al menos un pod en ejecución cuando un servicio esté inactivo:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  enable-scale-to-zero: "false"

Configurar el periodo de gracia de escalado a cero

scale-to-zero-grace-period limita cuánto tiempo puede tardar la programación de red durante el escalado a cero.

Aviso

Auméntelo solo si observa solicitudes descartadas durante el escalado a cero. Este parámetro no controla cuánto tiempo permanece activo el último pod. Para mantener el último pod, utilice scale-to-zero-pod-retention-period en su lugar.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  scale-to-zero-grace-period: "40s"

Configurar el periodo de retención de pods

scale-to-zero-pod-retention-period mantiene el último pod durante una duración mínima después de que cesa el tráfico, lo que evita inicios en frío en servicios con tráfico intermitente.

Por revisión:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Global:

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  scale-to-zero-pod-retention-period: "42s"

Configurar límites de escalado

Los límites de escalado establecen las cantidades mínima y máxima de réplicas para una revisión.

Anotación

Parámetro (global)

Propósito

autoscaling.knative.dev/min-scale

min-scale

Límite inferior: KPA nunca escala por debajo de esta cantidad

autoscaling.knative.dev/max-scale

max-scale

Límite superior: KPA nunca escala por encima de esta cantidad (0 = ilimitado)

min-scale mantiene un mínimo permanente de pods. Para retrasar la reducción de escala sin un mínimo permanente, utilice scale-down-delay en config-autoscaler en su lugar; los pods se reducirán igualmente después del retraso.

Ejemplos

Ejemplo 1: Escalar por objetivo de concurrencia

Despliegue una aplicación con escalado automático y un objetivo de concurrencia de 10, y pruébela con 50 solicitudes concurrentes.

  1. Deploy Knative in an ACK cluster o an ACK Serverless cluster.

  2. Cree el archivo autoscale-go.yaml con el siguiente contenido:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: autoscale-go
      namespace: default
    spec:
      template:
        metadata:
          labels:
            app: autoscale-go
          annotations:
            autoscaling.knative.dev/target: "10"  # Concurrency target: 10 requests per pod
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
  3. Aplique el manifiesto:

    kubectl apply -f autoscale-go.yaml
  4. Obtenga la dirección de la puerta de enlace Ingress. ALB:

    kubectl get albconfig knative-internet

    Salida esperada:

    NAME               ALBID                    DNSNAME                                              PORT&PROTOCOL   CERTID   AGE
    knative-internet   alb-hvd8nngl0lsdra15g0   alb-hvd8nng******.cn-beijing.alb.aliyuncs.com                            2

    MSE:

    kubectl -n knative-serving get ing stats-ingress

    Salida esperada:

    NAME            CLASS                  HOSTS   ADDRESS                         PORTS   AGE
    stats-ingress   knative-ingressclass   *       101.201.XX.XX,192.168.XX.XX   80      15d

    ASM:

    kubectl get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"

    Salida esperada:

    121.XX.XX.XX

    Kourier:

    kubectl -n knative-serving get svc kourier

    Salida esperada:

    NAME      TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)                      AGE
    kourier   LoadBalancer   10.0.XX.XX    39.104.XX.XX     80:31133/TCP,443:32515/TCP   49m
  5. Envíe 50 solicitudes concurrentes durante 30 segundos con hey:

    hey -z 30s -c 50 \
      -host "autoscale-go.default.example.com" \
      "http://121.199.XXX.XXX"  # Replace with your Ingress gateway address

    Salida esperada: KPA agrega 5 pods: 50 solicitudes concurrentes ÷ objetivo de 10 = 5 pods.

    hey

Ejemplo 2: Escalar con límites

Agregue min-scale: 1 y max-scale: 3 para mantener un pod en ejecución y limitar el despliegue a tres pods.

  1. Deploy Knative in an ACK cluster o an ACK Serverless cluster.

  2. Cree el archivo autoscale-go.yaml con el siguiente contenido:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: autoscale-go
      namespace: default
    spec:
      template:
        metadata:
          labels:
            app: autoscale-go
          annotations:
            autoscaling.knative.dev/target: "10"
            autoscaling.knative.dev/min-scale: "1"  # Keep at least 1 pod running
            autoscaling.knative.dev/max-scale: "3"  # Cap at 3 pods
        spec:
          containers:
            - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1
  3. Aplique el manifiesto:

    kubectl apply -f autoscale-go.yaml
  4. Obtenga la dirección de la puerta de enlace Ingress (Ejemplo 1, paso 4).

  5. Envíe 50 solicitudes concurrentes durante 30 segundos:

    hey -z 30s -c 50 \
      -host "autoscale-go.default.example.com" \
      "http://121.199.XXX.XXX"  # Replace with your Ingress gateway address

    Salida esperada: KPA escala a 3 pods (máximo) durante la carga y luego vuelve a 1 pod (mínimo), sin inicios en frío en la siguiente solicitud.

    scale bounds

Siguientes pasos