Definir regras de dimensionamento no Aplicativos de Contêiner do Azure

Aplicativos de Contêiner do Azure gerencia o dimensionamento horizontal automático por meio de um conjunto de regras de dimensionamento declarativo. À medida que uma revisão do aplicativo de contêiner é escalada horizontalmente, a plataforma cria novas instâncias da revisão sob demanda. Essas instâncias são conhecidas como réplicas.

Para dar suporte a esse comportamento de dimensionamento, Aplicativos de Contêiner do Azure usa KEDA (Dimensionamento automático controlado por eventos do Kubernetes). O KEDA dá suporte ao dimensionamento em uma variedade de métricas, como solicitações HTTP, mensagens de fila, carga de CPU e memória e fontes de eventos como Barramento de Serviço do Azure, Hubs de Eventos do Azure, Apache Kafka e Redis. Para obter mais informações, consulte Scalers na documentação do KEDA.

Ao adicionar ou editar regras de dimensionamento, você cria uma nova revisão do aplicativo de contêiner. Uma revisão é um instantâneo imutável do seu aplicativo de contêiner. Para saber quais tipos de alterações disparam uma nova revisão, consulte os tipos de alteração de revisão.

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

Definição de 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 conforme o 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 número máximo de réplicas configuráveis é 1.000.
Número máximo de réplicas por revisão	10	1	O número máximo de réplicas configuráveis é 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 (Protocolo de Controle de Transmissão) ou personalizado.
O comportamento é a combinação de regras e limites para determinar decisões de escala ao longo do tempo.

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

Ao definir suas regras de dimensionamento, considere os seguintes itens:

Não serão cobrados encargos de uso se o aplicativo de contêiner for escalado para zero.
As réplicas que não estão sendo processadas, mas permanecem na memória, podem ser cobradas a uma taxa "ociosa" menor. Para obter mais informações, confira Cobrança.
Se você 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, você poderá ver temporariamente mais réplicas do que o esperado. Os aplicativos de contêiner garantem que sua carga de trabalho de produção não seja afetada pelo aquecimento de novas réplicas antes do redirecionamento do tráfego, semelhante ao comportamento padrão do Kubernetes. As réplicas extras são removidas automaticamente após a conclusão da operação.

Regras de escala

Três categorias de gatilhos determinam como o escalonamento ocorre.

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 com a sua revisão.
Personalizado: com base em métricas personalizadas como:
- CPU
- Memória
- Fontes de dados com suporte para eventos:
  - Barramento de Serviço do Azure
  - Hubs de Eventos do Azure
  - Apache Kafka
  - Redis

Se você definir mais de uma regra de escala, o aplicativo de contêineres começará a escalar assim que a primeira condição de qualquer uma das regras for atendida.

Observação

Se você estiver usando Functions on Container Apps, a experiência padrão configura automaticamente regras de escala com base nos gatilhos e nas vinculações da função. O portal Azure desabilita o botão Add scale rules para esses aplicativos. Se você precisar de regras definidas pelo cliente, use allowScalingRuleOverride conforme descrito em Substituir regras de escala KEDA geradas automaticamente para Azure Functions em Aplicativos de Contêiner.

HTTP

Ao usar uma regra de dimensionamento HTTP, você controla o limite de solicitações HTTP simultâneas que determina como a revisão do aplicativo de contêiner é 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. Os trabalhos de Aplicativos de Contêiner não dão suporte a regras de escala HTTP.

No exemplo a seguir, a revisão escala horizontalmente até cinco réplicas e pode reduzir horizontalmente para zero. A propriedade da escala é definida como 100 solicitações simultâneas por segundo.

Exemplo

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

Propriedade de escala	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentRequests`	Quando o número de solicitações HTTP excede esse valor, o aplicativo adiciona outra réplica. O aplicativo continua adicionando réplicas até o valor `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'
              }
            }
          }
        ]
      }
    }
  }
}

Observação

Defina a propriedade properties.configuration.activeRevisionsMode do aplicativo de contêiner como single ao usar regras de escala de eventos não HTTP.

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

