Defina as regras de escalonamento no Azure Container Apps

Azure Container Apps gere a escalabilidade horizontal automática através de um conjunto de regras de escalabilidade declarativa. À medida que a revisão de uma aplicação container cresce, a plataforma cria novas instâncias da revisão sob demanda. Essas instâncias são conhecidas como réplicas.

Para suportar este comportamento de escalabilidade, o Azure Container Apps utiliza KEDA (Kubernetes Event-driven Autoscaling). O KEDA suporta escalabilidade contra uma variedade de métricas como pedidos HTTP, mensagens de fila, carga de CPU e memória, e fontes de eventos como Azure Service Bus, Hubs de Eventos do Azure, Apache Kafka e Redis. Para obter mais informações, consulte Scalers na documentação do KEDA.

Quando adicionas ou editas regras de escalabilidade, crias uma nova revisão da tua aplicação container. Uma revisão é um instantâneo imutável do seu aplicativo de contêiner. Para saber quais tipos de alterações acionam uma nova revisão, consulte Tipos de alteração de revisão.

Os trabalhos de Aplicativos de Contêiner controlados por eventos usam regras de dimensionamento para disparar execuções com base em eventos.

Definição da escala

O dimensionamento é a combinação de limites, regras e comportamento.

Os limites definem o número mínimo e máximo possível de réplicas por revisão à medida que seu aplicativo de contêiner é dimensionado.

Limite de escala	Valor padrão	Valor mínimo	Valor máximo
Número mínimo de réplicas por revisão	0	0	O máximo de réplicas configuráveis é de 1.000.
Número máximo de réplicas por revisão	10	1	O máximo de réplicas configuráveis é de 1.000.

As regras são os critérios usados pelos Aplicativos de Contêiner para decidir quando adicionar ou remover réplicas.

As regras de escala são implementadas como HTTP, TCP (Transmission Control Protocol) ou personalizadas.
O comportamento é a combinação de regras e limites para determinar decisões de escala ao longo do tempo.

O comportamento da escala explica como as decisões de escala são tomadas.

Ao definires as tuas regras de escala, considera os seguintes itens:

Você não será cobrado por utilização se a sua aplicação de contêiner for dimensionada para zero.
Réplicas que não estão a ser processadas mas permanecem na memória podem ser faturadas a uma taxa "ociosa" mais baixa. Para obter mais informações, consulte Cobrança.
Se quiser garantir que uma instância da revisão esteja sempre em execução, defina o número mínimo de réplicas como 1 ou superior.
Durante as atualizações ou manutenção da plataforma, pode ver temporariamente mais réplicas do que o esperado. O Container Apps garante que a sua carga de trabalho de produção não é afetada pelo pré-aquecimento de novas réplicas antes de transferir tráfego, semelhante ao comportamento padrão do Kubernetes. As réplicas extra são removidas automaticamente assim que a operação termina.

Regras de escala

Três categorias de gatilhos determinam o modo como ocorre o dimensionamento.

HTTP: Com base no número de solicitações HTTP simultâneas para sua revisão.
TCP: Com base no número de conexões TCP simultâneas para sua revisão.
Personalizado: com base em métricas personalizadas como:
- CPU
- Memória
- Fontes de dados orientadas a eventos suportadas:
  - Azure Service Bus
  - Hubs de Eventos do Azure
  - Apache Kafka
  - Redis

Se definires mais do que uma regra de escala, a aplicação container começa a escalar assim que a primeira condição de qualquer regra é cumprida.

Nota

Se estiveres a usar Funções em Aplicações de Contentores, a experiência padrão configura automaticamente as regras de escala com base nos gatilhos e associações de funções. O portal Azure desativa o botão Add scale rules para estas aplicações. Se precisar de regras definidas pelo utilizador, use allowScalingRuleOverride conforme descrito em Substituir regras de escala KEDA geradas automaticamente para Funções do Azure em Container Apps.

