Настройка правил масштабирования в Контейнеры приложений Azure

Контейнеры приложений Azure управляет автоматическим горизонтальным масштабированием с помощью набора декларативных правил масштабирования. По мере масштабирования редакции приложения-контейнера платформа создает новые экземпляры редакции по запросу. Эти экземпляры называются репликами.

Для поддержки этого поведения масштабирования Контейнеры приложений Azure использует KEDA (автомасштабирование на основе событий Kubernetes). KEDA поддерживает масштабирование для различных метрик, таких как HTTP-запросы, сообщения очереди, загрузка ЦП и памяти, а также источники событий, такие как Служебная шина Azure, Центры событий Azure, Apache Kafka и Redis. Дополнительные сведения см. в разделе "Масштабировщики" в документации ПО KEDA.

При добавлении или изменении правил масштабирования создается новая редакция приложения-контейнера. Ревизия — это неизменяемый снимок контейнерного приложения. Сведения о том, какие типы изменений активируют новую редакцию, см. в разделе "Типы изменений редакции".

Задания контейнерных приложений на основе событий используют правила масштабирования для активации выполнения на основе событий.

Определение масштабирования

Масштабирование — это сочетание ограничений, правил и поведения.

  • Ограничения определяют минимальное и максимально возможное количество реплик на каждую редакцию по мере масштабирования приложения-контейнера.

    Предел масштабирования Значение по умолчанию Минимальное значение Максимальное значение
    Минимальное количество реплик на версию 0 0 Максимально можно настроить 1000 реплик.
    Максимальное число реплик на одну ревизию 10 1 Максимально можно настроить 1000 реплик.

  • Правила — это критерии, используемые приложениями-контейнерами, чтобы решить, когда следует добавлять или удалять реплики.

    Правила масштабирования реализуются как HTTP, TCP (протокол управления передачей) или пользовательские.

  • Поведение — это сочетание правил и ограничений для определения решений масштабирования с течением времени.

    Поведение масштабирования объясняет, как принимаются решения о масштабировании.

Определяя правила масштабирования, рассмотрим следующие элементы:

  • Плата за использование не взимается, если контейнерное приложение масштабируется до нуля.
  • Реплики, которые не выполняют обработку, но остаются в памяти, могут тарифицироваться по более низкому тарифу за простой. Дополнительные сведения см. в разделе о выставлении счетов.
  • Если вы хотите убедиться, что экземпляр ревизии всегда запущен, установите значение для минимального количества реплик — 1 или больше.
  • Во время обновлений или обслуживания платформы может временно отображаться больше реплик, чем ожидалось. Container Apps обеспечивает, что рабочая нагрузка не затрагивается предварительным прогревом новых реплик перед переключением трафика, аналогично поведению Kubernetes по умолчанию. Дополнительные реплики удаляются автоматически после завершения операции.

Правила масштабирования

Три категории триггеров определяют, как выполняется масштабирование:

  • HTTP: на основе количества параллельных HTTP-запросов к вашей версии.
  • TCP: на основе количества одновременных TCP-подключений к ревизии.
  • Custom: на основе пользовательских метрик, таких как:
    • ЦП
    • Память
    • Поддерживаемые источники данных на основе событий:
      • Служебная шина Azure
      • Центры событий Azure
      • Apache Kafka
      • Редис

Если вы определяете несколько правил масштабирования, приложение-контейнер начинает масштабироваться после выполнения первого условия любого правила.

Примечание.

Если вы используете функции в приложениях контейнеров, интерфейс по умолчанию автоматически настраивает правила масштабирования на основе триггеров функций и привязок. Портал Azure отключает кнопку Добавить правила масштабирования для этих приложений. Если вам нужны определяемые клиентом правила, используйте allowScalingRuleOverride, как описано в разделе Переопределение автоматически созданных правил масштабирования KEDA для Функции Azure в Container Apps.

HTTP

При использовании правила масштабирования HTTP вы управляете пороговым значением параллельных HTTP-запросов, определяющих масштабирование редакции приложения-контейнера. Каждые 15 секунд число одновременных запросов вычисляется как количество запросов за последние 15 секунд, разделенных на 15 секунд. Задания контейнерных приложений не поддерживают правила масштабирования HTTP.

В следующем примере изменение позволяет масштабироваться до пяти реплик и может уменьшаться до нуля. Свойство масштабирования имеет значение 100 одновременных запросов в секунду.

Пример

В http разделе определяется правило масштабирования HTTP.

Свойство масштаба Описание Значение по умолчанию Минимальное значение Максимальное значение
concurrentRequests Когда число HTTP-запросов превышает это значение, приложение добавляет другую реплику. Приложение продолжает добавлять реплики до значения maxReplicas. 10 1 Недоступно 
resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'http-rule'
            http: {
              metadata: {
                concurrentRequests: '100'
              }
            }
          }
        ]
      }
    }
  }
}

Примечание.

properties.configuration.activeRevisionsMode Задайте свойству приложения-контейнера значение single при использовании правил масштабирования событий, отличных от HTTP.

В http разделе определяется правило масштабирования HTTP.

Свойство масштаба Описание Значение по умолчанию Минимальное значение Максимальное значение
concurrentRequests Когда число HTTP-запросов превышает это значение, приложение добавляет другую реплику. Приложение продолжает добавлять реплики до количества maxReplicas. 10 1 Недоступно 
{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Примечание.

properties.configuration.activeRevisionsMode Задайте свойству приложения-контейнера значение single при использовании правил масштабирования событий, отличных от HTTP.

Определите правило масштабирования HTTP с помощью --scale-rule-http-concurrency параметра в create командах или update командах.

Параметр CLI Описание Значение по умолчанию Минимальное значение Максимальное значение
--scale-rule-http-concurrency Если число одновременных HTTP-запросов превышает это значение, приложение добавляет другую реплику. Приложение продолжает добавлять реплики до количества max-replicas. 10 1 Недоступно 
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. Перейдите в приложение-контейнер в Azure portal.

  2. Выберите "Масштаб".

  3. Выберите Изменить и развернуть.

  4. Выберите вкладку "Масштаб ".

  5. Выберите минимальный и максимальный диапазон копий.

    Скриншот ползунка диапазона масштабирования Контейнеры приложений Azure.

  6. Выберите Добавить.

  7. В поле "Имя правила" введите имя правила.

  8. В раскрывающемся списке Тип выберите HTTP Масштабирование.

  9. В поле "Одновременные запросы" введите число одновременных запросов, которые требуется для приложения контейнера.

Протокол tcp

При использовании правила масштабирования TCP вы управляете пороговым значением параллельных TCP-подключений, определяющих масштабирование приложения. Каждые 15 секунд система вычисляет количество одновременных подключений в качестве количества подключений за последние 15 секунд, разделенных на 15 секунд. Задания контейнерных приложений не поддерживают правила масштабирования TCP.

В следующем примере редакция приложения-контейнера масштабируется максимум до пяти реплик и может уменьшаться до нуля. Порог масштабирования имеет значение 100 одновременных подключений в секунду.

Пример

В tcp разделе определяется правило масштабирования TCP.

Свойство масштаба Описание Значение по умолчанию Минимальное значение Максимальное значение
concurrentConnections Если число одновременных TCP-подключений превышает это значение, система добавляет другую реплику. Система продолжает добавлять реплики вплоть до значения maxReplicas по мере увеличения числа одновременных подключений. 10 1 Недоступно 
resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'tcp-rule'
            http: {
              metadata: {
                concurrentConnections: '100'
              }
            }
          }
        ]
      }
    }
  }
}

В tcp разделе определяется правило масштабирования TCP.

Свойство масштаба Описание Значение по умолчанию Минимальное значение Максимальное значение
concurrentConnections Если число одновременных TCP-подключений превышает это значение, система добавляет другую реплику. Система продолжает добавлять реплики вплоть до maxReplicas количества по мере увеличения числа одновременных подключений. 10 1 Недоступно 
{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "tcp-rule",
            "tcp": {
              "metadata": {
                "concurrentConnections": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Определите правило масштабирования TCP с помощью --scale-rule-tcp-concurrency параметра в create командах или update командах.

Параметр CLI Описание Значение по умолчанию Минимальное значение Максимальное значение
--scale-rule-tcp-concurrency Если число одновременных TCP-подключений превышает это значение, система добавляет другую реплику. Система продолжает добавлять реплики по мере увеличения числа одновременных подключений, пока их число не достигнет max-replicas. 10 1 Недоступно 
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

Портал Azure не поддерживает эту функцию. Используйте Azure CLI, Azure Resource Manager или Bicep для настройки правила масштабирования TCP.

Пользовательское

Создайте пользовательское правило масштабирования для Container Apps на основе любого ScaledObject-основанного масштабировщика KEDA, используя следующие значения по умолчанию:

Значение по умолчанию секунды
Интервал опроса 30
Период охлаждения 300

Примечание.

Период охлаждения действует только при масштабировании с конечной реплики до 0. Период охлаждения не влияет на масштабирование, так как удаляются другие реплики.

Для заданий Container Apps, управляемых событиями, создайте пользовательское правило автомасштабирования на основе любых средств масштабирования KEDA на основе ScaledJob.

В следующем примере показано, как создать пользовательское правило масштабирования.

Пример

В этом примере показано, как преобразовать масштабируемый элемент Служебная шина Azure scaler в правило масштабирования для контейнерных приложений, но вы можете использовать тот же процесс для любой другой спецификации ScaledObject, основанной на KEDA scaler.

Для проверки подлинности параметры аутентификации KEDA scaler принимают либо секреты контейнерных приложений, либо управляемое удостоверение.

В следующей процедуре показано, как преобразовать масштабировщик KEDA в правило масштабирования приложения-контейнера. Этот фрагмент является частью шаблона Bicep и показывает, как каждый раздел входит в контекст общего шаблона.

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>'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Ознакомьтесь с этим фрагментом, чтобы понять, как приведённые ниже примеры вписываются в шаблон Bicep.

Сначала определите тип и метаданные правила масштабирования.

  1. В спецификации масштабировщика KEDA найдите type значение.

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

  2. В шаблоне Bicep введите значение type масштабировщика в свойство custom.type правила масштабирования.

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

  3. В спецификации масштабировщика KEDA найдите значения metadata.

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

  4. В шаблоне Bicep добавьте все значения метаданных в секцию custom.metadata правила масштабирования.

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

Проверка подлинности

Правила масштабирования для приложений-контейнеров поддерживают проверку подлинности на основе секретов. Правила масштабирования для ресурсов Azure, включая Хранилище очередей Azure, Служебная шина Azure и Центры событий Azure, также поддерживают управляемое удостоверение. По возможности используйте аутентификацию с управляемыми удостоверениями, чтобы избежать хранения секретов в приложении.

Использование секретов

Чтобы использовать секреты для проверки подлинности, создайте секрет в массиве приложения-контейнера secrets . Используйте секретное значение в массиве auth правила масштабирования.

Масштабировщики KEDA могут использовать секреты из TriggerAuthentication, на который ссылается свойство authenticationRef. Объект TriggerAuthentication можно сопоставить с правилом масштабирования Container Apps.

  1. TriggerAuthentication Найдите объект, на который ссылается спецификация KEDAScaledObject.

  2. В объекте TriggerAuthentication найдите каждый secretTargetRef и связанный с ним секрет.

    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. В шаблоне Bicep для каждого отдельного секрета:

    1. Добавьте секрет в массив приложения secrets контейнера, содержащий имя и значение секрета.

    2. Добавьте запись в массив auth правила масштабирования.

      1. Установите значение свойства triggerParameter в значение свойства secretTargetRef объекта parameter.

      2. Установите значение свойства secretRef на имя свойства secretTargetRef элемента 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'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

    Некоторые масштабировщики поддерживают метаданные с суффиксом FromEnv для ссылки на значение в переменной среды. Приложения-контейнеры рассматривают первый контейнер, указанный в шаблоне ARM для переменной среды.

    Дополнительные сведения о безопасности см. в разделе "Рекомендации".

Использование управляемого удостоверения

Правила масштабирования контейнерных приложений могут использовать управляемое удостоверение для аутентификации в службах Azure. Следующий шаблон Bicep передает управляемое удостоверение на основе системы для аутентификации в масштабировщике очередей Azure.

Перед использованием следующего кода замените заполнители, окруженные вашими значениями <> .

scale: {
  minReplicas: 0
  maxReplicas: 4
  rules: [
    {
      name: 'azure-queue'
      custom: {
        type: 'azure-queue'
        metadata: {
          accountName: '<ACCOUNT_NAME>'
          queueName: '<QUEUE_NAME>'
          queueLength: '1'
        },
        identity: 'system'
      }
    }
  ]
}

Дополнительные сведения об использовании управляемого удостоверения с правилами масштабирования см. в разделе "Управляемое удостоверение".

В следующей процедуре показано, как преобразовать масштабировщик KEDA в правило масштабирования приложения-контейнера. Этот фрагмент является фрагментом шаблона ARM, чтобы показать, где каждый раздел подходит в контексте общего шаблона.

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

Просмотрите этот фрагмент, чтобы понять, как приведенные ниже примеры вписываются в шаблон ARM.

Сначала определите тип и метаданные правила масштабирования.

  1. В спецификации масштабировщика KEDA найдите type значение.

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

  2. В шаблоне ARM введите значение масштабировщика type в custom.type свойство правила масштабирования.

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

  3. В спецификации масштабировщика KEDA найдите значения metadata.

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

  4. В шаблоне ARM добавьте все значения метаданных в секцию custom.metadata правила масштабирования.

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

Проверка подлинности

Правила масштабирования для приложений-контейнеров поддерживают проверку подлинности на основе секретов. Правила масштабирования для ресурсов Azure, включая Хранилище очередей Azure, Служебная шина Azure и Центры событий Azure, также поддерживают управляемое удостоверение. По возможности используйте аутентификацию с управляемыми удостоверениями, чтобы избежать хранения секретов в приложении.

Использование секретов

Чтобы использовать секреты для проверки подлинности, создайте секрет в массиве приложения-контейнера secrets . Используйте секретное значение в массиве auth правила масштабирования.

Масштабировщики KEDA могут использовать секреты в TriggerAuthentication, на который ссылается свойство authenticationRef. Объект TriggerAuthentication можно сопоставить с правилом масштабирования Container Apps.

  1. TriggerAuthentication Найдите объект, на который ссылается спецификация KEDAScaledObject.

  2. В объекте TriggerAuthentication найдите каждый secretTargetRef и связанный с ним секрет.

    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. В шаблоне ARM для каждого секрета:

    1. Добавьте секрет в массив приложения secrets контейнера, содержащий имя и значение секрета.

    2. Добавьте запись в массив auth правила масштабирования.

      1. Установите значение свойства triggerParameter в значение свойства secretTargetRef объекта parameter.

      2. Установите значение свойства secretRef на имя свойства 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"         ⬅️
                  }                                          ⬅️
                ]
              }
            }
          ]
        }
      }
    }
  }
}

    Некоторые масштабировщики поддерживают метаданные с суффиксом FromEnv для ссылки на значение в переменной среды. Приложения-контейнеры рассматривают первый контейнер, указанный в шаблоне ARM для переменной среды.

    Дополнительные сведения о безопасности см. в разделе "Рекомендации".

Использование управляемого удостоверения

Правила масштабирования контейнерных приложений могут использовать управляемое удостоверение для аутентификации в службах Azure. Следующий шаблон ARM передаёт управляемое удостоверение, назначенное системой, для аутентификации масштабировщика очереди Azure.

Перед использованием следующего кода замените заполнители, окруженные вашими значениями <> .

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

Дополнительные сведения об использовании управляемого удостоверения с правилами масштабирования см. в разделе "Управляемое удостоверение".

  1. В спецификации масштабировщика KEDA найдите type значение.

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

  2. В команде CLI задайте --scale-rule-type параметр значению спецификации 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. В спецификации масштабировщика KEDA найдите значения metadata.

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

  4. В команде CLI задайте --scale-rule-metadata для параметра значения метаданных.

    Преобразуйте значения из формата YAML в пару "ключ-значение" для использования в командной строке. Разделите каждую пару "ключ-значение" с пробелом.

    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"

Проверка подлинности

Правила масштабирования для приложений-контейнеров поддерживают проверку подлинности на основе секретов. Правила масштабирования для ресурсов Azure, включая Хранилище очередей Azure, Служебная шина Azure и Центры событий Azure, также поддерживают управляемое удостоверение. По возможности используйте аутентификацию с управляемыми удостоверениями, чтобы избежать хранения секретов в приложении.

Использование секретов

Чтобы настроить аутентификацию на основе секретов для правила масштабирования в Container Apps, настройте секреты в приложении Container Apps и укажите ссылку на них в правиле масштабирования.

Масштабировщик KEDA поддерживает секреты в триггерной аутентификации, которую свойство authenticationRef использует для ссылки. Можно сопоставить объект TriggerAuthentication с правилом масштабирования контейнерных приложений.

  1. TriggerAuthentication Найдите объект, на который ссылается спецификация KEDAScaledObject. Определите каждый secretTargetRefTriggerAuthentication объект.

    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. В приложении-контейнере создайте секреты , соответствующие свойствам secretTargetRef .

  3. В команде CLI задайте параметры для каждой secretTargetRef записи.

    1. Создайте секретную запись с параметром --secrets. Если существует несколько секретов, разделите их пробелом.

    2. Создайте запись аутентификации с параметром --scale-rule-auth. Если есть несколько записей, разделите их пробелом.

    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"                ⬅️

Использование управляемого удостоверения

Правила масштабирования контейнерных приложений могут использовать управляемое удостоверение для аутентификации в службах Azure. Следующая команда создает приложение-контейнер с управляемым удостоверением, назначаемое пользователем, и использует его для проверки подлинности для масштабировщика очередей 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>

  1. Перейдите в приложение-контейнер в Azure portal.

  2. Выберите "Масштаб".

  3. Выберите Изменить и развернуть.

  4. Перейдите на вкладку "Масштаб и реплики ".

  5. Выберите минимальный и максимальный диапазон копий.

    Скриншот ползунка диапазона масштабирования Контейнеры приложений Azure.

  6. Выберите Добавить.

  7. В поле "Имя правила" введите имя правила.

  8. В раскрывающемся списке "Тип" выберите "Настраиваемый".

  9. В спецификации масштабировщика KEDA найдите type значение.

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

  10. В поле "Настраиваемый тип правила" введите значение масштабировщика type .

  11. В спецификации масштабировщика KEDA найдите значения metadata.

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

  12. На портале найдите раздел метаданных и нажмите кнопку "Добавить". Введите имя и значение для каждого элемента в разделе метаданных спецификации KEDA ScaledObject .

Проверка подлинности

Правила масштабирования для приложений-контейнеров поддерживают проверку подлинности на основе секретов. Правила масштабирования для ресурсов Azure, включая Хранилище очередей Azure, Служебная шина Azure и Центры событий Azure, также поддерживают управляемое удостоверение. По возможности используйте аутентификацию с управляемыми удостоверениями, чтобы избежать хранения секретов в приложении.

Использование секретов

  1. В приложении-контейнере создайте секреты , на которые вы хотите ссылаться.

  2. TriggerAuthentication Найдите объект, на который ссылается спецификация KEDAScaledObject. Определите каждый secretTargetRefTriggerAuthentication объект.

    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. В разделе "Проверка подлинности" выберите "Добавить", чтобы создать запись для каждого параметра KEDAsecretTargetRef.

Использование управляемого удостоверения

Проверка подлинности управляемого удостоверения не поддерживается на портале Azure. Используйте Azure CLI или Azure Resource Manager для проверки подлинности с помощью управляемого удостоверения.

Правило масштабирования по умолчанию

Если вы не создаете правило масштабирования, правило масштабирования по умолчанию применяется к приложению контейнера.

Триггер Минимум реплик Максимальное количество копий
HTTP 0 10

Внимание

Убедитесь, что вы создаете правило масштабирования или устанавливаете minReplicas на 1 или больше, если ингресс не включен. Если входящий трафик отключен и вы не зададите minReplicas или пользовательское правило масштабирования, контейнерное приложение масштабируется до нуля и не сможет снова запуститься.

Поведение масштабирования

Масштабирование имеет следующее поведение:

Поведение Значение
Интервал опроса 30 секунд
Период охлаждения 300 секунд
Увеличение масштаба окна стабилизации 0 секунд
Уменьшение окна стабилизации 300 секунд
Шаг масштабирования 1, 4, 8, 16, 32, ... до настраиваемого максимального количества реплик
Шаг уменьшения масштаба 100% реплик, которые должны быть отключены
Алгоритм масштабирования desiredReplicas = ceil(currentMetricValue / targetMetricValue)
  • Интервал опроса — это то, как часто KEDA запрашивает источники событий. Это значение не применяется к правилам масштабирования HTTP и TCP.
  • Период охлаждения — это время, в течение которого после последнего события KEDA ждёт перед тем, как приложение уменьшит количество реплик до минимального значения.
  • Окно стабилизации масштабирования вверх — это время, в течение которого KEDA ожидает, прежде чем принять решение о масштабировании вверх после выполнения условий такого масштабирования.
  • Окно стабилизации масштабирования вниз — это время, в течение которого KEDA ожидает перед тем, как принять решение о масштабировании вниз после того, как выполнены условия для масштабирования вниз.
  • Шаг масштабирования — количество реплик, добавляемых по мере масштабирования приложения контейнера. Она начинается с 1, а затем увеличивается до 4, 8, 16, 32 и т. д., до настроенного максимального количества реплик.
  • Шаг уменьшения масштаба состоит в том, сколько реплик удаляются по мере масштабирования приложения контейнера. KEDA удаляет все реплики, которые необходимо остановить.
  • Алгоритм масштабирования — это формула, используемая для вычисления текущего требуемого количества реплик.

Пример

Для следующего правила масштабирования:

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

По мере масштабирования приложения KEDA начинается с пустой очереди и выполняет следующие действия:

  1. Проверьте my-queue каждые 30 секунд.
  2. Если длина очереди равна 0, вернитесь к шагу 1.
  3. Если длина очереди превышает 0, масштабируйте приложение до 1.
  4. Если длина очереди равна 50, вычислите desiredReplicas = ceil(50/5) = 10.
  5. Масштабируйте приложение до min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount)).
  6. Вернитесь к шагу 1.

Если приложение масштабируется до максимального числа реплик — 20, процесс масштабирования проходит те же этапы, что и ранее. Уменьшение масштаба происходит только в том случае, если условие удовлетворяется в течение 300 секунд (окно стабилизации уменьшения масштаба). После того как длина очереди равна 0, KEDA ожидает 300 секунд (период охлаждения) перед масштабированием приложения до 0.

Рекомендации

Известные ограничения

  • Вертикальное масштабирование не поддерживается.

  • Количество реплик — это целевой объем, а не гарантия.

  • Если вы используете субъекты Dapr для управления состояниями, помните, что масштабирование до нуля не поддерживается. Dapr использует виртуальных актеров для управления асинхронными вызовами, что означает, что их представление в памяти не привязано к их идентичности или времени существования.

  • Изменение прокси-серверов KEDA через параметры прокси-серверов не поддерживается. Рекомендуется использовать профили рабочей нагрузки с шлюзом NAT или определяемым пользователем маршрутом (UDR) для отправки трафика на сетевое устройство, где можно проверить или прокси-трафик.

Следующие шаги

Управление секретами

  • Last updated on