Optimierung der Nutzung von IP-Adressen

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.

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.

Containerisierte Umgebungen nehmen dank der Modernisierung von Anwendungen rasant an Umfang zu. Das bedeutet, dass immer mehr Worker-Knoten und Pods bereitgestellt werden.

Das Amazon VPC CNI-Plugin weist jedem Pod eine IP-Adresse aus den CIDR (s) der VPC zu. Dieser Ansatz bietet mit 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.

Beim Entwerfen Ihrer AWS-Netzwerkarchitektur ist es wichtig, den IP-Verbrauch von Amazon EKS auf VPC- und Knotenebene zu optimieren. Auf diese Weise können Sie Probleme mit der IP-Erschöpfung verringern und die Pod-Dichte pro Knoten 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äfix-Delegierung ist eine Funktion von Amazon Virtual Private Cloud (Amazon VPC), mit der Sie Ihren Amazon Elastic Compute Cloud (Amazon EC2) -Instances IPv6 Präfixe zuweisen IPv4 können. Sie erhöht die IP-Adressen pro Netzwerkschnittstelle (ENI), was die Pod-Dichte pro Knoten erhöht und Ihre Recheneffizienz verbessert. Die Präfix-Delegierung wird auch bei Custom Networking unterstützt.

Ausführliche Informationen finden Sie in den Abschnitten Präfix-Delegierung mit Linux-Knoten und Präfix-Delegierung 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 Cluster VPCs und der Subnetze das Wachstum zu berücksichtigen.

Adoption IPv6ist eine hervorragende Möglichkeit, diese Probleme von Anfang an zu vermeiden. Für Unternehmen, deren Skalierbarkeitsanforderungen über die ursprüngliche Planung hinausgehen und diese nicht übernehmen können IPv6, ist die Verbesserung des VPC-Designs jedoch die empfohlene Antwort auf die Erschöpfung der IP-Adressen. Die von Amazon EKS-Kunden am häufigsten verwendete Technik besteht darin, der VPC nicht routingfähige sekundäre Daten hinzuzufügen und die VPC-CNI so CIDRs zu konfigurieren, dass sie diesen zusätzlichen IP-Bereich bei der Zuweisung von IP-Adressen zu Pods verwendet. Dies wird allgemein als benutzerdefiniertes Netzwerk bezeichnet.

Wir werden uns damit befassen, welche Variablen des Amazon VPC CNI Sie verwenden können, um den Ihren Knoten IPs zugewiesenen Warmpool zu optimieren. Wir werden diesen Abschnitt mit einigen anderen Architekturmustern schließen, die zwar nicht Teil von Amazon EKS sind, aber dazu beitragen können, die IP-Erschöpfung zu verringern.

Verwendung (empfohlen) IPv6

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

Amazon EKS-Cluster unterstützen IPv4 sowohl als auch IPv6. Standardmäßig verwenden EKS-Cluster den IPv4 Adressraum. Die Angabe eines IPv6 basierten Adressraums bei der Clustererstellung ermöglicht die Verwendung von IPv6. In einem IPv6 EKS-Cluster erhalten Pods und Dienste IPv6 Adressen, während ältere IPv4 Endgeräte 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. Innerhalb einer VPC (/56) ist die IPv6 CIDR-Blockgröße für IPv6 Subnetze auf /64 festgelegt. Dies bietet 2^64 (ungefähr 18 Trillionen) Adressen, sodass Sie Ihre Bereitstellungen auf EKS skalieren können. IPv6

Ausführliche Informationen finden Sie im Abschnitt Ausführen von IPv6 EKS-Clustern und praktische Erfahrungen finden Sie im Abschnitt Grundlegendes IPv6 zu Amazon EKS des Workshops Get hands-on with IPv6 .

Optimieren Sie den IP-Verbrauch in IPv4 Clustern

Dieser Abschnitt richtet sich an Kunden, die ältere Anwendungen ausführen und/oder noch nicht bereit sind, zu ihnen zu migrieren IPv6. Wir ermutigen zwar alle Unternehmen, IPv6 so schnell wie möglich auf diese Version umzusteigen, sind uns jedoch bewusst, dass einige Unternehmen möglicherweise noch nach alternativen Ansätzen suchen müssen, um ihre Container-Workloads zu skalieren. IPv4 Aus diesem Grund führen wir Sie auch durch die Architekturmuster zur Optimierung IPv4 (RFC1918) der Adressspeicherbelegung mit Amazon EKS-Clustern.

Planen Sie für Wachstum