HTTP

Quando utiliza uma regra de escalabilidade HTTP, controla o valor limite de pedidos HTTP simultâneos que determina como a revisão da sua aplicação em contentor é dimensionada. A cada 15 segundos, o número de solicitações simultâneas é calculado como o número de solicitações nos últimos 15 segundos dividido por 15. As tarefas de Aplicações de Contentor não suportam regras de escalonamento HTTP.

No exemplo a seguir, a versão pode ser ampliada para até cinco réplicas e pode ser reduzida para zero. A propriedade de dimensionamento é definida como 100 solicitações simultâneas por segundo.

Exemplo

A http seção define uma regra de escala HTTP.

Propriedade Scale	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentRequests`	Quando o número de pedidos HTTP ultrapassa este valor, a aplicação adiciona outra réplica. A aplicação continua a adicionar réplicas até à quantidade `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

Defina a properties.configuration.activeRevisionsMode propriedade da aplicação container para single quando se usam regras de escala de eventos que não sejam HTTP.

A http seção define uma regra de escala HTTP.

Propriedade Scale	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentRequests`	Quando o número de pedidos HTTP ultrapassa este valor, a aplicação adiciona outra réplica. A aplicação continua a adicionar réplicas até ao número `maxReplicas`.	10	1	n/d

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Nota

Defina a properties.configuration.activeRevisionsMode propriedade da aplicação container para single quando se usam regras de escala de eventos que não sejam HTTP.

Defina uma regra de escala HTTP usando o --scale-rule-http-concurrency parâmetro nos create comandos ou update .

Parâmetro CLI	Descrição	Valor padrão	Valor mínimo	Valor máximo
`--scale-rule-http-concurrency`	Quando o número de pedidos HTTP concorrentes ultrapassa este valor, a aplicação adiciona outra réplica. A aplicação continua a adicionar réplicas até à quantidade `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

Vá à sua aplicação container no Azure portal.
Selecione Escala.
Selecione Editar e implantar.
Selecione a guia Escala .
Selecione o intervalo mínimo e máximo de réplicas.
Selecione Adicionar.
Na caixa Nome da regra , insira um nome de regra.
Na lista suspensa Tipo, selecione Dimensionamento HTTP.
Na caixa de Pedidos Concorrentes , introduza o número de pedidos concorrentes que pretende para a sua aplicação container.

TCP

Quando usas uma regra de escalonamento TCP, controlas o limiar das ligações TCP concorrentes que determinam como a tua aplicação escala. A cada 15 segundos, o sistema calcula o número de ligações concorrentes como o número de ligações nos últimos 15 segundos dividido por 15. Tarefas de Container Apps não suportam regras de dimensionamento TCP.

No exemplo seguinte, a revisão da aplicação container escala até cinco réplicas e pode escalar até zero. O limite de dimensionamento é definido como 100 conexões simultâneas por segundo.

Exemplo

A tcp seção define uma regra de escala TCP.

Propriedade Scale	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentConnections`	Quando o número de ligações TCP concorrentes excede este valor, o sistema adiciona outra réplica. O sistema continua a adicionar réplicas até ao valor `maxReplicas` à medida que o número de ligações concorrentes aumenta.	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'
              }
            }
          }
        ]
      }
    }
  }
}

A tcp seção define uma regra de escala TCP.

Propriedade Scale	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentConnections`	Quando o número de ligações TCP concorrentes excede este valor, o sistema adiciona outra réplica. O sistema continua a adicionar réplicas até ao valor `maxReplicas` à medida que o número de ligações concorrentes aumenta.	10	1	n/d

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "tcp-rule",
            "tcp": {
              "metadata": {
                "concurrentConnections": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Defina uma regra de escala TCP usando o parâmetro --scale-rule-tcp-concurrency nos comandos create ou update.

Parâmetro CLI	Descrição	Valor padrão	Valor mínimo	Valor máximo
`--scale-rule-tcp-concurrency`	Quando o número de ligações TCP concorrentes excede este valor, o sistema adiciona outra réplica. O sistema vai adicionando réplicas até ao valor de `max-replicas` à medida que o número de ligações simultâneas aumenta.	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

O portal Azure não suporta esta funcionalidade. Utilize o CLI do Azure, o Azure Resource Manager ou o Bicep para configurar uma regra de escala TCP.

Personalizado

Crie uma regra de escalonamento personalizada para Aplicações Container baseada em qualquer escalador KEDA baseado em ScaledObject, usando estes valores predefinidos:

Valor padrão	Segundos
Intervalo de consulta	30
Período de reflexão	300

Nota

O período de recarga só entra em vigor ao escalar da réplica final até 0. O período de arrefecimento não afeta o dimensionamento, pois quaisquer réplicas adicionais são removidas.

Para tarefas do Container Apps acionadas por eventos, crie uma regra de dimensionamento personalizada com base em qualquer scaler do KEDA baseado em ScaledJob.

O exemplo a seguir demonstra como criar uma regra de escala personalizada.

Exemplo

Este exemplo mostra como converter um escalador Azure Service Bus numa regra de escala Container Apps, mas utiliza o mesmo processo para qualquer outra especificação de escalador baseada em ScaledObject do KEDA.

Para autenticação, os parâmetros de autenticação do escalonador KEDA utilizam segredos de Aplicativos de Contêiner ou identidade gerida.

O procedimento a seguir mostra como converter um escalador KEDA em uma regra de escala do Aplicativo de Contêiner. Este trecho é um trecho de um modelo Bicep para mostrar onde cada seção se encaixa no contexto do modelo geral.

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 excerto para contexto sobre como os seguintes exemplos se encaixam no modelo Bicep.

Primeiro, defina o tipo e os metadados da regra da escala.

A partir da especificação do escalador KEDA, encontre o valor type.

triggers:
 - type: azure-servicebus ⬅️
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

No modelo Bicep, insira o valor do escalador type na custom.type propriedade da regra de escala.

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

Na especificação do escalador KEDA, encontre os valores metadata.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue              ⬅️
    namespace: service-bus-namespace ⬅️
    messageCount: "5"                ⬅️

No modelo Bicep, adicione todos os valores de metadados à custom.metadata seção da regra de escala.

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

Autenticação

As regras de escala dos Aplicativos de Contêiner oferecem suporte à autenticação baseada em segredos. As regras de escala para recursos do Azure, incluindo Armazenamento de Filas do Azure, Azure Service Bus e Hubs de Eventos do Azure, também suportam identidade gerida. Sempre que possível, use a autenticação de identidade gerenciada para evitar o armazenamento de segredos no aplicativo.

Utilize segredos

Para usar segredos para autenticação, crie um segredo na matriz secrets da aplicação de contentor. Utilize o valor secreto na matriz auth da regra de escala.

Os dimensionadores do KEDA podem usar segredos num TriggerAuthentication referenciado pela propriedade authenticationRef. Você pode mapear o objeto TriggerAuthentication à regra de escala do Container Apps.

Encontre o TriggerAuthentication objeto referenciado pela especificação KEDA ScaledObject .

No objeto TriggerAuthentication, encontre cada secretTargetRef e o seu segredo associado.

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

No modelo Bicep, para cada segredo:

Adicione um segredo à matriz do secrets aplicativo contêiner que contém o nome e o valor secretos.

Adicione uma entrada à auth matriz da regra de escala.

Defina o valor da propriedade triggerParameter como o valor da propriedade secretTargetRef do parameter.

Defina o valor da propriedade secretRef para o nome da propriedade 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'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Alguns escaladores suportam metadados com o sufixo FromEnv para fazer referência a um valor em uma variável de ambiente. Container Apps examina o primeiro contêiner listado no modelo ARM para a variável de ambiente.

Consulte a seção de considerações para obter mais informações relacionadas à segurança.

Usando identidade gerenciada

As regras de escala das Aplicações Container podem usar identidade gerida para autenticar com os serviços do Azure. O seguinte modelo Bicep utiliza uma identidade gerida baseada no sistema para autenticar num escalador de fila do Azure.

Antes de usar o código a seguir, substitua os espaços reservados cercados por <> pelos seus 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 saber mais sobre como usar a identidade gerenciada com regras de escala, consulte Identidade gerenciada.

O procedimento a seguir mostra como converter um escalador KEDA em uma regra de escala do Aplicativo de Contêiner. Este trecho é um trecho de um modelo ARM para mostrar onde cada seção se encaixa no contexto do modelo geral.

{
  ...
  "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 excerto para contexto sobre como os seguintes exemplos se encaixam no modelo ARM.

Primeiro, defina o tipo e os metadados da regra da escala.

A partir da especificação do escalador KEDA, encontre o valor type.

triggers:
- type: azure-servicebus ⬅️
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

No modelo ARM, insira o valor do escalador type na custom.type propriedade da regra de escala.

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

Na especificação do escalador KEDA, encontre os valores metadata.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue              ⬅️
    namespace: service-bus-namespace ⬅️
    messageCount: "5"                ⬅️

No modelo ARM, adicione todos os valores de metadados à custom.metadata seção da regra de escala.

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

Autenticação

Utilize segredos

Para usar segredos na autenticação, crie um segredo na matriz secrets da aplicação de contentor. Utilize o valor secreto na matriz auth da regra de escala.

Os scalers do KEDA podem usar segredos num TriggerAuthentication ao qual a propriedade authenticationRef faz referência. Você pode mapear o objeto TriggerAuthentication à regra de escala do Container Apps.

Encontre o TriggerAuthentication objeto referenciado pela especificação KEDA ScaledObject .

No objeto TriggerAuthentication, encontre cada secretTargetRef e o seu segredo associado.

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

No modelo ARM, para cada segredo:

Adicione um segredo à matriz do secrets aplicativo contêiner que contém o nome e o valor secretos.
Adicione uma entrada à auth matriz da regra de escala.
1. Defina o valor da propriedade triggerParameter como o valor da propriedade secretTargetRef do parameter.
2. Defina o valor da propriedade secretRef para o nome da propriedade 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"         ⬅️
                  }                                          ⬅️
                ]
              }
            }
          ]
        }
      }
    }
  }
}

Consulte a seção de considerações para obter mais informações relacionadas à segurança.

Usando identidade gerenciada

As regras de escala das Aplicações Container podem usar identidade gerida para autenticar com os serviços do Azure. O seguinte modelo ARM passa para a identidade gerida atribuída pelo sistema para autenticar para um escalador de fila do Azure.

Antes de usar o código a seguir, substitua os espaços reservados cercados por <> pelos seus 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 saber mais sobre como usar a identidade gerenciada com regras de escala, consulte Identidade gerenciada.

A partir da especificação do escalador KEDA, encontre o valor type.

triggers:
- type: azure-servicebus ⬅️
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

No comando CLI, defina o --scale-rule-type parâmetro como o valor da especificação type .

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"

Na especificação do escalador KEDA, encontre os valores metadata.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue              ⬅️
    namespace: service-bus-namespace ⬅️
    messageCount: "5"                ⬅️

No comando CLI, defina o --scale-rule-metadata parâmetro como os valores de metadados.

Transforme os valores de um formato YAML para um par chave/valor para uso na linha de comandos. Separe cada par chave/valor com um espaço.

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"

Autenticação

Utilize segredos

Para configurar a autenticação baseada em segredos para uma regra de escala das Aplicações Container, configure os segredos na aplicação do contentor e faça referência a eles na regra de escala.

Um escalador KEDA suporta segredos em um TriggerAuthentication que a authenticationRef propriedade usa como referência. Você pode mapear o TriggerAuthentication objeto para a regra de escala de Aplicativos de Contêiner.

Encontre o TriggerAuthentication objeto referenciado pela especificação KEDA ScaledObject . Identifique cada secretTargetRef do TriggerAuthentication objeto.

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

Em seu aplicativo de contêiner, crie os segredos que correspondem às secretTargetRef propriedades.

No comando CLI, defina parâmetros para cada secretTargetRef entrada.

Crie uma entrada secreta com o --secrets parâmetro. Se houver vários segredos, separe-os com um espaço.
Crie uma entrada de autenticação com o --scale-rule-auth parâmetro. Se houver várias entradas, separe-as com um espaço.

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"                ⬅️

Usando identidade gerenciada

As regras de escala das Aplicações Container podem usar identidade gerida para autenticar com os serviços do Azure. O comando seguinte cria uma aplicação contentor com uma identidade gerida atribuída pelo utilizador e usa-a para autenticar para um escalador de fila do Azure.

Antes de usar o código a seguir, substitua os espaços reservados cercados por <> pelos seus 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>

Vá à sua aplicação container no Azure portal.
Selecione Escala.
Selecione Editar e implantar.
Selecione a aba Escala e Réplica.
Selecione o intervalo mínimo e máximo de réplicas.
Selecione Adicionar.
Na caixa Nome da regra , insira um nome de regra.
Na lista suspensa Tipo, selecione Personalizado.

A partir da especificação do escalador KEDA, encontre o valor type.

triggers:
- type: azure-servicebus ⬅️
  metadata:
    queueName: my-queue
    namespace: service-bus-namespace
    messageCount: "5"

Na caixa Tipo de regra personalizada, insira o valor do type scaler.

Na especificação do escalador KEDA, encontre os valores metadata.

triggers:
- type: azure-servicebus
  metadata:
    queueName: my-queue              ⬅️
    namespace: service-bus-namespace ⬅️
    messageCount: "5"                ⬅️

No portal, localize a seção Metadados e selecione Adicionar. Insira o nome e o valor de cada item na seção de metadados da especificação KEDA ScaledObject .

Autenticação

Utilize segredos

Em seu aplicativo de contêiner, crie os segredos que você deseja referenciar.

Encontre o TriggerAuthentication objeto referenciado pela especificação KEDA ScaledObject . Identifique cada secretTargetRef do TriggerAuthentication objeto.

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

Na seção Autenticação, selecione Adicionar para criar uma entrada para cada parâmetro KEDAsecretTargetRef.

Usando identidade gerenciada

A autenticação de identidade gerida não é suportada no Azure portal. Use o CLI do Azure ou Azure Resource Manager para autenticar usando identidade gerida.

Regra de escala padrão

Se você não criar uma regra de escala, a regra de escala padrão será aplicada ao seu aplicativo de contêiner.

Acionador	Réplicas mínimas	Máximo de réplicas
HTTP	0	10

Importante

Certifique-se de criar uma regra de escala ou definir minReplicas como 1 ou mais se não habilitar a entrada. Se o ingress estiver desativado e não definires uma minReplicas ou uma regra de escala personalizada, a tua aplicação container escala até zero e não tem forma de arrancar novamente.

Comportamento da escala

O dimensionamento tem os seguintes comportamentos:

Comportamento	Valor
Intervalo de consulta	30 segundos
Período de reflexão	300 segundos
Aumentar a janela de estabilização	0 segundos
Reduzir a janela de estabilização	300 segundos
Aumentar a escala da etapa	1, 4, 8, 16, 32, ... até contagem máxima de réplicas configurada
Reduzir etapa	100 réplicas% que precisam ser desligadas
Algoritmo de dimensionamento	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

O intervalo de sondagem é a frequência com que a KEDA consulta fontes de eventos. Esse valor não se aplica a regras de escala HTTP e TCP.
Período de arrefecimento é o tempo que o KEDA aguarda após o último evento antes de a aplicação ser reduzida para o número mínimo de réplicas.
A janela de estabilização de escalonamento é o tempo que o KEDA espera antes de realizar uma decisão de escalonamento depois de serem cumpridas as condições de escalonamento.
A janela de estabilização de redução de escala é o tempo que o KEDA espera antes de executar uma decisão de redução de escala depois de cumpridas as condições de redução de escala.
A etapa de dimensionamento é quantas réplicas são adicionadas à medida que seu aplicativo de contêiner é dimensionado. Ele começa em 1, depois aumenta para 4, 8, 16, 32 e assim por diante, até a contagem máxima de réplicas configurada.
Escala descendente é o número de réplicas que são removidas à medida que a tua aplicação de contentores cresce. O KEDA remove 100 % das réplicas que têm de ser terminadas.
Algoritmo de dimensionamento é a fórmula usada para calcular o número desejado atual de réplicas.

Exemplo

Para a seguinte regra 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"
      }
    }
  }
]

À medida que seu aplicativo se expande, o KEDA começa com uma fila vazia e executa as seguintes etapas:

Verifique my-queue a cada 30 segundos.
Se o comprimento da fila for igual a 0, volte ao passo 1.
Se o comprimento da fila for superior a 0, escala a aplicação para 1.
Se o comprimento da fila for 50, calcule desiredReplicas = ceil(50/5) = 10.
Escalar a aplicação para min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount)).
Volta ao passo 1.

Se a aplicação escalar até ao número máximo de réplicas de 20, a escalabilidade segue os mesmos passos anteriores. A redução de escala só acontece se a condição for satisfeita durante 300 segundos (janela de estabilização de redução de escala). Quando o comprimento da fila é 0, o KEDA aguarda por 300 segundos (período de resfriamento) antes de dimensionar o aplicativo para 0.

Considerações

No modo "várias revisões", adicionar um novo gatilho de escala cria uma nova revisão do seu aplicativo, mas a revisão antiga permanece disponível com as regras de escala antigas. Utilize a página de gestão de revisões para gerenciar alocações de tráfego.
Não incorre em custos de utilização quando uma aplicação escala até zero. Para mais informações sobre preços, consulte Faturação em Azure Container Apps.
Precisa de ativar a proteção de dados para todas as aplicações .NET no Azure Container Apps. Consulte Deploying and scaling an ASP.NET Core app no Azure Container Apps para mais detalhes.

Limitações conhecidas

Não há suporte para dimensionamento vertical.
As quantidades de réplicas são um valor-alvo, não uma garantia.
Se estiveres a usar atores Dapr para gerir estados, lembra-te que escalar até zero não é suportado. O Dapr usa atores virtuais para gerenciar chamadas assíncronas, o que significa que sua representação na memória não está vinculada à sua identidade ou tempo de vida.
Alterar os proxies do KEDA através das definições proxies não é suportada. Considere utilizar Perfis de carga de trabalho com um NAT Gateway ou uma Rota Definida pelo Utilizador (UDR) para enviar tráfego para um dispositivo de rede, onde pode inspecionar o tráfego ou atuar como proxy para o mesmo.

Próximos passos

Gerir segredos

Comentários

Esta página foi útil?

Last updated on 2026-05-26

Defina as regras de escalonamento no Azure Container Apps

Definição da escala

Regras de escala

HTTP

Exemplo

TCP

Exemplo

Personalizado

Exemplo

Autenticação

Utilize segredos

Usando identidade gerenciada

Autenticação

Utilize segredos

Usando identidade gerenciada

Autenticação

Utilize segredos

Usando identidade gerenciada

Autenticação

Utilize segredos

Usando identidade gerenciada

Regra de escala padrão

Comportamento da escala

Exemplo

Considerações

Limitações conhecidas

Próximos passos

Comentários

Recursos adicionais