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

Статья
06/29/2024

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

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

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

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

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

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

Предел масштабирования	Default value	Минимальное значение	Максимальное значение
Минимальное количество реплик на редакцию	0	0	Максимально настраиваемые реплики — 1000.
Максимальное число реплик на редакцию	10	1	Максимально настраиваемые реплики — 1000.

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

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

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

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

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

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

Масштабирование осуществляется тремя различными категориями триггеров:

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

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

HTTP

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

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

Пример

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

Свойство масштабирования	Description	Default value	Минимальное значение	Максимальное значение
`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	Description	Default value	Минимальное значение	Максимальное значение
`--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

Перейдите в приложение-контейнер в портал Azure
Выберите "Масштаб".
Выберите Изменить и развернуть.
Выберите вкладку "Масштаб ".
Выберите минимальный и максимальный диапазон реплик.
Выберите Добавить.
В поле "Имя правила" введите имя правила.
В раскрывающемся списке "Тип" выберите "Масштабирование HTTP".
В поле "Одновременные запросы" введите требуемое количество одновременных запросов для приложения контейнера.

TCP

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

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

Пример

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

Свойство масштабирования	Description	Default value	Минимальное значение	Максимальное значение
`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	Description	Default value	Минимальное значение	Максимальное значение
`--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 для настройки правила масштабирования TCP.

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

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

Defaults	сек.
Интервал опроса	30
Период охлаждения	300

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

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

Пример

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

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

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

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

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

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

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

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

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

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

В шаблоне 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 могут использовать секреты в триггераAuthentication , на которое ссылается authenticationRef свойство. Объект TriggerAuthentication можно сопоставить с правилом масштабирования приложений контейнеров.

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

В объекте 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

В шаблоне ARM для каждого секрета:
1. Добавьте секрет в массив приложения secrets контейнера, содержащий имя и значение секрета.
2. Добавьте запись в auth массив правила масштабирования.
  1. Задайте для свойства значение triggerParameter secretTargetRefparameter свойства.
  2. Задайте для свойства значение secretRef имени secretTargetRefkey свойства.
```
{
  ...
  "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": "apptest123",
          "queueName": "queue1",
          "queueLength": "1"
        },
        "identity": "system"
      }
    }
  ]
}

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

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

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

В команде 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"

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

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

В команде 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"

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

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

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

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

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

apiVersion: v1
kind: Secret
metadata:
  name: my-secrets
  namespace: my-project
type: Opaque
data:
  connection-string-secret: <SERVICE_BUS_CONNECTION_STRING>
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: azure-servicebus-auth
spec:
  secretTargetRef:
  - parameter: connection
    name: my-secrets
    key: connection-string-secret
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-servicebus-queue-rule
  namespace: default
spec:
  scaleTargetRef:
    name: my-scale-target
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: my-queue
      namespace: service-bus-namespace
      messageCount: "5"
    authenticationRef:
        name: azure-servicebus-auth

В приложении-контейнере создайте секреты , соответствующие свойствам secretTargetRef .

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

Создайте запись секрета с параметром --secrets . Если существует несколько секретов, разделите их пробелом.
Создайте запись проверки подлинности с параметром --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>

Замените заполнители значениями.

Перейдите в приложение-контейнер в портал Azure.
Выберите "Масштаб".
Выберите Изменить и развернуть.
Перейдите на вкладку "Масштаб и реплики ".
Выберите минимальный и максимальный диапазон реплик.
Выберите Добавить.
В поле "Имя правила" введите имя правила.
В раскрывающемся списке "Тип" выберите "Настраиваемый".

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

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

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

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

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

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

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

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

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

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

В разделе "Проверка подлинности" выберите "Добавить", чтобы создать запись для каждого параметра KEDAsecretTargetRef.

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

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

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

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

Триггер	Минимум реплик	Максимум реплик
HTTP	0	10

Внимание

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

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

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

Параметр	Значение
Интервал опроса	30 секунд
Период охлаждения	300 секунд
Увеличение масштаба окна стабилизации	0 секунд
Окно стабилизации уменьшения масштаба	300 секунд
Шаг масштабирования	1, 4, 100 % текущего
Шаг уменьшения масштаба	100 % текущего
Алгоритм масштабирования	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

Интервал опроса — это то, как часто источники событий запрашиваются KEDA. Это значение не применяется к правилам масштабирования HTTP и TCP.
Период охлаждения — это время после того, как прошлое событие было обнаружено до того, как приложение масштабируется до минимального количества реплик.
Увеличение масштаба окна стабилизации — это время ожидания перед выполнением решения по масштабированию после выполнения условий увеличения масштаба.
Окно стабилизации уменьшения масштаба — это время ожидания перед выполнением решения по уменьшению масштаба после выполнения условий уменьшения масштаба.
Шаг увеличения масштаба — это скорость добавления новых экземпляров. Начинается с 1, 4, 8, 16, 32, ... до настроенного максимального количества реплик.
Шаг уменьшения масштаба — это скорость удаления реплик. По умолчанию удаляются 100 % реплик, которые должны завершить работу.
Алгоритм масштабирования — это формула, используемая для вычисления текущего требуемого количества реплик.

Пример

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

"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 начинается с пустой очереди и выполняет следующие действия:

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

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

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

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

Поделиться через

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

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

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

HTTP

Пример

TCP

Пример

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

Пример

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

Обратная связь

Дополнительные ресурсы