Ustawianie reguł skalowania w Azure Container Apps

Azure Container Apps zarządza automatycznym skalowaniem w poziomie za pomocą zestawu reguł skalowania deklaratywnego. W miarę zwiększania skali wersji aplikacji kontenerowej platforma tworzy na żądanie nowe wystąpienia tej wersji. Te wystąpienia są nazywane replikami.

Aby obsługiwać takie skalowanie, Azure Container Apps używa KEDA (automatycznego skalowania opartego na zdarzeniach w Kubernetes). Usługa KEDA obsługuje skalowanie względem różnych metryk, takich jak żądania HTTP, komunikaty w kolejce, obciążenie procesora CPU i pamięci oraz źródła zdarzeń, takie jak Azure Service Bus, Azure Event Hubs, Apache Kafka i Redis. Aby uzyskać więcej informacji, zapoznaj się z Scalerami w dokumentacji KEDA.

Podczas dodawania lub edytowania reguł skalowania tworzysz nową wersję aplikacji kontenera. Rewizja to niezmienna migawka aplikacji kontenera. Aby dowiedzieć się, które typy zmian wyzwalają nową poprawkę, zobacz Typy zmian poprawek.

Zadania usługi Container Apps oparte na zdarzeniach używają reguł skalowania do wyzwalania wykonań na podstawie zdarzeń.

Definicja skalowania

Skalowanie to kombinacja limitów, reguł i zachowania.

Limity definiują minimalną i maksymalną możliwą liczbę replik na wersję w miarę skalowania aplikacji kontenera.

Limit skalowania	Domyślna wartość	Wartość minimalna	Wartość maksymalna
Minimalna liczba replik na rewizję	0	0	Maksymalna liczba konfigurowalnych replik to 1000.
Maksymalna liczba replik na rewizję	10	1	Maksymalna liczba konfigurowalnych replik to 1000.

Reguły są kryteriami używanymi przez usługę Container Apps do decydowania, kiedy należy dodawać lub usuwać repliki.

Reguły skalowania są implementowane jako HTTP, TCP (Transmission Control Protocol) lub niestandardowe.
Zachowanie to połączenie reguł i limitów w celu określenia decyzji dotyczących skalowania w czasie.

Zachowanie skali wyjaśnia, jak są podejmowane decyzje dotyczące skalowania.

Podczas definiowania reguł skalowania należy wziąć pod uwagę następujące elementy:

Koszty użycia nie są naliczane, gdy aplikacja kontenerowa zostanie zeskalowana do zera.
Opłaty za repliki, które nie są przetwarzane, ale pozostają w pamięci, mogą być rozliczane przy niższym współczynniku bezczynności. Aby uzyskać więcej informacji, zobacz Rozliczenia.
Jeśli chcesz mieć pewność, że instancja twojej wersji zawsze działa, ustaw minimalną liczbę replik na 1 lub więcej.
Podczas uaktualniania lub konserwacji platformy można tymczasowo zobaczyć więcej replik niż oczekiwano. Usługa Container Apps gwarantuje, że przygotowanie nowych replik przed przeniesieniem ruchu nie wpłynie na obciążenie produkcyjne, podobnie jak w przypadku domyślnego zachowania systemu Kubernetes. Dodatkowe repliki są usuwane automatycznie po zakończeniu operacji.

Reguły skalowania

Trzy kategorie wyzwalaczy określają, jak występuje skalowanie:

HTTP: na podstawie liczby współbieżnych żądań HTTP do poprawki.
TCP: na podstawie liczby współbieżnych połączeń TCP z poprawką.
Niestandardowe: na podstawie metryk niestandardowych, takich jak:
- CPU
- Pamięć
- Obsługiwane źródła danych sterowane zdarzeniami:
  - Azure Service Bus
  - Azure Event Hubs
  - Apache Kafka
  - Redis

Jeśli zdefiniujesz więcej niż jedną regułę skalowania, aplikacja kontenera zacznie być skalowana po spełnieniu pierwszego warunku dowolnej reguły.

Uwaga

Jeśli używasz usługi Functions w usłudze Container Apps, domyślne środowisko automatycznie konfiguruje reguły skalowania na podstawie wyzwalaczy funkcji i powiązań. Portal Azure wyłącza przycisk Dodaj reguły skalowania dla tych aplikacji. Jeśli potrzebujesz reguł zdefiniowanych przez użytkownika, użyj allowScalingRuleOverride zgodnie z opisem w artykule Zastępowanie automatycznie generowanych reguł skalowania KEDA dla usługi Azure Functions w Container Apps.

HTTP

W przypadku korzystania z reguły skalowania HTTP można kontrolować próg współbieżnych żądań HTTP określający sposób skalowania poprawek aplikacji kontenera. Co 15 sekund liczba współbieżnych żądań jest obliczana jako liczba żądań w ciągu ostatnich 15 sekund podzielonych przez 15. Zadania usługi Container Apps nie obsługują reguł skalowania HTTP.

W poniższym przykładzie poprawka jest skalowana w poziomie do pięciu replik i może być skalowana do zera. Właściwość skalowania jest ustawiona na 100 współbieżnych żądań na sekundę.

Przykład

Sekcja http definiuje regułę skalowania HTTP.

Właściwość skalowania	opis	Domyślna wartość	Wartość minimalna	Wartość maksymalna
`concurrentRequests`	Gdy liczba żądań HTTP przekracza tę wartość, aplikacja dodaje kolejną replikę. Aplikacja nadal dodaje repliki, aż do osiągnięcia liczby `maxReplicas`.	10	1	nie dotyczy

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'http-rule'
            http: {
              metadata: {
                concurrentRequests: '100'
              }
            }
          }
        ]
      }
    }
  }
}

Uwaga

Ustaw właściwość properties.configuration.activeRevisionsMode aplikacji kontenera na single w przypadku korzystania z reguł skalowania zdarzeń innych niż HTTP.

Sekcja http definiuje regułę skalowania HTTP.

Właściwość skalowania	opis	Domyślna wartość	Wartość minimalna	Wartość maksymalna
`concurrentRequests`	Gdy liczba żądań HTTP przekracza tę wartość, aplikacja dodaje kolejną replikę. Aplikacja nadal dodaje repliki aż do liczby `maxReplicas`.	10	1	nie dotyczy

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "http-rule",
            "http": {
              "metadata": {
                "concurrentRequests": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Uwaga

Ustaw właściwość properties.configuration.activeRevisionsMode aplikacji kontenerowej na wartość single podczas używania reguł skalowania opartych na zdarzeniach innych niż HTTP.

Zdefiniuj regułę skalowania HTTP za pomocą parametru --scale-rule-http-concurrency w poleceniach create lub update.

Parametr CLI	opis	Domyślna wartość	Wartość minimalna	Wartość maksymalna
`--scale-rule-http-concurrency`	Gdy liczba współbieżnych żądań HTTP przekracza tę wartość, aplikacja dodaje kolejną replikę. Aplikacja nadal dodaje repliki aż do liczby `max-replicas`.	10	1	nie dotyczy

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

Przejdź do aplikacji kontenerowej w portalu Azure.
Wybierz pozycję Skaluj.
Wybierz pozycję Edytuj i wdróż.
Wybierz kartę Skala .
Wybierz minimalny i maksymalny zakres replik.
Wybierz Dodaj.
W polu Nazwa reguły wprowadź nazwę reguły.
Z listy rozwijanej Typ wybierz pozycję Skalowanie HTTP.
W polu Współbieżne żądania wprowadź liczbę współbieżnych żądań dla aplikacji kontenera.

TCP

W przypadku używania reguły skalowania TCP można kontrolować próg współbieżnych połączeń TCP określający sposób skalowania aplikacji. Co 15 sekund system oblicza liczbę połączeń współbieżnych jako liczbę połączeń w ciągu ostatnich 15 sekund podzielonych przez 15. Zadania usługi Container Apps nie obsługują reguł skalowania TCP.

W poniższym przykładzie rewizja aplikacji kontenerowej skaluje się w poziomie maksymalnie do pięciu replik i może skalować się w dół do zera. Próg skalowania jest ustawiony na 100 połączeń współbieżnych na sekundę.

Przykład

Sekcja tcp definiuje regułę skalowania TCP.

Właściwość skalowania	opis	Domyślna wartość	Wartość minimalna	Wartość maksymalna
`concurrentConnections`	Gdy liczba współbieżnych połączeń TCP przekracza tę wartość, system dodaje kolejną replikę. System stale dodaje repliki aż do liczby `maxReplicas` wraz ze wzrostem liczby współbieżnych połączeń.	10	1	nie dotyczy

resource symbolicname 'Microsoft.App/containerApps@2025-02-02-preview' = {
  ...
  properties: {
    ...
    template: {
      ...
      scale: {
        maxReplicas: 0
        minReplicas: 5
        rules: [
          {
            name: 'tcp-rule'
            http: {
              metadata: {
                concurrentConnections: '100'
              }
            }
          }
        ]
      }
    }
  }
}

Sekcja tcp definiuje regułę skalowania TCP.

Właściwość skalowania	opis	Domyślna wartość	Wartość minimalna	Wartość maksymalna
`concurrentConnections`	Gdy liczba współbieżnych połączeń TCP przekracza tę wartość, system dodaje kolejną replikę. System nadal dodaje repliki aż do wartości `maxReplicas`, wraz ze wzrostem liczby współbieżnych połączeń.	10	1	nie dotyczy

{
  ...
  "resources": {
    ...
    "properties": {
      ...
      "template": {
        ...
        "scale": {
          "minReplicas": 0,
          "maxReplicas": 5,
          "rules": [{
            "name": "tcp-rule",
            "tcp": {
              "metadata": {
                "concurrentConnections": "100"
              }
            }
          }]
        }
      }
    }
  }
}

Zdefiniuj regułę skalowania TCP przy użyciu parametru --scale-rule-tcp-concurrency w poleceniach create lub update.

Parametr CLI	opis	Domyślna wartość	Wartość minimalna	Wartość maksymalna
`--scale-rule-tcp-concurrency`	Gdy liczba współbieżnych połączeń TCP przekracza tę wartość, system dodaje kolejną replikę. System stale dodaje repliki aż do liczby `max-replicas`, w miarę wzrostu liczby jednoczesnych połączeń.	10	1	nie dotyczy

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

Portal Azure nie obsługuje tej funkcji. Użyj Azure CLI, Azure Resource Manager lub Bicep, aby skonfigurować regułę skalowania TCP.

Niestandardowy

Utwórz niestandardową regułę skalowania usługi Container Apps na podstawie dowolnego modułu skalowania KEDA opartego na obiekcie ScaledObject przy użyciu następujących wartości domyślnych:

Domyślna wartość	Sekundy
Interwał sondowania	30
Okres schładzania	300

Uwaga

Okres schładzania ma zastosowanie tylko w przypadku skalowania z końcowej repliki do 0. Okres schładzania nie ma wpływu na skalowanie, ponieważ wszystkie inne repliki są usuwane.

W przypadku zadań usługi Container Apps opartych na zdarzeniach utwórz niestandardową regułę skalowania na podstawie dowolnych skalerów KEDA opartych na ScaledJob.

W poniższym przykładzie pokazano, jak utworzyć niestandardową regułę skalowania.

Przykład

W tym przykładzie pokazano, jak przekonwertować Azure Service Bus scaler na regułę skalowania usługi Container Apps, ale używasz tego samego procesu dla innych ScaledObject opartych na KEDA scaler specyfikacji.

W przypadku uwierzytelniania parametry uwierzytelniania modułu skalowania KEDA przyjmują wpisy tajne usługi Container Apps lub tożsamość zarządzaną.

Poniższa procedura przedstawia sposób konwertowania skalera KEDA na regułę skalowania aplikacji kontenerowej. Ten fragment kodu jest fragmentem szablonu Bicep, który pokazuje, gdzie każda sekcja mieści się w kontekście ogólnego szablonu.

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

Zapoznaj się z tym fragmentem, aby zapoznać się z kontekstem dotyczącym sposobu dopasowania poniższych przykładów do szablonu Bicep.

Najpierw zdefiniuj typ i metadane reguły skalowania.

W specyfikacji narzędzia skalowania KEDA znajdź wartość type.

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

W szablonie Bicep wprowadź wartość skalera type do właściwości custom.type reguły skalowania.

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

W specyfikacji narzędzia skalowania KEDA znajdź metadata wartości.

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

W szablonie Bicep dodaj wszystkie wartości metadanych do custom.metadata sekcji reguły skalowania.

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

Uwierzytelnianie

Reguły skalowania usługi Container Apps obsługują uwierzytelnianie oparte na tajemnicach. Reguły skalowania zasobów Azure, w tym Azure Queue Storage, Azure Service Bus i Azure Event Hubs, obsługują również tożsamość zarządzaną. Jeśli to możliwe, użyj uwierzytelniania tożsamości zarządzanej, aby uniknąć przechowywania wpisów tajnych w aplikacji.

Używanie tajemnic

Aby używać sekretów do uwierzytelniania, utwórz sekret w tablicy secrets aplikacji kontenera. Użyj wartości wpisu tajnego w tablicy auth reguły skalowania.

Skalery KEDA mogą używać sekretów w elemencie TriggerAuthentication, do którego odwołuje się właściwość authenticationRef. Obiekt TriggerAuthentication można mapować na regułę skalowania usługi Container Apps.

Znajdź obiekt TriggerAuthentication, do którego odwołuje się specyfikacja KEDA ScaledObject.

W obiekcie TriggerAuthentication znajdź każdy secretTargetRef i powiązany z nim sekret.

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

W szablonie Bicep, dla każdej tajemnicy:

Dodaj tajemnicę do tablicy aplikacji kontenera secrets, zawierającą nazwę i wartość tej tajemnicy.

Dodaj wpis do auth tablicy reguły skalowania.

Ustaw wartość właściwości triggerParameter na wartość właściwości secretTargetRef z parameter.

Ustaw wartość właściwości secretRef na nazwę właściwości secretTargetRef elementu 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'
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Niektóre narzędzia skalowania obsługują metadane z sufiksem FromEnv , aby odwoływać się do wartości w zmiennej środowiskowej. Usługa Container Apps analizuje pierwszy wymieniony kontener w szablonie ARM dla zmiennej środowiskowej.

Zapoznaj się z sekcją rozważań , aby uzyskać więcej informacji związanych z zabezpieczeniami.

Korzystanie z tożsamości zarządzanej

Reguły skalowania usługi Container Apps mogą używać tożsamości zarządzanej do uwierzytelniania za pomocą usług Azure. Poniższy szablon Bicep przekazuje tożsamość zarządzaną opartą na systemie w celu uwierzytelnienia w usłudze Azure Queue Scaler.

Przed użyciem poniższego kodu zamień symbole zastępcze zamknięte w <> swoimi wartościami.

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

Aby dowiedzieć się więcej na temat używania tożsamości zarządzanej z regułami skalowania, zobacz Tożsamość zarządzana.

Poniższa procedura przedstawia sposób konwertowania skalera KEDA na regułę skalowania aplikacji kontenerowej. Ten fragment kodu jest częścią szablonu ARM, który pokazuje, gdzie każda sekcja mieści się w kontekście całego szablonu.

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

Zapoznaj się z tym fragmentem, aby zapoznać się z kontekstem dotyczącym sposobu dopasowania poniższych przykładów do szablonu usługi ARM.

Najpierw zdefiniuj typ i metadane reguły skalowania.

W specyfikacji narzędzia skalowania KEDA znajdź wartość type.

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

W szablonie ARM wprowadź wartość skalera type do właściwości custom.type reguły skalowania.

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

W specyfikacji narzędzia skalowania KEDA znajdź metadata wartości.

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

W szablonie usługi ARM dodaj wszystkie wartości metadanych do custom.metadata sekcji reguły skalowania.

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

Uwierzytelnianie

Używanie tajemnic

Aby używać wpisów tajnych do uwierzytelniania, utwórz wpis tajny w tablicy secrets aplikacji kontenerowej. Użyj wartości klucza tajnego w tablicy auth reguły skalowania.

Skalery KEDA mogą używać sekretów w obiekcie TriggerAuthentication, do którego odwołuje się właściwość authenticationRef. Obiekt TriggerAuthentication można mapować na regułę skalowania usługi Container Apps.

Znajdź obiekt TriggerAuthentication, do którego odwołuje się specyfikacja KEDA ScaledObject.

W obiekcie TriggerAuthentication znajdź każdy secretTargetRef i powiązany z nim sekret.

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

W szablonie ARM, dla każdego sekretu:

Dodaj tajemnicę do tablicy aplikacji kontenera secrets, zawierającą nazwę i wartość tej tajemnicy.
Dodaj wpis do auth tablicy reguły skalowania.
1. Ustaw wartość właściwości triggerParameter na wartość właściwości secretTargetRef z parameter.
2. Ustaw wartość właściwości secretRef na nazwę właściwości secretTargetRef elementu 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"         ⬅️
                  }                                          ⬅️
                ]
              }
            }
          ]
        }
      }
    }
  }
}

Zapoznaj się z sekcją rozważań , aby uzyskać więcej informacji związanych z zabezpieczeniami.

Korzystanie z tożsamości zarządzanej

Reguły skalowania usługi Container Apps mogą używać tożsamości zarządzanej do uwierzytelniania za pomocą usług Azure. Poniższy szablon ARM przekazuje tożsamość zarządzaną przypisaną przez system w celu uwierzytelniania skalera Azure Queue.

Przed użyciem poniższego kodu zamień symbole zastępcze zamknięte w <> swoimi wartościami.

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

Aby dowiedzieć się więcej na temat używania tożsamości zarządzanej z regułami skalowania, zobacz Tożsamość zarządzana.

W specyfikacji narzędzia skalowania KEDA znajdź wartość type.

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

W poleceniu CLI ustaw parametr --scale-rule-type na wartość type specyfikacji.

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"

W specyfikacji narzędzia skalowania KEDA znajdź metadata wartości.

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

W poleceniu wiersza polecenia ustaw parametr --scale-rule-metadata na wartości metadanych.

Przekształć wartości z formatu YAML na parę klucz/wartość do użycia w wierszu polecenia. Oddziel każdą parę klucz-wartość spacją.

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"

Uwierzytelnianie

Używanie tajemnic

Aby skonfigurować uwierzytelnianie oparte na wpisach tajnych dla reguły skalowania usługi Container Apps, skonfiguruj wpisy tajne w aplikacji kontenera i odwołaj się do nich w regule skalowania.

Narzędzie skalowania KEDA obsługuje tajemnice w elemencie TriggerAuthentication, które właściwość authenticationRef wykorzystuje jako odniesienie. Można zmapować obiekt TriggerAuthentication na regułę skalowania Container Apps.

Znajdź obiekt TriggerAuthentication, do którego odwołuje się specyfikacja KEDA ScaledObject. Zidentyfikuj każdy obiekt 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

W aplikacji kontenera utwórz tajemnice, które odpowiadają właściwościom secretTargetRef.

W poleceniu CLI ustaw parametry dla każdego wpisu secretTargetRef.

Utwórz wpis tajny z parametrem --secrets . Jeśli jest wiele tajemnic, oddziel je spacją.
Utwórz wpis uwierzytelniania za pomocą parametru --scale-rule-auth. Jeśli istnieje wiele wpisów, oddziel je spacją.

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

Korzystanie z tożsamości zarządzanej

Reguły skalowania usługi Container Apps mogą używać tożsamości zarządzanej do uwierzytelniania za pomocą usług Azure. Następujące polecenie tworzy aplikację kontenerową z tożsamością zarządzaną, przypisaną przez użytkownika, i używa jej do uwierzytelniania dla skalera kolejek Azure.

Przed użyciem poniższego kodu zamień symbole zastępcze zamknięte w <> swoimi wartościami.

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>

