Partilhar via

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

  • Artigo

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

Adicionar ou editar regras de dimensionamento 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 acionam uma nova revisão, consulte Tipos de alteração de revisão.

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

Definição da escala

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

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

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

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

    As regras de escala são implementadas como HTTP, TCP (Transmission Control Protocol) ou personalizadas.

  • O comportamento é a combinação de regras e limites para determinar decisões de escala ao longo do tempo.

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

Ao definir suas regras de dimensionamento, é importante considerar os seguintes itens:

  • Você não será cobrado por taxas de uso se seu aplicativo de contêiner for dimensionado para zero.
  • As réplicas que não estão processando, mas permanecem na memória, podem ser cobradas a uma taxa "ociosa" menor. Para obter mais informações, consulte Faturamento.
  • Se quiser garantir que uma instância da revisão esteja sempre em execução, defina o número mínimo de réplicas como 1 ou superior.

Regras de escala

O dimensionamento é impulsionado por três categorias diferentes de gatilhos:

  • HTTP: Com base no número de solicitações HTTP simultâneas para sua revisão.
  • TCP: Com base no número de conexões TCP simultâneas para sua revisão.
  • Personalizado: com base na CPU, memória ou fontes de dados controladas por eventos suportadas, tais como:
    • Azure Service Bus
    • Hubs de Eventos do Azure
    • Apache Kafka
    • Redis

Se você definir mais de uma regra de escala, o aplicativo contêiner começará a ser dimensionado assim que a primeira condição de qualquer regra for atendida.

HTTP

Com uma regra de dimensionamento HTTP, você tem controle sobre o limite de solicitações HTTP simultâneas que determina como a revisão do aplicativo 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 suportam regras de dimensionamento HTTP.

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

Exemplo

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

Propriedade Scale Description Default value Valor mínimo Valor máximo
concurrentRequests Quando o número de solicitações HTTP excede esse valor, outra réplica é adicionada. As réplicas continuam a ser adicionadas ao pool até o maxReplicas montante. 10 1 n/d 
{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Nota

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

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

Parâmetro CLI Description Default value Valor mínimo Valor máximo
--scale-rule-http-concurrency Quando o número de solicitações HTTP simultâneas excede esse valor, outra réplica é adicionada. As réplicas continuam a ser adicionadas ao pool até o max-replicas montante. 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

  1. Vá para seu aplicativo de contêiner no portal do Azure

  2. Selecione Escala.

  3. Selecione Editar e implantar.

  4. Selecione a guia Escala .

  5. Selecione o intervalo mínimo e máximo de réplicas.

    Captura de ecrã do controlo de deslize de escala das Aplicações de Contentor do Azure.

  6. Selecione Adicionar.

  7. Na caixa Nome da regra , insira um nome de regra.

  8. Na lista suspensa Tipo , selecione Dimensionamento HTTP.

  9. 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 dimensionamento TCP, você tem controle sobre o limite de conexões TCP simultâneas que determina como seu aplicativo é dimensionado. 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 suportam regras de dimensionamento TCP.

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

Exemplo

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

Propriedade Scale Description Default value 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 à quantidade à medida que maxReplicas 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 --scale-rule-tcp-concurrency parâmetro nos create comandos or update .

Parâmetro CLI Description Default value 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 à quantidade à medida que max-replicas 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

Não há suporte no portal do Azure. Use a CLI do Azure ou o Azure Resource Manager para configurar uma regra de escala TCP.

Personalizado

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

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

Para trabalhos de Aplicativos de Contêiner orientados a 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 escala personalizada.

Exemplo

Este exemplo mostra como converter um escalador do Barramento de Serviço do Azure em uma regra de escala de Aplicativos de Contêiner, mas você usa o mesmo processo para qualquer outra especificação de escalador KEDA baseada 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 como converter um escalador KEDA em uma regra de escala do Aplicativo de Contêiner. Este trecho é um trecho de um modelo ARM para mostrar onde cada seção se encaixa no contexto do modelo geral.

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "configuration": {
        ...
        "secrets": [
          {
            "name": "<NAME>",
            "value": "<VALUE>"
          }
        ]
      },
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [
            {
              "name": "<RULE_NAME>",
              "custom": {
                "metadata": {
                  ...
                },
                "auth": [
                  {
                    "secretRef": "<NAME>",
                    "triggerParameter": "<PARAMETER>"
                  }
                ]
              }
            }
          ]
        }
      }
    }
  }
}

Consulte este trecho para obter o contexto de como os exemplos abaixo se encaixam no modelo ARM.

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

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

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

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

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

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

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

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

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

Autenticação

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

Use segredos

Para usar segredos para autenticação, você precisa criar um segredo na matriz do aplicativo secrets contêiner. O valor secreto auth é usado na matriz da regra de escala.

Os escaladores KEDA podem usar segredos em um TriggerAuthentication que é referenciado authenticationRef pela propriedade. Você pode mapear o objeto TriggerAuthentication para a regra de escala Container Apps.

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

  2. TriggerAuthentication No objeto, encontre cada secretTargetRef um 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

  3. No modelo ARM, para cada segredo:

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

    2. Adicione uma entrada à auth matriz da regra de escala.

      1. Defina o triggerParameter valor da propriedade como o valor da secretTargetRefpropriedade do parameter .

      2. Defina o secretRef valor da propriedade como o nome da secretTargetRefpropriedade do 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 escaladores suportam metadados com o sufixo FromEnv para fazer referência a um valor em uma variável de ambiente. Container Apps examina o primeiro contêiner listado no modelo ARM para a variável de ambiente.

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

Usando identidade gerenciada

As regras de escala de Aplicativos de Contêiner podem usar a identidade gerenciada para autenticar com os serviços do Azure. O modelo ARM a seguir passa a identidade gerenciada baseada no sistema para autenticar para um escalador de fila 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 como usar a identidade gerenciada com regras de escala, consulte Identidade gerenciada.

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

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

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

    az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
  --scale-rule-name azure-servicebus-queue-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata "queueName=my-queue" \
                        "namespace=service-bus-namespace" \
                        "messageCount=5" \
  --scale-rule-auth "connection=connection-string-secret"

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

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

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

    Você precisa transformar os valores de um formato YAML em um par chave/valor para uso na linha de comando. Separe cada par chave/valor com um espaço.

    az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
  --scale-rule-name azure-servicebus-queue-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata "queueName=my-queue" \
                        "namespace=service-bus-namespace" \
                        "messageCount=5" \
  --scale-rule-auth "connection=connection-string-secret"

Autenticação

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

Use 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 suporta segredos em um TriggerAuthentication que a authenticationRef propriedade usa como referência. Você pode mapear o TriggerAuthentication objeto para a regra de escala de Aplicativos de Contêiner.

  1. Encontre o TriggerAuthentication objeto referenciado pela especificação KEDA ScaledObject . Identifique cada secretTargetRef um dos TriggerAuthentication objetos.

    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

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

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

    1. Crie uma entrada secreta com o --secrets parâmetro. Se houver vários segredos, separe-os com um espaço.

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

    az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --secrets "connection-string-secret=<SERVICE_BUS_CONNECTION_STRING>" \
  --scale-rule-name azure-servicebus-queue-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata "queueName=my-queue" \
                        "namespace=service-bus-namespace" \
                        "messageCount=5" \
  --scale-rule-auth "connection=connection-string-secret"

Usando identidade gerenciada

As regras de escala 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 o usa para autenticar para uma escala 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 espaços reservados por seus valores.

  1. Vá para seu aplicativo de contêiner no portal do Azure.

  2. Selecione Escala.

  3. Selecione Editar e implantar.

  4. Selecione a guia Escala e réplicas .

  5. Selecione o intervalo mínimo e máximo de réplicas.

    Captura de ecrã do controlo de deslize de escala das Aplicações de Contentor do Azure.

  6. Selecione Adicionar.

  7. Na caixa Nome da regra , insira um nome de regra.

  8. Na lista suspensa Tipo, selecione Personalizado.

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

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

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

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

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

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

