Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługa Azure Container Apps zarządza automatycznym skalowaniem w poziomie za pomocą zestawu reguł skalowania deklaratywnego. W miarę skalowania rewizji aplikacji kontenerowej, nowe wystąpienia rewizji są tworzone na żądanie. Te wystąpienia są nazywane replikami.
Aby zapewnić obsługę tego zachowania skalowania, usługa Azure Container Apps jest obsługiwana przez usługę KEDA (skalowanie automatyczne oparte na zdarzeniach platformy 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.
Dodawanie lub edytowanie reguł skalowania powoduje utworzenie nowej poprawki 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.
- Repliki, które nie są przetwarzane, ale pozostają w pamięci, mogą być rozliczane według niższej stawki „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.
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 rozpocznie skalowanie po spełnieniu pierwszego warunku wszystkich reguł.
HTTP
Dzięki regule skalowania HTTP masz kontrolę nad progiem współbieżnych żądań HTTP, które określają 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ść, dodawana jest inna replika. Repliki nadal dodają do puli, aż do osiągnięcia ilości 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
properties.configuration.activeRevisionsMode
Ustaw właściwość aplikacji kontenera na single
wartość , jeśli używasz 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ść, dodawana jest inna replika. Repliki nadal dodają do puli, aż do osiągnięcia ilości maxReplicas . |
10 | 1 | nie dotyczy |
{
...
"resources": {
...
"properties": {
...
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [{
"name": "http-rule",
"http": {
"metadata": {
"concurrentRequests": "100"
}
}
}]
}
}
}
}
}
Uwaga
properties.configuration.activeRevisionsMode
Ustaw właściwość aplikacji kontenera na single
wartość , jeśli używasz reguł skalowania zdarzeń innych niż HTTP.
Zdefiniuj regułę skalowania HTTP przy użyciu 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 przekroczy tę wartość, dodawana jest inna replika. Repliki nadal dodają do puli, aż do osiągnięcia ilości 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 kontenera w witrynie Azure Portal
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ź żądaną liczbę współbieżnych żądań dla aplikacji kontenera.
TCP
Za pomocą reguły skalowania TCP masz kontrolę nad progiem współbieżnych połączeń TCP, które określają sposób skalowania aplikacji. Co 15 sekund liczba połączeń współbieżnych jest obliczana jako liczba 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, wersja aplikacji kontenera jest skalowana do pięciu replik i może być skalowana 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 przekroczy tę wartość, dodawana jest inna replika. Repliki nadal są dodawane do ilości maxReplicas w miarę jak rośnie liczba połączeń współbieżnych. |
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 przekroczy tę wartość, dodawana jest inna replika. Repliki nadal są dodawane do ilości maxReplicas w miarę jak rośnie liczba połączeń współbieżnych. |
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 przekroczy tę wartość, dodawana jest inna replika. Repliki są nadal dodawane aż do max-replicas wartości w miarę wzrostu liczby współbieżnych 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
Nie obsługiwane w Azure portal. Użyj interfejsu wiersza polecenia platformy Azure, usługi Azure Resource Manager lub Bicep , aby skonfigurować regułę skalowania TCP.
Niestandardowy
Możesz utworzyć niestandardową regułę skalowania usługi Container Apps na podstawie dowolnego modułu skalowania KEDA opartego na obiekcie ScaledObject z następującymi wartościami domyślnymi:
Ustawienia domyślne | Sekundy |
---|---|
Interwał sondowania | 30 |
Okres schładzania | 300 |
W przypadku zadań usługi Container Apps opartych na zdarzeniach można utworzyć niestandardową regułę skalowania na podstawie dowolnych skalowania KEDA opartych na skalowanych obiektach Job.
W poniższym przykładzie pokazano, jak utworzyć niestandardową regułę skalowania.
Przykład
W tym przykładzie pokazano, jak przekonwertować narzędzie skalowania usługi Azure Service Bus na regułę skalowania usługi Container Apps, ale używasz tego samego procesu dla dowolnej innej specyfikacji narzędzia skalowania KEDA opartej na usłudze ScaledObject.
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 należy zdefiniować 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ścicustom.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 platformy Azure, w tym usługi 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ć tajemnic do uwierzytelniania, należy utworzyć tajemnicę w tablicy aplikacji kontenerowej secrets
. Tajna wartość jest używana w tablicy reguły skali auth
.
Narzędzia skalowania KEDA mogą używać wpisów tajnych 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 KEDAScaledObject
.W obiekcie
TriggerAuthentication
znajdź każdysecretTargetRef
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ścisecretTargetRef
zparameter
.Ustaw wartość właściwości
secretRef
na nazwę właściwościsecretTargetRef
elementukey
.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ą zagadnień, 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 platformy Azure. Poniższy szablon Bicep wprowadza systemową tożsamość zarządzaną w celu uwierzytelniania 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 należy zdefiniować 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ścicustom.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
Reguły skalowania usługi Container Apps obsługują uwierzytelnianie oparte na tajemnicach. Reguły skalowania zasobów platformy Azure, w tym usługi 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ć tajemnic do uwierzytelniania, należy utworzyć tajemnicę w tablicy aplikacji kontenerowej secrets
. Tajna wartość jest używana w tablicy reguły skali auth
.
Narzędzia skalowania KEDA mogą używać wpisów tajnych 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 KEDAScaledObject
.W obiekcie
TriggerAuthentication
znajdź każdysecretTargetRef
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.Ustaw wartość właściwości
triggerParameter
na wartość właściwościsecretTargetRef
zparameter
.Ustaw wartość właściwości
secretRef
na nazwę właściwościsecretTargetRef
elementukey
.
{ ... "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" ⬅️ } ⬅️ ] } } ] } } } } }
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ą zagadnień, 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 platformy Azure. Poniższy szablon usługi ARM przekazuje tożsamość zarządzaną opartą na systemie w celu uwierzytelniania 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.
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.Musisz przekształcić 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
Reguły skalowania usługi Container Apps obsługują uwierzytelnianie oparte na tajemnicach. Reguły skalowania zasobów platformy Azure, w tym usługi 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 skonfigurować uwierzytelnianie oparte na wpisach tajnych dla reguły skalowania usługi Container Apps, należy skonfigurować wpisy tajne w aplikacji kontenera i odwoływać 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 KEDAScaledObject
. Zidentyfikuj każdy obiektsecretTargetRef
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
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 platformy Azure. Poniższe polecenie tworzy aplikację kontenera z tożsamością zarządzaną przypisaną przez użytkownika i używa jej do uwierzytelniania w usłudze Azure Queue Scaler.
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 kontenera w witrynie Azure Portal.
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
Reguły skalowania usługi Container Apps obsługują uwierzytelnianie oparte na tajemnicach. Reguły skalowania zasobów platformy Azure, w tym usługi 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
W aplikacji kontenera utwórz tajne, do których chcesz się odwołać.
Znajdź obiekt
TriggerAuthentication
, do którego odwołuje się specyfikacja KEDAScaledObject
. Zidentyfikuj każdy obiektsecretTargetRef
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
W sekcji Uwierzytelnianie wybierz pozycję Dodaj, aby utworzyć wpis dla każdego parametru KEDA
secretTargetRef
.
Korzystanie z tożsamości zarządzanej
Uwierzytelnianie tożsamości zarządzanej nie jest obsługiwane w portalu Azure. Użyj interfejsu wiersza polecenia platformy Azure lub usługi 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
lub 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 schładzania to czas, jaki mija od wystąpienia ostatniego zdarzenia, zanim aplikacja zmniejsza się do minimalnej liczby replik.
- Okno stabilizacji skalowania w górę to czas, jaki należy odczekać przed podjęciem decyzji o skalowaniu w górę po spełnieniu warunków skalowania.
- Okno stabilizacji skalowania w dół to okres oczekiwania przed podjęciem decyzji o skalowaniu w dół, który zaczyna się po spełnieniu warunków skalowania w dół.
- 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ół określa, ile replik jest usuwanych podczas zmniejszania rozmiaru aplikacji kontenerowej. 100% replik, które muszą zostać zamknięte, jest usuwanych.
- 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 wynosi 0, wróć do (1).
- Jeśli długość kolejki wynosi > 0, przeprowadź skalowanie aplikacji do 1.
- Jeśli długość kolejki wynosi 50, oblicz wartość
desiredReplicas = ceil(50/5) = 10
. - Skalowanie aplikacji do
min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
- Wróć do (1).
Jeśli aplikacja została przeskalowana do maksymalnej liczby replik 20, skalowanie przechodzi przez te same poprzednie kroki. Skalowanie w dół ma miejsce tylko wtedy, gdy warunek został 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.
W przypadku skalowania aplikacji do zera nie są naliczane żadne opłaty za użycie. Aby uzyskać więcej informacji o cenach, zobacz Rozliczenia w usłudze Azure Container Apps.
Musisz włączyć ochronę danych dla wszystkich aplikacji platformy .NET w usłudze Azure Container Apps. Aby uzyskać szczegółowe informacje, zobacz Wdrażanie i skalowanie aplikacji ASP.NET Core w usłudze 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 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 profilów obciążeń z bramą NAT lub trasą zdefiniowaną przez użytkownika (UDR) do wysyłania ruchu do urządzenia sieciowego, gdzie ruch może być sprawdzany lub przechodzić przez serwer proxy.