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

Artigo
07/27/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. Para aprender quais tipos de alterações disparam uma nova revisão, consulte os tipos de alterações de 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

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

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

Limite de escala	Valor padrão	Valor mínimo	Valor máximo
Número mínimo de réplicas por revisão	0	0	O 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 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 (Protocolo de Controle de Transmissão) ou personalizadas.
O comportamento é a combinação de regras e limites para determinar decisões de escala ao longo do tempo.

O comportamento do dimensionamento explica como as decisões de dimensionamento 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 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 continuam 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 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 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 autenticação, os parâmetros de autenticação do escalonador KEDA usam segredos de 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. 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

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 um TriggerAuthentication que é 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 ARM, para cada segredo:

Adicione um secreto à matriz secrets do aplicativo contêiner contendo 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 parameter do secretTargetRef.
2. Defina o valor da propriedade secretRef como o nome da propriedade secretTargetRef key.

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

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.

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.

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

Para saber mais sobre a utilização de identidade gerida com regras de escala, veja Identidade gerida.

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 escalonador KEDA suporta segredos em um 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 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"

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.

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>

Substitua os espaços reservados pelos seus valores.

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

Usar segredos

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.

Usar a identidade gerenciada

A autenticação de identidade gerenciada não tem suporte no portal do Azure. Use o CLI do Azure ou Azure Resource Manager para autenticar usando 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 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"
      }
    }
  }
]

À 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õ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

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

Regra de escala padrão

Comportamento da escala

Exemplo

Considerações

Limitações conhecidas

Próximas etapas

Comentários

Recursos adicionais