Schaalregels instellen in Azure Container Apps

2025-06-26

Azure Container Apps beheert automatisch horizontaal schalen via een set declaratieve schaalregels. Naarmate de revisie van een container-app wordt uitgeschaald, worden nieuwe exemplaren van de revisie op aanvraag gemaakt. Deze exemplaren worden replica's genoemd.

Ter ondersteuning van dit schaalgedrag wordt Azure Container Apps mogelijk gemaakt door KEDA (Kubernetes Event-driven Autoscaling). KEDA ondersteunt schalen op basis van verschillende metrische gegevens, zoals HTTP-aanvragen, wachtrijberichten, CPU- en geheugenbelasting en gebeurtenisbronnen zoals Azure Service Bus, Azure Event Hubs, Apache Kafka en Redis. Zie Scalers in de KEDA-documentatie voor meer informatie.

Door schaalregels toe te voegen of te bewerken, wordt een nieuwe revisie van uw container-app gemaakt. Een revisie is een onveranderbare momentopname van uw container-app. Zie Revisiewijzigingstypen voor meer informatie over welke typen wijzigingen een nieuwe revisie activeren.

Gebeurtenisgestuurde Container Apps-taken maken gebruik van schaalregels om uitvoeringen te activeren op basis van gebeurtenissen.

Schaaldefinitie

Schaalvergroting is de combinatie van limieten, regels en gedrag.

Limieten bepalen het minimale en maximale aantal replica's per revisie naarmate uw containerapp wordt opgeschaald.

Schaallimiet	Standaardwaarde	Minimumwaarde	Maximumwaarde
Minimum aantal replica's per versie	0	0	Maximum aantal replica's dat kan worden geconfigureerd, zijn 1000.
Maximum aantal replica's per versie	10	1	Maximum aantal replica's dat kan worden geconfigureerd, zijn 1000.

Regels zijn de criteria die door Container Apps worden gebruikt om te bepalen wanneer replica's moeten worden toegevoegd of verwijderd.

Schaalregels worden geïmplementeerd als HTTP, TCP (Transmission Control Protocol) of op maat.
Gedrag is de combinatie van regels en limieten om schaalbeslissingen in de loop van de tijd te bepalen.

In schaalgedrag wordt uitgelegd hoe schaalbeslissingen worden genomen.

Wanneer u uw schaalregels definieert, is het belangrijk om rekening te houden met de volgende items:

Er worden geen gebruikskosten in rekening gebracht als uw container-app teruggeschakeld wordt naar nul.
Replica's die niet worden verwerkt maar in het geheugen blijven, kunnen gefactureerd worden tegen een lager 'inactief' tarief. Zie Facturering voor meer informatie.
Als u ervoor wilt zorgen dat een exemplaar van uw revisie altijd wordt uitgevoerd, stelt u het minimum aantal replica's in op 1 of hoger.

Regels voor schalen

Drie categorieën triggers bepalen hoe schalen plaatsvindt:

HTTP: Op basis van het aantal gelijktijdige HTTP-aanvragen voor uw revisie.
TCP: Op basis van het aantal gelijktijdige TCP-verbindingen met uw revisie.
Aangepast: Op basis van aangepaste metrische gegevens, zoals:
- CPU (Centrale Verwerkings Eenheid)
- Geheugen
- Ondersteunde gebeurtenisgestuurde gegevensbronnen:
  - Azure Service Bus (een cloud-gebaseerde berichtendienst van Microsoft)
  - Azure Event Hubs
  - Apache Kafka
  - Redis

Als u meer dan één schaalregel definieert, begint de container-app te schalen zodra aan de eerste voorwaarde van regels wordt voldaan.

HTTP

Met een HTTP-schaalregel hebt u controle over de drempelwaarde van gelijktijdige HTTP-aanvragen die bepalen hoe de revisie van uw container-app wordt geschaald. Elke 15 seconden wordt het aantal gelijktijdige aanvragen berekend als het aantal aanvragen in de afgelopen 15 seconden gedeeld door 15. Container Apps-taken bieden geen ondersteuning voor HTTP-schaalregels.

