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.

Benutzerdefiniertes Netzwerk

Standardmäßig weist Amazon VPC CNI Pods eine IP-Adresse zu, die aus dem primären Subnetz ausgewählt wurde. Das primäre Subnetz ist das Subnetz-CIDR, an das die primäre ENI angeschlossen ist, normalerweise das Subnetz von. node/host

Wenn das Subnetz-CIDR zu klein ist, kann das CNI möglicherweise nicht genügend sekundäre IP-Adressen abrufen, um sie Ihren Pods zuzuweisen. Dies ist eine häufige Herausforderung für EKS-IPv4-Cluster.

Benutzerdefiniertes Netzwerk ist eine Lösung für dieses Problem.

Benutzerdefinierte Netzwerke lösen das Problem der IP-Erschöpfung, indem die Knoten- und Pod-IPs aus sekundären VPC-Adressräumen (CIDR) zugewiesen werden. Die benutzerdefinierte Netzwerkunterstützung unterstützt die benutzerdefinierte EniConfig-Ressource. Die EniConfig enthält einen alternativen Subnetz-CIDR-Bereich (der aus einem sekundären VPC-CIDR stammt) sowie die Sicherheitsgruppe (n), zu der die Pods gehören werden. Wenn das benutzerdefinierte Netzwerk aktiviert ist, erstellt das VPC-CNI sekundäre ENIs in dem unter EniConfig definierten Subnetz. Das CNI weist Pods IP-Adressen aus einem CIDR-Bereich zu, der in einer ENIConfig-CRD definiert ist.

Da die primäre ENI nicht für benutzerdefinierte Netzwerke verwendet wird, ist die maximale Anzahl von Pods, die Sie auf einem Knoten ausführen können, niedriger. Die Pods im Host-Netzwerk verwenden weiterhin die IP-Adresse, die der primären ENI zugewiesen ist. Darüber hinaus wird die primäre ENI verwendet, um die Übersetzung des Quellnetzwerks abzuwickeln und den Pod-Verkehr außerhalb des Knotens weiterzuleiten.

Beispielkonfiguration

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 andere RFC1918-Bereiche. Sie können es beispielsweise als sekundären CIDR für Ihre VPC verwenden100.64.0.0/16. Weitere Informationen zu den zulässigen und eingeschränkten CIDR-Blockzuordnungen, die Sie mit Ihrer VPC verwenden können, finden Sie unter IPv4-CIDR-Blockzuordnungsbeschränkungen im Abschnitt VPC- und Subnetzdimensionierung der VPC-Dokumentation.

Wie in der Abbildung unten dargestellt, verwendet das primäre Elastic Network Interface (ENI) des Worker-Knotens immer noch den primären VPC-CIDR-Bereich (in diesem Fall 10.0.0). 0/16), aber die sekundären ENIs verwenden den sekundären VPC-CIDR-Bereich (in diesem Fall 100.64.0). 0/16). Jetzt, damit die Pods den 100.64.0 verwenden. 0/16 Im CIDR-Bereich müssen Sie das CNI-Plugin für die Verwendung benutzerdefinierter Netzwerke konfigurieren. Sie können die hier dokumentierten Schritte ausführen.

Wenn das CNI benutzerdefinierte Netzwerke verwenden soll, setzen Sie die AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG Umgebungsvariable auftrue.

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

Wann weist AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true das CNI dem Pod eine IP-Adresse aus einem Subnetz zu, das in definiert ist. ENIConfig Die ENIConfig benutzerdefinierte Ressource wird verwendet, um das Subnetz zu definieren, in dem Pods geplant werden.

apiVersion : crd.k8s.amazonaws.com/v1alpha1
kind : ENIConfig
metadata:
  name: us-west-2a
spec:
  securityGroups:
    - sg-0dff111a1d11c1c11
  subnet: subnet-011b111c1f11fdf11

Beim Erstellen der ENIconfig benutzerdefinierten Ressourcen müssen Sie neue Worker-Knoten erstellen und die vorhandenen Knoten entleeren. Die vorhandenen Worker Nodes und Pods bleiben davon unberührt.

Empfehlungen

Verwenden Sie in folgenden Fällen ein benutzerdefiniertes Netzwerk

Wir empfehlen Ihnen, ein benutzerdefiniertes Netzwerk in Betracht zu ziehen, wenn Sie mit der IPv4-Erschöpfung zu kämpfen haben und IPv6 noch nicht verwenden können. Die Amazon EKS-Unterstützung für https://datatracker.ietf.org/doc/html/rfc6598 RFC6598-Speicherplatz ermöglicht es Ihnen, Pods über RFC1918-Standards hinaus zu skalieren, um Herausforderungen bei der Erschöpfung zu bewältigen. https://datatracker.ietf.org/doc/html/rfc1918 Bitte erwägen Sie, die Präfix-Delegierung bei benutzerdefinierten Netzwerken zu verwenden, um die Pod-Dichte auf einem Knoten zu erhöhen.

Sie könnten ein benutzerdefiniertes Netzwerk in Betracht ziehen, wenn Sie eine Sicherheitsanforderung haben, um Pods in einem anderen Netzwerk mit unterschiedlichen Sicherheitsgruppenanforderungen auszuführen. Wenn benutzerdefinierte Netzwerke aktiviert sind, verwenden die Pods andere Subnetze oder Sicherheitsgruppen, wie in der EniConfig definiert, als die primäre Netzwerkschnittstelle des Knotens.

Benutzerdefinierte Netzwerke sind in der Tat eine ideale Option für die Bereitstellung mehrerer EKS-Cluster und -Anwendungen zur Verbindung von Rechenzentrumsdiensten vor Ort. Sie können die Anzahl der privaten Adressen (RFC1918), auf die EKS in Ihrer VPC zugreifen kann, für Dienste wie Amazon Elastic Load Balancing erhöhen und NAT-GW gleichzeitig nicht routbaren CG-NAT Speicherplatz für Ihre Pods über mehrere Cluster hinweg verwenden. Durch benutzerdefinierte Netzwerke mit dem Transit-Gateway und einer Shared Services-VPC (einschließlich NAT-Gateways über mehrere Availability Zones für hohe Verfügbarkeit) können Sie skalierbare und vorhersehbare Datenverkehrsflüsse bereitstellen. In diesem Blogbeitrag wird ein Architekturmuster beschrieben, das eine der am meisten empfohlenen Methoden ist, EKS-Pods mithilfe benutzerdefinierter Netzwerke mit einem Rechenzentrumsnetzwerk zu verbinden.

Vermeiden Sie benutzerdefinierte Netzwerke, wenn

Bereit zur Implementierung von IPv6

Benutzerdefiniertes Netzwerk kann Probleme mit der IP-Erschöpfung mildern, erfordert jedoch zusätzlichen Betriebsaufwand. Wenn Sie derzeit eine Dual-Stack (IPv4/IPv6) -VPC bereitstellen oder Ihr Plan IPv6-Unterstützung beinhaltet, empfehlen wir stattdessen die Implementierung von IPv6-Clustern. Sie können IPv6-EKS-Cluster einrichten und Ihre Apps migrieren. In einem IPv6-EKS-Cluster erhalten sowohl Kubernetes als auch Pods eine IPv6-Adresse und können sowohl mit IPv4- als auch mit IPv6-Endpunkten ein- und ausgehen. Bitte lesen Sie die bewährten Methoden für den Betrieb von IPv6-EKS-Clustern. Ausführen von IPv6-EKS-Clustern

Erschöpfter Speicherplatz CG-NAT

Wenn Sie derzeit CIDRs aus dem CG-NAT Space verwenden oder kein sekundäres CIDR mit Ihrer Cluster-VPC verknüpfen können, müssen Sie außerdem möglicherweise andere Optionen prüfen, z. B. die Verwendung eines alternativen CNI. Wir empfehlen dringend, dass Sie entweder kommerziellen Support in Anspruch nehmen oder über das interne Wissen verfügen, um Patches für das Open-Source-CNI-Plugin-Projekt zu debuggen und einzureichen. Weitere Informationen finden Sie im Benutzerhandbuch für alternative CNI-Plugins.

Verwenden Sie ein privates NAT-Gateway

Amazon VPC bietet jetzt private NAT-Gateway-Funktionen. Das private NAT-Gateway von Amazon ermöglicht es Instances in privaten Subnetzen, eine Verbindung zu anderen VPCs und lokalen Netzwerken mit überlappenden CIDRs herzustellen. Erwägen Sie, die in diesem Blogbeitrag beschriebene Methode zu verwenden, um ein privates NAT-Gateway einzusetzen, um Kommunikationsprobleme für die EKS-Workloads zu beheben, die durch überlappende CIDRs verursacht werden. Dies ist eine wichtige Beschwerde, die von unseren Kunden geäußert wurde. Benutzerdefinierte Netzwerke können die sich überschneidenden CIDR-Probleme nicht alleine lösen, und sie verschärfen die Konfigurationsprobleme.

Die in diesem Blogbeitrag verwendete Netzwerkarchitektur folgt den Empfehlungen unter Kommunikation zwischen überlappenden Netzwerken aktivieren in der Amazon VPC-Dokumentation. Wie in diesem Blogbeitrag gezeigt, können Sie die Verwendung von privaten NAT-Gateways in Verbindung mit RFC6598-Adressen ausweiten, um die Probleme der Kunden mit der Erschöpfung privater IP-Adressen zu lösen. Die EKS-Cluster und Worker Nodes werden in der Version 100.64.0 bereitgestellt, die nicht routbar ist. 0/16 Sekundärer VPC-CIDR-Bereich, wohingegen das private NAT-Gateway und das NAT-Gateway in den routingfähigen RFC1918-CIDR-Bereichen bereitgestellt werden. In dem Blog wird erklärt, wie ein Transit-Gateway zur Verbindung von VPCs verwendet wird, um die Kommunikation zwischen VPCs mit überlappenden, nicht routbaren CIDR-Bereichen zu erleichtern. Für Anwendungsfälle, in denen EKS-Ressourcen im nicht routbaren Adressbereich einer VPC mit anderen VPCs kommunizieren müssen, die keine überlappenden Adressbereiche haben, haben Kunden die Möglichkeit, VPC-Peering zu verwenden, um solche VPCs miteinander zu verbinden. Diese Methode könnte zu potenziellen Kosteneinsparungen führen, da die gesamte Datenübertragung innerhalb einer Availability Zone über eine VPC-Peering-Verbindung jetzt kostenlos ist.

Einzigartiges Netzwerk für Knoten und Pods

Wenn Sie Ihre Knoten und Pods aus Sicherheitsgründen in einem bestimmten Netzwerk isolieren müssen, empfehlen wir Ihnen, Knoten und Pods von einem größeren sekundären CIDR-Block aus (z. B. 100.64.0) in einem Subnetz bereitzustellen. 0/8). Nach der Installation des neuen CIDR in Ihrer VPC können Sie mithilfe des sekundären CIDR eine weitere Knotengruppe bereitstellen und die ursprünglichen Knoten entleeren, um die Pods automatisch erneut auf den neuen Worker-Knoten bereitzustellen. Weitere Informationen zur Implementierung finden Sie in diesem Blogbeitrag. https://aws.amazon.com/blogs/containers/optimize-ip-addresses-usage-by-pods-in-your-amazon-eks-cluster/

Benutzerdefiniertes Netzwerk wird in der Konfiguration, die in der folgenden Abbildung dargestellt ist, nicht verwendet. Stattdessen werden Kubernetes-Worker-Knoten in Subnetzen aus dem sekundären VPC-CIDR-Bereich Ihrer VPC bereitgestellt, z. B. 100.64.0. 0/10. Sie können den EKS-Cluster am Laufen halten (die Steuerungsebene bleibt auf der ursprünglichen Ebene subnet/s), aber die Knoten und Pods werden auf eine sekundäre Ebene verschoben subnet/s. Dies ist eine weitere, wenn auch unkonventionelle Technik, um die Gefahr einer IP-Erschöpfung in einer VPC zu mindern. Wir schlagen vor, die alten Knoten zu entleeren, bevor die Pods erneut auf die neuen Worker-Knoten verteilt werden.

Automatisieren Sie die Konfiguration mit Availability Zone-Labels

Sie können Kubernetes so aktivieren, dass die entsprechende EniConfig automatisch für die Availability Zone (AZ) des Worker-Knotens angewendet wird.

Kubernetes fügt das Tag automatisch zu Ihren Worker-Knoten hinzu. topology.kubernetes.io/zone Amazon EKS empfiehlt, die Availability Zone als Ihren ENI-Konfigurationsnamen zu verwenden, wenn Sie nur ein sekundäres Subnetz (alternatives CIDR) pro AZ haben. Sie können dann das Label, das zur Erkennung des ENI-Konfigurationsnamens verwendet wird, auf setzen. topology.kubernetes.io/zone Beachten Sie, dass das Tag veraltet failure-domain.beta.kubernetes.io/zone ist und durch das Tag ersetzt wird. topology.kubernetes.io/zone

kubectl set env daemonset aws-node -n kube-system "AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true"
kubectl set env daemonset aws-node -n kube-system "ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone"

Wenn Sie mehrere sekundäre Subnetze pro Verfügbarkeitszone haben, müssen Sie ein bestimmtes ENI_CONFIG_LABEL_DEF erstellen. Sie könnten erwägen, ENI_CONFIG_LABEL_DEF als zu konfigurieren k8s.amazonaws.com/eniConfig und Knoten mit benutzerdefinierten EniConfig-Namen wie und zu kennzeichnen. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1 k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2

Ersetzen Sie die Pods bei der Konfiguration des sekundären Netzwerks

Durch das Aktivieren benutzerdefinierter Netzwerke werden die vorhandenen Knoten nicht geändert. Benutzerdefiniertes Netzwerk ist eine störende Maßnahme. Anstatt nach der Aktivierung des benutzerdefinierten Netzwerks alle Worker-Knoten in Ihrem Cluster fortlaufend zu ersetzen, empfehlen wir, die CloudFormation AWS-Vorlage im EKS-Handbuch für die ersten Schritte mit einer benutzerdefinierten Ressource zu aktualisieren, die eine Lambda-Funktion aufruft, um das aws-node Daemonset mit der Umgebungsvariablen zu aktualisieren, um benutzerdefinierte Netzwerke zu ermöglichen, bevor die Worker-Knoten bereitgestellt werden.

Wenn Sie vor der Umstellung auf die benutzerdefinierte CNI-Netzwerkfunktion Knoten in Ihrem Cluster hatten, auf denen Pods ausgeführt wurden, sollten Sie die Knoten absperren und entleeren, um die Pods ordnungsgemäß herunterzufahren und dann die Knoten zu beenden. Nur neue Knoten, die dem EniConfig-Label oder den Anmerkungen entsprechen, verwenden ein benutzerdefiniertes Netzwerk. Daher kann den Pods, die auf diesen neuen Knoten geplant sind, eine IP aus dem sekundären CIDR zugewiesen werden.

Berechnen Sie die maximale Anzahl von Pods pro Knoten

Da die primäre ENI des Knotens nicht mehr für die Zuweisung von Pod-IP-Adressen verwendet wird, verringert sich die Anzahl der Pods, die Sie auf einem bestimmten EC2-Instance-Typ ausführen können. Um diese Einschränkung zu umgehen, können Sie die Präfixzuweisung für benutzerdefinierte Netzwerke verwenden. Bei der Präfixzuweisung wird jede sekundäre IP auf sekundären ENIs durch ein /28-Präfix ersetzt.

Berücksichtigen Sie die maximale Anzahl von Pods für eine m5.large-Instance mit benutzerdefiniertem Netzwerk.

Die maximale Anzahl von Pods, die Sie ohne Präfixzuweisung ausführen können, beträgt 29

Durch das Aktivieren von Präfix-Anhängen erhöht sich die Anzahl der Pods auf 290.

Wir empfehlen jedoch, Max-Pods auf 110 statt 290 einzustellen, da die Instanz eine relativ kleine Anzahl virtueller CPUs hat. Bei größeren Instances empfiehlt EKS einen maximalen Pod-Wert von 250. Wenn Sie Präfix-Anhänge mit kleineren Instance-Typen (z. B. m5.large) verwenden, ist es möglich, dass Sie die CPU- und Speicherressourcen der Instance weit vor ihren IP-Adressen erschöpfen.

Identifizieren Sie die bestehende Speicherplatznutzung CG-NAT

Ein benutzerdefiniertes Netzwerk ermöglicht es Ihnen, das Problem der IP-Erschöpfung zu mindern, es kann jedoch nicht alle Herausforderungen lösen. Wenn Sie bereits CG-NAT Speicherplatz für Ihren Cluster verwenden oder einfach nicht in der Lage sind, Ihrer Cluster-VPC einen sekundären CIDR zuzuordnen, empfehlen wir Ihnen, andere Optionen zu prüfen, z. B. die Verwendung eines alternativen CNI oder die Umstellung auf IPv6-Cluster.