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.

Optimierung der IP-Adressnutzung

Containerisierte Umgebungen nehmen dank der Anwendungsmodernisierung in rasantem Tempo an Umfang zu. Das bedeutet, dass immer mehr Worker Nodes und Pods eingesetzt werden.

Das Amazon VPC CNI-Plugin weist jedem Pod eine IP-Adresse aus den CIDR (s) der VPC zu. Dieser Ansatz bietet mithilfe von Tools wie VPC Flow Logs und anderen Überwachungslösungen eine vollständige Sichtbarkeit der Pod-Adressen. Je nach Workload-Typ kann dies dazu führen, dass eine beträchtliche Anzahl von IP-Adressen von den Pods verbraucht wird.

Bei der Gestaltung Ihrer AWS-Netzwerkarchitektur ist es wichtig, die Amazon EKS-IP-Nutzung auf VPC- und Knotenebene zu optimieren. Dies hilft Ihnen, Probleme mit der IP-Erschöpfung zu vermeiden und die Pod-Dichte pro Knoten zu erhöhen.

In diesem Abschnitt werden wir Techniken besprechen, die Ihnen helfen können, diese Ziele zu erreichen.

Optimieren Sie den IP-Verbrauch auf Knotenebene

Die Präfixdelegierung ist eine Funktion von Amazon Virtual Private Cloud (Amazon VPC), mit der Sie Ihren Amazon Elastic Compute Cloud (Amazon EC2) -Instances IPv4- oder IPv6-Präfixe zuweisen können. Es erhöht die IP-Adressen pro Netzwerkschnittstelle (ENI), was die Pod-Dichte pro Knoten erhöht und Ihre Recheneffizienz verbessert. Die Delegierung von Präfixen wird auch mit Custom Networking unterstützt.

Detaillierte Informationen finden Sie in den Abschnitten Präfixdelegierung mit Linux-Knoten und Präfixdelegierung mit Windows-Knoten.

Reduzieren Sie die IP-Erschöpfung

Um zu verhindern, dass Ihre Cluster alle verfügbaren IP-Adressen verbrauchen, empfehlen wir dringend, bei der Dimensionierung Ihrer VPCs und Subnetze das Wachstum zu berücksichtigen.

Die Einführung von IPv6 ist eine hervorragende Möglichkeit, diese Probleme von Anfang an zu vermeiden. Für Unternehmen, deren Skalierbarkeitsanforderungen die anfängliche Planung übersteigen und die IPv6 nicht einführen können, ist die Verbesserung des VPC-Designs jedoch die empfohlene Reaktion auf die Erschöpfung der IP-Adressen. Die bei Amazon EKS-Kunden am häufigsten verwendete Technik besteht darin, der VPC nicht routingfähige sekundäre CIDRs hinzuzufügen und das VPC-CNI so zu konfigurieren, dass dieser zusätzliche IP-Bereich bei der Zuweisung von IP-Adressen zu Pods verwendet wird. Dies wird allgemein als benutzerdefiniertes Netzwerk bezeichnet. Benutzerdefiniertes Netzwerk

Wir werden erläutern, welche Variablen des Amazon VPC-CNI Sie verwenden können, um den warmen IP-Pool zu optimieren, der Ihren Knoten zugewiesen ist. Wir schließen diesen Abschnitt mit einigen anderen Architekturmustern, die Amazon EKS nicht eigen sind, aber dazu beitragen können, die IP-Erschöpfung zu verringern.

Verwenden Sie IPv6 (empfohlen)

Die Einführung von IPv6 ist der einfachste Weg, um die Einschränkungen von RFC1918 zu umgehen. Wir empfehlen dringend, IPv6 als erste Option bei der Auswahl einer Netzwerkarchitektur in Betracht zu ziehen. IPv6 bietet insgesamt einen deutlich größeren IP-Adressraum, und Clusteradministratoren können sich auf die Migration und Skalierung von Anwendungen konzentrieren, ohne sich um die IPv4-Beschränkungen kümmern zu müssen.

Amazon EKS-Cluster unterstützen sowohl IPv4 als auch IPv6. Standardmäßig verwenden EKS-Cluster den IPv4-Adressraum. Wenn Sie bei der Clustererstellung einen IPv6-basierten Adressraum angeben, wird die Verwendung von IPv6 ermöglicht. In einem IPv6-EKS-Cluster erhalten Pods und Dienste IPv6-Adressen, während ältere IPv4-Endpunkte weiterhin eine Verbindung zu Diensten herstellen können, die auf IPv6-Clustern ausgeführt werden, und umgekehrt. Die gesamte Pod-to-Pod-Kommunikation innerhalb eines Clusters erfolgt immer über IPv6. In einer VPC (/56) ist die IPv6-CIDR-Blockgröße für IPv6-Subnetze auf /64 festgelegt. Dies bietet 2^64 (ungefähr 18 Trillionen) IPv6-Adressen, mit denen Sie Ihre Bereitstellungen auf EKS skalieren können.

Ausführliche Informationen finden Sie im Abschnitt Ausführen von IPv6-EKS-Clustern. Praktische Erfahrungen finden Sie im Abschnitt Understanding IPv6 on Amazon EKS des Workshops Get Hands-on with IPv6. https://catalog.workshops.aws/ipv6-on-aws/en-US

Optimieren Sie den IP-Verbrauch in IPv4-Clustern

Dieser Abschnitt richtet sich an Kunden, die ältere Anwendungen ausführen und noch nicht bereit and/or sind, auf IPv6 zu migrieren. Wir empfehlen zwar allen Unternehmen, so schnell wie möglich auf IPv6 zu migrieren, aber wir sind uns bewusst, dass einige Unternehmen möglicherweise noch nach alternativen Ansätzen suchen müssen, um ihre Container-Workloads mit IPv4 zu skalieren. Aus diesem Grund werden wir Sie auch durch die Architekturmuster führen, um den IPv4-Adressspeicherverbrauch (RFC1918) mit Amazon EKS-Clustern zu optimieren.

Planen Sie für Wachstum

Als erste Verteidigungslinie gegen IP-Erschöpfung empfehlen wir dringend, Ihre IPv4-VPCs und -Subnetze unter Berücksichtigung des Wachstums zu dimensionieren, um zu verhindern, dass Ihre Cluster alle verfügbaren IP-Adressen verbrauchen. Sie können keine neuen Pods oder Knoten erstellen, wenn die Subnetze nicht über genügend verfügbare IP-Adressen verfügen.

Bevor Sie VPC und Subnetze erstellen, wird empfohlen, von der erforderlichen Workload-Skala aus rückwärts zu arbeiten. Wenn beispielsweise Cluster mit eksctl (einem einfachen CLI-Tool zum Erstellen und Verwalten von Clustern auf EKS) erstellt werden, werden standardmäßig /19-Subnetze erstellt. Eine Netzmaske von /19 ist für die meisten Workload-Typen geeignet, sodass mehr als 8000 Adressen zugewiesen werden können.

Darüber hinaus kann Amazon EKS bis zu 4 elastische Netzwerkschnittstellen (X-ENI) erstellen, die für die Kommunikation mit der Steuerungsebene erforderlich sind (weitere Informationen finden Sie hier). Überlegungen zu VPC und Subnetz Bei Cluster-Upgrades erstellt Amazon EKS neue X-ENIs und löscht die alten, wenn das Upgrade erfolgreich ist. Aus diesem Grund empfehlen wir eine Netzmaske von mindestens /28 (16 IP-Adressen) für Subnetze, die einem EKS-Cluster zugeordnet sind.

Sie können die https://github.com/aws/aws-eks-best-practices/blob/master/latest/bpg/networking/subnet-calc/subnet-calc.xlsx Beispieltabelle des EKS Subnet Calculator verwenden, um Ihr Netzwerk zu planen. Die Tabelle berechnet die IP-Nutzung auf der Grundlage von Workloads und der VPC-ENI-Konfiguration. Die IP-Nutzung wird mit einem IPv4-Subnetz verglichen, um festzustellen, ob die Konfiguration und die Subnetzgröße für Ihre Arbeitslast ausreichend sind. Beachten Sie, dass wir empfehlen, ein neues Subnetz mit den ursprünglichen CIDR-Blöcken der VPC zu erstellen, wenn die verfügbaren IP-Adressen für Subnetze in Ihrer VPC ausgehen. Beachten Sie, dass Amazon EKS jetzt die Änderung von Cluster-Subnetzen und Sicherheitsgruppen ermöglicht.

Benutzerdefiniertes Netzwerk

Wenn Sie dabei sind, den RFC1918-IP-Speicherplatz auszuschöpfen, können Sie das benutzerdefinierte Netzwerkmuster verwenden, um routingfähige IPs zu schonen, indem Sie Pods in dedizierten zusätzlichen Subnetzen einplanen. Benutzerdefinierte Netzwerke akzeptieren zwar gültige VPC-Bereiche für den sekundären CIDR-Bereich, wir empfehlen jedoch, CIDRs aus dem 100.64.0.0/10 gemeinsam genutzten Adressraum (RFC 6598) zu verwenden, da diese in einer Unternehmensumgebung mit geringerer Wahrscheinlichkeit verwendet werden als RFC1918-Bereiche. Sie können es beispielsweise als sekundären CIDR für Ihre VPC verwenden100.64.0.0/16. Zulässige sekundäre CIDR-Bereiche finden Sie unter https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html#add-cidr-block-restrictions IPv4-CIDR-Blockzuordnungsbeschränkungen.

