Festlegen von Skalierungsregeln in Azure Container Apps

Azure Container Apps verwaltet die automatische horizontale Skalierung über eine Reihe deklarativer Skalierungsregeln. Wenn eine Container-App-Revision skaliert wird, erstellt die Plattform neue Instanzen der Revision bei Bedarf. Diese Instanzen werden als Replikate bezeichnet.

Um dieses Skalierungsverhalten zu unterstützen, verwendet Azure Container Apps KEDA (Kubernetes Event-driven Autoscaling). KEDA unterstützt die Skalierung für eine Vielzahl von Metriken wie HTTP-Anforderungen, Warteschlangennachrichten, CPU- und Speicherlast sowie Ereignisquellen wie Azure Service Bus, Azure Event Hubs, Apache Kafka und Redis. Weitere Informationen finden Sie in der KEDA-Dokumentation unter Scalers.

Wenn Sie Skalierungsregeln hinzufügen oder bearbeiten, erstellen Sie eine neue Überarbeitung Ihrer Container-App. Eine Überarbeitung ist eine unveränderliche Momentaufnahme Ihrer Container App. Unter Änderungstypen für Revisionen erfahren Sie, welche Arten von Änderungen eine neue Revision auslösen.

Ereignisgesteuerte Container Apps-Aufträge verwenden Skalierungsregeln, um die Ausführung auf der Grundlage von Ereignissen auszulösen.

Skalierungsdefinition

Die Skalierung ist eine Kombination aus Grenzwerten, Regeln und Verhalten.

Grenzwerte definieren die minimale und maximale mögliche Anzahl von Replikaten pro Revision, wenn Ihre Container-Anwendung skaliert wird.

Skalierungslimit	Standardwert	Mindestwert	Höchstwert
Mindestanzahl von Replikaten pro Überarbeitung	0	0	Es können maximal 1.000 Replikate konfiguriert werden.
Maximale Anzahl von Replikaten pro Überarbeitung	10	1	Es können maximal 1.000 Replikate konfiguriert werden.

Regeln sind die Kriterien, die von Container-Apps verwendet werden, um zu entscheiden, wann Replikate hinzugefügt oder entfernt werden sollen.

Skalierungsregeln werden als HTTP, TCP (Transmission Control-Protokoll) oder benutzerdefiniert implementiert.
Verhalten ist die Kombination aus Regeln und Grenzwerten, um Skalierungsentscheidungen im Laufe der Zeit zu bestimmen.

Das Skalierungsverhalten erklärt, wie Skalierungsentscheidungen getroffen werden.

Berücksichtigen Sie beim Definieren ihrer Skalierungsregeln die folgenden Elemente:

Ihnen werden keine Nutzungsgebühren in Rechnung gestellt, wenn Ihre Container App auf Null skaliert.
Replikate, die nicht verarbeitet werden, aber im Arbeitsspeicher verbleiben, werden möglicherweise mit einer niedrigeren "Leerlaufrate" abgerechnet. Weitere Informationen finden Sie unter Abrechnung.
Wenn Sie sicherstellen möchten, dass immer eine Instanz Ihrer Überarbeitung ausgeführt wird, setzen Sie die Mindestanzahl der Replikate auf 1 oder höher.
Während Plattformupgrades oder Wartungen werden möglicherweise vorübergehend mehr Replikate als erwartet angezeigt. Container-Apps stellen sicher, dass Ihre Produktionsauslastung nicht beeinträchtigt wird, indem neue Replikate vorab aufgewärmt werden, bevor der Datenverkehr umgeleitet wird, ähnlich dem Standardverhalten von Kubernetes. Die zusätzlichen Replikate werden nach Abschluss des Vorgangs automatisch entfernt.

Skalierungsregeln

Drei Kategorien von Triggern bestimmen, wie die Skalierung auftritt:

HTTP: Basierend auf der Anzahl gleichzeitiger HTTP-Anforderungen an Ihre Revision.
TCP: Basierend auf der Anzahl gleichzeitiger TCP-Verbindungen mit Ihrer Revision.
Benutzerdefiniert: Basierend auf benutzerdefinierten Metriken wie:
- Zentrale Verarbeitungseinheit (CPU)
- Gedächtnis
- Unterstützte ereignisgesteuerte Datenquellen:
  - Azure Service Bus
  - Azure Event Hubs
  - Apache Kafka
  - Redis

