Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Skalierung von Beanstalk Cluster-Umgebungen
Eine Beanstalk Cluster-Umgebung skaliert, indem die Anzahl der * Replikate Ihrer Anwendung, die sie ausführt, geändert wird*. Ein Replikat ist eine laufende Kopie Ihres Container-Images. Amazon EKS stellt die Knotenkapazität bereit, die diese Replikate benötigen, und fügt Knoten hinzu oder entfernt sie entsprechend, sodass Sie die Größe der Anwendung statt einer Flotte von Instances anpassen müssen.
Dies ist der Hauptunterschied zu Beanstalk Standard, das eine Auto Scaling-Gruppe von Amazon EC2-Instances skaliert. Die `aws:autoscaling:*` Namespaces gelten nicht für eine Beanstalk Cluster-Umgebung. Die Skalierung wird stattdessen über den `aws:elasticbeanstalk:eks:environment:autoscaling` Namespace und seine untergeordneten Namespaces konfiguriert. Informationen zu jeder Option und ihren akzeptierten Werten finden Sie unter. [Konfigurationsoptionen für Beanstalk Cluster-Umgebungen](command-options-general-eks.md)
## Festlegen der Replikatgrenzen
Zwei Optionen begrenzen die Anzahl der Replikate: `min-replica` und`max-replica`, beide im Namespace. `aws:elasticbeanstalk:eks:environment:autoscaling` Elastic Beanstalk behält die Anzahl der Replikate zwischen ihnen bei.
Stellen Sie beide Optionen auf denselben Wert ein, um eine feste Anzahl von Replikaten auszuführen. Stellen Sie einen `max-replica` höheren Wert ein`min-replica`, um die Umgebung zwischen den beiden Werten skalieren zu lassen. In einer Umgebung wird immer mindestens ein Replikat ausgeführt, da es `1` als niedrigsten Wert `min-replica` akzeptiert wird.
```
$ aws elasticbeanstalk update-environment \
--environment-name {{my-cluster-env}} \
--option-settings \
Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=min-replica,Value=2 \
Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=max-replica,Value=20
```
## Wie Elastic Beanstalk entscheidet, wann skaliert werden soll
Innerhalb dieser Grenzen * entscheiden ein oder mehrere * Trigger über die Anzahl der Replikate. Elastic Beanstalk wertet die Trigger anhand des festgelegten Intervalls aus. `polling-interval` Wenn die Trigger die Berichterstattung über Aktivitäten beenden, wartet Elastic Beanstalk den festgelegten Zeitraum ab, `cooldown-period` bevor die Umgebung wieder herunterskaliert wird. Auf diese Weise wird verhindert, dass Replikate entfernt werden, die bald wieder benötigt werden.
Wenn Sie überhaupt keinen Trigger konfigurieren, skaliert die Umgebung entsprechend der CPU-Auslastung ihrer Replikate. In den verbleibenden Abschnitten werden die Trigger beschrieben, die Sie stattdessen konfigurieren können.
## Skalierung auf CPU oder Arbeitsspeicher
Um die Ressourcen zu skalieren, die Ihre Replikate verbrauchen, legen Sie einen Metriktyp und einen Zielwert im `aws:elasticbeanstalk:eks:environment:autoscaling:trigger` Namespace fest. Elastic Beanstalk fügt Replikate hinzu oder entfernt sie, um die Umgebung in der Nähe des von Ihnen festgelegten Ziels zu halten.
+ Stellen Sie für CPU und ein. `cpu-metric-type` `cpu-value`
+ Für Speicher setzen Sie `memory-metric-type` und`memory-value`.
Ein Metriktyp von `Utilization` behandelt den Wert als Prozentsatz dessen, was das Replikat über die `memory` Optionen `cpu` und reserviert, sodass a `cpu-value` of auf 75 Prozent der reservierten CPU `75` abzielt. Ein Metriktyp von `AverageValue` behandelt den Wert als absoluten Betrag pro Replikat.
Sie können sowohl den CPU- als auch den Speicher-Trigger in einer Umgebung einrichten.
```
$ aws elasticbeanstalk update-environment \
--environment-name {{my-cluster-env}} \
--option-settings \
Namespace=aws:elasticbeanstalk:eks:environment:autoscaling:trigger,OptionName=cpu-metric-type,Value=Utilization \
Namespace=aws:elasticbeanstalk:eks:environment:autoscaling:trigger,OptionName=cpu-value,Value=75
```
## Skalierung nach einem Zeitplan
Um eine bestimmte Anzahl von Replikaten in einem sich wiederholenden Zeitfenster auszuführen, legen Sie `scaler-type` das Fenster in fest `cron` und beschreiben Sie es. `scaler-metadata` Dieses benötigt ein JSON-Objekt mit vier Feldern.
| Feld | Description |
| --- | --- |
| timezone | Die Zeitzone, in der das Fenster ausgedrückt wird, als IANA-Zeitzonenname wie UTCAmerica/New\_York, oder. Asia/Tokyo |
| start | Wenn das Fenster geöffnet wird, als Cron-Ausdruck aus fünf Feldern (Minute, Stunde, Monatstag, Monat, Wochentag). |
| end | Wenn das Fenster geschlossen wird, im gleichen Format. |
| desiredReplicas | Die Anzahl der Replikate, die ausgeführt werden sollen, während das Fenster geöffnet ist. Wählen Sie einen Wert innerhalb Ihrer min-replica und max-replica -Grenzen. |
Außerhalb des Fensters kehrt die Umgebung zu`min-replica`. Im folgenden Beispiel werden fünf Replikate während der Arbeitszeiten an Wochentagen in UTC ausgeführt:
```
$ cat schedule.json
[
{
"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
"OptionName": "scaler-type",
"Value": "cron"
},
{
"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
"OptionName": "scaler-metadata",
"Value": "{\"timezone\":\"UTC\",\"start\":\"0 8 * * 1-5\",\"end\":\"0 18 * * 1-5\",\"desiredReplicas\":\"5\"}"
}
]
$ aws elasticbeanstalk update-environment \
--environment-name {{my-cluster-env}} \
--option-settings file://schedule.json
```
Eine Umgebung benötigt einen Zeitplan. Um die Anzahl der Replikate in mehreren Fenstern zu variieren, z. B. bei einem anderen Wochenendplan, kombinieren Sie den Zeitplan mit einem anderen Trigger, wie unter beschrieben[Kombinieren von Triggern](#configuring-cluster-scaling-combining).
**Anmerkung**
Die Einstellungen werden in einer Datei gespeichert, da ein `scaler-metadata` Wert selbst ein JSON-Dokument ist. Informationen zu den Formularen, die von AWS CLI akzeptiert werden`--option-settings`, finden Sie unter [ Verwenden der Abkürzungssyntax im. AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-shorthand.html)
## Skalierung anhand einer Metrik von Ihrem eigenen Endpunkt aus
Um auf der Grundlage eines Werts zu skalieren, den Ihr eigener Service meldet, wie z. B. die Warteschlangentiefe oder die Anzahl der Aufträge während des Fluges, legen Sie `scaler-type` diesen Wert fest. `metrics-api` Elastic Beanstalk liest einen von Ihnen angegebenen HTTP-Endpunkt und skaliert anhand der dort gefundenen Zahl. Beschreiben Sie den Endpunkt in. `scaler-metadata`
| Feld | Description |
| --- | --- |
| url | Der Endpunkt, den Elastic Beanstalk liest. |
| valueLocation | Wo die Zahl in der JSON-Antwort steht, als gepunkteter Pfad. Für einen Antworttext von {"data":{"result":[{"value":"500"}]}} lautet data.result.0.value die Position. |
| targetValue | Die Menge, die ein Replikat voraussichtlich verarbeiten wird. |
Elastic Beanstalk dividiert den gemeldeten Wert durch `targetValue` und rundet ihn auf, um die Anzahl der Replikate zu erhalten. Diese Anzahl wird dann innerhalb Ihrer Replikatgrenzen gehalten. Bei einem Wert `targetValue` von `100` fragt ein gemeldeter Wert von nach fünf Replikaten. `500`
Sie können den Auslöser auf Ihre eigene Umgebung richten. Da die URL der Umgebung erst nach dem Start bekannt ist, sollten Sie sie `url` bei einem Update und nicht bei der Erstellung festlegen.
Das folgende Beispiel skaliert auf der Grundlage einer Tiefe, die von der Anwendung gemeldet wird, wobei ein Replikat pro 100 gemeldeten Arbeitseinheiten verwendet wird:
```
$ cat trigger.json
[
{
"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
"OptionName": "scaler-type",
"Value": "metrics-api"
},
{
"Namespace": "aws:elasticbeanstalk:eks:environment:autoscaling:trigger",
"OptionName": "scaler-metadata",
"Value": "{\"url\":\"https://{{my-service.example.com}}/queue-depth\",\"valueLocation\":\"data.result.0.value\",\"targetValue\":\"100\"}"
}
]
$ aws elasticbeanstalk update-environment \
--environment-name {{my-cluster-env}} \
--option-settings file://trigger.json
```
### Authentifizierung am Endpunkt
Wenn für Ihren Endpunkt Anmeldeinformationen erforderlich sind, speichern Sie diese in einem AWS Secrets Manager Secret und setzen Sie sie `scaler-auth-secret` auf den ARN des Secrets. Sie können es nur festlegen, wenn es `scaler-type` ist`metrics-api`. Stellen Sie `scaler-auth-mode` das Schema ein, das Ihr Endpunkt erwartet. Der Wert des Geheimnisses ist ein JSON-Objekt, dessen Schlüssel von diesem Schema abhängen.
| Authentifizierungsmodus | Erforderliche Schlüssel im Geheimnis |
| --- | --- |
| bearer, die Standardeinstellung | token |
| basic | username und password |
| apiKey | apiKey |
| tls | ca, cert und key |
Stellen Sie auch die `application-role` Umgebungsoption ein. Elastic Beanstalk mountet die Anmeldeinformationen mithilfe der Pod-Identität der Umgebung, die nur existiert, wenn sie festgelegt ist, in Ihre Replikate. `application-role` Ohne sie schlägt das Mounten fehl und die Replikate werden nicht gestartet. Für einen Zeitplan-Trigger ist dies nicht erforderlich, ebenso wenig wie für einen Metrik-Endpunkt, für den keine Anmeldeinformationen erforderlich sind.
Die * Anwendungsrolle der Umgebung * liest den Secret. Geben Sie ihm also beides `secretsmanager:GetSecretValue` und `secretsmanager:DescribeSecret` den ARN des Secrets zu. Elastic Beanstalk aktualisiert die Anmeldeinformationen nach einem Zeitplan, und bei der Aktualisierung wird die aktuelle Version des Secrets überprüft, sodass eine Umgebung, die erteilt wurde, nur normal `GetSecretValue` gestartet wird und dann bei jeder späteren Aktualisierung fehlschlägt. Informationen zu den Rollen, die eine Beanstalk-Cluster-Umgebung verwendet, finden Sie unter. [Berechtigungen für Beanstalk Cluster](beanstalk-cluster-permissions.md)
Dieses Geheimnis ist unabhängig von der `secrets` Option, die Ihrer Anwendung geheime Schlüssel zuweist. Wenn Sie den Wert von ändern, werden die Replikate der Umgebung `scaler-auth-secret` ersetzt, da die Anmeldeinformationen bereitgestellt werden, wenn ein Replikat gestartet wird.
## Kombinieren von Triggern
Eine Umgebung benötigt einen ereignisgesteuerten Trigger, entweder einen Zeitplan oder eine Endpunktmetrik, da `scaler-type` und dieser einen einzigen Trigger `scaler-metadata` beschreibt. Er kann neben diesem Trigger auch die CPU- und Speicher-Trigger enthalten.
Zwei Verhaltensweisen sollten Sie kennen, bevor Sie sie kombinieren:
+ Die Einstellung `scaler-type` ersetzt die unter beschriebene Standard-CPU-Skalierung[Wie Elastic Beanstalk entscheidet, wann skaliert werden soll](#configuring-cluster-scaling-triggers). Um auch auf der CPU weiter zu skalieren, legen Sie `cpu-metric-type` und `cpu-value` explizit fest.
+ Wenn mehr als ein Trigger zutrifft, gewinnt die höchste Replikatanzahl. Ein Zeitplan, der nach fünf Replikaten fragt, und ein CPU-Trigger, der nach drei Replikaten fragt, ergeben fünf.
Das Kombinieren eines Zeitplans mit einem CPU-Trigger ist eine übliche Kombination: Der Zeitplan enthält die Anzahl der Replikate, die Sie während der Hauptverkehrszeiten erwarten, und der CPU-Trigger bleibt die restliche Zeit verfügbar.
## Beobachten Sie, wie die Umgebung skaliert
Auf der Überwachungsseite der Umgebung in der Elastic Beanstalk-Konsole wird ein ** Diagramm zur Anzahl der ** Anwendungsreplikate angezeigt, in dem die Replikate aufgeführt sind, die in der Umgebung im Laufe der Zeit ausgeführt werden. Ein Vergleich mit den ** Diagrammen für ** CPU (Kerne) ** und ** Arbeitsspeicher (Byte) zeigt, ob ein Trigger sein Ziel erfüllt. Informationen zum Zustand und zu den Messwerten, die eine Beanstalk Cluster-Umgebung meldet, finden Sie unter. [Überwachung von Beanstalk Cluster-Umgebungen](monitoring-cluster-environments.md)
Elastic Beanstalk zeichnet ein Umgebungsereignis auf, wenn es eine Skalierungseinstellung ändert, sodass der Event-Stream der Umgebung anzeigt, wann eine Skalierungsänderung wirksam wurde.