Propriedade de escala	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentRequests`	Quando o número de solicitações HTTP excede esse valor, o aplicativo adiciona outra réplica. O aplicativo continua adicionando réplicas até o valor `maxReplicas`.	10	1	n/d

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

Observação

Defina a propriedade properties.configuration.activeRevisionsMode do aplicativo de contêiner como single ao usar regras de escalonamento de eventos não HTTP.

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

Parâmetro da CLI	Descrição	Valor padrão	Valor mínimo	Valor máximo
`--scale-rule-http-concurrency`	Quando o número de solicitações HTTP simultâneas excede esse valor, o aplicativo adiciona outra réplica. O aplicativo continua a adicionar réplicas até atingir a 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á para seu aplicativo de contêiner 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.
No menu suspenso Tipo, selecione Escala HTTP.
Na caixa Solicitações Simultâneas, insira o número de solicitações simultâneas desejadas para seu aplicativo de contêiner.

TCP

Ao usar uma regra de dimensionamento TCP, você controla o limite de conexões TCP simultâneas que determinam como seu aplicativo é dimensionado. A cada 15 segundos, o sistema calcula o número de conexões simultâneas como o número de conexões nos últimos 15 segundos dividido por 15. Os trabalhos de Aplicativos de Contêiner não dão suporte a regras de escala TCP.

No exemplo a seguir, a revisão do aplicativo de contêiner é escalada horizontalmente para até cinco réplicas e pode ser dimensionada em zero. O limite de escala é definido como 100 conexões simultâneas por segundo.

Exemplo

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

Propriedade de escala	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentConnections`	Quando o número de conexões TCP simultâneas excede esse valor, o sistema adiciona outra réplica. O sistema continua adicionando réplicas até a quantidade de `maxReplicas`, à medida que o número de conexões simultâneas 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 seção tcp define uma regra de dimensionamento TCP.

Propriedade de escala	Descrição	Valor padrão	Valor mínimo	Valor máximo
`concurrentConnections`	Quando o número de conexões TCP simultâneas excede esse valor, o sistema adiciona outra réplica. O sistema continua adicionando réplicas até a quantidade de `maxReplicas`, à medida que o número de conexões simultâneas 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 por meio do parâmetro --scale-rule-tcp-concurrency nos comandos create ou update.

Parâmetro da CLI	Descrição	Valor padrão	Valor mínimo	Valor máximo
`--scale-rule-tcp-concurrency`	Quando o número de conexões TCP simultâneas excede esse valor, o sistema adiciona outra réplica. O sistema continua adicionando réplicas até a quantidade de `max-replicas`, à medida que o número de conexõ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 do Azure não dá suporte a esse recurso. Use o CLI do Azure, Azure Resource Manager ou Bicep para configurar uma regra de escala TCP.

Personalizado

Crie uma regra de dimensionamento de Aplicativos de Contêiner personalizada com base em qualquer dimensionador KEDA baseado em ScaledObject usando estes valores padrão:

Valor padrão	Segundos
Intervalo de sondagem	30
Período de resfriamento	300

Observação

O período de resfriamento só entra em vigor ao dimensionar da réplica final para 0. O período de resfriamento não afeta o dimensionamento, pois todas as outras réplicas são removidas.

Para tarefas de Aplicativos de Contêineres orientadas a eventos, crie uma regra de dimensionamento personalizada com base em qualquer escalador KEDA baseado em ScaledJob.

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

Exemplo

Esse exemplo mostra como converter um dimensionador de Barramento do Serviço do Azure em uma regra de dimensionamento de Aplicativos de Contêiner, mas você usa o mesmo processo para qualquer outra especificação do dimensionador KEDA baseado em ScaledObject.

Para autenticação, os parâmetros de autenticação do escalador KEDA aceitam segredos dos Aplicativos de Contêiner ou identidade gerenciada.

O procedimento a seguir mostra a você como converter um dimensionador KEDA em uma regra de dimensionamento de Aplicativo de Contêiner. Este trecho de código é uma parte de um modelo Bicep para mostrar onde cada seção se encaixa no contexto do modelo como um todo.

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 trecho para obter contexto sobre como os exemplos a seguir se encaixam no modelo de Bicep.

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

Na especificação do dimensionador KEDA, localize o valor type.

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

No modelo Bicep, insira o valor do scaler type na propriedade custom.type 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 dimensionador KEDA, localize os valores de 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 de Aplicativos de Contêiner oferecem suporte à autenticação baseada em segredos. Regras de escala para recursos Azure, incluindo Armazenamento de Filas do Azure, Barramento de Serviço do Azure e Hubs de Eventos do Azure, também dão suporte à identidade gerenciada. Sempre que possível, utilize a autenticação de identidade gerida para evitar o armazenamento de segredos dentro da aplicação.

Usar segredos

Para usar segredos na autenticação, crie um segredo no array secrets do aplicativo de contêiner. Use o valor do segredo na auth matriz da regra de escala.

Os escaladores KEDA podem usar segredos em um TriggerAuthentication referenciado pela propriedade authenticationRef. Você pode mapear o objeto TriggerAuthentication para a regra de dimensionamento de Aplicativos de Contêiner.

Localize o objeto TriggerAuthentication mencionado pela especificação de ScaledObject do KEDA.

No objeto TriggerAuthentication, encontre cada secretTargetRef e 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 Bíceps, para cada segredo:

Adicione um segredo ao array do aplicativo de contêiner secrets que contém o nome e o valor do segredo.

Adicione uma entrada à matriz auth da regra de escala.

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