Wenn Sie mehrere Skalierungsregel definieren, beginnt die Container-App zu skalieren, sobald die erste Bedingung einer Regel erfüllt ist.

Hinweis

Wenn Sie Funktionen für Container-Apps verwenden, konfiguriert die Standardoberfläche automatisch Skalierungsregeln basierend auf Funktionsauslösern und Bindungen. Das Azure-Portal deaktiviert die Schaltfläche Add scale rules für diese Apps. Wenn Sie benutzerdefinierte Regeln benötigen, verwenden Sie allowScalingRuleOverride wie in Override automatisch generierte KEDA-Skalierungsregeln für Azure Functions für Container-Apps beschrieben.

HTTP

Wenn Sie eine HTTP-Skalierungsregel verwenden, steuern Sie den Schwellenwert für gleichzeitige HTTP-Anforderungen, die bestimmen, wie ihre Container-App-Überarbeitung skaliert wird. Alle 15 Sekunden wird die Anzahl der gleichzeitigen Anforderungen berechnet, indem die Anzahl der Anforderungen der letzten 15 Sekunden durch 15 geteilt wird. Container Apps-Aufträge unterstützen keine HTTP-Skalierungsregeln.

Im folgenden Beispiel skaliert die Überarbeitung bis zu fünf Replikate hoch und kann auf 0 herunterskaliert werden. Die Skalierungseigenschaft ist auf 100 gleichzeitige Anforderungen pro Sekunde eingestellt.

Beispiel

Der http-Abschnitt definiert eine HTTP-Skalierungsregel.

Skalierungseigenschaft	Beschreibung	Standardwert	Mindestwert	Höchstwert
`concurrentRequests`	Wenn die Anzahl der HTTP-Anforderungen diesen Wert überschreitet, fügt die App ein weiteres Replikat hinzu. Die App fügt weiterhin Replikate bis zum `maxReplicas` Betrag hinzu.	10	1	–

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

Hinweis

Legen Sie die properties.configuration.activeRevisionsMode-Eigenschaft der Container-App bei Verwendung von Skalierungsregeln für Nicht-HTTP-Ereignisse auf single fest.

Der http-Abschnitt definiert eine HTTP-Skalierungsregel.

Skalierungseigenschaft	Beschreibung	Standardwert	Mindestwert	Höchstwert
`concurrentRequests`	Wenn die Anzahl der HTTP-Anforderungen diesen Wert überschreitet, fügt die App ein weiteres Replikat hinzu. Die App fügt weiterhin Replikate bis zum `maxReplicas` Betrag hinzu.	10	1	–

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

Hinweis

Legen Sie die properties.configuration.activeRevisionsMode-Eigenschaft der Container-App bei der Verwendung von Nicht-HTTP-Ereignisskalierungsregeln auf single fest.

Definieren Sie eine HTTP-Skalierungsregel mithilfe des --scale-rule-http-concurrency Parameters in den create Befehlen oder update Befehlen.

CLI-Parameter	Beschreibung	Standardwert	Mindestwert	Höchstwert
`--scale-rule-http-concurrency`	Wenn die Anzahl gleichzeitiger HTTP-Anforderungen diesen Wert überschreitet, fügt die App ein weiteres Replikat hinzu. Die App fügt weiterhin Replikate bis zum `max-replicas` Betrag hinzu.	10	1	–

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --scale-rule-name azure-http-rule \
  --scale-rule-type http \
  --scale-rule-http-concurrency 100

Wechseln Sie in der Azure portal zu Ihrer Container-App.
Wählen Sie Skalieren aus.
Wählen Sie Bearbeiten und bereitstellen aus.
Klicken Sie auf die Registerkarte Skalieren.
Wählen Sie den minimalen und maximalen Replikatbereich aus.
Wählen Sie Hinzufügen aus.
Geben Sie im Feld Regelname einen Namen für die Regel ein.
Wählen Sie in der Dropdownliste Typ die Option HTTP-Skalierung aus.
Geben Sie im Feld "Gleichzeitige Anforderungen " die Anzahl der gleichzeitigen Anforderungen für Ihre Container-App ein.

TCP

Wenn Sie eine TCP-Skalierungsregel verwenden, steuern Sie den Schwellenwert für gleichzeitige TCP-Verbindungen, die bestimmen, wie Ihre App skaliert wird. Alle 15 Sekunden berechnet das System die Anzahl gleichzeitiger Verbindungen als die Anzahl der Verbindungen in den letzten 15 Sekunden dividiert durch 15 Sekunden. Container Apps-Aufträge unterstützen keine TCP-Skalierungsregeln.

Im folgenden Beispiel skaliert die Revision der Container-App auf bis zu fünf Replikate hoch und kann auf null herunterskaliert werden. Der Skalierungsschwellenwert wurde auf 100 gleichzeitige Verbindungen pro Sekunde festgelegt.

Beispiel

Der Abschnitt tcp definiert eine TCP-Skalierungsregel.

Skalierungseigenschaft	Beschreibung	Standardwert	Mindestwert	Höchstwert
`concurrentConnections`	Wenn die Anzahl gleichzeitiger TCP-Verbindungen diesen Wert überschreitet, fügt das System ein weiteres Replikat hinzu. Das System fügt fortlaufend weitere Replikate hinzu, bis die unter `maxReplicas` angegebene Anzahl erreicht ist, während die Anzahl gleichzeitiger Verbindungen zunimmt.	10	1	–

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

Der Abschnitt tcp definiert eine TCP-Skalierungsregel.

Skalierungseigenschaft	Beschreibung	Standardwert	Mindestwert	Höchstwert
`concurrentConnections`	Wenn die Anzahl gleichzeitiger TCP-Verbindungen diesen Wert überschreitet, fügt das System ein weiteres Replikat hinzu. Das System fügt so lange Replikate hinzu, bis die Anzahl `maxReplicas` erreicht ist, wenn die Zahl gleichzeitiger Verbindungen steigt.	10	1	–

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

Definieren Sie eine TCP-Skalierungsregel mithilfe des --scale-rule-tcp-concurrency Parameters in den create Befehlen oder update Befehlen.

CLI-Parameter	Beschreibung	Standardwert	Mindestwert	Höchstwert
`--scale-rule-tcp-concurrency`	Wenn die Anzahl gleichzeitiger TCP-Verbindungen diesen Wert überschreitet, fügt das System ein weiteres Replikat hinzu. Das System fügt bis zur Anzahl `max-replicas` weitere Replikate hinzu, wenn die Anzahl der gleichzeitigen Verbindungen steigt.	10	1	–

az containerapp create \
  --name <CONTAINER_APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <CONTAINER_IMAGE_LOCATION>
  --min-replicas 0 \
  --max-replicas 5 \
  --transport tcp \
  --ingress <external/internal> \
  --target-port <CONTAINER_TARGET_PORT> \
  --scale-rule-name azure-tcp-rule \
  --scale-rule-type tcp \
  --scale-rule-tcp-concurrency 100

Dieses Feature wird vom Azure-Portal nicht unterstützt. Verwenden Sie die Azure CLI, Azure Resource Manager oder Bicep, um eine TCP-Skalierungsregel zu konfigurieren.

Benutzerdefiniert

Erstellen Sie eine benutzerdefinierte Skalierungsregel für Container-Apps, die auf einem scaledObject-basierten KEDA-Scaler basiert, indem Sie die folgenden Standardwerte verwenden:

Standardwert	Sekunden
Abfrageintervall	30
Abkühlphase	300

Hinweis

Der Abkühlzeitraum wird nur wirksam, wenn die Skalierung vom endgültigen Replikat auf 0 erfolgt. Der Abkühlzeitraum wirkt sich nicht auf die Skalierung aus, da andere Replikate entfernt werden.

Erstellen Sie für ereignisgesteuerte Container-Apps-Jobs eine benutzerdefinierte Skalierungsregel auf Grundlage von ScaledJob-basierten KEDA-Scalern.

Das folgende Beispiel veranschaulicht das Erstellen einer benutzerdefinierten Skalierungsregel.

Beispiel

In diesem Beispiel wird gezeigt, wie Sie einen Azure Service Bus Scaler in eine Skalierungsregel für Container-Apps konvertieren, aber sie verwenden denselben Prozess für alle anderen ScaledObject-basierten KEDA scaler Spezifikation.

Bei der Authentifizierung akzeptieren KEDA-Scalerparameter für die Authentifizierung Geheimnisse für Container Apps oder eine verwaltete Identität.

Das folgende Verfahren zeigt, wie Sie einen KEDA-Scaler in eine Container App-Skalierungsregel konvertieren. Dieser Codeausschnitt ist ein Auszug aus einer Bicep-Vorlage, um Ihnen zu zeigen, wo jeder Abschnitt im Kontext der Gesamtvorlage passt.

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

In diesem Auszug finden Sie kontextbezogene Informationen dazu, wie die folgenden Beispiele in die Bicep Vorlage passen.

Definieren Sie zunächst den Typ und die Metadaten der Skalierungsregel.

Suchen Sie aus der KEDA-Scalerspezifikation den type-Wert.

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

Geben Sie in der Vorlage "Bicep" den Scalerwert type in die custom.type-Eigenschaft der Skalierungsregel ein.

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

Suchen Sie aus der KEDA-Scalerspezifikation die metadata-Werte.

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

Fügen Sie in der Vorlage "Bicep" alle Metadatenwerte zum custom.metadata Abschnitt der Skalierungsregel hinzu.

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

Authentifizierung

Container-Apps-Skalierungsregeln unterstützen die geheimnisbasierte Authentifizierung. Skalierungsregeln für Azure Ressourcen, einschließlich Azure Queue Storage, Azure Service Bus und Azure Event Hubs, unterstützen auch verwaltete Identitäten. Verwenden Sie nach Möglichkeit die Authentifizierung mithilfe verwalteter Identitäten, um die Speicherung von Geheimnissen in der App zu vermeiden.

Verwenden von Geheimnissen

Um geheime Schlüssel für die Authentifizierung zu verwenden, erstellen Sie einen geheimen Schlüssel im Array der Container-App secrets . Verwenden Sie den geheimen Wert im auth Array der Skalierungsregel.

KEDA-Scaler können geheime Schlüssel in einer TriggerAuthentication verwenden, auf die die authenticationRef Eigenschaft verweist. Sie können das TriggerAuthentication-Objekt der Skalierungsregel für Container Apps zuordnen.

Finden Sie das TriggerAuthentication-Objekt, auf das die KEDA-ScaledObject-Spezifikation verweist.

Suchen Sie im TriggerAuthentication-Objekt nach den einzelnen secretTargetRef-Elementen und dem zugehörigen Geheimnis.

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 der Vorlage Bicep für jedes Geheimnis:

Fügen Sie ein Geheimnis zum secrets-Array der Container-App hinzu, das den Namen und den Wert des Geheimnisses enthält.

Fügen Sie dem Array auth der Skalierungsregel einen Eintrag hinzu.

Setzen Sie den Wert der Eigenschaft triggerParameter auf den Wert der Eigenschaft secretTargetRef von parameter.

Legen Sie den Wert der Eigenschaft secretRef auf den Namen der Eigenschaft secretTargetRef von key fest.

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

Einige Scaler unterstützen Metadaten mit dem FromEnv-Suffix, um auf einen Wert in einer Umgebungsvariable zu verweisen. Container Apps untersucht den ersten Container, der in der ARM-Vorlage für die Umgebungsvariable aufgeführt ist.

Weitere sicherheitsbezogene Informationen finden Sie im Abschnitt Überlegungen.

Verwenden einer verwalteten Identität

Skalierungsregeln für Container-Apps können verwaltete Identitäten verwenden, um sich bei Azure Diensten zu authentifizieren. Die folgende Bicep-Vorlage übergibt die systembasierte verwaltete Identität zur Authentifizierung bei einem Azure Warteschlangen-Scaler.

Bevor Sie den folgenden Code verwenden, ersetzen Sie die Platzhalter, die mit <> gekennzeichnet sind, durch Ihre Werte.

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

Weitere Informationen zur Verwendung verwalteter Identitäten mit Skalierungsregeln finden Sie unter Verwaltete Identitäten.

Das folgende Verfahren zeigt, wie Sie einen KEDA-Scaler in eine Container App-Skalierungsregel konvertieren. Dieser Ausschnitt ist ein Auszug aus einer ARM-Vorlage, der Ihnen zeigt, wo die einzelnen Abschnitte im Kontext der Gesamtvorlage stehen.

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

In diesem Auszug finden Sie kontextbezogene Informationen dazu, wie die folgenden Beispiele in die ARM-Vorlage passen.

Definieren Sie zunächst den Typ und die Metadaten der Skalierungsregel.

Suchen Sie aus der KEDA-Scalerspezifikation den type-Wert.

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

Geben Sie in der ARM-Vorlage den Skalierungswert type in die Eigenschaft custom.type der Skalierungsregel ein.

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

Suchen Sie aus der KEDA-Scalerspezifikation die metadata-Werte.

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

Fügen Sie in der ARM-Vorlage alle Metadatenwerte zum Abschnitt custom.metadata der Skalierungsregel hinzu.

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

Authentifizierung

Verwenden von Geheimnissen

Finden Sie das TriggerAuthentication-Objekt, auf das die KEDA-ScaledObject-Spezifikation verweist.

Suchen Sie im TriggerAuthentication-Objekt nach den einzelnen secretTargetRef-Elementen und dem zugehörigen Geheimnis.

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

Gehen Sie in der ARM-Vorlage für jedes Geheimnis wie folgt vor:

Fügen Sie ein Geheimnis zum secrets-Array der Container-App hinzu, das den Namen und den Wert des Geheimnisses enthält.
Fügen Sie dem Array auth der Skalierungsregel einen Eintrag hinzu.
1. Setzen Sie den Wert der Eigenschaft triggerParameter auf den Wert der Eigenschaft secretTargetRef von parameter.
2. Legen Sie den Wert der Eigenschaft secretRef auf den Namen der Eigenschaft secretTargetRef von key fest.

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

Weitere sicherheitsbezogene Informationen finden Sie im Abschnitt Überlegungen.

Verwenden einer verwalteten Identität

Skalierungsregeln für Container-Apps können verwaltete Identitäten verwenden, um sich bei Azure Diensten zu authentifizieren. Die folgende ARM-Vorlage übergibt die vom System zugewiesene verwaltete Identität zur Authentifizierung für einen Azure Queue Scaler.

Bevor Sie den folgenden Code verwenden, ersetzen Sie die Platzhalter, die mit <> gekennzeichnet sind, durch Ihre Werte.

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

Weitere Informationen zur Verwendung verwalteter Identitäten mit Skalierungsregeln finden Sie unter Verwaltete Identitäten.

Suchen Sie aus der KEDA-Scalerspezifikation den type-Wert.

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

Legen Sie im CLI-Befehl den --scale-rule-type-Parameter auf den Spezifikationswert type fest.

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"

Suchen Sie aus der KEDA-Scalerspezifikation die metadata-Werte.

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

Legen Sie im CLI-Befehl den --scale-rule-metadata-Parameter auf die Metadatenwerte fest.

Transformieren Sie die Werte aus einem YAML-Format in ein Schlüssel-Wert-Paar für die Verwendung in der Befehlszeile. Trennen Sie jedes Schlüsselwertpaar durch ein Leerzeichen.

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"

Authentifizierung

Verwenden von Geheimnissen

Um die geheime Authentifizierung für eine Skalierungsregel für Container-Apps zu konfigurieren, konfigurieren Sie die geheimen Schlüssel in der Container-App, und verweisen Sie in der Skalierungsregel darauf.

Ein KEDA-Scaler unterstützt Geheimnisse in einem TriggerAuthentication-Objekt, das von der Eigenschaft authenticationRef als Referenz verwendet wird. Sie können das TriggerAuthentication-Objekt der Container Apps-Skalierungsregel zuordnen.

Finden Sie das TriggerAuthentication-Objekt, auf das die KEDA-ScaledObject-Spezifikation verweist. Identifizieren Sie jedes secretTargetRef des TriggerAuthentication-Objekts.

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

Erstellen Sie in Ihrer Container App die Geheimnisse, die den secretTargetRef-Eigenschaften entsprechen.

Legen Sie im CLI-Befehl Parameter für jeden secretTargetRef-Eintrag fest.

Erstellen Sie einen geheimen Eintrag mit dem --secrets-Parameter. Wenn mehrere Geheimnisse vorhanden sind, trennen Sie sie durch ein Leerzeichen.
Erstellen Sie einen Authentifizierungseintrag mit dem --scale-rule-auth-Parameter. Wenn mehrere Einträge vorhanden sind, trennen Sie sie durch ein Leerzeichen.

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

Verwenden einer verwalteten Identität

Skalierungsregeln für Container-Apps können verwaltete Identitäten verwenden, um sich bei Azure Diensten zu authentifizieren. Mit dem folgenden Befehl wird eine Container-App mit einer vom Benutzer zugewiesenen verwalteten Identität erstellt und zur Authentifizierung für einen Azure Queue Scaler verwendet.

Bevor Sie den folgenden Code verwenden, ersetzen Sie die Platzhalter, die mit <> gekennzeichnet sind, durch Ihre Werte.

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>

Wechseln Sie in der Azure portal zu Ihrer Container-App.
Wählen Sie Skalieren aus.
Wählen Sie Bearbeiten und bereitstellen aus.
Wählen Sie die Registerkarte Skalieren und Replikate aus.
Wählen Sie den minimalen und maximalen Replikatbereich aus.
Wählen Sie Hinzufügen aus.
Geben Sie im Feld Regelname einen Namen für die Regel ein.
Wählen Sie in der Dropdownliste Typ die Option Benutzerdefiniert aus.

Suchen Sie aus der KEDA-Scalerspezifikation den type-Wert.

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

Geben Sie im Feld Benutzerdefinierter Regeltyp den Skalierungswert type ein.

Suchen Sie aus der KEDA-Scalerspezifikation die metadata-Werte.

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

Suchen Sie im Portal den Abschnitt Metadaten, und wählen Sie Hinzufügen aus. Geben Sie den Namen und Wert für jedes Element im Metadatenabschnitt der KEDA-Spezifikation ScaledObject ein.

Authentifizierung

Verwenden von Geheimnissen

Erstellen Sie in Ihrer Container App die Geheimnisse, auf die Sie verweisen möchten.

Finden Sie das TriggerAuthentication-Objekt, auf das die KEDA-ScaledObject-Spezifikation verweist. Identifizieren Sie jedes secretTargetRef des TriggerAuthentication-Objekts.

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ählen Sie im Abschnitt Authentifizierung die Option Hinzufügen aus, um einen Eintrag für jeden KEDA-Parameter secretTargetRef zu erstellen.

Verwenden einer verwalteten Identität

Die verwaltete Identitätsauthentifizierung wird im Azure portal nicht unterstützt. Verwenden Sie die Azure CLI oder Azure Resource Manager, um sich mit verwalteter Identität zu authentifizieren.

Standard-Skalierungsregel

Wenn Sie keine Skalierungsregel erstellen, wird die Standard-Skalierungsregel auf Ihre Container App angewendet.

Auslöser	Mindestanzahl Replikate	Maximale Anzahl Replikate
HTTP	0	10

Wichtig

Stellen Sie sicher, dass Sie entweder eine Skalierungsregel erstellen oder minReplicas auf 1 oder mehr setzen, wenn Sie das Ingress nicht aktivieren. Wenn der Eingangsdatenverkehr deaktiviert ist und Sie weder minReplicas noch eine benutzerdefinierte Skalierungsregel definieren, wird Ihre Container-App auf null skaliert und kann nicht wieder gestartet werden.

Skalierungsverhalten

Die Skalierung hat das folgende Verhalten:

Verhalten	Wert
Abfrageintervall	30 Sekunden
Abkühlphase	300 Sekunden
Stabilisierungsfenster vergrößern	0 Sekunden
Stabilisierungsfenster für Herunterskalierung	300 Sekunden
Hochskalierungsschritt	1, 4, 8, 16, 32, ... bis zur konfigurierten maximalen Replikatanzahl
Herunterskalierungsschritt	100 % der Replikate, die heruntergefahren werden müssen
Skalierungsalgorithmus	`desiredReplicas = ceil(currentMetricValue / targetMetricValue)`

Abfrageintervall ist, wie häufig KEDA Ereignisquellen abfragt. Dieser Wert gilt nicht für HTTP- und TCP-Skalierungsregeln.
Abklingzeit bezeichnet den Zeitraum, den KEDA nach dem letzten Ereignis wartet, bevor die Anwendung auf ihre minimale Replikatanzahl herunterskaliert wird.
Das Stabilisierungsfenster für die Hochskalierung gibt an, wie lange KEDA wartet, bevor es eine Entscheidung zur Hochskalierung trifft, sobald die Bedingungen für eine Hochskalierung erfüllt sind.
Das Stabilisierungsfenster für das Herunterskalieren gibt an, wie lange KEDA wartet, bevor es eine Entscheidung zum Herunterskalieren trifft, sobald die Bedingungen für das Herunterskalieren erfüllt sind.
Schritt zum Skalieren ist, wie viele Replikate hinzugefügt werden, wenn Ihre Container-App skaliert wird. Es beginnt bei 1, erhöht sich dann auf 4, 8, 16, 32 usw. bis zur konfigurierten maximalen Replikatanzahl.
Die Schrittweite beim Herunterskalieren gibt an, wie viele Replikate entfernt werden, wenn Ihre Container-App herunterskaliert wird. KEDA baut 100 % der Replikate ab, die beendet werden müssen.
Skalierungsalgorithmus ist die Formel, die zum Berechnen der aktuellen gewünschten Anzahl von Replikaten verwendet wird.

Beispiel

Für die folgende Skalierungsregel:

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

Wenn Ihre App aufskaliert wird, beginnt KEDA mit einer leeren Warteschlange und führt die folgenden Schritte aus:

Überprüfen Sie my-queue alle 30 Sekunden.
Wenn die Warteschlangenlänge gleich 0 ist, fahren Sie mit Schritt 1 fort.
Wenn die Warteschlangenlänge größer als 0 ist, skalieren Sie die App auf 1.
Wenn die Warteschlangenlänge 50 ist, berechnen Sie desiredReplicas = ceil(50/5) = 10.
Skalieren der App auf min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount)).
Wechseln Sie zurück zu Schritt 1.

Wenn die App auf die maximale Replikatanzahl von 20 skaliert wird, durchläuft die Skalierung dieselben vorherigen Schritte. Eine Herunterskalierung erfolgt nur, wenn die Bedingung 300 Sekunden lang erfüllt ist (Stabilisierungsfenster für die Herunterskalierung). Sobald die Warteschlangenlänge 0 ist, wartet KEDA 300 Sekunden (Abkühlzeitraum), bevor die App auf 0 skaliert wird.

Überlegungen

Im Mehrfachrevisionsmodus wird durch das Hinzufügen eines neuen Skalierungsgtriggers eine neue Revision Ihrer Anwendung erstellt, aber Ihre alte Revision bleibt mit den alten Skalierungsregeln verfügbar. Verwenden Sie die Seite Revisionsverwaltung, um Datenverkehrszuordnungen zu verwalten.
Es entstehen keine Nutzungsgebühren, wenn eine Anwendung auf Null skaliert wird. Weitere Preisinformationen finden Sie unter Billing in Azure Container Apps.
Sie müssen den Datenschutz für alle .NET Apps auf Azure Container Apps aktivieren. Weitere Informationen finden Sie unter Deploying und Skalieren einer ASP.NET Core App auf Azure Container Apps.

Bekannte Einschränkungen

Vertikale Skalierung wird nicht unterstützt.
Replikatmengen sind eine Zielmenge, keine Garantie.
Wenn Sie Dapr-Akteure zum Verwalten von Zuständen verwenden, denken Sie daran, dass die Skalierung auf Null nicht unterstützt wird. Dapr verwendet virtuelle Akteure, um asynchrone Aufrufe zu verwalten, was bedeutet, dass deren In-Memory-Darstellung nicht an ihre Identität oder Lebensdauer gebunden ist.
Das Ändern von KEDA-Proxys über die Proxyeinstellungen wird nicht unterstützt. Erwägen Sie die Verwendung von Workloadprofilen mit einem NAT-Gateway oder einer benutzerdefinierten Route (USER Defined Route, UDR), um Datenverkehr an eine Netzwerkanwendung zu senden, in der Sie den Datenverkehr prüfen oder proxyieren können.

Nächste Schritte

Verwalten von Geheimnissen

Feedback

War diese Seite hilfreich?

Last updated on 2026-05-24

Festlegen von Skalierungsregeln in Azure Container Apps

Skalierungsdefinition

Skalierungsregeln

HTTP

Beispiel

TCP

Beispiel

Benutzerdefiniert

Beispiel

Authentifizierung

Verwenden von Geheimnissen

Verwenden einer verwalteten Identität

Authentifizierung

Verwenden von Geheimnissen

Verwenden einer verwalteten Identität

Authentifizierung

Verwenden von Geheimnissen

Verwenden einer verwalteten Identität

Authentifizierung

Verwenden von Geheimnissen

Verwenden einer verwalteten Identität

Standard-Skalierungsregel

Skalierungsverhalten

Beispiel

Überlegungen

Bekannte Einschränkungen

Nächste Schritte

Feedback

Zusätzliche Ressourcen