Autenticação

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

Use segredos

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

  2. Encontre o TriggerAuthentication objeto referenciado pela especificação KEDA ScaledObject . Identifique cada secretTargetRef um dos TriggerAuthentication objetos.

    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

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

Usando identidade gerenciada

A autenticação de identidade gerenciada não é suportada 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.

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

Importante

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

Comportamento da escala

O comportamento de dimensionamento tem os seguintes padrões:

Parâmetro Value
Intervalo de consulta 30 segundos
Período de reflexão 300 segundos
Aumentar a janela de estabilização 0 segundos
Reduzir a janela de estabilização 300 segundos
Escalonar a etapa 1, 4, 100% da corrente
Reduzir etapa 100% da corrente
Algoritmo de dimensionamento 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 após o último evento ter sido observado antes que o aplicativo diminua para sua contagem mínima de réplicas.
  • A janela de estabilização de escala é quanto tempo esperar antes de executar uma decisão de aumento de escala uma vez que as condições de aumento de escala foram atendidas.
  • A janela de estabilização de redução de escala é quanto tempo esperar antes de executar uma decisão de redução de escala depois que as condições de redução de escala forem atendidas.
  • A etapa de escalonamento é a taxa em que novas instâncias são adicionadas. Começa com 1, 4, 8, 16, 32, ... até a contagem máxima de réplicas configurada.
  • A etapa de redução de escala é a taxa na qual as réplicas são removidas. Por padrão, 100% das réplicas que precisam ser encerradas são removidas.
  • Algoritmo de dimensionamento é a fórmula usada para calcular o número desejado atual de réplicas.

Exemplo

Para a seguinte regra de escala:

"minReplicas": 0,
"maxReplicas": 20,
"rules": [
  {
    "name": "azure-servicebus-queue-rule",
    "custom": {
      "type": "azure-servicebus",
      "metadata": {
        "queueName": "my-queue",
        "namespace": "service-bus-namespace",
        "messageCount": "5"
      }
    }
  }
]

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

  1. Verifique my-queue a cada 30 segundos.
  2. Se o comprimento da fila for igual a 0, volte para (1).
  3. Se o comprimento da fila for > 0, dimensione o aplicativo para 1.
  4. Se o comprimento da fila for 50, calcule desiredReplicas = ceil(50/5) = 10.
  5. Dimensionar o aplicativo para min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
  6. Volte para (1).

Se o aplicativo foi dimensionado para a contagem máxima de réplicas de 20, o dimensionamento passa pelas mesmas etapas anteriores. A redução de escala só acontece se a condição foi satisfeita por 300 segundos (janela de estabilização de redução de escala). Quando o comprimento da fila é 0, o KEDA aguarda por 300 segundos (período de resfriamento) antes de dimensionar o aplicativo para 0.

Considerações

  • No modo "várias revisões", adicionar um novo gatilho de escala cria uma nova revisão do seu aplicativo, mas a revisão antiga permanece disponível com as regras de escala antigas. Use a página Gerenciamento de revisão para gerenciar alocações de tráfego.

  • Nenhuma cobrança de uso é incorrida quando um aplicativo é dimensionado para zero. Para obter mais informações sobre preços, consulte Cobrança em 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 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 dimensionamento vertical.

  • As quantidades de réplicas são um valor-alvo, não uma garantia.

  • Se você estiver usando atores de Dapr para gerenciar estados, lembre-se de que o dimensionamento para zero não é suportado. O Dapr usa atores virtuais para gerenciar chamadas assíncronas, o que significa que sua representação na memória não está vinculada à sua identidade ou tempo de vida.

Próximos passos

Gerir segredos