Defina o valor da propriedade secretRef como o nome da propriedade secretTargetRefkey.

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 dimensionadores dão suporte a metadados com o sufixo FromEnv para mencionar um valor em uma variável de ambiente. Os Aplicativos de Contêiner conferem o primeiro contêiner listado no modelo do ARM para a variável de ambiente.

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

Usar a identidade gerenciada

As regras de escala dos Aplicativos de Contêiner podem usar a identidade gerenciada para autenticar com serviços do Azure. O modelo Bicep a seguir passa a identidade gerenciada do sistema para autenticar em um escalador de Filas 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 a você como converter um dimensionador KEDA em uma regra de dimensionamento de Aplicativo de Contêiner. Esse snippet de código é um trecho de um modelo do ARM que mostra onde cada seção se encaixa no contexto do modelo total.

{
  ...
  "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 trecho para obter contexto sobre como os exemplos a seguir se encaixam no modelo do ARM.

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

Na especificação do dimensionador KEDA, localize o valor type.

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

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

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

Na especificação do dimensionador KEDA, localize os valores de metadata.

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

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

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

Autenticação

Usar segredos

Para usar segredos na autenticação, crie um segredo no array do aplicativo de contêiner secrets. Use o valor secreto na matriz auth da regra de escala.

Localize o objeto TriggerAuthentication mencionado pela especificação de ScaledObject do KEDA.

No objeto TriggerAuthentication, encontre cada secretTargetRef e 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 ao array do aplicativo de contêiner secrets que contém o nome e o valor do segredo.
Adicione uma entrada à matriz auth da regra de escala.
1. Defina o valor da propriedade triggerParameter para o valor da propriedade secretTargetRef do parameter.
2. Defina o valor da propriedade secretRef como o nome da propriedade secretTargetRefkey.

{
  ...
  "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 considerações para obter mais informações relacionadas à segurança.

Usar a identidade gerenciada

As regras de escala dos Aplicativos de Contêiner podem usar a identidade gerenciada para autenticar com serviços do Azure. O seguinte modelo ARM passa na identidade gerenciada atribuída no sistema para autenticar um escalador de filas 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.

Na especificação do dimensionador KEDA, localize o valor type.

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

No comando da CLI, defina o parâmetro --scale-rule-type para o valor type da especificaçã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"

Na especificação do dimensionador KEDA, localize os valores de metadata.

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

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

Transforme os valores de um formato YAML em um par chave/valor para uso na linha de comando. Separe cada par de 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

Usar segredos

Para configurar a autenticação baseada em segredos para uma regra de escala de Aplicativos de Contêiner, configure os segredos no aplicativo de contêiner e referencie-os na regra de escala.

Um escalador KEDA dá suporte a segredos em uma TriggerAuthentication que a propriedade authenticationRef usa para referência. Você pode mapear o objeto TriggerAuthentication para a regra de escala do Aplicativos de Contêiner do Azure.

Localize o objeto TriggerAuthentication mencionado pela especificação de ScaledObject do KEDA. Identifique cada secretTargetRef do 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

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

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

Crie uma entrada secreta com o parâmetro --secrets. Se existirem vários segredos, separe-os com um espaço.
Crie uma entrada de autenticação com o parâmetro --scale-rule-auth. Se existirem 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"                ⬅️

Usar a identidade gerenciada

As regras de escala dos Aplicativos de Contêiner podem usar a identidade gerenciada para autenticar com serviços do Azure. O comando a seguir cria um aplicativo de contêiner com uma identidade gerenciada atribuída pelo usuário e a usa para autenticar para um dimensionador de filas 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á para seu aplicativo de contêiner no Azure portal.
Selecione Escala.
Selecione Editar e implantar.
Selecione a guia Escala e réplicas .
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.

Na especificação do dimensionador KEDA, localize o valor type.

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

Na caixa de tipo de regra personalizada , insira o valor do dimensionador type .

Na especificação do dimensionador KEDA, localize os valores de 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 ScaledObject do KEDA.

Autenticação

Usar segredos

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

Localize o objeto TriggerAuthentication mencionado pela especificação de ScaledObject do KEDA. Identifique cada secretTargetRef do 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

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

Usar a identidade gerenciada

Não há suporte para autenticação de identidade gerenciada no Azure portal. Use o CLI do Azure ou Azure Resource Manager para autenticar usando a identidade gerenciada.

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.

Gatilho	Número mínimo de réplicas	Número máximo de réplicas
HTTP	0	10

Importante

Certifique-se de criar uma regra de dimensionamento ou defina minReplicas como 1 ou mais, se você não habilitar a entrada. Se a entrada estiver desabilitada e você não definir uma minReplicas ou uma regra de escala personalizada, o aplicativo de contêiner será dimensionado para zero e não terá como iniciar o backup.

Comportamento de escala

O dimensionamento tem os seguintes comportamentos:

Comportamento	Valor
Intervalo de sondagem	30 segundos
Período de resfriamento	300 segundos
Escalar verticalmente a janela de estabilização	0 segundos
Reduzir verticalmente a janela de estabilização	300 segundos
Etapa escalar verticalmente	1, 4, 8, 16, 32, ... até a contagem máxima de réplicas configurada
Etapa de redução horizontal	100% de réplicas que precisam ser desligadas
Algoritmo de escala	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

O intervalo de sondagem é a frequência com que o KEDA consulta fontes de eventos. Esse valor não se aplica a regras de escala HTTP e TCP.
O período de resfriamento é o tempo que o KEDA aguarda após o último evento antes de o aplicativo ser reduzido ao seu número mínimo de réplicas.
Janela de estabilização da escala é o tempo que o KEDA aguarda antes de realizar uma decisão de expansão assim que as condições para expansão são atendidas.
Janela de estabilização de redução horizontal é o tempo que o KEDA aguarda antes de realizar uma decisão de redução horizontal depois que as condições para redução horizontal são atendidas.
A etapa escalar verticalmente é quantas réplicas são adicionadas à medida que o aplicativo de contêiner é expandido. Ele começa em 1 e, em seguida, aumenta para 4, 8, 16, 32 e assim por diante, até a contagem máxima de réplicas configurada.
A etapa de redução horizontal é quantas réplicas são removidas à medida que o aplicativo de contêiner é dimensionado. KEDA remove 100% das réplicas que precisam ser encerradas.
O algoritmo de dimensionamento é a fórmula usada para calcular o número de réplicas desejado atualmente.

Exemplo

Para a regra de dimensionamento a seguir:

"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 é expandido, o KEDA começa com uma fila vazia e executa as seguintes etapas:

Verifica my-queue a cada 30 segundos.
Se o comprimento da fila for igual a 0, volte para a etapa 1.
Se o comprimento da fila for maior que 0, dimensione o aplicativo para 1.
Se o comprimento da fila de espera for 50, calcula desiredReplicas = ceil(50/5) = 10.
Escalar o aplicativo para min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount)).
Volte para a etapa 1.

