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 SubnetzCIDR, an das das primäre Subnetz angeschlossen ENI ist, normalerweise das Subnetz des Knoten/Hosts.

Wenn das Subnetz zu klein CIDR ist, können sie 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 der Knoten und der Pod IPs aus sekundären VPC Adressräumen zugewiesen werden ()CIDR. Die Unterstützung benutzerdefinierter Netzwerke unterstützt ENIConfig benutzerdefinierte Ressourcen. ENIConfigDazu gehören ein alternativer CIDR Subnetzbereich (aus einem sekundären Bereich VPCCIDR) sowie die Sicherheitsgruppe (n), zu der die Pods gehören werden. Wenn das benutzerdefinierte Netzwerk aktiviert ist, wird VPC CNI ein sekundäres Netzwerk ENIs in dem unter definierten Subnetz erstellt. ENIConfig Das CNI weist Pods IP-Adressen aus einem CIDR Bereich zu, der in a definiert ist. ENIConfig CRD

Da der primäre ENI Pod nicht von benutzerdefinierten Netzwerken 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 dem primären Server zugewiesene IP-AdresseENI. Darüber hinaus ENI wird der Primärserver 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 NAT CG-Bereich zu verwenden, d. h. 100.64.0.0/10 oder 198.19.0.0/16, da diese Bereiche in einer Unternehmensumgebung mit geringerer Wahrscheinlichkeit verwendet werden als andere Bereiche. RFC1918 Weitere Informationen zu den zulässigen und eingeschränkten CIDR Blockzuordnungen, die Sie mit Ihrem verwenden könnenVPC, finden IPv4 CIDR Sie unter Einschränkungen für Blockzuordnungen im Abschnitt und zur Größe von Subnetzen der Dokumentation. VPC VPC

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 das sekundäre ENIs verwendet den sekundären VPC CIDR Bereich (in diesem Fall 100.64.0.0/16). Damit die Pods nun den CIDR Bereich 100.64.0.0/16 verwenden können, müssen Sie das Plugin für die Verwendung benutzerdefinierter Netzwerke konfigurieren. CNI Sie können die hier dokumentierten Schritte ausführen.

Wenn Sie benutzerdefinierte Netzwerke verwenden CNI möchten, 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 AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true CNI wird die Pod-IP-Adresse aus einem Subnetz zugewiesen, das in ENIConfig definiert ist. 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 diese IPv6 noch nicht nutzen können. Die EKS Unterstützung von Amazon für RFC6598Speicherplatz ermöglicht es Ihnen, Pods zu skalieren, um RFC1918Probleme 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 sie in der ENIConfig primären Netzwerkschnittstelle des Knotens definiert sind.

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 Ihren VPC vier Diensten wie Amazon Elastic Load Balancing und NAT -GW zugegriffen werden kann, und gleichzeitig nicht routingfähigen NAT CG-Speicherplatz für Ihre Pods in mehreren Clustern verwenden. Benutzerdefinierte Netzwerke mit dem Transit-Gateway und Shared Services VPC (einschließlich NAT Gateways in mehreren Availability Zones für hohe Verfügbarkeit) ermöglichen Ihnen die Bereitstellung skalierbarer und vorhersehbarer Datenverkehrsflüsse. 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 IPv6

Benutzerdefinierte Netzwerke können Probleme mit der IP-Erschöpfung abmildern, erfordern jedoch zusätzlichen betrieblichen Aufwand. Wenn Sie derzeit ein Dual-Stack-System (IPv4/IPv6) einsetzen VPC oder Ihr Plan IPv6 Support beinhaltet, empfehlen wir, stattdessen Cluster zu implementierenIPv6. 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 mit beiden Endpunkten ein- IPv4 und IPv6 ausgehen. Bitte lesen Sie sich die Best Practices für Running Clusters durch. IPv6 EKS

Erschöpfter CG-Speicherplatz NAT

Wenn Sie derzeit den CG-Bereich nutzen CIDRs oder keinen sekundären NAT Speicher CIDR mit Ihrem Cluster verknüpfen könnenVPC, müssen Sie möglicherweise andere Optionen in Betracht ziehen, z. B. die Verwendung einer Alternative. 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 CNI Open-Source-Plugin-Projekt zu verfügen. Weitere Informationen finden Sie im Benutzerhandbuch für alternative CNI Plugins.

Verwenden Sie Private NAT Gateway

Amazon bietet VPC 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 zu verbinden, die sich überschneiden. CIDRs Erwägen Sie, die in diesem Blogbeitrag beschriebene Methode zum Einsatz eines privaten NAT Gateways zu verwenden, um Kommunikationsprobleme im Zusammenhang mit den durch Überschneidungen verursachten EKS Workloads zu lösen — eine erhebliche BeschwerdeCIDRs, die von unseren Kunden geäußert wurde. Kundenspezifische Netzwerke können die sich überschneidenden CIDR Probleme nicht alleine lösen, und das macht die Konfiguration noch schwieriger.

Die in der Implementierung dieses Blogposts verwendete Netzwerkarchitektur folgt den Empfehlungen unter Kommunikation zwischen überlappenden Netzwerken aktivieren in der VPC Amazon-Dokumentation. Wie in diesem Blogbeitrag gezeigt, können Sie die Nutzung von Private NAT Gateway in Verbindung mit RFC6598 Adressen ausweiten, um die Erschöpfung der privaten IP-Adressen von Kunden zu bewältigen. Die EKS Cluster und Worker-Knoten werden im VPC sekundären CIDR Bereich 100.64.0.0/16 bereitgestellt, während das private NAT Gateway und das Gateway in den routbaren Bereichen bereitgestellt werden. NAT RFC1918 CIDR In diesem Blog wird erklärt, wie ein Transit-Gateway für Verbindungen verwendet wird, um die Kommunikation zwischen überlappenden, nicht routbaren VPCs Bereichen zu erleichtern. VPCs CIDR Für Anwendungsfälle, in denen EKS Ressourcen in einem VPC nicht routbaren Adressbereich mit anderen kommunizieren müssen, die keine überlappenden Adressbereiche habenVPCs, haben Kunden die Möglichkeit, Peering zu verwenden, um solche Verbindungen miteinander zu verbinden. VPC VPCs 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 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 der neuen Knoten CIDR in Ihrem VPC können Sie eine weitere Knotengruppe mithilfe der sekundären Knoten bereitstellen CIDR 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 Ihrem VPC sekundären VPC CIDR Bereich bereitgestellt, z. B. 100.64.0.0/10. Sie können den EKS Cluster weiterlaufen lassen (die Steuerungsebene bleibt auf dem Original). subnet/s), but the nodes and Pods will be moved to a secondary subnet/s Dies ist eine weitere, wenn auch unkonventionelle Technik zur Minderung der Gefahr einer IP-Erschöpfung in einem. VPC 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 die entsprechende Availability Zone (AZ) ENIConfig für den Worker-Knoten automatisch angewendet wird.

Kubernetes fügt das Tag automatisch topology.kubernetes.io/zonezu Ihren Worker-Knoten hinzu. Amazon EKS empfiehlt, die Availability Zone als ENI Konfigurationsnamen zu verwenden, wenn Sie nur ein sekundäres Subnetz (alternativCIDR) pro AZ haben. 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

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 Namen wie k8s.amazonaws.com/eniConfig=us-west-2a-subnet-1und k8s.amazonaws.com/eniConfig=us-west-2a-subnet-2zu kennzeichnen.

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 alle Worker-Knoten in Ihrem Cluster nach der Aktivierung von Custom Networking fortlaufend zu ersetzen, empfehlen wir, die AWS CloudFormation Vorlage im EKSGetting Started Guide 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 der ENIConfig Bezeichnung oder den Anmerkungen entsprechen, verwenden benutzerdefinierte Netzwerke. Daher kann den Pods, die auf diesen neuen Knoten geplant sind, eine sekundäre IP-Adresse zugewiesen werden. CIDR

Berechnen Sie die maximale Anzahl an Pods pro Knoten

Da der primäre ENI Knoten 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 der ENIs sekundären 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 eine relativ geringe Anzahl virtueller Pods hat. CPUs Für größere Instances wird ein maximaler Pod-Wert von 250 EKS empfohlen. Wenn Sie Präfixanhänge mit kleineren Instance-Typen (z. B. m5.large) verwenden, ist es möglich, dass Sie die Instance CPU - und Speicherressourcen deutlich vor ihren IP-Adressen erschöpfen.

Identifizieren Sie die bestehende Nutzung von CG-Space 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 NAT CG-Space für Ihren Cluster verwenden oder einfach nicht in der Lage sind, Ihrem Cluster einen sekundären CIDR Speicherplatz zuzuordnen, empfehlen wir IhnenVPC, andere Optionen zu prüfen, z. B. die Verwendung einer Alternative CNI oder die Umstellung auf Cluster. IPv6

📝 Bearbeiten Sie diese Seite auf GitHub