Als erste Verteidigungslinie gegen IP-Erschöpfung empfehlen wir dringend, Ihre Größe IPv4 VPCs und die 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.

Vor dem Aufbau von VPC und Subnetzen wird empfohlen, von der erforderlichen Workload-Skala aus rückwärts zu arbeiten. Wenn Cluster beispielsweise 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 und ermöglicht die Zuweisung von mehr als 8000 Adressen.

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 hier). 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 Beispieltabelle 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. Denken Sie daran, dass wir empfehlen, ein neues Subnetz mit den ursprünglichen CIDR-Blöcken der VPC zu erstellen, wenn Subnetze in Ihrer VPC keine verfügbaren IP-Adressen mehr haben. Beachten Sie, dass Amazon EKS jetzt die Änderung von Cluster-Subnetzen und Sicherheitsgruppen ermöglicht.

Benutzerdefiniertes Netzwerk

Wenn Sie im Begriff sind, den RFC1918 IP-Speicherplatz zu erschöpfen, können Sie das benutzerdefinierte Netzwerkmuster verwenden, um Routing-fähig zu halten, IPs indem Sie Pods in dedizierten zusätzlichen Subnetzen einplanen. Benutzerdefinierte Netzwerke akzeptieren zwar einen gültigen VPC-Bereich für den sekundären CIDR-Bereich, wir empfehlen jedoch, CIDRs (/16) aus dem CG-NAT-Bereich zu verwenden, d. h. 100.64.0.0/10 oder, 198.19.0.0/16 da diese in einer Unternehmensumgebung mit geringerer Wahrscheinlichkeit verwendet werden als Bereiche. RFC1918

Ausführliche Informationen finden Sie im speziellen Abschnitt für benutzerdefinierte Netzwerke.

Verbesserte Subnetzerkennung

Enhanced Subnet Discovery bietet eine optimierte Alternative zur Netzwerkkonfiguration bei IP-Erschöpfung, indem neue Subnetze markiert werden, sodass sie vom Amazon VPC CNI erkannt werden können. 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 die aktuellen Subnetze Ihres Clusters keine IP-Adressen mehr haben, können Sie Ihrem Amazon EKS-Cluster einfach wie folgt zusätzliche 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 unter Amazon VPC CNI provides Enhanced Subnet Discovery im AWS-Container-Blog.

Optimieren Sie den warmen Pool IPs

Mit der Standardkonfiguration behält das VPC-CNI eine gesamte ENI (und die zugehörige IPs) im warmen Pool. Dies kann eine große Anzahl von Daten in Anspruch nehmen IPs, insbesondere bei größeren Instance-Typen.

Wenn in Ihrem Cluster-Subnetz nur eine begrenzte Anzahl von IP-Adressen verfügbar ist, überprüfen Sie diese Umgebungsvariablen für die VPC-CNI-Konfiguration:

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 aufzurufen.

Bitte beachten Sie, dass ein WARM_IP_TARGET zu niedriger Wert zu zusätzlichen Aufrufen der EC2 API führen kann, was zu einer Drosselung der Anfragen führen kann. Verwenden Sie bei großen Clustern zusammen mit, MINIMUM_IP_TARGET um eine Drosselung 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 für Ihre vorhandenen Anwendungen im laufenden Betrieb ohne Ausfallzeiten anpassen. Sie sollten jedoch Werte wählen, die Ihren Skalierbarkeitsanforderungen entsprechen. Wenn Sie beispielsweise mit Batch-Workloads arbeiten, empfehlen wir, die Standardeinstellung so zu aktualisieren, dass sie den Anforderungen WARM_ENI_TARGET an die Pod-Skalierung entspricht. Durch WARM_ENI_TARGET die Einstellung auf einen hohen Wert bleibt immer der warme IP-Pool erhalten, der für die Ausführung großer Batch-Workloads erforderlich ist, und somit werden Verzögerungen bei der Datenverarbeitung vermieden.

Überwachen Sie den IP-Adressbestand

Zusätzlich zu den oben beschriebenen Lösungen ist es auch wichtig, einen Überblick über die IP-Auslastung 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 noch andere Architekturmuster, die Amazon EKS nicht eigen sind und die bei IP-Erschöpfung helfen können. Sie können beispielsweise die Kommunikation zwischen Konten optimieren VPCs oder eine VPC für mehrere Konten gemeinsam nutzen, um die IPv4 Adresszuweisung einzuschränken.

Erfahren Sie hier mehr über diese Muster: