Definir regras de colocação em escala em Aplicativos de Contêiner do Azure

2025-05-21

Os Aplicativos de Contêiner do Azure gerenciam a colocação em escala horizontal automático por meio de um conjunto de regras de colocação em escala declarativo. À medida que uma revisão de aplicativo de contêiner é escalada horizontalmente, novas instâncias de revisão são criadas sob demanda. Essas instâncias são conhecidas como réplicas.

Para dar suporte a esse comportamento de dimensionamento, os Aplicativos de Contêiner do Azure são alimentados pelo KEDA (Dimensionamento automático controlado por eventos do Kubernetes). O KEDA dá suporte à escala com base 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.

Adicionar ou editar regras de escala cria uma nova revisão do seu 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, é importante considerar 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.

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 (Unidade Central de Processamento)
- 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êiner começará a ser escalado quando a primeira condição de qualquer regra for atendida.

HTTP

Com uma regra de escala HTTP, você tem controle sobre o limite de solicitações HTTP simultâneas que determina como a revisão do aplicativo de contêiner é escalada. 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, uma outra réplica é adicionada. As réplicas continuam a ser adicionadas ao pool até a 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'
              }
            }
          }
        ]
      }
    }
  }
}

Observação

Ao usar regras de dimensionamento de eventos não HTTP, defina a propriedade properties.configuration.activeRevisionsMode do aplicativo de contêiner como single.

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, uma outra réplica é adicionada. As réplicas continuam a ser adicionadas ao pool até a quantidade `maxReplicas`.	10	1	N/D

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

Observação

Ao usar regras de dimensionamento de eventos não HTTP, defina a propriedade properties.configuration.activeRevisionsMode do aplicativo de contêiner como single.

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, uma outra réplica é adicionada. As réplicas continuam a ser adicionadas ao pool até 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 o seu aplicativo de contêiner no portal do Azure.
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 desejado de solicitações simultâneas para seu aplicativo de contêiner.

TCP

Com uma regra de escala TCP, você tem controle sobre o limite de conexões TCP simultâneas que determina como seu aplicativo é escalado. A cada 15 segundos, o número de conexões simultâneas é calculado 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 escala horizontalmente até cinco réplicas e pode reduzir horizontalmente para zero. O limite de escala é definido como 100 conexões simultâneas por segundo.

Exemplo

A tcp seção define uma regra de escala 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, outra réplica é adicionada. As réplicas continuam sendo adicionadas até o valor `maxReplicas` conforme 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, outra réplica é adicionada. As réplicas continuam sendo adicionadas até o valor `maxReplicas` conforme 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 usando o 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, outra réplica é adicionada. As réplicas continuam a ser adicionadas até o valor `max-replicas`, à medida que o número de conexões simultâneas aumentar.	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

Sem suporte no portal do Azure. Use a CLI do Azure, o Azure Resource Manager ou o Bicep para configurar uma regra de escala TCP.

Personalizado

Você pode criar uma regra de dimensionamento de Aplicativos de Contêiner personalizada com base em qualquer dimensionador KEDA baseado em ScaledObject com estes padrões:

Padrões	Segundos
Intervalo de sondagem	30
Período de resfriamento	300

Para trabalhos de Aplicativos de Contêiner controlados por eventos, você pode criar 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

Este exemplo mostra como converter um dimensionador do Azure Service Bus em uma regra de escala para Container Apps, mas você pode usar o mesmo processo para qualquer outra especificação de dimensionador KEDA baseada 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 abaixo se encaixam no modelo Bicep.

Primeiro, você define o tipo e os metadados da regra de dimensionamento.

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. As regras de escala para recursos do Azure, incluindo o Armazenamento de Filas do Azure, o Azure Service Bus e os Hubs de Eventos do Azure, também suportam a identidade gerida. 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 para autenticação, você precisa criar um segredo na matriz secrets do aplicativo contêiner. O valor secreto é usado na matriz auth da regra de escala.