Se o aplicativo escalar até o número máximo de 20 réplicas, a escalabilidade seguirá as mesmas etapas de antes. A redução só acontece se a condição permanecer satisfeita por 300 segundos (janela de estabilização para redução). Após o comprimento da fila de espera chegar a 0, o KEDA aguardará 300 segundos (período de resfriamento) antes de dimensionar o aplicativo como 0.

Considerações

No modo "revisões múltiplas", adicionar um novo gatilho de dimensionamento criará uma nova revisão do seu aplicativo, mas sua revisão antiga continuará disponível com as regras de dimensionamento antigas. Use a página Gerenciamento de Revisão para gerenciar alocações de tráfego.
Você não incorre em encargos de uso quando um aplicativo é dimensionado para zero. Para obter mais informações sobre preços, consulte Billing no Aplicativos de Contêiner do Azure.
Você precisa habilitar a proteção de dados para todos os aplicativos .NET no Aplicativos de Contêiner do Azure. Consulte Implantando e dimensionando um aplicativo ASP.NET Core em Aplicativos de Contêiner do Azure para obter detalhes.

Limitações conhecidas

Não há suporte para a colocação em escala vertical.
As quantidades de réplica são um valor de destino, não uma garantia.
Se você estiver usando atores Dapr para gerenciar estados, tenha em mente que não há suporte para dimensionamento para zero. O Dapr usa atores virtuais para gerenciar chamadas assíncronas, o que significa que a representação dele em memória não está vinculada à identidade ou ao tempo de vida dele.
Não há suporte para alterar proxies KEDA por meio das configurações de proxies . Considere usar perfis de carga de trabalho com um Gateway da NAT ou UDR (Rota Definida pelo Usuário) a fim de enviar o tráfego para um equipamento de rede, no qual você pode inspecionar o tráfego ou criar proxy para ele.

Próximas etapas

Gerenciar segredos

Comentários

Esta página foi útil?

Last updated on 2026-05-26

Definir regras de dimensionamento no Aplicativos de Contêiner do Azure

Definição de escala

Regras de escala

HTTP

Exemplo

TCP

Exemplo

Personalizado

Exemplo

Autenticação

Usar segredos

Usar a identidade gerenciada

Autenticação

Usar segredos

Usar a identidade gerenciada

Autenticação

Usar segredos

Usar a identidade gerenciada

Autenticação

Usar segredos

Usar a identidade gerenciada

Regra de escala padrão

Comportamento de escala

Exemplo

Considerações

Limitações conhecidas

Próximas etapas

Comentários

Recursos adicionais