Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Container Apps verwaltet die automatische horizontale Skalierung mithilfe einer Reihe deklarativer Skalierungsregeln. Wenn eine Überarbeitung der Container-App hochskaliert wird, werden neue Instanzen der Überarbeitung bei Bedarf erstellt. Diese Instanzen werden als Replikate bezeichnet.
Um dieses Skalierungsverhalten zu unterstützen, wird Azure Container Apps von KEDA (Kubernetes Event-driven Autoscaling) unterstützt. 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, wird eine neue Version Ihrer Container App erstellt. 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.
Beim Definieren von Skalierungsregeln ist es wichtig, Folgendes zu berücksichtigen:
- Ihnen werden keine Nutzungsgebühren in Rechnung gestellt, wenn Ihre Container App auf Null skaliert.
- Replikate, die nicht verarbeitet werden, aber im Arbeitsspeicher verbleiben, können mit einer niedrigeren „Leerlaufrate“ abgerechnet werden. 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.
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-Servicebus
- Azure Event Hubs
- Apache Kafka
- Redis
Wenn Sie mehrere Skalierungsregeln 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, werden Skalierungsregeln basierend auf den Funktionsauslösern und Bindungen automatisch konfiguriert. Daher wird die Schaltfläche "Skalierungsregeln hinzufügen" im Azure-Portal für diese Apps deaktiviert. Die Manuelle Skalierungsregelkonfiguration ist in diesem Szenario nicht erforderlich oder wird nicht unterstützt.
HTTP
Mit einer HTTP-Skalierungsregel haben Sie die Kontrolle über den Schwellenwert der gleichzeitigen HTTP-Anforderungen, der bestimmt, 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, wird ein weiteres Replikat hinzugefügt. Replikate werden dem Pool weiterhin bis zu einer Anzahl von maxReplicas hinzugefügt. |
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 Eigenschaft properties.configuration.activeRevisionsMode
der Container-App auf single
fest, wenn Sie Nicht-HTTP-Ereignisskalierungsregeln verwenden.
Der http
-Abschnitt definiert eine HTTP-Skalierungsregel.
Skalierungseigenschaft | Beschreibung | Standardwert | Mindestwert | Höchstwert |
---|---|---|---|---|
concurrentRequests |
Wenn die Anzahl der HTTP-Anforderungen diesen Wert überschreitet, wird ein weiteres Replikat hinzugefügt. Replikate werden dem Pool weiterhin bis zu einer Anzahl von maxReplicas hinzugefügt. |
10 | 1 | – |
{
...
"resources": {
...
"properties": {
...
"template": {
...
"scale": {
"minReplicas": 0,
"maxReplicas": 5,
"rules": [{
"name": "http-rule",
"http": {
"metadata": {
"concurrentRequests": "100"
}
}
}]
}
}
}
}
}
Hinweis
Legen Sie die Eigenschaft properties.configuration.activeRevisionsMode
der Container-App auf single
fest, wenn Sie Nicht-HTTP-Ereignisskalierungsregeln verwenden.
Definieren Sie eine HTTP-Skalierungsregel mithilfe des Parameters --scale-rule-http-concurrency
in den Befehlen create
oder update
.
CLI-Parameter | Beschreibung | Standardwert | Mindestwert | Höchstwert |
---|---|---|---|---|
--scale-rule-http-concurrency |
Wenn die Anzahl der gleichzeitigen HTTP-Anforderungen diesen Wert überschreitet, wird ein weiteres Replikat hinzugefügt. Replikate werden dem Pool weiterhin bis zu einer Anzahl von max-replicas hinzugefügt. |
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
Navigieren Sie im 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 gewünschte Anzahl gleichzeitiger Anforderungen für Ihre Container-App ein.
TCP
Mit einer TCP-Skalierungsregel haben Sie die Kontrolle über den Schwellenwert gleichzeitiger TCP-Verbindungen, die bestimmen, wie Ihre App skaliert wird. Alle 15 Sekunden wird die Anzahl der gleichzeitigen Verbindungen berechnet, indem die Anzahl der Verbindungen der letzten 15 Sekunden durch 15 geteilt wird. Container Apps-Aufträge unterstützen keine TCP-Skalierungsregeln.
Im folgenden Beispiel skaliert die Überarbeitung der Container-App bis zu fünf Replikate hoch und kann auf 0 herunterskaliert werden. Der Skalierungsschwellenwert wurde auf 100 gleichzeitige Verbindungen pro Sekunde festgelegt.
Beispiel
Der tcp
Abschnitt definiert eine TCP-Skalierungsregel.
Skalierungseigenschaft | Beschreibung | Standardwert | Mindestwert | Höchstwert |
---|---|---|---|---|
concurrentConnections |
Wenn die Anzahl gleichzeitiger TCP-Verbindungen diesen Wert überschreitet, wird ein weiteres Replikat hinzugefügt. Replikate werden bei steigender Anzahl gleichzeitiger Verbindungen solange hinzugefügt, bis die Anzahl von maxReplicas erreicht ist. |
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, wird ein weiteres Replikat hinzugefügt. Replikate werden bei steigender Anzahl gleichzeitiger Verbindungen solange hinzugefügt, bis die Anzahl von maxReplicas erreicht ist. |
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 Parameters --scale-rule-tcp-concurrency
in den Befehlen create
oder update
.
CLI-Parameter | Beschreibung | Standardwert | Mindestwert | Höchstwert |
---|---|---|---|---|
--scale-rule-tcp-concurrency |
Wenn die Anzahl gleichzeitiger TCP-Verbindungen diesen Wert überschreitet, wird ein weiteres Replikat hinzugefügt. Replikate werden bei steigender Anzahl gleichzeitiger Verbindungen solange hinzugefügt, bis die Anzahl von max-replicas erreicht ist. |
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
Im Azure-Portal nicht unterstützt. Verwenden Sie azure CLI, Azure Resource Manager oder Bicep , um eine TCP-Skalierungsregel zu konfigurieren.
Benutzerdefiniert
Sie können eine benutzerdefinierte Skalierungsregel für Container Apps basierend auf jedem scaledObject-basierten KEDA-Scaler mit den folgenden Standardwerten erstellen:
Standardeinstellungen | Sekunden |
---|---|
Abfrageintervall | 30 |
Abkühlphase | 300 |
Für ereignisgesteuerte Container Apps-Aufträge können Sie eine benutzerdefinierte Skalierungsregel basierend auf allen scaledJob-basierten KEDA-Scalers erstellen.
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 jede andere ScaledObject-basierte KEDA-Scalerspezifikation.
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 Vorlage Bicep passen.
Zunächst definieren Sie 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 diecustom.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 Geheimnisse für die Authentifizierung zu verwenden, müssen Sie ein Geheimnis im Array secrets
der Container-App erstellen. Der Geheimniswert wird im Array auth
der Skalierungsregel verwendet.
KEDA-Skalierer können Geheimnisse in einem TriggerAuthentication-Objekt verwenden, auf das von der Eigenschaft authenticationRef
verwiesen wird. 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 einzelnensecretTargetRef
-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 EigenschaftsecretTargetRef
vonparameter
.Legen Sie den Wert der Eigenschaft
secretRef
auf den Namen der EigenschaftsecretTargetRef
vonkey
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
Container Apps-Skalierungsregeln können verwaltete Identität verwenden, um sich bei Azure-Diensten zu authentifizieren. Die folgende Bicep-Vorlage übergibt die systembasierte 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.
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.
Zunächst definieren Sie 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 Eigenschaftcustom.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
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 Geheimnisse für die Authentifizierung zu verwenden, müssen Sie ein Geheimnis im Array secrets
der Container-App erstellen. Der Geheimniswert wird im Array auth
der Skalierungsregel verwendet.
KEDA-Skalierer können Geheimnisse in einem TriggerAuthentication-Objekt verwenden, auf das von der Eigenschaft authenticationRef
verwiesen wird. 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 einzelnensecretTargetRef
-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.Setzen Sie den Wert der Eigenschaft
triggerParameter
auf den Wert der EigenschaftsecretTargetRef
vonparameter
.Legen Sie den Wert der Eigenschaft
secretRef
auf den Namen der EigenschaftsecretTargetRef
vonkey
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" ⬅️ } ⬅️ ] } } ] } } } } }
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
Container Apps-Skalierungsregeln können verwaltete Identität verwenden, um sich bei Azure-Diensten zu authentifizieren. Die folgende ARM-Vorlage übergibt die systembasierte 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 Spezifikationswerttype
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.Sie müssen die Werte aus einem YAML-Format in ein Schlüssel-Wert-Paar umwandeln, um sie in der Befehlszeile zu verwenden. 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
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 die geheimnisbasierte Authentifizierung für eine Container Apps-Skalierungsregel zu konfigurieren, konfigurieren Sie die Geheimnisse in der Container-App und verweisen 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 jedessecretTargetRef
desTriggerAuthentication
-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
Container Apps-Skalierungsregeln können verwaltete Identität verwenden, um sich bei Azure-Diensten zu authentifizieren. Der folgende Befehl erstellt eine Container-App mit einer benutzerseitig zugewiesenen verwalteten Identität und verwendet sie zum Authentifizieren für einen Azure Queue-Scaler.
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>
Navigieren Sie im 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
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
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 jedessecretTargetRef
desTriggerAuthentication
-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 mithilfe einer verwalteten 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 Eingang deaktiviert ist und Sie keine minReplicas
- oder benutzerdefinierte Skalierungsregel definieren, wird Ihre Container App auf 0 skaliert und hat keine Möglichkeit, wieder zu starten.
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 Ereignisquellen von KEDA abgefragt werden. Dieser Wert gilt nicht für HTTP- und TCP-Skalierungsregeln.
- Abkühlzeitraum ist die Zeitspanne, die nach Beobachtung des letzten Ereignisses vergeht, bevor die Anwendung auf ihre minimale Replikatanzahl skaliert.
- Skalierungsstabilisierungsfenster ist, wie lange gewartet werden muss, bevor eine Skalierungsentscheidung durchgeführt wird, nachdem die Skalierungsbedingungen erfüllt wurden.
- Das Stabilisierungsfenster für Herunterskalierung deutet an, wie lange gewartet werden muss, bevor eine Entscheidung für eine Herunterskalierung durchgeführt wird, nachdem die Bedingungen für die Skalierung nach unten erfüllt wurden.
- 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.
- Der Schritt für die Skalierung nach unten besteht darin, wie viele Replikate entfernt werden, wenn die Container-App skaliert wird. 100 % der Replikate, die heruntergefahren werden müssen, werden entfernt.
- 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, wechseln Sie zurück zu (1).
- Wenn die Länge der Warteschlange > 0 ist, skalieren Sie die Anwendung auf 1.
- Wenn die Warteschlangenlänge 50 ist, berechnen Sie
desiredReplicas = ceil(50/5) = 10
. - App skalieren auf
min(maxReplicaCount, desiredReplicas, max(4, 2*currentReplicaCount))
- Zurück zu (1).
Wenn die App auf die maximale Replikatanzahl von 20 skaliert wurde, durchläuft die Skalierung dieselben vorherigen Schritte. Eine Herunterskalierung erfolgt nur, wenn die Bedingung für 300 Sekunden erfüllt wurde (Stabilisierungsfenster für 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 Abrechnung in Azure Container Apps.
Sie müssen den Schutz von Daten für alle .NET-Apps in Azure Container Apps aktivieren. Weitere Informationen finden Sie unter Bereitstellen und Skalieren einer ASP.NET Core-App in 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, sollten Sie bedenken, 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 Netzwerk-Appliance zu senden, in der Datenverkehr überprüft oder von dort aus übertragen werden kann.