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

Artigo
02/20/2024

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.

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. Confira os tipos de alteração de revisão para ver quais tipos disparam uma nova revisão.

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

Definição de escala

A escala é definida pela combinação de limites, regras e comportamento.

Os limites são 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 número máximo de réplicas configuráveis é de 300 no portal do Azure e 1.000 na CLI do Azure.
Número máximo de réplicas por revisão	10	1	O número máximo de réplicas configuráveis é de 300 no portal do Azure e 1.000 na CLI do Azure.

Para obter mais informações, consulte Cotas para os Aplicativos de Contêiner do Azure.

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

As regras de dimensionamento são implementadas como HTTP, TCP ou personalizadas.
O comportamento é a forma como as regras e limites são combinados para determinar as decisões de dimensionamento ao longo do tempo.

O comportamento do dimensionamento explica como as decisões de dimensionamento são calculadas.

Ao definir suas regras de escala, lembre-se dos 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 mais baixa com o status de "ociosas". Para mais informações, consulte Faturamento.
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

A escala é orientada por três categorias diferentes de gatilhos:

HTTP: baseia-se no número de solicitações HTTP simultâneas para a sua revisão.
TCP: baseia-se no número de conexões TCP simultâneas com a sua revisão.
Personalizadas: baseiam-se na CPU, na memória ou em fontes de dados orientadas por eventos com suporte, como, por exemplo:
- 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 são compatíveis com regras de dimensionamento 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

{
  ...
  "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 Dimensionar.
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 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 são compatíveis com regras de dimensionamento 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 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 continuarão a ser adicionadas até o valor `maxReplicas`, à medida que o número de conexões simultâneas aumentar.	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 continuarão 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 \
  --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 ou o Azure Resource Manager para configurar uma regra de dimensionamento 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 os seguintes padrões:

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

Para trabalhos de Aplicativos de Contêiner orientados por eventos, você pode criar uma regra de dimensionamento personalizada com base em qualquer dimensionador 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 fins de autenticação, os parâmetros de autenticação do dimensionador KEDA são convertidos em segredos de Aplicativos de Contêiner.

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ê vai definir 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

Um dimensionador KEDA pode dar suporte ao uso de segredos em uma TriggerAuthentication que é mencionada pela propriedade authenticationRef. Você pode mapear o objeto TriggerAuthentication para a regra de dimensionamento de Aplicativos de Contêiner.

Observação

As regras de dimensionamento dos Aplicativos de Contêiner são compatíveis apenas com referências secretas. Outros tipos de autenticação, como identidade do pod, não têm suporte.

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

Na especificação do KEDA, localize cada secretTargetRef do objeto TriggerAuthentication e seu respectivo segredo.

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 do ARM, adicione todas as entradas à matriz auth da regra de dimensionamento.

Adicione um segredo à matriz de secrets do aplicativo de contêiner que contém o valor do segredo.
Defina o valor da propriedade triggerParameter para o valor da propriedade key do TriggerAuthentication.
Defina o valor da propriedade secretRef para o nome do segredo dos Aplicativos de Contêiner.

{
  ...
  "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"
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
}

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.

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

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ê precisará 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

Um dimensionador KEDA pode ser compatível com o uso de segredos em uma TriggerAuthentication mencionada pela propriedade authenticationRef. Você pode mapear o objeto TriggerAuthentication para a regra de dimensionamento de Aplicativos de Contêiner.

Observação

As regras de dimensionamento dos Aplicativos de Contêiner são compatíveis apenas com referências secretas. Outros tipos de autenticação, como identidade do pod, não têm suporte.

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 propriedades secretTargetRef.

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"

Vá para o aplicativo de contêiner no portal do Azure.
Selecione Dimensionar.
Selecione Editar e implantar.
Selecione a guia Dimensionamento 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 Personalizada.

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 Tipo de regra personalizada, insira o valor type do dimensionador.

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

Observação

As regras de dimensionamento dos Aplicativos de Contêiner são compatíveis apenas com referências secretas. Outros tipos de autenticação, como identidade do pod, não têm suporte.

No seu aplicativo de contêiner, crie os segredos que você quer mencionar.

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 de secretTargetRef do KEDA.

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 um minReplicas ou uma regra de dimensionamento personalizada, seu aplicativo de contêiner será dimensionado como zero e não conseguirá reiniciar.

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)`

Um 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 define quanto tempo após o último evento ter sido observado o aplicativo será reduzido ao número mínimo de réplicas.
A janela de estabilização da ampliação é o tempo de espera antes de executar uma decisão de ampliação assim que as condições para a ampliação forem atendidas.
Ajanela de estabilização da redução é o tempo de espera antes de executar uma decisão de redução assim que as condições para a redução forem atendidas.
A etapa de ampliação é a frequência com 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 frequência com que 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"
      }
    }
  }
]

Começando por uma fila de espera vazia, o KEDA executa as seguintes etapas em um cenário de ampliação:

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ões para gerenciar as alocações de tráfego.
Nenhuma cobrança é incorrida quando um aplicativo é dimensionado para zero. Para saber mais 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, lembre-se de que não há suporte para colocação em escala 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.

Próximas etapas

Gerenciar segredos

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

Autenticação

Autenticação

Regra de escala padrão

Comportamento da escala

Exemplo

Considerações

Limitações conhecidas

Próximas etapas

Recursos adicionais