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

Benutzerdefinierte Netzwerke sind eine Lösung für dieses Problem.

Benutzerdefiniertes Netzwerk behebt das Problem der IP-Erschöpfung, indem die Knoten- und Pod-IPs aus sekundären VPC-Adressräumen (CIDR) zugewiesen werden. Die Unterstützung benutzerdefinierter Netzwerke unterstützt die benutzerdefinierte EniConfig-Ressource. Die EniConfig umfasst einen alternativen Subnetz-CIDR-Bereich (aus einem sekundären VPC-CIDR zusammengestellt) sowie die Sicherheitsgruppe (n), zu der die Pods gehören werden. Wenn Custom Networking 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 von benutzerdefinierten Netzwerken verwendet wird, ist die maximale Anzahl von Pods, die Sie auf einem Knoten ausführen können, niedriger. Die Host-Netzwerk-Pods verwenden weiterhin die IP-Adresse, die der primären ENI zugewiesen wurde. Darüber hinaus wird das primäre ENI verwendet, um die Übersetzung des Quellnetzwerks zu verarbeiten und den Pods-Verkehr außerhalb des Knotens weiterzuleiten.

Beispielkonfiguration

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 es weniger wahrscheinlich ist, dass diese in einer Unternehmensumgebung verwendet werden als andere RFC1918-Bereiche. Weitere Informationen zu den zulässigen und eingeschränkten CIDR-Blockzuordnungen, die Sie mit Ihrer VPC verwenden können, finden Sie unter Einschränkungen der IPv4-CIDR-Blockzuweisung im Abschnitt VPC und Subnetzgröße der VPC-Dokumentation.

Wie in der Abbildung unten dargestellt, verwendet das primäre Elastic Network Interface (ENI) des Worker-Knotens weiterhin 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 die 100.64.0 verwenden. 0/16 CIDR-Bereich, Sie müssen das CNI-Plugin für die Verwendung benutzerdefinierter Netzwerke konfigurieren. Sie können die hier dokumentierten Schritte ausführen.

Wenn Sie möchten, dass das CNI benutzerdefinierte Netzwerke verwendet, setzen Sie die AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG Umgebungsvariable auf. true

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 die Pod-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

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

Empfehlungen

Verwenden Sie Custom Networking, wenn

Wir empfehlen Ihnen, benutzerdefinierte Netzwerke in Betracht zu ziehen, wenn Sie mit IPv4-Erschöpfung zu kämpfen haben und IPv6 noch nicht verwenden können. Die Amazon EKS-Unterstützung für den RFC6598-Speicherplatz ermöglicht es Ihnen, Pods über RFC1918 hinaus zu skalieren, um Probleme mit Erschöpfung zu bewältigen. Bitte erwägen Sie, die Präfix-Delegierung mit benutzerdefinierten Netzwerken zu verwenden, um die Pod-Dichte auf einem Knoten zu erhöhen.