In het volgende voorbeeld wordt de revisie opgeschaald naar vijf replica's en kan weer teruggeschaald worden naar nul. De schaaleigenschap is ingesteld op 100 gelijktijdige aanvragen per seconde.

Voorbeeld

In de http sectie wordt een HTTP-schaalregel gedefinieerd.

Eigenschap voor schaalbaarheid	Beschrijving	Standaardwaarde	Minimumwaarde	Maximumwaarde
`concurrentRequests`	Wanneer het aantal HTTP-aanvragen deze waarde overschrijdt, wordt er een andere replica toegevoegd. Replica's blijven aan de pool toevoegen tot het `maxReplicas`-bedrag is bereikt.	10	1	n.v.t.

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

Notitie

Stel de properties.configuration.activeRevisionsMode eigenschap van de container-app in op single, wanneer u niet-HTTP-regels voor gebeurtenisschaal gebruikt.

In de http sectie wordt een HTTP-schaalregel gedefinieerd.

Eigenschap voor schaalbaarheid	Beschrijving	Standaardwaarde	Minimumwaarde	Maximumwaarde
`concurrentRequests`	Wanneer het aantal HTTP-aanvragen deze waarde overschrijdt, wordt er een andere replica toegevoegd. Replica's blijven aan de pool toevoegen tot het `maxReplicas`-bedrag is bereikt.	10	1	n.v.t.

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

Notitie

Stel de properties.configuration.activeRevisionsMode eigenschap van de container-app in op single, wanneer u niet-HTTP-regels voor gebeurtenisschaal gebruikt.

Definieer een HTTP-schaalregel met behulp van de --scale-rule-http-concurrency parameter in de create of update opdrachten.

CLI-parameter	Beschrijving	Standaardwaarde	Minimumwaarde	Maximumwaarde
`--scale-rule-http-concurrency`	Wanneer het aantal gelijktijdige HTTP-aanvragen deze waarde overschrijdt, wordt er een andere replica toegevoegd. Replica's blijven aan de pool toevoegen tot het `max-replicas`-bedrag is bereikt.	10	1	n.v.t.

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

Ga naar uw container-app in Azure Portal
Selecteer Schaal.
Selecteer Bewerken en implementeren.
Selecteer het tabblad Schaal .
Selecteer het minimum- en maximumbereik voor replica's.
Selecteer Toevoegen.
Voer in het vak Regelnaam een regelnaam in.
Kies in de vervolgkeuzelijst Type de optie HTTP-schaling.
Voer in het vak Gelijktijdige aanvragen het gewenste aantal gelijktijdige aanvragen voor uw container-app in.

TCP

Met een TCP-schaalregel hebt u controle over de drempelwaarde van gelijktijdige TCP-verbindingen die bepalen hoe uw app wordt geschaald. Elke 15 seconden wordt het aantal gelijktijdige verbindingen berekend als het aantal verbindingen in de afgelopen 15 seconden gedeeld door 15. Container Apps-taken bieden geen ondersteuning voor TCP-schaalregels.

In het volgende voorbeeld kan de revisie van de container-app uitschalen naar maximaal vijf replica's en inschalen naar nul. De drempelwaarde voor schalen wordt ingesteld op 100 gelijktijdige verbindingen per seconde.

Voorbeeld

In de tcp sectie wordt een TCP-schaalregel gedefinieerd.

Eigenschap voor schaalbaarheid	Beschrijving	Standaardwaarde	Minimumwaarde	Maximumwaarde
`concurrentConnections`	Wanneer het aantal gelijktijdige TCP-verbindingen deze waarde overschrijdt, wordt er een andere replica toegevoegd. Replica's blijven worden toegevoegd tot de `maxReplicas` limiet naarmate het aantal gelijktijdige verbindingen toeneemt.	10	1	n.v.t.

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

In de tcp sectie wordt een TCP-schaalregel gedefinieerd.

Eigenschap voor schaalbaarheid	Beschrijving	Standaardwaarde	Minimumwaarde	Maximumwaarde
`concurrentConnections`	Wanneer het aantal gelijktijdige TCP-verbindingen deze waarde overschrijdt, wordt er een andere replica toegevoegd. Replica's blijven worden toegevoegd tot de `maxReplicas` limiet naarmate het aantal gelijktijdige verbindingen toeneemt.	10	1	n.v.t.

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

Definieer een TCP-schaalregel met behulp van de --scale-rule-tcp-concurrency parameter in de create of update opdrachten.

CLI-parameter	Beschrijving	Standaardwaarde	Minimumwaarde	Maximumwaarde
`--scale-rule-tcp-concurrency`	Wanneer het aantal gelijktijdige TCP-verbindingen deze waarde overschrijdt, wordt er een andere replica toegevoegd. Replica's blijven worden toegevoegd tot de `max-replicas` hoeveelheid naarmate het aantal gelijktijdige verbindingen toeneemt.	10	1	n.v.t.

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

Niet ondersteund in Azure Portal. Gebruik de Azure CLI, Azure Resource Manager of Bicep om een TCP-schaalregel te configureren.

Aanpassen

U kunt een aangepaste Container Apps-schaalregel maken op basis van elke KEDA-schaalder op basis van ScaledObject met de volgende standaardwaarden:

Standaardinstellingen	Seconden
Peilinginterval	30
Afkoelperiode	300

Voor gebeurtenisgestuurde Container Apps-taken kunt u een aangepaste schaalregel maken op basis van op ScaledJob gebaseerde KEDA-schaalders.

In het volgende voorbeeld ziet u hoe u een aangepaste schaalregel maakt.

Voorbeeld

In dit voorbeeld ziet u hoe u een Azure Service Bus-scaler converteert naar een Container Apps-schaalregel, maar u gebruikt hetzelfde proces voor elke andere keda-schaalspecificatie op basis van ScaledObject.

Voor verificatie kunnen KEDA-scaler-verificatieparameters gebruikmaken van geheimen van Container Apps of beheerde identiteit.

In de volgende procedure ziet u hoe u een KEDA-schaalprogramma converteert naar een container-app-schaalregel. Dit fragment is een fragment van een Bicep-sjabloon om aan te geven waar elke sectie in de context van de algemene sjabloon past.

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

Raadpleeg dit fragment voor context over hoe de onderstaande voorbeelden in de Bicep-sjabloon passen.

Eerst definieert u het type en de metagegevens van de schaalregel.

Zoek de type waarde in de KEDA-schaalspecificatie.

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

Voer in de Bicep-sjabloon de schaalwaarde type in de eigenschap custom.type van de schaalregel in.

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

Zoek de metadata-waarden in de KEDA-schaalspecificatie.

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

Voeg in de Bicep-sjabloon alle metagegevenswaarden toe aan de custom.metadata sectie van de schaalregel.

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

Verificatie

Container Apps-schaalregels ondersteunen verificatie op basis van geheimen. Schaalregels voor Azure-resources, waaronder Azure Queue Storage, Azure Service Bus en Azure Event Hubs, bieden ook ondersteuning voor beheerde identiteiten. Gebruik waar mogelijk verificatie van beheerde identiteiten om te voorkomen dat geheimen in de app worden opgeslagen.

Geheimen gebruiken

Als u geheimen wilt gebruiken voor verificatie, moet u een geheim maken in de matrix van secrets de container-app. De geheime waarde wordt gebruikt in de auth matrix van de schaalregel.

KEDA-schaalders kunnen geheimen gebruiken in een TriggerAuthentication waarnaar wordt verwezen door de authenticationRef eigenschap. U kunt het TriggerAuthentication-object toewijzen aan de schaalregel voor Container Apps.

Zoek het TriggerAuthentication object waarnaar wordt verwezen door de KEDA-specificatie ScaledObject .

Zoek in het TriggerAuthentication object elk secretTargetRef en het bijbehorende geheim.

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

In de Bicep-sjabloon voor elk geheim:

Voeg een geheim toe aan de matrix van secrets de container-app die de geheime naam en waarde bevat.

Voeg een vermelding toe aan de auth matrix van de schaalregel.

Stel de waarde van de triggerParameter eigenschap in op de waarde van de secretTargetRefparameter eigenschap.

Stel de waarde van de secretRef eigenschap in op de naam van de secretTargetRefkey eigenschap.

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

Sommige schaalders ondersteunen metagegevens met het FromEnv achtervoegsel om te verwijzen naar een waarde in een omgevingsvariabele. Container Apps bekijkt de eerste container die wordt vermeld in de ARM-sjabloon voor de omgevingsvariabele.

Raadpleeg de sectie overwegingen voor meer beveiligingsgerelateerde informatie.

Beheerde identiteit gebruiken

Container Apps-schaalregels kunnen beheerde identiteit gebruiken om te verifiëren met Azure-services. De volgende Bicep-sjabloon geeft een door het systeem gebaseerde beheerde identiteit door om te verifiëren voor een Azure Queue Scaler.

Voordat u de volgende code gebruikt, vervangt u de tijdelijke aanduidingen die omgeven zijn door <> met uw waarden.

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

Zie Beheerde identiteit voor meer informatie over het gebruik van beheerde identiteiten met schaalregels.

In de volgende procedure ziet u hoe u een KEDA-schaalprogramma converteert naar een container-app-schaalregel. Dit fragment is een fragment van een ARM-sjabloon om aan te geven waar elke sectie in de context van de algemene sjabloon past.

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

Raadpleeg dit fragment voor context over hoe de onderstaande voorbeelden in de ARM-sjabloon passen.

Eerst definieert u het type en de metagegevens van de schaalregel.

Zoek de type waarde in de KEDA-schaalspecificatie.

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

Voer in de ARM-sjabloon de schaalwaarde type in de custom.type eigenschap van de schaalregel in.

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

Zoek de metadata-waarden in de KEDA-schaalspecificatie.

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

Voeg in de ARM-sjabloon alle metagegevenswaarden toe aan de custom.metadata sectie van de schaalregel.

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

Verificatie

Geheimen gebruiken

Als u geheimen wilt gebruiken voor verificatie, moet u een geheim maken in de matrix van secrets de container-app. De geheime waarde wordt gebruikt in de auth matrix van de schaalregel.

Zoek het TriggerAuthentication object waarnaar wordt verwezen door de KEDA-specificatie ScaledObject .

Zoek in het TriggerAuthentication object elk secretTargetRef en het bijbehorende geheim.

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

In de ARM-sjabloon voor elk geheim:

Voeg een geheim toe aan de matrix van secrets de container-app die de geheime naam en waarde bevat.
Voeg een vermelding toe aan de auth matrix van de schaalregel.
1. Stel de waarde van de triggerParameter eigenschap in op de waarde van de secretTargetRefparameter eigenschap.
2. Stel de waarde van de secretRef eigenschap in op de naam van de secretTargetRefkey eigenschap.

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

Raadpleeg de sectie overwegingen voor meer beveiligingsgerelateerde informatie.

Beheerde identiteit gebruiken

Container Apps-schaalregels kunnen beheerde identiteit gebruiken om te verifiëren met Azure-services. De volgende ARM-sjabloon geeft een systeem-gebaseerde beheerde identiteit door om te authenticeren voor een Azure Queue Scaler.

Voordat u de volgende code gebruikt, vervangt u de tijdelijke aanduidingen die omgeven zijn door <> met uw waarden.

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

Zie Beheerde identiteit voor meer informatie over het gebruik van beheerde identiteiten met schaalregels.

Zoek de type waarde in de KEDA-schaalspecificatie.

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

Stel in de CLI-opdracht de --scale-rule-type parameter in op de specificatiewaarde 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"

Zoek de metadata-waarden in de KEDA-schaalspecificatie.

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

Stel in de CLI-opdracht de --scale-rule-metadata parameter in op de metagegevenswaarden.

Je moet de waarden omzetten van een YAML-formaat naar een sleutel/waarde-paar voor gebruik in de opdrachtregel. Scheid elke sleutel/waardepaar met een spatie.

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"

Verificatie

Geheimen gebruiken

Als u verificatie op basis van geheimen voor een Container Apps-schaalregel wilt configureren, configureert u de geheimen in de container-app en verwijst u ernaar in de schaalregel.

Een KEDA-schaalfunctie ondersteunt geheimen in een TriggerAuthentication die door de authenticationRef eigenschap wordt gebruikt voor referentie. U kunt het TriggerAuthentication object toewijzen aan de schaalregel voor Container Apps.

Zoek het TriggerAuthentication object waarnaar wordt verwezen door de KEDA-specificatie ScaledObject . Identificeer elk secretTargetRef van het TriggerAuthentication object.

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

Maak in uw container-app de geheimen die overeenkomen met de secretTargetRef eigenschappen.

Stel in de CLI-opdracht parameters in voor elke secretTargetRef vermelding.

Maak een geheime vermelding met de --secrets parameter. Als er meerdere geheimen zijn, scheidt u deze met een spatie.
Maak een verificatievermelding met de --scale-rule-auth parameter. Als er meerdere items zijn, scheidt u deze met een spatie.

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

Beheerde identiteit gebruiken

Container Apps-schaalregels kunnen beheerde identiteit gebruiken om te verifiëren met Azure-services. Met de volgende opdracht maakt u een container-app met een door de gebruiker toegewezen beheerde identiteit en gebruikt deze om te verifiëren voor een Azure Queue Scaler.

Voordat u de volgende code gebruikt, vervangt u de tijdelijke aanduidingen die omgeven zijn door <> met uw waarden.

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>

Ga naar uw container-app in Azure Portal.
Selecteer Schaal.
Selecteer Bewerken en implementeren.
Selecteer het tabblad Schaal en replica's .
Selecteer het minimum- en maximumbereik voor replica's.
Selecteer Toevoegen.
Voer in het vak Regelnaam een regelnaam in.
Selecteer Aangepast in de vervolgkeuzelijst Type.

Zoek de type waarde in de KEDA-schaalspecificatie.

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

Voer in het vak Aangepast regeltype de waarde van de schaalschaal in type .

Zoek de metadata-waarden in de KEDA-schaalspecificatie.

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

Zoek in de portal de sectie Metagegevens en selecteer Toevoegen. Voer de naam en waarde in voor elk item in de sectie metagegevens van keda-specificatie ScaledObject .

Verificatie

Geheimen gebruiken

Maak in uw container-app de geheimen waarnaar u wilt verwijzen.

Zoek het TriggerAuthentication object waarnaar wordt verwezen door de KEDA-specificatie ScaledObject . Identificeer elk secretTargetRef van het TriggerAuthentication object.

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

Selecteer Toevoegen in de sectie Verificatie om een vermelding te maken voor elke KEDA-parameter.secretTargetRef

Beheerde identiteit gebruiken

Verificatie van beheerde identiteiten wordt niet ondersteund in Azure Portal. Gebruik de Azure CLI of Azure Resource Manager om te verifiëren met behulp van een beheerde identiteit.

Standaardschaalregel

Als u geen schaalregel maakt, wordt de standaardschaalregel toegepast op uw container-app.

Activator	Minimum aantal replicas	Maximum aantal replica's
HTTP	0	10

Belangrijk

Zorg ervoor dat u een schaalregel opstelt of minReplicas instelt op 1 of meer, indien u geen inkomend verkeer inschakelt. Als inkomend verkeer is uitgeschakeld en u geen minReplicas of aangepaste schaalregel definieert, dan wordt uw container-app geschaald naar nul en kan deze niet opnieuw worden gestart.

Schaalgedrag

Schalen heeft het volgende gedrag:

Gedrag	Weergegeven als
Peilinginterval	30 seconden
Afkoelperiode	300 seconden
Stabilisatievenster omhoog schalen	0 seconden
Stabilisatievenster omlaag schalen	300 seconden
Stap omhoog schalen	1, 4, 8, 16, 32, ... tot aan het geconfigureerde maximale aantal replica's
Stappen verminderen	100% replica's die moeten worden uitgeschakeld
Schaalalgoritme	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

Polling-interval is hoe vaak gebeurtenisbronnen worden opgevraagd door KEDA. Deze waarde is niet van toepassing op HTTP- en TCP-schaalregels.
Afkoelperiode is de tijdsduur vanaf het moment dat de laatste gebeurtenis is waargenomen, voordat de toepassing wordt teruggeschaald naar het minimale aantal replica's.
Het venster voor het opschalen van stabilisatie is hoe lang moet worden gewacht voordat een beslissing voor omhoog schalen wordt uitgevoerd zodra aan de voorwaarden voor omhoog schalen is voldaan.
Het stabilisatievenster voor omlaag schalen is de tijd die gewacht moet worden voordat een beslissing tot omlaag schalen wordt genomen, zodra aan de voorwaarden voor het omlaag schalen is voldaan.
Opschaalstap is het aantal replica's dat wordt toegevoegd wanneer uw container-app wordt uitgeschakeld. Het begint bij 1 en neemt vervolgens in stappen toe naar 4, 8, 16, 32, enzovoort, tot het geconfigureerde maximumaantal replica's.
Stap voor omlaag schalen is het aantal replica's dat wordt verwijderd wanneer uw container-app wordt afgeschaald. 100% replica's die moeten worden afgesloten, worden verwijderd.
Het algoritme voor schalen is de formule die wordt gebruikt om het huidige gewenste aantal replica's te berekenen.

Voorbeeld

Voor de volgende schaalregel:

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

Naarmate uw app uitschaalt, begint KEDA met een lege wachtrij en voert u de volgende stappen uit:

Controleer my-queue elke 30 seconden.
Als de wachtrijlengte gelijk is aan 0, gaat u terug naar (1).
Als de lengte van de wachtrij 0 is > , schaalt u de app naar 1.
Als de lengte van de wachtrij 50 is, berekent u desiredReplicas = ceil(50/5) = 10.
App schalen naar min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
Ga terug naar (1).

Als de app is geschaald naar het maximale aantal replica's van 20, volgt het schalen dezelfde eerdere stappen. Omlaag schalen gebeurt alleen als aan de voorwaarde is voldaan gedurende 300 seconden (venster voor omlaag schalen). Zodra de wachtrijlengte 0 is, wacht KEDA 300 seconden (afkoelperiode) voordat de app wordt geschaald naar 0.

Overwegingen

In de modus 'meerdere revisies' maakt het toevoegen van een nieuwe schaaltrigger een nieuwe revisie van uw toepassing, maar uw oude revisie blijft beschikbaar met de oude schaalregels. Gebruik de pagina Revisiebeheer om verkeerstoewijzingen te beheren.
Er worden geen gebruikskosten in rekening gebracht wanneer een toepassing wordt geschaald naar nul. Zie Facturering in Azure Container Apps voor meer prijsinformatie.
U moet gegevensbeveiliging inschakelen voor alle .NET-apps in Azure Container Apps. Zie Een ASP.NET Core-app implementeren en schalen in Azure Container Apps voor meer informatie.

Bekende beperkingen

Verticaal schalen wordt niet ondersteund.
Replicahoeveelheden zijn een doelbedrag, geen garantie.
Als u Dapr-actoren gebruikt om statussen te beheren, moet u er rekening mee houden dat schalen naar nul niet wordt ondersteund. Dapr maakt gebruik van virtuele actoren voor het beheren van asynchrone aanroepen, wat betekent dat hun in-memory weergave niet is gekoppeld aan hun identiteit of levensduur.
Het wijzigen van KEDA-proxy's via de instellingen voor proxy's wordt niet ondersteund. Overweeg het gebruik van workloadprofielen met een NAT-gateway of door de gebruiker gedefinieerde route (UDR) om verkeer naar een netwerkapparaat te verzenden, waar verkeer van daaruit kan worden geïnspecteerd of geproxied.

Volgende stappen

Geheimen beheren

Delen via

Schaalregels instellen in Azure Container Apps

Schaaldefinitie

Regels voor schalen

HTTP

Voorbeeld

TCP

Voorbeeld

Aanpassen

Voorbeeld

Verificatie

Geheimen gebruiken

Beheerde identiteit gebruiken

Verificatie

Geheimen gebruiken

Beheerde identiteit gebruiken

Verificatie

Geheimen gebruiken

Beheerde identiteit gebruiken

Verificatie

Geheimen gebruiken

Beheerde identiteit gebruiken

Standaardschaalregel

Schaalgedrag

Voorbeeld

Overwegingen

Bekende beperkingen

Volgende stappen

Feedback

Aanvullende resources