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. # Beanstalk Cluster-Architektur Beanstalk Cluster verwendet dieselben Konzepte für Elastic Beanstalk-Anwendungen, Anwendungsversionen, Umgebungen und Konfigurationsoptionen wie Beanstalk Standard. Beanstalk Standard ist der Umgebungstyp. EC2-based Beanstalk Cluster verwendet eine andere Rechenebene und Konfigurationsoberfläche. In diesem Thema werden die Unterschiede nach Aspekten beschrieben und der entsprechende Umgebungstyp identifiziert. ## Modell berechnen In Beanstalk Standard startet Elastic Beanstalk Amazon Elastic Compute Cloud (Amazon EC2) -Instances in einer Auto Scaling-Gruppe, die der Umgebung gewidmet ist. Die Anwendung wird direkt auf diesen Instances ausgeführt. In einer Beanstalk-Cluster-Umgebung führt Elastic Beanstalk die Anwendung stattdessen als Container-Image auf einem Amazon EKS-Cluster aus, das von Ihren Beanstalk-Cluster-Umgebungen gemeinsam genutzt werden kann. Elastic Beanstalk erstellt und betreibt den Cluster. Elastic Beanstalk plant die Anwendung auf dem Cluster. Elastic Beanstalk isoliert jede Umgebung auf dem Cluster und gleicht die Anzahl der Anwendungsreplikate so ab, dass sie den konfigurierten Werten entspricht. Sie erstellen keinen Cluster, wählen nicht aus, auf welchem Cluster eine Umgebung ausgeführt wird, und Sie wählen auch nicht deren Kubernetes-Version aus. Mehrere Ihrer Umgebungen können auf demselben Amazon EKS-Cluster ausgeführt werden. Elastic Beanstalk platziert eine Umgebung auf dem Cluster, die die konfigurierten VPC-Subnetze bedient. Es erstellt einen Cluster, wenn diese Subnetze zum ersten Mal verwendet werden; siehe. [Gruppierung der Umgebung](#beanstalk-cluster-clusters-sharing) Der automatische Modus von Amazon EKS bietet Knotenkapazität. Es fügt Knoten hinzu und entfernt sie, sodass sie zu den geplanten Containern passen. Da der Cluster gemeinsam genutzt werden kann und die Knotenkapazität von Amazon EKS verwaltet wird, wird die Anzahl der Instanzen nicht über den `aws:autoscaling:asg` Namespace konfiguriert. Stattdessen wird die Anzahl der Anwendungsreplikate mit den `max-replica` Optionen `min-replica` und im `aws:elasticbeanstalk:eks:environment:autoscaling` Namespace festgelegt. Informationen zu den Replikatgrenzen und den Triggern, die die Anzahl der Replikate ändern, finden Sie unter. [Skalierung von Beanstalk Cluster-Umgebungen](configuring-cluster-scaling.md) Elastic Beanstalk löst die Konfiguration der Umgebung anhand der von Ihnen angegebenen Optionseinstellungen auf und wendet die aufgelöste Konfiguration an, wenn die Umgebung erstellt oder aktualisiert wird. Wenn dieselbe Konfigurationsoption mehrmals angegeben wird, gewinnt das letzte Mal. Um die Konfiguration zu ändern, aktualisieren Sie die Optionseinstellungen. ## Unterschiede zu Beanstalk Standard In der folgenden Tabelle sind die kundenseitigen Unterschiede zwischen Beanstalk Standard und einer Beanstalk Cluster-Umgebung zusammengefasst. Jede Zeile enthält Links zu dem Thema, das das Elastic Beanstalk-Konzept ausführlich behandelt. | Aspekt | Beanstalk Standard | Beanstalk Cluster-Umgebung | | --- | --- | --- | | Datenverarbeitung | Dedizierte Amazon EC2-Instances in einer Auto Scaling-Gruppe, die über die Namespaces konfiguriert wurden. aws:autoscaling:\* | Container, die auf einem Amazon EKS-Cluster geplant sind und von Ihren Beanstalk-Cluster-Umgebungen gemeinsam genutzt werden können. Elastic Beanstalk isoliert jede Umgebung auf dem Cluster. Die Knoten werden von Amazon EKS Auto Mode bereitgestellt. | | Skalierung | Amazon EC2-Instances wurden von einer Auto Scaling-Gruppe hinzugefügt und entfernt, wobei Trigger und geplante Aktionen über die aws:autoscaling:\* Namespaces konfiguriert wurden. Siehe [Automatische Skalierung Ihrer Elastic Beanstalk-Umgebungsinstanzen](using-features.managing.as.md). | Anwendungsreplikate wurden innerhalb der max-replica Grenzen hinzugefügt und entfernt, min-replica was die CPU, den Arbeitsspeicher, einen Zeitplan oder eine Metrik angeht, die Ihr eigener Endpunkt meldet. Siehe [Skalierung von Beanstalk Cluster-Umgebungen](configuring-cluster-scaling.md). | | Artefakt zur Bereitstellung | Ein Quellpaket, das Elastic Beanstalk auf einem Plattform-AMI (Solution Stack) ausführt. Siehe [Von Elastic Beanstalk unterstützte Plattformen](concepts.platforms.md). | Ein Container-Image in Amazon Elastic Container Registry (Amazon ECR). Das Image wird direkt bereitgestellt, oder es wird eine Quelle bereitgestellt, damit Elastic Beanstalk sie in ein Image integrieren kann. Siehe [Erstellen von Container-Images für Beanstalk Cluster-Umgebungen](beanstalk-cluster-app-versions.md). | | Konzept der Plattform | Ein verwalteter Lösungspaket (Betriebssystem, Webserver und Sprachlaufzeit auf einem AMI). Siehe [Von Elastic Beanstalk unterstützte Plattformen](concepts.platforms.md). | Kein Lösungspaket oder AMI. Die Laufzeit wird durch das Container-Image und die Version des Clusters definiert, den Elastic Beanstalk erstellt. | | Bereitstellungsrichtlinie | All-at-once, fortlaufende oder unveränderliche Bereitstellungen, die über den Namespace konfiguriert werden. aws:elasticbeanstalk:command | Ein fortlaufendes Update (die Standardeinstellung) oder alles auf einmal, konfiguriert mit der strategy Option im Namespace. aws:elasticbeanstalk:eks:environment:deployment Der Optionswert für alles auf einmal istRecreate. | | Konfigurations-Namespaces | Klassische Namespaces wie und. aws:autoscaling:\* aws:elasticbeanstalk:environment Siehe [Konfigurationsoptionen](command-options.md). | Die Namespaces. aws:elasticbeanstalk:eks:\* Keiner der klassischen Compute-Namespaces gilt. | | Gesundheit | Wird vom Host-Manager und Load Balancer für jede Instanz gemeldet. | Per-instance Der Zustand wird nicht gemeldet. Bei einem Application Load Balancer umfasst der Status die Load Balancer-Metriken, die Elastic Beanstalk auswertet. Damit gilt diese load-balancer-type=None Bewertung von Anforderungsrate, Fehlerrate und Latenz nicht. Siehe [Überwachung von Beanstalk Cluster-Umgebungen](monitoring-cluster-environments.md). | ## Customer-provided und vom Service verwaltete Ressourcen Elastic Beanstalk erstellt und betreibt den Amazon EKS-Cluster, auf dem eine Beanstalk-Cluster-Umgebung ausgeführt wird. Die von Amazon EKS benötigten Cluster- und Node-Rollen AWS Identity and Access Management (IAM) werden vom Kunden bereitgestellt. Wir empfehlen, die unter beschriebenen Rollennamen und AWS verwalteten Richtlinien zu verwenden[Berechtigungen für Beanstalk Cluster](beanstalk-cluster-permissions.md), da Elastic Beanstalk verlangt, dass jede Umgebung auf einem Cluster dieselben Rollen bereitstellt. Eine Anwendungsrolle kann auch für die laufende Anwendung über Amazon EKS Pod Identity bereitgestellt werden. Die Anwendungsrolle wird bei der Erstellung der Umgebung in der Elastic Beanstalk-Konsole ausgewählt. Das vollständige IAM-Verantwortungsmodell und das Verfahren zur Verwendung von Anwendungsrollen finden Sie unter. [Berechtigungen für Beanstalk Cluster](beanstalk-cluster-permissions.md) VPC-Subnetze für die Umgebung sind optional. Wenn Subnetze weggelassen werden, verwendet Elastic Beanstalk die öffentlichen Subnetze der Standard-VPC. Der Subnetzsatz bestimmt, auf welchem Cluster die Umgebung ausgeführt wird. Informationen zur Clusterzuweisung und zur Infrastruktur, die Elastic Beanstalk betreibt, finden Sie unter. [Gruppierung der Umgebung](#beanstalk-cluster-clusters-sharing) Elastic Beanstalk betreibt die Anwendung auf dem vom Dienst erstellten Cluster. Es stellt das Container-Image bereit und wendet fortlaufende Aktualisierungen über den Namespace an. `aws:elasticbeanstalk:eks:environment:deployment` Es gleicht die laufende Anzahl von Anwendungsreplikaten mit den `min-replica` und -Grenzen in der Konfiguration ab`max-replica`. Es meldet den Zustand der Umgebung anhand der unter beschriebenen Gesundheitszustände. [Überwachung von Beanstalk Cluster-Umgebungen](monitoring-cluster-environments.md) Elastic Beanstalk verfolgt jeden Cluster, dem es Umgebungen zuweist, als service-verwaltet. **Wichtig** Elastic Beanstalk weist Umgebungen nur Clustern zu, die der erwarteten dienstverwalteten Konfiguration entsprechen. Wenn die Infrastruktur dieser Konfiguration nicht mehr entspricht, beendet Elastic Beanstalk die Auswahl des Clusters für neue Umgebungen. Änderungen an der Umgebung werden durch den Betrieb und die Konfiguration von Elastic Beanstalk vorgenommen. ## Anforderungen und Einschränkungen der Anwendung Eine Beanstalk Cluster-Umgebung erfordert eine Anwendung, die als Container-Image und als ein oder mehrere identische, austauschbare Replikate ausgeführt werden kann. Ein Load Balancer ist optional. Wenn ein Load Balancer konfiguriert ist, verteilt er Anfragen auf Anwendungsreplikate. Ein zustandsloser Webservice oder eine API, deren Replikate keinen lokalen Status haben, der einen Neustart überstehen muss, erfüllt diese Anforderung. Der Anforderungsport, die CPU- und Speicheranforderungen, die Anzahl der Anwendungsreplikate und das Bereitstellungsverhalten werden mithilfe der Optionen konfiguriert. `aws:elasticbeanstalk:eks:*` Elastic Beanstalk stellt die Clusterkapazität über den Amazon EKS-Automodus bereit. Bestätigen Sie die folgenden Anwendungsanforderungen und Einschränkungen, bevor Sie eine Beanstalk-Cluster-Umgebung erstellen: + Der lokale Speicher ist nicht persistent. Jede Kopie der Anwendung hat temporären Speicher, der verloren geht, wenn die Kopie neu gestartet wird. Eine Anwendung, die Uploads, Caches oder Arbeitsdateien auf die lokale Festplatte schreibt und dafür sorgt, dass sie einen Neustart überstehen, ist ohne externen persistenten Speicher nicht kompatibel. + Anfragen werden auf die Anwendungsreplikate verteilt. + Elastic Beanstalk erstellt ein Container-Image aus dem Quellcode für unterstützte Sprachen. Sie können auch ein Dockerfile oder ein vorgefertigtes Image bereitstellen. Siehe [Erstellen von Container-Images für Beanstalk Cluster-Umgebungen](beanstalk-cluster-app-versions.md). ## Konfigurationsbeispiel Die folgende AWS CLI Anforderung legt den Anforderungsport, die Speicheranforderung, die Anzahl der laufenden Replikate und das Bereitstellungsverhalten für eine Beanstalk Cluster-Umgebung fest. Die Einstellungen verwenden die Namespaces. `aws:elasticbeanstalk:eks:*` ``` $ aws elasticbeanstalk update-environment \ --environment-name my-cluster-env \ --option-settings \ Namespace=aws:elasticbeanstalk:eks:environment,OptionName=service-port,Value=8080 \ Namespace=aws:elasticbeanstalk:eks:environment,OptionName=memory,Value=1Gi \ Namespace=aws:elasticbeanstalk:eks:environment,OptionName=load-balancer-type,Value=ALB \ Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=min-replica,Value=3 \ Namespace=aws:elasticbeanstalk:eks:environment:autoscaling,OptionName=max-replica,Value=3 \ Namespace=aws:elasticbeanstalk:eks:environment:deployment,OptionName=strategy,Value=RollingUpdate \ Namespace=aws:elasticbeanstalk:eks:environment:deployment:strategy:rolling,OptionName=max-surge,Value=25% \ Namespace=aws:elasticbeanstalk:eks:environment:deployment:strategy:rolling,OptionName=max-unavailable,Value=0 ``` Die `strategy` Option akzeptiert `RollingUpdate` oder`Recreate`, was in der Konsole als fortlaufendes Update und als alles gleichzeitig angezeigt wird. Mit`RollingUpdate`, `max-surge` begrenzt, wie viele zusätzliche Replikate Elastic Beanstalk während einer Bereitstellung startet. Die `max-unavailable` Option begrenzt, wie viele vorhandene Replikate gleichzeitig heruntergefahren werden. Jede Option akzeptiert eine Anzahl oder einen Prozentsatz. Der `memory` Wert verwendet die Kubernetes-Mengenschreibweise wie `1Gi` oder. `512Mi` Den vollständigen Optionssatz finden Sie unter. [Konfigurationsoptionen für Beanstalk Cluster-Umgebungen](command-options-general-eks.md) ## Gruppierung der Umgebung Elastic Beanstalk gruppiert Ihre Beanstalk-Cluster-Umgebungen nach den von ihnen verwendeten VPC-Subnetzen in Clustern: + Umgebungen im selben AWS Konto, die denselben Satz von Subnetzen verwenden, werden auf demselben Cluster ausgeführt. * * + Eine Umgebung, die einen anderen Satz von Subnetzen verwendet, wird auf einem * anderen * Cluster ausgeführt. Die erste Umgebung, die Sie mit einer bestimmten Gruppe von Subnetzen erstellen, veranlasst Elastic Beanstalk, einen Cluster dafür zu erstellen, was etwa zehn Minuten dauert. Elastic Beanstalk meldet dies in den Ereignissen der Umgebung: ``` INFO Creating CloudFormation stack for cluster infrastructure. This is a one-time operation and generally takes about 10 minutes. stack='beanstalk-cluster-{{uuid}}' INFO Starting cluster assignment. environment='my-cluster-env' INFO Successfully completed cluster assignment. environment='my-cluster-env' clusterArn='arn:aws:eks:us-east-1:{{111122223333}}:cluster/beanstalk-cluster-{{uuid}}' ``` Elastic Beanstalk platziert spätere Umgebungen, die dieselben Subnetze verwenden, auf dem vorhandenen Cluster. Ihre Ereignisse melden die Zuweisung ohne die Meldung zur Stackerstellung. Elastic Beanstalk benennt sowohl den Cluster als auch den Stack, der AWS CloudFormation ihn erstellt. `beanstalk-cluster-{{uuid}}` Die Reihenfolge, in der Elastic Beanstalk Subnetze betrachtet, spielt keine Rolle. Dieselben Subnetze in einer anderen Reihenfolge sind dieselbe Gruppe. Nur die Subnetzgruppe wählt den Cluster aus. Wenn ein Cluster bereits für den Subnetzsatz registriert ist, müssen die von Ihnen angegebenen Cluster- und Knotenrolleneinstellungen mit den für diesen Cluster registrierten Rollen übereinstimmen. Elastic Beanstalk lehnt widersprüchliche Rolleneinstellungen ab; verschiedene Rollen-ARNs wählen keinen anderen Cluster aus. Sie geben auch die Observability-Rolle an, und Elastic Beanstalk validiert sie auf die gleiche Weise anhand des Clusters. Die optionale Anwendungsrolle gehört zur Umgebung und kann je nach Umgebung unterschiedlich sein. Konfigurieren Sie sie, indem Sie das Verfahren zur Erstellung der Umgebung unter aktivieren. [Konfigurieren Sie eine Anwendungsrolle](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-application-role) Elastic Beanstalk begrenzt nicht, wie viele Umgebungen sich einen Cluster teilen. Amazon EKS Auto Mode fügt Knoten hinzu, die zu den im Cluster geplanten Containern passen. Durch die gemeinsame Nutzung von Clustern wird kein umgebungsspezifisches Skalierungslimit hinzugefügt. Jede Umgebung unterliegt weiterhin ihren konfigurierten Replikat- oder Autoscaling-Grenzwerten, den geltenden Dienstkontingenten und der verfügbaren Kapazität. Um eine Umgebung auf einem separaten Cluster auszuführen, erstellen Sie ihn mit einer anderen Gruppe von Subnetzen. **Wichtig** Sie können die Subnetze oder die Cluster-, Knoten- und Observability-Rollen einer vorhandenen Beanstalk Cluster-Umgebung nicht ändern. Elastic Beanstalk lehnt ein solches Update ab, anstatt Ihre Umgebung in einen anderen Cluster zu verschieben, und meldet: `Changes to EKS cluster configuration (subnets and IAM roles) are not currently supported for an existing environment. Please revert these option settings to continue.` Um eine Anwendung in andere Subnetze oder Rollen zu verschieben, erstellen Sie eine neue Umgebung mit den gewünschten Einstellungen und tauschen Sie dann die beiden Umgebungs-CNAMES aus. Siehe [Blue/Green Bereitstellungen mit Elastic Beanstalk](using-features.CNAMESwap.md). Entscheiden Sie, welche Subnetze und Clusterrollen eine Umgebung verwendet, wenn Sie sie erstellen. Siehe [Erste Schritte mit Beanstalk Cluster](beanstalk-cluster-getting-started.md). ## Isolierung zwischen Umgebungen, die sich Rechenleistung teilen Subnetze sind die primäre Grenze zwischen Umgebungen. Da die Subnetzgruppe den Cluster auswählt, erhält eine Gruppe von Umgebungen mit eigenen Subnetzen ihren eigenen Cluster, ihre eigenen Knoten und ihr eigenes Netzwerk. Innerhalb eines einzelnen Clusters isoliert Elastic Beanstalk standardmäßig den Netzwerkverkehr zwischen Beanstalk-Cluster-Umgebungen. Mithilfe der Optionen im `aws:elasticbeanstalk:eks:environment` Namespace können Sie bestimmten Umgebungen die Kommunikation ermöglichen oder eine Umgebung auf dedizierten Knoten platzieren. Informationen zu den Grenzen, die Ihnen die einzelnen Optionen bieten, zu den Optionen, mit denen sie erweitert werden, und dazu, was ein gemeinsam genutzter Cluster nicht voneinander trennt, finden Sie unter. [Multi-tenancy für Beanstalk Cluster-Umgebungen](beanstalk-cluster-multi-tenancy.md) ## Konfiguration der verwalteten Infrastruktur Elastic Beanstalk erstellt jeden Cluster mit einer festen Konfiguration, die Sie nicht auswählen: | Einstellung | Was konfiguriert Elastic Beanstalk | | --- | --- | | Kubernetes-Version | Elastic Beanstalk wählt die Version bei der Clustererstellung aus. Elastic Beanstalk erstellt einen neuen Cluster mit der neuesten Kubernetes-Version, die es unterstützt. In einer Umgebung auf einem vorhandenen Cluster wird die Version ausgeführt, die der Cluster bereits hat. Diese Version bleibt für die gesamte Lebensdauer des Clusters unverändert. | | Kapazität des Knotens | Amazon EKS Auto Mode, der Knoten entsprechend den auf dem Cluster geplanten Containern hinzufügt und entfernt. Node-capacity Die Konfiguration wird vom Dienst verwaltet. | | Zugriff auf die Cluster-Infrastruktur | Service-managed. Konfigurieren Sie die Umgebung über die Elastic Beanstalk-API AWS CLI, die oder die Elastic Beanstalk-Konsole. | | Cluster-Add-ons | Elastic Beanstalk installiert und pingt die Add-Ons, auf die Ihre Umgebung angewiesen ist. Wenn Elastic Beanstalk eine neue angepinnte Add-On-Version einführt, wendet es das Update bei einer nachfolgenden Erstellung oder Aktualisierung der Umgebung auf Ihren Cluster an. Sie planen das Update nicht selbst und wenden es auch nicht an. | Da Elastic Beanstalk diese selbst festlegt, konfigurieren Sie Ihre * Anwendung * mithilfe der `aws:elasticbeanstalk:eks:*` Optionen, anstatt den Cluster zu konfigurieren. Siehe [Konfigurationsoptionen für Beanstalk Cluster-Umgebungen](command-options-general-eks.md). ## Abweichung bei der Cluster-Konfiguration Elastic Beanstalk betreibt einen Cluster, den es erstellt hat, nur solange dieser Cluster der erwarteten dienstverwalteten Konfiguration entspricht. Wenn die Infrastruktur dieser Konfiguration nicht mehr entspricht, erkennt Elastic Beanstalk eine Konfigurationsabweichung, unterbricht die Cluster-Wartung und meldet ein Umgebungsereignis: ``` ERROR Cluster drift detected for environment 'my-cluster-env'. {{what changed}}. Service will skip cluster maintenance for this environment. ``` Während ein Cluster driftet: + Elastic Beanstalk platziert keine neuen Umgebungen darauf. + Elastic Beanstalk verwaltet sie nicht mehr, auch nicht mehr per Service verwaltete Add-on-Versionsupdates. + Aktualisierungen der Umgebungen, die bereits darauf ausgeführt werden, schlagen fehl. Drift kann wiederhergestellt werden. Machen Sie zur Wiederherstellung die Änderung rückgängig, die den Fehler verursacht hat, sodass der Cluster wieder der Konfiguration entspricht, die Elastic Beanstalk erwartet. Das Drift-Ereignis benennt, was sich geändert hat, und zeigt Ihnen, was rückgängig gemacht werden muss. Elastic Beanstalk bewertet den Cluster beim nächsten Umgebungsvorgang erneut und nimmt die Verwaltung wieder auf, sobald die Konfiguration übereinstimmt. Versuchen Sie den fehlgeschlagenen Vorgang erneut. Wenn Sie die erwartete Konfiguration nicht wiederherstellen können, wenden Sie sich an den AWS Support. Um Abweichungen zu vermeiden, nehmen Sie Änderungen an der Umgebung mithilfe der Betriebs- und Konfigurationsoptionen von Elastic Beanstalk vor, anstatt den Cluster direkt zu ändern. Siehe [Konfigurationsoptionen für Beanstalk Cluster-Umgebungen](command-options-general-eks.md). ## Löschen des Clusters Elastic Beanstalk plant das Löschen des Clusters drei Stunden nach dem Beenden der letzten Umgebung. Wenn Sie in diesem Intervall eine weitere Umgebung mit denselben Subnetzen erstellen, bricht Elastic Beanstalk die ausstehende Bereinigung ab und verwendet den vorhandenen Cluster erneut. **Um das Löschen der vom Service verwalteten Infrastruktur zu überprüfen** 1. Bevor Sie die letzte Umgebung beenden, zeichnen Sie den Cluster-ARN über Elastic Beanstalk auf. Bei einer vom Dienst erstellten Cluster-Infrastruktur setzt die CloudFormation Vorlage den Clusternamen auf den Stack-Namen. Der Name nach dem letzten Schrägstrich des Cluster-ARN identifiziert daher den Stack für die schreibgeschützte Löschüberprüfung in diesem Verfahren: ``` $ aws elasticbeanstalk describe-environment-resources \ --environment-name my-cluster-env \ --query 'EnvironmentResources.Cluster.Name' ``` Der Befehl gibt den Cluster-ARN zurück. Der Stackname ist der Teil des ARN nach dem letzten Schrägstrich. **Wichtig** Der abgeleitete Stackname ist nur für den schreibgeschützten CloudFormation Kellner bestimmt und beschreibt die unten aufgeführten Operationen. Geben Sie ihn nicht an oder einen anderen Vorgang weiter `delete-stack``update-stack`, der die vom Service verwaltete Infrastruktur verändert. Notieren Sie den Cluster-ARN und den abgeleiteten Stacknamen. Sie verwenden sie für die nachfolgenden Schritte zur schreibgeschützten Überprüfung. 1. Beenden Sie die Umgebung und stellen Sie sicher, dass sie das Ziel erreicht, `Terminated` indem Sie die Schritte unter ausführen. [Elastic Beanstalk-Umgebung terminieren](using-features.terminating.md) Die Clusterbereinigung beginnt separat nach dem dreistündigen Wiederverwendungsintervall. Bei der Beendigung der Umgebung wird nicht auf das Löschen des Clusters gewartet. 1. Verwenden Sie nach drei Stunden einen IAM-Principal mit der Genehmigung, den vom Service erstellten Stack zu beschreiben. Der CloudFormation Kellner verwendet bis zu 60 Minuten lang alle 30 Sekunden schreibgeschützte Stack-Beschreibungen und ist erfolgreich, wenn der Stack nicht mehr existiert: ``` $ aws cloudformation wait stack-delete-complete \ --stack-name {{cluster-stack-name}} ``` Der Kellner hat Erfolg, wenn der Stapel nicht mehr existiert. Schlägt dies fehl, ist der Stack auch nach Ablauf der Frist noch vorhanden. Verwenden Sie `aws cloudformation describe-stacks` und`aws cloudformation describe-stack-events`, um den Stackstatus und alle `DELETE_FAILED` Ereignisse zu überprüfen. 1. Wenn der Kellner meldet, dass der Stack nach Ablauf der Frist immer noch existiert, stellen Sie fest, ob der Cluster in einer anderen Umgebung wiederverwendet wurde. Listet die aktiven Beanstalk-Cluster-Umgebungen im Konto und in der Region auf: ``` $ aws elasticbeanstalk describe-environments \ --query "Environments[?Tier.Name=='Cluster' && Tier.Type=='EKS'].EnvironmentName" ``` Lesen Sie für jede aufgelistete Umgebung ihren Cluster-ARN: ``` $ aws elasticbeanstalk describe-environment-resources \ --environment-name {{environment-name}} \ --query 'EnvironmentResources.Cluster.Name' ``` Eine Umgebung, deren Cluster-ARN mit dem aufgezeichneten Cluster-ARN übereinstimmt, bedeutet, dass das Löschen zur Wiederverwendung abgebrochen wurde. Wenn keine Umgebung passt, verwenden Sie den Stack-Status und die `DELETE_FAILED` Ereignisse, um die zurückgehaltenen Ressourcen zu diagnostizieren. Löschen oder ändern Sie einen vom Service verwalteten Stack nicht manuell. Wenden Sie sich an den AWS Support, falls der Stack auch nach Ablauf der Frist noch verfügbar ist, ohne dass eine aktive Umgebung oder ein umsetzbarer Fehler vorliegt CloudFormation .