Sie könnten benutzerdefinierte Netzwerke in Betracht ziehen, wenn Sie eine Sicherheitsanforderung haben, 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) erhöhen, auf die EKS in Ihrer VPC für Dienste wie Amazon Elastic Load Balancing zugreifen kann NAT-GW, und gleichzeitig nicht routingfähigen CG-NAT Speicherplatz für Ihre Pods in mehreren Clustern verwenden. Durch benutzerdefinierte Netzwerke mit dem Transit-Gateway und einer Shared Services-VPC (einschließlich NAT-Gateways in mehreren 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 für die Implementierung von IPv6

Benutzerdefinierte Netzwerke können Probleme mit der IP-Erschöpfung verringern, erfordern jedoch zusätzlichen betrieblichen Aufwand. Wenn Sie derzeit eine Dual-Stack (IPv4/IPv6) -VPC bereitstellen oder Ihr Plan IPv6-Unterstützung beinhaltet, empfehlen wir, stattdessen IPv6-Cluster zu implementieren. 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 ausgehend kommunizieren. Bitte lesen Sie sich die bewährten Methoden für die Ausführung von IPv6-EKS-Clustern durch.

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 Ihnen dringend, entweder kommerziellen Support in Anspruch zu nehmen oder über die erforderlichen internen Kenntnisse zum Debuggen und Einreichen von Patches für das Open-Source-CNI-Plug-in-Projekt zu verfügen. Weitere Informationen finden Sie im Benutzerhandbuch für alternative CNI-Plugins.

Verwenden Sie das private NAT-Gateway

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

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 Probleme mit der Erschöpfung privater IP-Adressen von Kunden zu lösen. Die EKS-Cluster und Worker-Knoten werden in der nicht routbaren Version 100.64.0 bereitgestellt. 0/16 Sekundärer VPC-CIDR-Bereich, wohingegen das private NAT-Gateway und das NAT-Gateway für die routbaren RFC1918-CIDR-Bereiche bereitgestellt werden. In diesem 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 potenzielle Kosteneinsparungen bieten, da der gesamte Datentransfer 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 für ein bestimmtes Netzwerk isolieren müssen, empfehlen wir Ihnen, Knoten und Pods in einem Subnetz von einem größeren sekundären CIDR-Block aus bereitzustellen (z. B. 100.64.0). 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.

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 weiterlaufen lassen (die Steuerungsebene bleibt auf dem Original 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 der IP-Erschöpfung in einer VPC zu verringern. Wir schlagen vor, die alten Knoten zu entleeren, bevor die Pods auf den neuen Worker-Knoten neu bereitgestellt werden.

Automatisieren Sie die Konfiguration mit Availability Zone Labels

Sie können Kubernetes so einrichten, dass es automatisch die entsprechende ENIConfig für die Availability Zone (AZ) des Worker-Nodes anwendet.

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 die Bezeichnung, die zur Erkennung des ENI-Konfigurationsnamens verwendet wird, auf festlegen. topology.kubernetes.io/zone Beachten Sie, dass das Tag veraltet failure-domain.beta.kubernetes.io/zone ist und durch das Tag ersetzt wurde. 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 Availability Zone haben, müssen Sie ein bestimmtes ENI_CONFIG_LABEL_DEF erstellen. Sie könnten erwägen, Knoten mit benutzerdefinierten EniConfig-Namen zu konfigurieren ENI_CONFIG_LABEL_DEF k8s.amazonaws.com/eniConfigund sie mit benutzerdefinierten EniConfig-Namen wie und zu kennzeichnen. k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2

Ersetzen Sie Pods bei der Konfiguration des sekundären Netzwerks

Durch die Aktivierung benutzerdefinierter Netzwerke werden vorhandene Knoten nicht geändert. Benutzerdefiniertes Networking 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 „Erste 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 aktivieren, 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 sperren 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 benutzerdefinierte Netzwerke. Daher kann den auf diesen neuen Knoten geplanten Pods eine IP aus dem sekundären CIDR zugewiesen werden.

Berechnen Sie die maximale Anzahl an Pods pro Knoten

Da die primäre ENI des Knotens nicht mehr für die Zuweisung von Pod-IP-Adressen verwendet wird, sinkt 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 mit benutzerdefinierten Netzwerken verwenden. Bei der Präfixzuweisung wird jede sekundäre IP auf sekundären ENIs durch ein /28-Präfix ersetzt.

Beachten 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, ist 29.

Durch die Aktivierung von Präfixanhängen wird die Anzahl der Pods auf 290 erhöht.

Wir empfehlen jedoch, max-pods auf 110 statt 290 zu setzen, da die Instanz über eine relativ geringe Anzahl virtueller CPUs verfügt. Für größere Instances empfiehlt EKS einen maximalen Pod-Wert von 250. Wenn Sie Präfixanhänge mit kleineren Instance-Typen (z. B. m5.large) verwenden, ist es möglich, dass Sie die CPU- und Speicherressourcen der Instance deutlich vor ihren IP-Adressen erschöpfen.

Identifizieren Sie die bestehende Speicherplatznutzung CG-NAT

Mit benutzerdefinierten Netzwerken können Sie das Problem der IP-Erschöpfung verringern, es können jedoch nicht alle Probleme gelöst werden. Wenn Sie bereits CG-NAT Speicherplatz für Ihren Cluster verwenden oder einfach nicht in der Lage sind, Ihrer Cluster-VPC ein sekundäres CIDR zuzuordnen, empfehlen wir Ihnen, andere Optionen zu prüfen, z. B. die Verwendung eines alternativen CNI oder die Umstellung auf IPv6-Cluster.