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.
# Multi-tenancy für Beanstalk Cluster-Umgebungen
Beanstalk Cluster-Umgebungen, die dieselben Subnetze verwenden, werden auf demselben Amazon EKS-Cluster ausgeführt, sodass sie sich die Recheninfrastruktur teilen. Elastic Beanstalk trennt sie auf diesem gemeinsam genutzten Cluster: Die Anwendung jeder Umgebung wird in einer eigenen Partition des Clusters ausgeführt, und Elastic Beanstalk blockiert standardmäßig den Netzwerkverkehr zwischen Umgebungen. In diesem Thema wird beschrieben, welche Trennung Sie erhalten, wie Sie sie erweitern oder verschärfen können und welche Anforderungen ein gemeinsam genutzter Cluster nicht erfüllen kann.
Die Isolierung zwischen Beanstalk Cluster-Umgebungen hat zwei unabhängige Dimensionen. Die Netzwerkisolierung steuert, welche Umgebungen Datenverkehr an die Anwendung einer Umgebung senden können. Die Compute-Isolierung steuert, ob die Anwendungsreplikate einer Umgebung Knoten mit anderen Umgebungen gemeinsam nutzen. Sie können beide ohne die andere konfigurieren.
## Auswahl einer Isolationsgrenze
Entscheiden Sie, wie stark eine Umgebung sein muss, bevor Sie sie erstellen, da die Auswahl anhand der von Ihnen zugewiesenen Subnetze getroffen wird und Sie die Subnetze einer vorhandenen Umgebung nicht ändern können. Zwei Grenzen sind verfügbar, und sie entsprechen den beiden Mehrmandantenmodellen, die Amazon EKS dokumentiert.
| Grenze | Wie bekommst du es | Was es trennt |
| --- | --- | --- |
| Gemeinsamer Cluster (Soft-Multi-Tenancy) | Erstellen Sie die Umgebungen mit derselben Gruppe von Subnetzen. Dies ist die Standardeinstellung, wenn Umgebungen eine VPC-Konfiguration gemeinsam nutzen. | Die Anwendung jeder Umgebung wird in einer eigenen Partition des Clusters ausgeführt, wobei der Netzwerkverkehr zwischen Umgebungen standardmäßig blockiert ist. Die Umgebungen teilen sich den Cluster selbst und die Knoten gemeinsam, sofern Sie keine dedizierten Knoten konfigurieren. |
| Separate Cluster (harte Mehrmandantenfähigkeit) | Erstellen Sie die Umgebungen mit verschiedenen Gruppen von Subnetzen. Elastic Beanstalk erstellt dann für jeden Satz einen separaten Cluster. | Nichts wird geteilt. Separate Cluster haben separate Steuerungsebenen, separate Knoten und keinen Netzwerkpfad zwischen den Anwendungen, die auf ihnen ausgeführt werden. |
Ein gemeinsam genutzter Cluster sorgt für eine logische Trennung zwischen Umgebungen, die durch die Konfiguration erzwungen wird, die Elastic Beanstalk auf den Cluster anwendet. Ein separater Cluster sorgt für die Trennung der Infrastruktur. Amazon EKS dokumentiert den Cluster als das Konstrukt, das eine starke Sicherheitsgrenze bietet, da ein Workload, der Zugriff auf einen Knoten erlangt hat, die Anmeldeinformationen und Daten von allem anderen, was auf diesem Knoten ausgeführt wird, erreichen kann. Die logische Trennung innerhalb eines Clusters ist eine weiche Mehrmandantenfähigkeit; ein Cluster für jeden Mandanten ist eine harte Mehrmandantenfähigkeit. Allgemeine Hinweise, die sich daraus ergeben, finden Sie unter [ Tenant Isolation ](https://docs.aws.amazon.com/eks/latest/best-practices/tenant-isolation.html) im * Amazon EKS Best Practices Guide. *
**Wichtig**
Verwenden Sie separate Subnetzgruppen und daher separate Cluster, wenn in Umgebungen Workloads ausgeführt werden, die die Infrastruktur nicht gemeinsam nutzen dürfen. Beispiele hierfür sind Umgebungen, die verschiedenen Endkunden Ihres Unternehmens gehören, Umgebungen, in denen Code ausgeführt wird, auf den Sie keinen Einfluss haben, und Umgebungen, die einem Compliance-System unterliegen, das eine Trennung der Infrastruktur erfordert. Die im Rest dieses Themas beschriebenen Steuerelemente trennen Umgebungen in einem gemeinsam genutzten Cluster, aber sie machen einen gemeinsam genutzten Cluster nicht zu separaten Clustern.
Separate Cluster kosten mehr und nutzen die Kapazität weniger effizient, da jeder Cluster separat abgerechnet wird und Knoten nicht clusterübergreifend gemeinsam genutzt werden können. Ein gemeinsam genutzter Cluster ist die richtige Wahl für Umgebungen, die ein Team besitzt und gemeinsam betreibt, z. B. die Dienste, aus denen eine einzelne Anwendung besteht. Die Trennung von Produktion und Entwicklung ist ein häufiger Grund dafür, unterschiedliche Subnetzgruppen zu verwenden, auch wenn dies nicht erforderlich ist. Informationen dazu, wie Elastic Beanstalk Umgebungen in Clustern gruppiert, finden Sie unter. [Gruppierung der Umgebung](beanstalk-cluster-concepts.md#beanstalk-cluster-clusters-sharing) Die Subnetzeinstellungen selbst finden Sie unter. [Konfiguration des Netzwerks für Beanstalk Cluster-Umgebungen](configuring-cluster-networking.md)
## Netzwerkisolierung auf einem gemeinsam genutzten Cluster
Elastic Beanstalk blockiert standardmäßig den Netzwerkverkehr zwischen Beanstalk Cluster-Umgebungen auf einem gemeinsam genutzten Cluster. Dafür ist keine Konfiguration erforderlich, und es gibt keine Option, die es ausschaltet. Die Anwendungsreplikate einer Umgebung können auf keinem Port Datenverkehr von den Anwendungskopien einer anderen Umgebung empfangen, es sei denn, Sie erlauben dies mit einer der Optionen in diesem Abschnitt.
Elastic Beanstalk ermöglicht es seinen eigenen Betriebskomponenten, Ihre Anwendung zu erreichen, sodass Statusberichte, Protokollerfassung und metrikbasierte Skalierung weiterhin funktionieren.
Der Datenverkehr, der über den Load Balancer in eine Umgebung gelangt, ist davon nicht betroffen. Das Blockieren gilt für den Datenverkehr, der von den Anwendungsreplikaten einer Umgebung direkt an die einer anderen Umgebung gesendet wird, nicht für Datenverkehr, der von außerhalb des Clusters ankommt. Anfragen, die Ihre Anwendung über ihren Application Load Balancer erreichen, werden normal zugestellt, einschließlich Anfragen, die eine andere Umgebung an den öffentlichen Endpunkt dieses Load Balancers sendet.
### Ermöglicht die Kommunikation zwischen Umgebungen
Drei Optionen im `aws:elasticbeanstalk:eks:environment` Namespace ermöglichen den Verkehr zwischen Umgebungen in einem gemeinsam genutzten Cluster. Jede enthält eine durch Kommas getrennte Liste. Namen sind auf die Zeichen`a-z`, `A-Z``0-9`, und beschränkt`-`; sie müssen mit einem Buchstaben beginnen und 4 bis 40 Zeichen lang sein. Wenn Sie einen von ihnen ändern, wird die Umgebung nicht unterbrochen.
| Option | Auswirkung | Benutze es wenn |
| --- | --- | --- |
| ingress-groups | Verbindet die Umgebung mit einer oder mehreren benannten Gruppen. Jede Umgebung in einer Gruppe kann Datenverkehr in beide Richtungen an jede andere Umgebung in dieser Gruppe senden. Eine Umgebung kann zu mehr als einer Gruppe gehören. | Eine Reihe von Umgebungen müssen sich alle gegenseitig aufrufen, z. B. die Dienste einer Anwendung. |
| ingress-allowlist-environments | Erlaubt den benannten Umgebungen, Datenverkehr an diese Umgebung zu senden. Die Erlaubnis ist eine Möglichkeit: Wenn Sie eine Umgebung hier benennen, wird sie von dieser Umgebung nicht aufgerufen. | Eine Umgebung dient einer internen API, die von bestimmten anderen Umgebungen aufgerufen wird. |
| ingress-allowlist-groups | Ermöglicht jeder Umgebung in den genannten Gruppen, Datenverkehr in eine Richtung an diese Umgebung zu senden, ohne diesen Gruppen beizutreten. | Eine Umgebung dient einer Gruppe von Anrufern, die sich bereits eine Gruppe teilen, und dürfen im Gegenzug keinen Zugriff auf sie erhalten. |
Wird in jeder Umgebung eingerichtet`ingress-groups`, die der Gruppe beitritt. Die Gruppenmitgliedschaft wird nicht von einem Ort aus konfiguriert. Eine Umgebung verlässt eine Gruppe, wenn Sie die Gruppe aus ihrem `ingress-groups` Wert entfernen oder die Umgebung beenden. Stellen Sie die Allowlist-Optionen für die Umgebung ein, die * den Datenverkehr * empfängt, und benennen Sie die Anrufer, die Sie zulassen möchten.
Die beiden Mechanismen kombinieren sich. Eine Umgebung kann einer Gruppe für die Dienste beitreten, mit denen sie als Peer arbeitet, und einen Anrufer, der sie in einer Richtung erreichen muss, separat zulassen. Informationen zum Festlegen von Konfigurationsoptionen für eine Umgebung finden Sie unter. [Konfigurationsoptionen](command-options.md)
Durch das Zulassen des Datenverkehrs wird die Erkennung nicht konfiguriert. Ihre Anwendung muss trotzdem wissen, welche Adresse angerufen werden soll. Diese Adresse geben Sie auf dieselbe Weise an, wie Sie jede andere Einstellung über eine Umgebungseigenschaft angeben. Elastic Beanstalk fügt die Adressen der Umgebungen, die Sie zulassen, nicht ein.
## Dedizierte Knoten für eine Umgebung
Standardmäßig plant Elastic Beanstalk Anwendungsreplikate aus jeder Umgebung auf der gemeinsam genutzten Knotenkapazität des Clusters, sodass Kopien aus verschiedenen Umgebungen auf demselben Knoten ausgeführt werden können. Um die Anwendungsreplikate einer Umgebung auf Knoten zu speichern, die keine andere Umgebung verwendet, setzen Sie die `node-pool` Option im `aws:elasticbeanstalk:eks:environment` Namespace auf einen Namen Ihrer Wahl.
Elastic Beanstalk reserviert dann eine Reihe von Knoten für diesen Namen und plant nur Anwendungsreplikate aus Umgebungen mit demselben Wert für diese Knoten ein. `node-pool` Umgebungen, in denen kein Wert oder ein anderer Wert festgelegt ist, können nicht auf diesen Knoten platziert werden.
**Wichtig**
Umgebungen, die einen gemeinsamen `node-pool` Wert haben, teilen sich Knoten miteinander. Um einer einzelnen Umgebung Knoten zuzuweisen, die sonst nicht verwendet werden, weisen Sie ihr einen Wert zu, den keine andere Umgebung verwendet.
Beim Ändern werden die Anwendungsreplikate der Umgebung `node-pool` neu gestartet, sodass Elastic Beanstalk sie auf die richtigen Knoten verschieben kann. Dedizierte Knoten reduzieren auch die Auswirkungen der Ressourcennutzung einer Umgebung auf eine andere, da die Umgebungen nicht mehr um die CPU und den Arbeitsspeicher desselben Knotens konkurrieren. Dedizierte Knoten sind unabhängig von der Netzwerkisolierung: Umgebungen können auf separaten Knoten ausgeführt werden und trotzdem kommunizieren dürfen, oder sie teilen sich Knoten und werden von der Kommunikation ausgeschlossen.
Reservieren Sie `node-pool` für eine Anforderung, die sich speziell auf die Knotenkapazität bezieht. Wenn Ihr Ziel darin besteht, Umgebungen voneinander zu trennen, ist es einfacher, ihnen verschiedene Subnetze zuzuweisen, da sowohl der Cluster als auch die Knoten voneinander getrennt werden.
## Was ein gemeinsam genutzter Cluster nicht trennt
Machen Sie sich mit diesen Grenzwerten vertraut, bevor Sie Umgebungen mit unterschiedlichen Sicherheits- oder Compliance-Anforderungen auf demselben Cluster platzieren. Jeder von ihnen ist darauf zurückzuführen, dass sich die Umgebungen einen Cluster teilen, und jeder wird entfernt, indem den Umgebungen unterschiedliche Subnetze zugewiesen werden, sodass Elastic Beanstalk separate Cluster erstellt.
+ **Ausgehender Verkehr ist nicht eingeschränkt. ** Die Standardtrennung blockiert den Verkehr, der in einer Umgebung ankommt. Sie schränkt nicht ein, wohin die Anwendung einer Umgebung Datenverkehr senden kann. Eine Anwendung kann jedes Ziel erreichen, das ihre Netzwerkkonfiguration und ihre IAM-Berechtigungen zulassen, einschließlich des Internets und anderer AWS Dienste. Es gibt keine Option, die den ausgehenden Datenverkehr aus einer Beanstalk-Cluster-Umgebung einschränkt.
+ **Die Steuerungsebene des Clusters wird gemeinsam genutzt. ** Jede Umgebung auf dem Cluster wird von einer Amazon EKS-Steuerungsebene bedient, und ihre Kubernetes-Version ist für die gesamte Lebensdauer des Clusters festgelegt. Elastic Beanstalk bedient die Steuerungsebene und Sie konfigurieren sie nicht, aber sie wird nicht pro Umgebung dupliziert.
+ **Knoten werden gemeinsam genutzt, sofern Sie keine dedizierten Knoten konfigurieren. ** `node-pool`Andernfalls werden Anwendungsreplikate aus verschiedenen Umgebungen auf denselben Knoten ausgeführt und beanspruchen dieselbe CPU und denselben Arbeitsspeicher. Elastic Beanstalk reserviert keine Knotenkapazität pro Umgebung.
+ **Cluster-wide Fehler wirken sich auf jede Umgebung im Cluster aus. ** Wenn Elastic Beanstalk die Verwaltung eines Clusters einstellt, weil seine Infrastruktur nicht mehr der erwarteten Konfiguration entspricht, schlagen Aktualisierungen für jede Umgebung auf diesem Cluster fehl, bis die Abweichung behoben ist. Die Wiederherstellung erfolgt pro Cluster und nicht pro Umgebung: Machen Sie die Änderung rückgängig, die sie verursacht hat, und Elastic Beanstalk nimmt die Verwaltung des Clusters und all seiner Umgebungen wieder auf. Siehe [Abweichung bei der Cluster-Konfiguration](beanstalk-cluster-concepts.md#beanstalk-cluster-clusters-drift).
Application-level Für den Schutz sind Sie an beiden Grenzen verantwortlich. Durch die Netzwerktrennung zwischen Umgebungen werden weder Anrufer authentifiziert, noch der Datenverkehr zwischen Umgebungen verschlüsselt noch eingeschränkt, was eine Anwendung mit den gespeicherten Anmeldeinformationen macht. Weisen Sie jeder Umgebung ihre eigene Anwendungsrolle zu, sodass ihre AWS Berechtigungen auf sie beschränkt sind, und behandeln Sie erlaubten Datenverkehr zwischen Umgebungen als Datenverkehr, den Ihre Anwendung noch autorisieren muss. Siehe [Berechtigungen für die Anwendung](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-application).
## Abgleich einer Anforderung mit einer Kontrolle
| Anforderung | Steuerung |
| --- | --- |
| Umgebungen dürfen die Infrastruktur nicht gemeinsam nutzen | Erstellen Sie sie mit unterschiedlichen Gruppen von Subnetzen, sodass Elastic Beanstalk für jedes Subnetz einen eigenen Cluster erstellt. Entscheiden Sie dies, bevor Sie die Umgebungen erstellen. Sie können die Subnetze danach nicht mehr ändern. |
| Umgebungen dürfen einander nicht über das Netzwerk erreichen | Keine Konfiguration. Dies ist die Standardeinstellung für einen gemeinsam genutzten Cluster. |
| Eine Reihe von Umgebungen muss sich gegenseitig aufrufen | Stellen ingress-groups Sie für jede von ihnen den gleichen Gruppennamen ein. |
| Eine Umgebung muss Anrufe von bestimmten anderen akzeptieren, aber nicht umgekehrt | Stellen Sie ingress-allowlist-environments oder ingress-allowlist-groups auf die Umgebung ein, die den Verkehr empfängt. |
| Die Anwendungsreplikate einer Umgebung dürfen sich keine Knoten mit anderen Umgebungen teilen | Auf node-pool einen Wert setzen, den keine andere Umgebung verwendet. |
| Der ausgehende Verkehr einer Umgebung muss eingeschränkt werden | Nicht über eine Konfigurationsoption verfügbar. Schränken Sie es in der Anwendung oder über die Netzwerkkonfiguration der Subnetze ein, die Sie der Umgebung zuweisen. |