Establecimiento de reglas de escalado en Azure Container Apps

Azure Container Apps administra el escalado horizontal automático mediante un conjunto de reglas de escalado declarativo. A medida que una revisión de la aplicación en contenedor escala horizontalmente, la plataforma crea nuevas instancias de la revisión según demanda. Estas instancias se conocen como réplicas.

Para admitir este comportamiento de escalado, Azure Container Apps usa KEDA (escalado automático controlado por eventos de Kubernetes). KEDA admite el escalado en una variedad de métricas, como solicitudes HTTP, mensajes de cola, carga de CPU y memoria, y orígenes de eventos como Azure Service Bus, Azure Event Hubs, Apache Kafka y Redis. Para obtener más información, consulte Scalers en la documentación de KEDA.

Al agregar o editar reglas de escalado, se crea una nueva revisión de la aplicación contenedora. Una revisión es una instantánea inmutable de la aplicación contenedora. Para obtener información sobre qué tipos de cambios desencadenan una nueva revisión, consulte revisión tipos de cambio.

Los trabajos de Container Apps controlados por eventos usan reglas de escalado para desencadenar ejecuciones basadas en eventos.

Definición de escala

El escalado es la combinación de límites, reglas y comportamiento.

  • Los límites definen el número mínimo y máximo posible de réplicas por revisión a medida que escala su aplicación contenedora.

    Límite de escala Valor predeterminado Valor mínimo Valor máximo
    Número mínimo de réplicas por revisión 0 0 El número máximo de réplicas configurables es de 1000.
    Número máximo de réplicas por revisión 10 1 El número máximo de réplicas configurables es de 1000.
  • Las reglas son los criterios utilizados por Container Apps para decidir cuándo agregar o quitar réplicas.

    Las reglas de escalado se implementan como HTTP, TCP (protocolo de control de transmisión) o personalizadas.

  • El comportamiento es la combinación de reglas y límites para determinar las decisiones de escala a lo largo del tiempo.

    Comportamiento de escalado explica cómo se toman decisiones de escala.

A medida que defina las reglas de escalado, tenga en cuenta los siguientes elementos:

  • No se le facturan cargos de uso si la aplicación contenedora se escala a cero.
  • Las réplicas que no se procesan, pero que permanecen en memoria se pueden facturar con una tasa de "inactividad" inferior. Para obtener más información, vea Facturación.
  • Si desea asegurarse de que siempre se está ejecutando una instancia de su revisión, establezca el número mínimo de réplicas en 1 o superior.
  • Durante las actualizaciones o el mantenimiento de la plataforma, podría ver temporalmente más réplicas de las esperadas. Container Apps garantiza que la carga de producción no se vea afectada por el calentamiento previo de las nuevas réplicas antes de redirigir el tráfico, tal como ocurre con el comportamiento predeterminado de Kubernetes. Las réplicas adicionales se quitan automáticamente una vez completada la operación.

Normas de escala

Tres categorías de desencadenadores determinan cómo se produce el escalado:

  • HTTP: se basa en el número de solicitudes HTTP simultáneas a la revisión.
  • TCP: se basa en el número de conexiones TCP simultáneas a la revisión.
  • Personalizado: basado en métricas personalizadas como:
    • Unidad Central de Procesamiento (CPU)
    • Memoria
    • Orígenes de datos controlados por eventos admitidos:
      • Azure Service Bus
      • Azure Event Hubs
      • Apache Kafka
      • Redis

Si define más de una regla de escalado, la aplicación contenedora comienza a escalar una vez que se cumple la primera condición de cualquier regla.

Nota:

Si usa Functions en Container Apps, la experiencia predeterminada configura automáticamente reglas de escalado basadas en desencadenadores y enlaces de función. El portal de Azure deshabilita el botón Agregar reglas de escalado para estas aplicaciones. Si necesita reglas definidas por el usuario, use allowScalingRuleOverride como se describe en Invalidar las reglas de escalado de KEDA generadas automáticamente para Azure Functions en Container Apps.

HTTP

Cuando se usa una regla de escalado HTTP, se controla el umbral de solicitudes HTTP simultáneas que determina cómo se escala la revisión de la aplicación contenedora. Cada 15 segundos, el número de solicitudes simultáneas se calcula como el número de solicitudes de los últimos 15 segundos dividido por 15. Los trabajos de Container Apps no admiten reglas de escalado HTTP.

En el ejemplo siguiente, la revisión escala verticalmente hasta cinco réplicas y puede escalar horizontalmente a cero. La propiedad de escalado se establece en 100 solicitudes simultáneas por segundo.

Ejemplo

La sección http define una regla de escalado HTTP.

Propiedad de escala Descripción Valor predeterminado Valor mínimo Valor máximo
concurrentRequests Cuando el número de solicitudes HTTP supera este valor, la aplicación agrega otra réplica. La aplicación sigue agregando réplicas hasta la cantidad maxReplicas. 10 1 N/D
resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'http-rule'
            http: {
              metadata: {
                concurrentRequests: '100'
              }
            }
          }
        ]
      }
    }
  }
}

Nota:

Establezca la properties.configuration.activeRevisionsMode propiedad de la aplicación contenedora en single al usar reglas de escalado de eventos que no son HTTP.

La sección http define una regla de escalado HTTP.

Propiedad de escala Descripción Valor predeterminado Valor mínimo Valor máximo
concurrentRequests Cuando el número de solicitudes HTTP supera este valor, la aplicación agrega otra réplica. La aplicación sigue agregando réplicas hasta la cantidad maxReplicas. 10 1 N/D
{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Nota:

Establezca la properties.configuration.activeRevisionsMode propiedad de la aplicación contenedora en single al usar reglas de escalado de eventos que no son HTTP.

Defina una regla de escalado HTTP mediante el parámetro --scale-rule-http-concurrency en los comandos create o update.

Parámetro de la CLI Descripción Valor predeterminado Valor mínimo Valor máximo
--scale-rule-http-concurrency Cuando el número de solicitudes HTTP simultáneas supera este valor, la aplicación agrega otra réplica. La aplicación sigue añadiendo réplicas hasta alcanzar la cantidad max-replicas. 10 1 N/D
az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --scale-rule-name azure-http-rule \
  --scale-rule-type http \
  --scale-rule-http-concurrency 100
  1. Vaya a su aplicación de contenedores en el portal de Azure.

  2. Selecciona escala.

  3. Seleccione Editar e implementar.

  4. Seleccione la pestaña Escala.

  5. Seleccione el intervalo de réplica mínimo y máximo.

    Captura de pantalla del control deslizante de rango de escala de Azure Container Apps.

  6. Seleccione Agregar.

  7. En el cuadro Nombre de regla, escriba un nombre para la regla.

  8. En la lista desplegable Tipo, seleccione Escalado HTTP.

  9. En el cuadro Solicitudes simultáneas , escriba el número de solicitudes simultáneas que desee para la aplicación contenedora.

TCP

Cuando se usa una regla de escalado TCP, se controla el umbral de conexiones TCP simultáneas que determina cómo se escala la aplicación. Cada 15 segundos, el sistema calcula el número de conexiones simultáneas como el número de conexiones en los últimos 15 segundos divididos por 15. Los trabajos de Container Apps no admiten reglas de escalado TCP.

En el ejemplo siguiente, la revisión de la aplicación de contenedor se escala horizontalmente hasta cinco réplicas y puede reducirse a cero. El umbral de escalado se establece en 100 conexiones simultáneas por segundo.

Ejemplo

La sección tcp define una regla de escalado TCP.

Propiedad de escala Descripción Valor predeterminado Valor mínimo Valor máximo
concurrentConnections Cuando el número de conexiones TCP simultáneas supera este valor, el sistema agrega otra réplica. El sistema sigue agregando réplicas hasta la maxReplicas cantidad a medida que aumenta el número de conexiones simultáneas. 10 1 N/D
resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'tcp-rule'
            http: {
              metadata: {
                concurrentConnections: '100'
              }
            }
          }
        ]
      }
    }
  }
}

La sección tcp define una regla de escalado TCP.

Propiedad de escala Descripción Valor predeterminado Valor mínimo Valor máximo
concurrentConnections Cuando el número de conexiones TCP simultáneas supera este valor, el sistema agrega otra réplica. El sistema sigue agregando réplicas hasta la maxReplicas cantidad a medida que aumenta el número de conexiones simultáneas. 10 1 N/D
{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "tcp-rule",
            "tcp": {
              "metadata": {
                "concurrentConnections": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Defina una regla de escalado TCP mediante el parámetro --scale-rule-tcp-concurrency en los comandos create o update.

Parámetro de la CLI Descripción Valor predeterminado Valor mínimo Valor máximo
--scale-rule-tcp-concurrency Cuando el número de conexiones TCP simultáneas supera este valor, el sistema agrega otra réplica. El sistema sigue agregando réplicas hasta la max-replicas cantidad a medida que aumenta el número de conexiones simultáneas. 10 1 N/D
az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --transport tcp \
  --ingress <external/internal> \
  --target-port <CONTAINER_TARGET_PORT> \
  --scale-rule-name azure-tcp-rule \
  --scale-rule-type tcp \
  --scale-rule-tcp-concurrency 100

El portal de Azure no admite esta característica. Use el CLI de Azure, Azure Resource Manager o Bicep para configurar una regla de escalado TCP.

Personalizado

Cree una regla de escalado de Container Apps personalizada basada en cualquier escalador KEDA basado en ScaledObject mediante estos valores predeterminados:

Valor predeterminado Segundos
Intervalo de sondeo 30
Período de enfriamiento 300

Nota:

El período de enfriamiento solo surte efecto al escalar de la réplica final a 0. El período de enfriamiento no afecta al escalado, ya que se quitan otras réplicas.

En el caso de los trabajos de Container Apps controlados por eventos, cree una regla de escalado personalizada basada en cualquier escalador KEDA basado en ScaledJob.

En el siguiente ejemplo se muestra cómo crear una regla de escalado personalizada.

Ejemplo

En este ejemplo se muestra cómo convertir una Azure Service Bus scaler en una regla de escalado de Container Apps, pero se usa el mismo proceso para cualquier otra especificación ScaledObject basada en KEDA.

Para la autenticación, los parámetros de autenticación del escalador KEDA toman secretos de Container Apps o identidad administrada.

En el procedimiento siguiente se muestra cómo convertir un escalador KEDA en una regla de escalado de aplicaciones de Container. Este fragmento de código es un extracto de una plantilla de Bicep para mostrar dónde encaja cada sección en el contexto de la plantilla general.

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    configuration: {
      ...
      secrets: [
        {
          name: '<NAME>'
          value: '<VALUE>'
        }
      ]
    }
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: '<RULE_NAME>'
            custom: {
              metadata: {
                ...
              }
              auth: [
                {
                  secretRef: '<NAME>'
                  triggerParameter: '<PARAMETER>'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Consulte este extracto para obtener contexto sobre cómo encajan los ejemplos siguientes en la plantilla de Bicep.

En primer lugar, defina el tipo y los metadatos de la regla de escalado.

  1. En la especificación del escalador KEDA, busque el valor type.

    triggers:
     - type: azure-servicebus ⬅️
      metadata:
        queueName: my-queue
        namespace: service-bus-namespace
        messageCount: "5"
    
  2. En la plantilla de Bicep, escriba el valor type del escalador en la propiedad custom.type de la regla de escalado.

    ...
    rules: [
      {
        name: 'azure-servicebus-queue-rule'
        custom: {
          type: 'azure-servicebus' ⬅️
          metadata: {
            queueName: 'my-queue'
            namespace: 'service-bus-namespace'
            messageCount: '5'
          }
        }
      }
    ]
    ...
    
  3. En la especificación del escalador KEDA, busque los valores metadata.

    triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue              ⬅️
        namespace: service-bus-namespace ⬅️
        messageCount: "5"                ⬅️
    
  4. En la plantilla de Bicep, agregue todos los valores de metadatos a la sección custom.metadata de la regla de escalado.

    ...
    rules: [
      {
        name: 'azure-servicebus-queue-rule'
        custom: {
          type: 'azure-servicebus'
          metadata: {
            queueName: 'my-queue'              ⬅️
            namespace: 'service-bus-namespace' ⬅️
            messageCount: '5'                  ⬅️
          }
        }
      }
    ]
    ...
    

Autenticación

Las reglas de escalado de Container Apps admiten la autenticación basada en secretos. Las reglas de escalado de los recursos de Azure, incluidos Azure Queue Storage, Azure Service Bus y Azure Event Hubs, también admiten la identidad administrada. Siempre que sea posible, use la autenticación de identidad administrada para evitar almacenar secretos dentro de la aplicación.

Uso de secretos

Para usar secretos para la autenticación, cree un secreto en la matriz de la aplicación contenedora secrets . Use el valor secreto en la auth matriz de la regla de escalado.

Los scalers de KEDA pueden usar secretos definidos en un TriggerAuthentication al que hace referencia la propiedad authenticationRef. Puede asignar el objeto TriggerAuthentication a la regla de escalado de Container Apps.

  1. Busque el objeto TriggerAuthentication al que hace referencia la especificación ScaledObject de KEDA.

  2. En el objeto TriggerAuthentication, busque cada secretTargetRef y su secreto asociado.

    apiVersion: v1
    kind: Secret
    metadata:
      name: my-secrets
      namespace: my-project
    type: Opaque
    data:
      connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> ⬅️
    ---
    apiVersion: keda.sh/v1alpha1
    kind: TriggerAuthentication
    metadata:
      name: azure-servicebus-auth
    spec:
      secretTargetRef:
      - parameter: connection         ⬅️
        name: my-secrets              ⬅️
        key: connection-string-secret ⬅️
    ---
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: azure-servicebus-queue-rule
      namespace: default
    spec:
      scaleTargetRef:
        name: my-scale-target
      triggers:
      - type: azure-servicebus
        metadata:
          queueName: my-queue
          namespace: service-bus-namespace
          messageCount: "5"
        authenticationRef:
            name: azure-servicebus-auth
    
  3. En la plantilla de Bicep, para cada secreto:

    1. Agregue un secreto a la matriz secrets de la aplicación contenedora que contiene el nombre y el valor del secreto.

    2. Agregue una entrada a la matriz auth de la regla de escalado.

      1. Establezca el valor de la propiedad triggerParameter en el valor de la propiedad secretTargetRef de parameter.

      2. Establezca el valor de la propiedad secretRef en el nombre de la propiedad secretTargetRef de key.

        resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
          ...
          properties: {
            ...
            configuration: {
              ...
              secrets: [
                {                                          ⬅️
                  name: 'connection-string-secret'         ⬅️
                  value: '<SERVICE_BUS_CONNECTION_STRING>' ⬅️
                }                                          ⬅️
              ]
            }
            template: {
              ...
              scale: {
                maxReplicas: 0
                minReplicas: 5
                rules: [
                  {
                    name: 'azure-servicebus-queue-rule'
                    custom: {
                      type: 'azure-servicebus'
                      metadata: {
                        queueName: 'my-queue'
                        namespace: 'service-bus-namespace'
                        messageCount: '5'
                      }
                      auth: [
                        {
                          secretRef: 'connection-string-secret'
                          triggerParameter: 'connection'
                        }
                      ]
                    }
                  }
                ]
              }
            }
          }
        }
        

    Algunos escaladores admiten metadatos con el sufijo FromEnv para hacer referencia a un valor de una variable de entorno. Container Apps examina el primer contenedor que se muestra en la plantilla de ARM de la variable de entorno.

    Consulte la sección consideraciones para obtener más información relacionada con la seguridad.

Uso de una identidad administrada

Las reglas de escalado de Container Apps pueden usar la identidad administrada para autenticarse con servicios de Azure. La siguiente plantilla de formato Bicep transfiere una identidad administrada por el sistema para autenticar un componente de escalado de la cola de Azure.

Antes de usar el código siguiente, reemplace los marcadores de posición rodeados por <> con sus valores.

scale: {
  minReplicas: 0
  maxReplicas: 4
  rules: [
    {
      name: 'azure-queue'
      custom: {
        type: 'azure-queue'
        metadata: {
          accountName: '<ACCOUNT_NAME>'
          queueName: '<QUEUE_NAME>'
          queueLength: '1'
        },
        identity: 'system'
      }
    }
  ]
}

Para más información sobre el uso de identidad administrada con reglas de escalado, consulte Identidad administrada.

En el procedimiento siguiente se muestra cómo convertir un escalador KEDA en una regla de escalado de aplicaciones de Container. Este fragmento de código es un extracto de una plantilla de ARM para mostrar dónde encaja cada sección en el contexto de la plantilla general.

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "configuration": {
        ...
        "secrets": [
          {
            "name": "<NAME>",
            "value": "<VALUE>"
          }
        ]
      },
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [
            {
              "name": "<RULE_NAME>",
              "custom": {
                "metadata": {
                  ...
                },
                "auth": [
                  {
                    "secretRef": "<NAME>",
                    "triggerParameter": "<PARAMETER>"
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
}

Consulte este extracto para obtener contexto sobre cómo encajan los ejemplos siguientes en la plantilla de ARM.

En primer lugar, defina el tipo y los metadatos de la regla de escalado.

  1. En la especificación del escalador KEDA, busque el valor type.

    triggers:
    - type: azure-servicebus ⬅️
      metadata:
        queueName: my-queue
        namespace: service-bus-namespace
        messageCount: "5"
    
  2. En la plantilla de ARM, escriba el valor type del escalador en la propiedad custom.type de la regla de escalado.

    ...
    "rules": [
      {
        "name": "azure-servicebus-queue-rule",
        "custom": {
          "type": "azure-servicebus",  ⬅️
          "metadata": {
            "queueName": "my-queue",
            "namespace": "service-bus-namespace",
            "messageCount": "5"
          }
        }
      }
    ]
    ...
    
  3. En la especificación del escalador KEDA, busque los valores metadata.

    triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue              ⬅️
        namespace: service-bus-namespace ⬅️
        messageCount: "5"                ⬅️
    
  4. En la plantilla de ARM, agregue todos los valores de metadatos a la sección custom.metadata de la regla de escalado.

    ...
    "rules": [
      {
        "name": "azure-servicebus-queue-rule",
        "custom": {
          "type": "azure-servicebus",
          "metadata": {
            "queueName": "my-queue",              ⬅️
            "namespace": "service-bus-namespace", ⬅️
            "messageCount": "5"                   ⬅️
          }
        }
      }
    ]
    ...
    

Autenticación

Las reglas de escalado de Container Apps admiten la autenticación basada en secretos. Las reglas de escalado de los recursos de Azure, incluidos Azure Queue Storage, Azure Service Bus y Azure Event Hubs, también admiten la identidad administrada. Siempre que sea posible, use la autenticación de identidad administrada para evitar almacenar secretos dentro de la aplicación.

Uso de secretos

Para usar secretos para la autenticación, cree un secreto en la matriz de la aplicación contenedora secrets . Use el valor secreto en la auth matriz de la regla de escalado.

Los escaladores de KEDA pueden usar secretos en un TriggerAuthentication al que hace referencia la propiedad authenticationRef. Puede asignar el objeto TriggerAuthentication a la regla de escalado de Container Apps.

  1. Busque el objeto TriggerAuthentication al que hace referencia la especificación ScaledObject de KEDA.

  2. En el objeto TriggerAuthentication, busque cada secretTargetRef y su secreto asociado.

    apiVersion: v1
    kind: Secret
    metadata:
      name: my-secrets
      namespace: my-project
    type: Opaque
    data:
      connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> ⬅️
    ---
    apiVersion: keda.sh/v1alpha1
    kind: TriggerAuthentication
    metadata:
      name: azure-servicebus-auth
    spec:
      secretTargetRef:
      - parameter: connection         ⬅️
        name: my-secrets              ⬅️
        key: connection-string-secret ⬅️
    ---
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: azure-servicebus-queue-rule
      namespace: default
    spec:
      scaleTargetRef:
        name: my-scale-target
      triggers:
      - type: azure-servicebus
        metadata:
          queueName: my-queue
          namespace: service-bus-namespace
          messageCount: "5"
        authenticationRef:
            name: azure-servicebus-auth
    
  3. En la plantilla de ARM, para cada secreto:

    1. Agregue un secreto a la matriz secrets de la aplicación contenedora que contiene el nombre y el valor del secreto.

    2. Agregue una entrada a la matriz auth de la regla de escalado.

      1. Establezca el valor de la propiedad triggerParameter en el valor de la propiedad secretTargetRef de parameter.

      2. Establezca el valor de la propiedad secretRef en el nombre de la propiedad secretTargetRef de key.

    {
      ...
      "resources": {
        ...
        "properties": {
          ...
          "configuration": {
            ...
            "secrets": [
              {                                            ⬅️
                "name": "connection-string-secret",        ⬅️
                "value": "<SERVICE_BUS_CONNECTION_STRING>" ⬅️
              }                                            ⬅️
            ]
          },
          "template": {
            ...
            "scale": {
              "minReplicas": 0,
              "maxReplicas": 5,
              "rules": [
                {
                  "name": "azure-servicebus-queue-rule",
                  "custom": {
                    "type": "azure-servicebus",
                    "metadata": {
                      "queueName": "my-queue",
                      "namespace": "service-bus-namespace",
                      "messageCount": "5"
                    },
                    "auth": [
                      {                                          ⬅️
                        "secretRef": "connection-string-secret", ⬅️
                        "triggerParameter": "connection"         ⬅️
                      }                                          ⬅️
                    ]
                  }
                }
              ]
            }
          }
        }
      }
    }
    

    Algunos escaladores admiten metadatos con el sufijo FromEnv para hacer referencia a un valor de una variable de entorno. Container Apps examina el primer contenedor que se muestra en la plantilla de ARM de la variable de entorno.

    Consulte la sección consideraciones para obtener más información relacionada con la seguridad.

Uso de una identidad administrada

Las reglas de escalado de Container Apps pueden usar la identidad administrada para autenticarse con servicios de Azure. La siguiente plantilla ARM transfiere una identidad asignada por el sistema para autenticar un componente de escalado de la cola de Azure.

Antes de usar el código siguiente, reemplace los marcadores de posición rodeados por <> con sus valores.

"scale": {
  "minReplicas": 0,
  "maxReplicas": 4,
  "rules": [
    {
      "name": "azure-queue",
      "custom": {
        "type": "azure-queue",
        "metadata": {
          "accountName": "<ACCOUNT_NAME>",
          "queueName": "<QUEUE_NAME>",
          "queueLength": "1"
        },
        "identity": "system"
      }
    }
  ]
}

Para más información sobre el uso de identidad administrada con reglas de escalado, consulte Identidad administrada.

  1. En la especificación del escalador KEDA, busque el valor type.

    triggers:
    - type: azure-servicebus ⬅️
      metadata:
        queueName: my-queue
        namespace: service-bus-namespace
        messageCount: "5"
    
  2. En el comando de la CLI, establezca el parámetro --scale-rule-type en el valor type de la especificación.

    az containerapp create \
      --name <CONTAINER_APP_NAME> \
      --resource-group <RESOURCE_GROUP> \
      --environment <ENVIRONMENT_NAME> \
      --image <CONTAINER_IMAGE_LOCATION>
      --min-replicas 0 \
      --max-replicas 5 \
      --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
      --scale-rule-name azure-servicebus-queue-rule \
      --scale-rule-type azure-servicebus \ ⬅️
      --scale-rule-metadata "queueName=my-queue" \
                            "namespace=service-bus-namespace" \
                            "messageCount=5" \
      --scale-rule-auth "connection=connection-string-secret"
    
  3. En la especificación del escalador KEDA, busque los valores metadata.

    triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue              ⬅️
        namespace: service-bus-namespace ⬅️
        messageCount: "5"                ⬅️
    
  4. En el comando de la CLI, establezca el parámetro --scale-rule-metadata en los valores de metadatos.

    Transforme los valores de un formato YAML en un par clave-valor para su uso en la línea de comandos. Separe cada par clave-valor con un espacio.

    az containerapp create \
      --name <CONTAINER_APP_NAME> \
      --resource-group <RESOURCE_GROUP> \
      --environment <ENVIRONMENT_NAME> \
      --image <CONTAINER_IMAGE_LOCATION>
      --min-replicas 0 \
      --max-replicas 5 \
      --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
      --scale-rule-name azure-servicebus-queue-rule \
      --scale-rule-type azure-servicebus \
      --scale-rule-metadata "queueName=my-queue" \              ⬅️
                            "namespace=service-bus-namespace" \ ⬅️
                            "messageCount=5" \                  ⬅️
      --scale-rule-auth "connection=connection-string-secret"
    

Autenticación

Las reglas de escalado de Container Apps admiten la autenticación basada en secretos. Las reglas de escalado de los recursos de Azure, incluidos Azure Queue Storage, Azure Service Bus y Azure Event Hubs, también admiten la identidad administrada. Siempre que sea posible, use la autenticación de identidad administrada para evitar almacenar secretos dentro de la aplicación.

Uso de secretos

Para configurar la autenticación basada en secretos para una regla de escalado de Container Apps, configure los secretos en la aplicación contenedora y haga referencia a ellos en la regla de escalado.

Un escalador KEDA admite secretos en un TriggerAuthentication que usa la propiedad authenticationRef como referencia. Puede asignar el objeto TriggerAuthentication a la regla de escalado de Container Apps.

  1. Busque el objeto TriggerAuthentication al que hace referencia la especificación ScaledObject de KEDA. Identifique cada secretTargetRef del objeto TriggerAuthentication.

    apiVersion: v1
    kind: Secret
    metadata:
      name: my-secrets
      namespace: my-project
    type: Opaque
    data:
      connection-string-secret: <SERVICE_BUS_CONNECTION_STRING> ⬅️
    ---
    apiVersion: keda.sh/v1alpha1
    kind: TriggerAuthentication
    metadata:
      name: azure-servicebus-auth
    spec:
      secretTargetRef:
      - parameter: connection         ⬅️
        name: my-secrets              ⬅️
        key: connection-string-secret ⬅️
    ---
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: azure-servicebus-queue-rule
      namespace: default
    spec:
      scaleTargetRef:
        name: my-scale-target
      triggers:
      - type: azure-servicebus
        metadata:
          queueName: my-queue
          namespace: service-bus-namespace
          messageCount: "5"
        authenticationRef:
            name: azure-servicebus-auth
    
  2. En la aplicación contenedora, cree los secretos que coincidan con las propiedades de secretTargetRef.

  3. En el comando de la CLI, establezca parámetros para cada entrada secretTargetRef.

    1. Cree una entrada de secreto con el parámetro --secrets. Si hay varios secretos, sepárelos con un espacio.

    2. Cree una entrada de autenticación con el parámetro --scale-rule-auth. Si hay varias entradas, sepárelas con un espacio.

    az containerapp create \
      --name <CONTAINER_APP_NAME> \
      --resource-group <RESOURCE_GROUP> \
      --environment <ENVIRONMENT_NAME> \
      --image <CONTAINER_IMAGE_LOCATION>
      --min-replicas 0 \
      --max-replicas 5 \
      --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \ ⬅️
      --scale-rule-name azure-servicebus-queue-rule \
      --scale-rule-type azure-servicebus \
      --scale-rule-metadata "queueName=my-queue" \
                            "namespace=service-bus-namespace" \
                            "messageCount=5" \
      --scale-rule-auth "connection=connection-string-secret"                ⬅️
    

Uso de una identidad administrada

Las reglas de escalado de Container Apps pueden usar la identidad administrada para autenticarse con servicios de Azure. El comando siguiente crea una aplicación contenedora con una identidad administrada asignada por el usuario y la usa para autenticarse para un escalador de colas de Azure.

Antes de usar el código siguiente, reemplace los marcadores de posición rodeados por <> con sus valores.

az containerapp create \
  --resource-group <RESOURCE_GROUP> \
  --name <APP_NAME> \
  --environment <ENVIRONMENT_ID> \
  --user-assigned <USER_ASSIGNED_IDENTITY_ID> \
  --scale-rule-name azure-queue \
  --scale-rule-type azure-queue \
  --scale-rule-metadata "accountName=<AZURE_STORAGE_ACCOUNT_NAME>" "queueName=queue1" "queueLength=1" \
  --scale-rule-identity <USER_ASSIGNED_IDENTITY_ID>
  1. Vaya a su aplicación de contenedores en el portal de Azure.

  2. Selecciona escala.

  3. Seleccione Editar e implementar.

  4. Seleccione la pestaña Escalado y réplicas.

  5. Seleccione el intervalo de réplica mínimo y máximo.

    Captura de pantalla del control deslizante de rango de escala de Azure Container Apps.

  6. Seleccione Agregar.

  7. En el cuadro Nombre de regla, escriba un nombre para la regla.

  8. En la lista desplegable Tipo, seleccione Personalizado.

  9. En la especificación del escalador KEDA, busque el valor type.

    triggers:
    - type: azure-servicebus ⬅️
      metadata:
        queueName: my-queue
        namespace: service-bus-namespace
        messageCount: "5"
    
  10. En el cuadro Tipo de regla personalizada, escriba el valor type del escalador.

  11. En la especificación del escalador KEDA, busque los valores metadata.

    triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue              ⬅️
        namespace: service-bus-namespace ⬅️
        messageCount: "5"                ⬅️
    
  12. En el portal, busque la sección Metadatos y seleccione Agregar. Escriba el nombre y el valor de cada elemento de la sección de metadatos de la especificación ScaledObject de KEDA.

Autenticación

Las reglas de escalado de Container Apps admiten la autenticación basada en secretos. Las reglas de escalado de los recursos de Azure, incluidos Azure Queue Storage, Azure Service Bus y Azure Event Hubs, también admiten la identidad administrada. Siempre que sea posible, use la autenticación de identidad administrada para evitar almacenar secretos dentro de la aplicación.

Uso de secretos

  1. En la aplicación contenedora, cree los secretos a los que desea hacer referencia.

  2. Busque el objeto TriggerAuthentication al que hace referencia la especificación ScaledObject de KEDA. Identifique cada secretTargetRef del objeto TriggerAuthentication.

    apiVersion: v1
    kind: Secret
    metadata:
      name: my-secrets
      namespace: my-project
    type: Opaque
    data:
      connection-string-secret: <SERVICE_BUS_CONNECTION_STRING>
    ---
    apiVersion: keda.sh/v1alpha1
    kind: TriggerAuthentication
    metadata:
      name: azure-servicebus-auth
    spec:
      secretTargetRef:
      - parameter: connection         ⬅️
        name: my-secrets              ⬅️
        key: connection-string-secret ⬅️
    ---
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: azure-servicebus-queue-rule
      namespace: default
    spec:
      scaleTargetRef:
        name: my-scale-target
      triggers:
      - type: azure-servicebus
        metadata:
          queueName: my-queue
          namespace: service-bus-namespace
          messageCount: "5"
        authenticationRef:
            name: azure-servicebus-auth
    
  3. En la sección Autenticación, seleccione Agregar para crear una entrada para cada parámetro secretTargetRef de KEDA.

Uso de una identidad administrada

La autenticación de identidad administrada no se admite en el Azure portal. Use el CLI de Azure o Azure Resource Manager para autenticarse mediante la identidad administrada.

Regla de escalado predeterminada

Si no crea una regla de escalado, la regla de escalado predeterminada se aplica a la aplicación contenedora.

Desencadenador Réplicas mínimas Número máximo de réplicas
HTTP 0 10

Importante

Asegúrese de crear una regla de escalado o establecer minReplicas en 1 o más si no habilita la entrada. Si el ingress está deshabilitado y no defines una minReplicas o una regla de escalado personalizada, la aplicación contenedora se escala a cero y no tiene forma de volver a iniciarse.

Comportamiento de escala

El escalado tiene los siguientes comportamientos:

Comportamiento Valor
Intervalo de sondeo 30 segundos
Período de enfriamiento 300 segundos
Ventana de estabilización de escalado vertical 0 segundos
Ventana de estabilización de reducción vertical 300 segundos
Paso de escalado vertical 1, 4, 8, 16, 32, ... hasta el número máximo de réplicas configurado
Paso de reducción vertical 100 % de las réplicas que necesitan apagarse
Algoritmo de escalado desiredReplicas = ceil(currentMetricValue / targetMetricValue)
  • El intervalo de sondeo es la frecuencia con la que keDA consulta orígenes de eventos. Este valor no se aplica a las reglas de escalado HTTP y TCP.
  • El período de enfriamiento es el tiempo que espera KEDA después del último evento antes de que la aplicación se reduzca a su número mínimo de réplicas.
  • Ventana de estabilización de scale up indica cuánto tiempo espera KEDA antes de tomar una decisión de escalar verticalmente una vez que se cumplen las condiciones para ello.
  • La ventana de estabilización de reducción vertical es cuánto tiempo espera KEDA antes de realizar una decisión de reducción vertical una vez que se cumplen las condiciones de reducción vertical.
  • El paso de escalado es el número de réplicas que se agregan a medida que la aplicación de contenedor se escala hacia afuera. Comienza en 1 y, a continuación, aumenta a 4, 8, 16, 32, etc., hasta el recuento máximo de réplicas configurado.
  • El paso de reducción es el número de réplicas que se eliminan cuando se reduce la aplicación contenedora. KEDA elimina el 100 % de las réplicas que deben desactivarse.
  • El algoritmo de escalado es la fórmula que se usa para calcular el número deseado actual de réplicas.

Ejemplo

Para la siguiente regla de escala:

"minReplicas": 0,
"maxReplicas": 20,
"rules": [
  {
    "name": "azure-servicebus-queue-rule",
    "custom": {
      "type": "azure-servicebus",
      "metadata": {
        "queueName": "my-queue",
        "namespace": "service-bus-namespace",
        "messageCount": "5"
      }
    }
  }
]

A medida que la aplicación se expande, KEDA comienza con una cola vacía y realiza los siguientes pasos:

  1. Compruebe my-queue cada 30 segundos.
  2. Si la longitud de la cola es igual a 0, vuelva al paso 1.
  3. Si la longitud de la cola es mayor que 0, escale la aplicación a 1.
  4. Si la longitud de la cola es 50, calcule desiredReplicas = ceil(50/5) = 10.
  5. Escala la aplicación a min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount)).
  6. Vuelva al paso 1.

Si la aplicación se escala al número máximo de réplicas de 20, el escalado pasa por los mismos pasos anteriores. La reducción vertical solo se produce si la condición se cumple durante 300 segundos (ventana de estabilización de reducción vertical). Una vez que la longitud de la cola es 0, KEDA espera 300 segundos (período de recuperación) antes de escalar la aplicación a 0.

Consideraciones

  • En el modo de revisiones múltiples, al agregar un nuevo desencadenador de escalado, se crea una nueva revisión de la aplicación, pero la revisión anterior sigue estando disponible con las reglas de escalado antiguas. Use la página Administración de revisiones para administrar sus asignaciones de tráfico.

  • No se incurre en ningún cargo de uso cuando una aplicación se escala a cero. Para obtener más información sobre los precios, consulte Billing en Azure Container Apps.

  • Debe habilitar la protección de datos para todas las aplicaciones de .NET en Azure Container Apps. Consulte Deploying and scaling an ASP.NET Core app on Azure Container Apps (Implementación y escalado de una aplicación de ASP.NET Core en Azure Container Apps para obtener más información.

Limitaciones conocidas

  • No se admite el escalado vertical.

  • Las cantidades de réplicas son una cantidad objetivo, no una garantía.

  • Si usa actores de Dapr para administrar estados, tenga en cuenta que no se admite el escalado a cero. Dapr usa actores virtuales para administrar llamadas asincrónicas, lo que significa que su representación en memoria no está vinculada a su identidad o duración.

  • No se admite el cambio de servidores proxy KEDA a través de la configuración de servidores proxy . Considere la posibilidad de usar perfiles de carga de trabajo con una puerta de enlace NAT o una ruta definida por el usuario (UDR) para enviar tráfico a un dispositivo de red, donde puede inspeccionar o proxy el tráfico.

Pasos siguientes