Partilhar via

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

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.

Para dar suporte a esse comportamento de dimensionamento, os Aplicativos de Contêiner do Azure são alimentados pelo KEDA (Kubernetes Event-driven Autoscaling). KEDA oferece suporte ao dimensionamento com base numa variedade de métricas, como solicitações HTTP, mensagens de fila, carga de CPU e memória, e também em fontes de eventos como o 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 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 Valor padrão 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 utilização se a sua aplicação de contêiner for dimensionada para zero.
  • As réplicas que não estão em processamento, mas permanecem na memória, podem ser cobradas a uma taxa menor por estarem "em espera". Para obter mais informações, consulte Cobrança.
  • 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

Três categorias de gatilhos determinam o modo como ocorre o dimensionamento.

  • 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 em métricas personalizadas como:
    • CPU
    • Memória
    • Fontes de dados orientadas a eventos suportadas:
      • 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.

Nota

Se você estiver usando Funções em Aplicativos de Contêiner , as regras de escala serão configuradas automaticamente com base nos gatilhos e associações de funções. Como resultado, o botão "Adicionar regras de escala" no portal do Azure será desabilitado para esses aplicativos. A configuração manual da regra de escala não é necessária ou suportada neste cenário.

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. As tarefas de Aplicações de Contentor não suportam regras de escalonamento HTTP.

No exemplo a seguir, a versão pode ser ampliada para até cinco réplicas e pode ser reduzida 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 Descrição Valor padrão 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é ao maxReplicas montante. 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'
              }
            }
          }
        ]
      }
    }
  }
}

Nota

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

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

Propriedade Scale Descrição Valor padrão 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é ao 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 parâmetro --scale-rule-http-concurrency nos comandos create ou update.

Parâmetro 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, outra réplica é adicionada. As réplicas continuam a ser adicionadas ao pool até ao 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 deslizante de escala das Azure Container Apps.

  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. Tarefas de Container Apps não suportam regras de dimensionamento TCP.

No exemplo a seguir, a revisão da versão do aplicativo de contêiner escala para até cinco réplicas e pode escalar 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 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 à maxReplicas quantidade à medida que o número de conexões simultâneas aumenta. 10 1 n/d 
resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'tcp-rule'
            http: {
              metadata: {
                concurrentConnections: '100'
              }
            }
          }
        ]
      }
    }
  }
}

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

Propriedade Scale 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 à maxReplicas quantidade à medida que o número de conexões simultâneas aumenta. 10 1 n/d 
{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "tcp-rule",
            "tcp": {
              "metadata": {
                "concurrentConnections": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Defina uma regra de escala TCP usando o parâmetro --scale-rule-tcp-concurrency nos comandos create ou update.

Parâmetro 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. Continuam a ser adicionadas réplicas até à quantidade de max-replicas à medida que o número de conexões simultâneas aumenta. 10 1 n/d 
az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --transport tcp \
  --ingress <external/internal> \
  --target-port <CONTAINER_TARGET_PORT> \
  --scale-rule-name azure-tcp-rule \
  --scale-rule-type tcp \
  --scale-rule-tcp-concurrency 100

Não há suporte no portal do Azure. Use a CLI do Azure, o Gerenciador de Recursos do Azure ou o Bicep para configurar uma regra de escala TCP.

Personalizado

Você pode criar uma regra de escalonamento personalizada de Aplicativos de Contêiner baseada em qualquer escalador ScaledObject baseado em KEDA com estas predefinições:

Padrões Segundos
Intervalo de consulta 30
Período de reflexão 300

Nota

O período de espera só entra em vigor quando se reduz a escala da réplica final para 0. O período de resfriamento não afeta o dimensionamento, pois quaisquer outras réplicas são removidas.

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 Azure Service Bus em uma regra de escala de Apps de Contêiner, mas usa o mesmo processo para qualquer outra especificação do escalador KEDA baseada em ScaledObject.

Para autenticação, os parâmetros de autenticação do escalonador KEDA utilizam segredos de Aplicativos de Contêiner ou identidade gerida.

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 Bicep para mostrar onde cada seção se encaixa no contexto do modelo geral.

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 contextualizar como os exemplos abaixo se encaixam no modelo Bicep.

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

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

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

  2. No modelo Bicep, 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 valores metadata.

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

  4. 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 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.

Utilize 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 referenciado pela propriedade authenticationRef. Você pode mapear o objeto TriggerAuthentication à regra de escala do Container Apps.

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

  2. No objeto TriggerAuthentication, encontre cada secretTargetRef e o 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 Bicep, 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 valor da propriedade triggerParameter como o valor da propriedade secretTargetRef do parameter.

      2. Defina o valor da propriedade secretRef para o nome da propriedade secretTargetRef de key.

        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 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 Bicep a seguir passa a identidade gerenciada baseada no sistema para autenticar para um escalador 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 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 valor type.

    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 valores metadata.

    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.

Utilize 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 referenciado pela propriedade authenticationRef. Você pode mapear o objeto TriggerAuthentication à regra de escala do Container Apps.

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

  2. No objeto TriggerAuthentication, encontre cada secretTargetRef e o 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 valor da propriedade triggerParameter como o valor da propriedade secretTargetRef do parameter.

      2. Defina o valor da propriedade secretRef para o nome da propriedade secretTargetRef de 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 seguinte modelo ARM utiliza a identidade gerida baseada no sistema para se autenticar a 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.

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

    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 valores metadata.

    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.

Utilize 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 do TriggerAuthentication objeto.

    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.

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>

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

  2. Selecione Escala.

  3. Selecione Editar e implantar.

  4. Selecione a aba Escala e Réplica.

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

    Captura de ecrã do controlo deslizante de escala das Azure Container Apps.

  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 valor type.

    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 type scaler.

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

    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.

Utilize 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 do TriggerAuthentication objeto.

    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 dimensionamento tem os seguintes comportamentos:

Comportamento Valor
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
Aumentar a escala da etapa 1, 4, 8, 16, 32, ... até contagem máxima de réplicas configurada
Reduzir etapa 100 réplicas% que precisam ser desligadas
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.
  • Período de arrefecimento representa o tempo que decorre desde a observação do último evento até que a aplicação reduza para a 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 dimensionamento é quantas réplicas são adicionadas à medida que seu aplicativo de contêiner é dimensionado. Ele começa em 1, depois aumenta para 4, 8, 16, 32 e assim por diante, até a contagem máxima de réplicas configurada.
  • A etapa de redução de escala é quantas réplicas são removidas à medida que seu aplicativo de contêiner é dimensionado. 100% de réplicas que precisam ser desligadas 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 tamanho da fila for > 0, dimensione a aplicação 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. Utilize a página de gestão de revisões para gerenciar alocações de tráfego.

  • Não há encargos de uso quando uma aplicação é dimensionada para zero. Para obter mais informações sobre preços, consulte Cobrança em Aplicações de Contentores 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.

  • Não é suportada a alteração de proxies KEDA por meio das definições de proxies. Considere usar perfis de carga de trabalho com um gateway NAT ou Rota Definida pelo Utilizador (UDR) para enviar tráfego para um dispositivo de rede, onde o tráfego pode ser inspecionado ou passar por proxy a partir daí.

Próximos passos

Gerir segredos

  • Last updated on