Os escaladores KEDA podem usar segredos em uma TriggerAuthentication referenciada 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.
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.

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 de aplicativos de contêiner podem usar a identidade gerenciada para autenticar com os serviços do Azure. O modelo Bicep a seguir passa uma identidade gerenciada baseada no sistema para autenticação em um dimensionador 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 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 esse trecho para obter um contexto de como os exemplos abaixo se encaixam no modelo do ARM.

Primeiro, você define o tipo e os metadados da regra de dimensionamento.

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 para autenticação, você precisa criar um segredo na matriz secrets do aplicativo contêiner. O valor secreto é usado 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 de aplicativos de contêiner podem usar a identidade gerenciada para autenticar com os serviços do Azure. O seguinte modelo ARM passa na identidade gerida baseada 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.

Você precisa transformar os valores de um formato YAML em um par de chave-valor a ser usado 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 faça referência a eles 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 de aplicativos de contêiner podem usar a identidade gerenciada para autenticar com os 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 utiliza para autenticar 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á para o aplicativo de contêiner no portal do Azure.
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 portal do Azure. Use a CLI do Azure ou o 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á escalado para zero e não poderá ser reiniciado.

Comportamento da escala

O comportamento da escala tem os seguintes padrões:

Parâmetro	Valor
Intervalo de sondagem	30 segundos
Período de resfriamento	300 segundos
Janela de estabilização de escala vertical	0 segundos
Janela de estabilização de redução vertical	300 segundos
Etapa de escalar verticalmente	1, 4, 100% do atual
Etapa de reduzir verticalmente	100% do atual
Algoritmo de escala	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

O intervalo de sondagem é a frequência com que as fontes de eventos são consultadas pelo KEDA. Esse valor não se aplica a regras de escala HTTP e TCP.
O período de resfriamento é o tempo que se passa após a observação do último evento antes que o aplicativo reduza para sua contagem mínima de réplicas.
A janela de estabilização de escala é quanto tempo aguardar antes de executar uma decisão de aumento de escala quando as condições de expansão forem atendidas.
A janela de estabilização da redução é o tempo de espera antes de tomar uma decisão de redução, uma vez que as condições para redução tenham sido atendidas.
Etapa de aumento de escala é a taxa em que novas instâncias são adicionadas. Começa com 1, 4, 8, 16, 32, ... até a quantidade máxima de réplicas configurada.
A etapa de redução é a taxa na qual as réplicas são removidas. Por padrão, 100% das réplicas que precisam ser desligadas são removidas.
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 de espera for igual a 0, retorna para (1).
Se o comprimento da fila de espera for > 0, dimensiona o aplicativo como 1.
Se o comprimento da fila de espera for 50, calcula desiredReplicas = ceil(50/5) = 10.
Dimensiona o aplicativo como min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
Retorna para (1).

Se o aplicativo tiver sido dimensionado como o número máximo de 20 réplicas, o dimensionamento passará pelas mesmas etapas anteriores. A redução só irá ocorrer se a condição tiver sido atendida por 300 segundos (janela de estabilização de 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.
Nenhuma cobrança é incorrida quando um aplicativo é dimensionado para zero. Para obter mais informações sobre preços, confira Cobrança nos Aplicativos de Contêiner do Azure.
Você precisa habilitar a proteção de dados para todos os aplicativos .NET nos Aplicativos de Contêiner do Azure. Consulte Implantação e dimensionamento de um aplicativo ASP.NET Core nos 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) para enviar tráfego para um dispositivo de rede, onde o tráfego pode ser inspecionado ou encaminhado por proxy a partir daí.

Próximas etapas

Gerenciar segredos

Compartilhar via

Definir regras de colocação em escala em 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 da escala

Exemplo

Considerações

Limitações conhecidas

Próximas etapas

Comentários

Recursos adicionais