Przejdź do aplikacji kontenerowej w portalu Azure.
Wybierz pozycję Skaluj.
Wybierz pozycję Edytuj i wdróż.
Wybierz kartę Skalowanie i repliki .
Wybierz minimalny i maksymalny zakres replik.
Wybierz Dodaj.
W polu Nazwa reguły wprowadź nazwę reguły.
Z listy rozwijanej Typ wybierz pozycję Niestandardowe.

W specyfikacji narzędzia skalowania KEDA znajdź wartość type.

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

W polu Typ reguły niestandardowej wprowadź wartość modułu type skalowania.

W specyfikacji narzędzia skalowania KEDA znajdź metadata wartości.

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

W portalu znajdź sekcję Metadane i wybierz pozycję Dodaj. Wprowadź nazwę i wartość dla każdego elementu w sekcji metadanych specyfikacji KEDA ScaledObject .

Uwierzytelnianie

Używanie tajemnic

W aplikacji kontenera utwórz tajne, do których chcesz się odwołać.

Znajdź obiekt TriggerAuthentication, do którego odwołuje się specyfikacja KEDA ScaledObject. Zidentyfikuj każdy obiekt 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

W sekcji Uwierzytelnianie wybierz pozycję Dodaj, aby utworzyć wpis dla każdego parametru KEDAsecretTargetRef.

Korzystanie z tożsamości zarządzanej

Uwierzytelnianie zarządzanej tożsamości nie jest obsługiwane w portalu Azure. Użyj Azure CLI lub Azure Resource Manager do uwierzytelniania przy użyciu tożsamości zarządzanej.

Domyślna reguła skalowania

Jeśli nie utworzysz reguły skalowania, domyślna reguła skalowania zostanie zastosowana do aplikacji kontenera.

Wyzwalacz	Minimalna liczba replik	Maksymalna liczba replik
HTTP	0	10

Ważne

Upewnij się, że utworzono regułę skalowania lub ustawiono wartość minReplicas 1 lub więcej, jeśli nie włączysz ruchu przychodzącego. Jeśli ruch przychodzący jest wyłączony i nie zdefiniujesz minReplicas ani niestandardowej reguły skalowania, aplikacja kontenerowa skaluje się do zera i nie ma możliwości ponownego uruchomienia.

Zachowanie podczas skalowania

Skalowanie ma następujące zachowania:

Zachowanie	Wartość
Interwał sondowania	30 sekund
Okres schładzania	300 sekund
Zwiększenie okna stabilizacji	0 sekund
Skalowanie w dół okna stabilizacji	300 sekund
Krok skalowania w górę	1, 4, 8, 16, 32, ... aż do maksymalnie skonfigurowanej liczby replik
Krok skalowania w dół	100 replik%, które muszą zostać zamknięte
Algorytm skalowania	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

Interwał sondowania to częstotliwość wykonywania zapytań dotyczących źródeł zdarzeń przez usługę KEDA. Ta wartość nie ma zastosowania do reguł skalowania HTTP i TCP.
Okres oczekiwania to czas, przez jaki KEDA czeka po ostatnim zdarzeniu, zanim skaluje aplikację w dół do minimalnej liczby replik.
Okno stabilizacji skalowania w górę to czas, przez jaki KEDA czeka, zanim podejmie decyzję o skalowaniu w górę po spełnieniu warunków skalowania w górę.
Okno stabilizacji dla skalowania w dół to czas, przez jaki KEDA czeka, zanim podejmie decyzję o skalowaniu w dół, gdy warunki skalowania w dół zostaną spełnione.
Krok skalowania poziomo to liczba dodanych replik w miarę zwiększania zasięgu aplikacji kontenera. Zaczyna się od 1, a następnie zwiększa się do 4, 8, 16, 32 itd. do skonfigurowanej maksymalnej liczby replik.
Krok skalowania w dół to liczba replik usuniętych w miarę skalowania aplikacji kontenera. KEDA redukuje o 100% liczbę replik, które należy wyłączyć.
Algorytm skalowania to formuła używana do obliczania bieżącej żądanej liczby replik.

Przykład

Dla następującej reguły skalowania:

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

W miarę zwiększania skali aplikacji usługa KEDA zaczyna się od pustej kolejki i wykonuje następujące kroki:

Sprawdź my-queue co 30 sekund.
Jeśli długość kolejki jest równa 0, wróć do kroku 1.
Jeśli długość kolejki jest większa niż 0, przeprowadź skalowanie aplikacji do wartości 1.
Jeśli długość kolejki wynosi 50, oblicz wartość desiredReplicas = ceil(50/5) = 10.
Skaluj aplikację do min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount)).
Wróć do kroku 1.

Jeśli aplikacja skaluje się do maksymalnej liczby replik 20, skalowanie przechodzi przez te same poprzednie kroki. Skalowanie w dół odbywa się tylko wtedy, gdy warunek jest spełniony przez 300 sekund (okno stabilizacji skalowania w dół). Gdy długość kolejki wynosi 0, KEDA czeka na 300 sekund (okres schładzania) przed skalowaniem aplikacji do 0.

Kwestie wymagające rozważenia

W trybie "wiele poprawek" dodanie nowego wyzwalacza skalowania spowoduje utworzenie nowej poprawki aplikacji, ale stara wersja pozostaje dostępna ze starymi regułami skalowania. Użyj strony zarządzania wersjami, aby zarządzać przydziałem ruchu.
Opłaty za użycie nie są naliczane, gdy aplikacja jest skalowana do zera. Aby uzyskać więcej informacji o cenach, zobacz Billing w Azure Container Apps.
Należy włączyć ochronę danych dla wszystkich aplikacji .NET w Azure Container Apps. Aby uzyskać szczegółowe informacje, zobacz Deploying and scaling an ASP.NET Core app on Azure Container Apps (Wdrażanie i skalowanie aplikacji ASP.NET Core w Azure Container Apps

Znane ograniczenia

Skalowanie w pionie nie jest obsługiwane.
Ilości repliki to kwota docelowa, a nie gwarancja.
Jeśli używasz aktorów Języka Dapr do zarządzania stanami, pamiętaj, że skalowanie do zera nie jest obsługiwane. Dapr używa aktorów wirtualnych do zarządzania wywołaniami asynchronicznymi, co oznacza, że ich reprezentacja w pamięci nie jest powiązana z tożsamością ani czasem życia.
Zmiana serwerów proxy KEDA za pośrednictwem ustawień serwerów proxy nie jest obsługiwana. Rozważ użycie profili obciążenia z bramą NAT lub trasą zdefiniowaną przez użytkownika (UDR), aby kierować ruch do urządzenia sieciowego, na którym można analizować ruch lub przekazywać go przez serwer proxy.

Następne kroki

Zarządzanie tajemnicami

Opinia

Czy ta strona była pomocna?

Last updated on 2026-05-26

Ustawianie reguł skalowania w Azure Container Apps

Definicja skalowania

Reguły skalowania

HTTP

Przykład

TCP

Przykład

Niestandardowy

Przykład

Uwierzytelnianie

Używanie tajemnic

Korzystanie z tożsamości zarządzanej

Uwierzytelnianie

Używanie tajemnic

Korzystanie z tożsamości zarządzanej

Uwierzytelnianie

Używanie tajemnic

Korzystanie z tożsamości zarządzanej

Uwierzytelnianie

Używanie tajemnic

Korzystanie z tożsamości zarządzanej

Domyślna reguła skalowania

Zachowanie podczas skalowania

Przykład

Kwestie wymagające rozważenia

Znane ograniczenia

Następne kroki

Opinia

Dodatkowe zasoby