Detaillierte Informationen finden Sie im entsprechenden Abschnitt für benutzerdefinierte Netzwerke.

Verbesserte Subnetzerkennung

Enhanced Subnet Discovery bietet eine optimierte Netzwerkkonfigurationsalternative gegen IP-Erschöpfung, indem neue Subnetze markiert werden, sodass sie vom Amazon VPC-CNI erkannt werden können. Amazon VPC CNI Mit Enhanced Subnet Discovery können die aktuellen Workloads weiterhin in denselben Subnetzen ausgeführt werden, und Amazon Elastic Kubernetes Service (Amazon EKS) kann jetzt zusätzliche Pods in den neuen „nutzbaren Subnetzen“ planen.

Wenn den aktuellen Subnetzen Ihres Clusters die IP-Adressen ausgehen, können Sie Ihrem Amazon EKS-Cluster einfach wie folgt weitere Subnetze hinzufügen:

Sobald Enhanced Subnet Discovery auf Ihren VPC- und Amazon EKS-Clustern aktiviert ist, werden neue Elastic Network Interfaces (ENIs) an Ihre Amazon EKS-Knoten angehängt, wie in der folgenden Abbildung beschrieben:

Weitere Informationen finden Sie im AWS-Container-Blog unter Amazon VPC CNI führt Enhanced Subnet Discovery ein.

Optimieren Sie den warmen IP-Pool

In der Standardkonfiguration speichert das VPC-CNI eine gesamte ENI (und die zugehörigen IPs) im warmen Pool. Dies kann eine große Anzahl von IPs verbrauchen, insbesondere bei größeren Instance-Typen.

Wenn in Ihrem Cluster-Subnetz eine begrenzte Anzahl von IP-Adressen verfügbar ist, sollten Sie die folgenden VPC-CNI-Konfigurationsumgebungsvariablen unter die Lupe nehmen:

Sie können den Wert von so konfigurierenMINIMUM_IP_TARGET, dass er der Anzahl der Pods, die Sie voraussichtlich auf Ihren Knoten ausführen werden, genau entspricht. Dadurch wird sichergestellt, dass das CNI bei der Erstellung von Pods IP-Adressen aus dem warmen Pool zuweisen kann, ohne die EC2-API aufrufen zu müssen.

Bitte beachten Sie, dass ein WARM_IP_TARGET zu niedriger Wert zu zusätzlichen Aufrufen der EC2-API führt, was zu einer Drosselung der Anfragen führen kann. Verwenden Sie bei großen Clustern zusammen mit, um eine Drosselung MINIMUM_IP_TARGET der Anfragen zu vermeiden.

Um diese Optionen zu konfigurieren, können Sie das aws-k8s-cni.yaml Manifest herunterladen und die Umgebungsvariablen festlegen. Zum Zeitpunkt der Erstellung dieses Artikels befindet sich die neueste Version hier. Überprüfen Sie, ob die Version des Konfigurationswerts mit der installierten VPC-CNI-Version übereinstimmt.

Sie können die CNI-Parameter im laufenden Betrieb ohne Ausfallzeiten für Ihre vorhandenen Anwendungen anpassen. Sie sollten jedoch Werte wählen, die Ihren Skalierbarkeitsanforderungen entsprechen. Wenn Sie beispielsweise mit Batch-Workloads arbeiten, empfehlen wir, die Standardwerte so WARM_ENI_TARGET zu aktualisieren, dass sie den Anforderungen der Pod-Skala entsprechen. Wenn WARM_ENI_TARGET Sie einen hohen Wert festlegen, bleibt immer der warme IP-Pool erhalten, der für die Ausführung großer Batch-Workloads erforderlich ist, und so Verzögerungen bei der Datenverarbeitung vermieden werden.

Überwachen Sie den IP-Adressbestand

Zusätzlich zu den oben beschriebenen Lösungen ist es auch wichtig, einen Überblick über die IP-Nutzung zu haben. Sie können den IP-Adressbestand von Subnetzen mit CNI Metrics Helper überwachen. Einige der verfügbaren Metriken sind:

Sie können auch CloudWatch Alarme einrichten, um benachrichtigt zu werden, wenn einem Subnetz die IP-Adressen ausgehen.

Weitere Überlegungen

Es gibt andere Architekturmuster, die Amazon EKS nicht eigen sind und die bei der Erschöpfung des geistigen Eigentums helfen können. Sie können beispielsweise die Kommunikation zwischen VPCs optimieren oder eine VPC für mehrere Konten gemeinsam nutzen, um die IPv4-Adresszuweisung einzuschränken.

Erfahren Sie hier mehr über diese Muster: