Unterstützung für die Verbesserung dieser Seite beitragen
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.
Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.
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.
Weitere Informationen zu VPC-Netzwerke und Load Balancing in EKS Auto Mode
In diesem Thema wird erläutert, wie Sie die Netzwerk- und Load-Balancer-Features der Virtual Private Cloud (VPC) in EKS Auto Mode konfigurieren. Obwohl EKS Auto Mode die meisten Netzwerkkomponenten automatisch verwaltet, können Sie bestimmte Aspekte der Netzwerkkonfiguration Ihres Clusters dennoch über NodeClass-Ressourcen und Load-Balancer-Annotationen anpassen.
Wenn Sie den EKS-Automodus verwenden, AWS verwaltet es die VPC Container Network Interface (CNI) -Konfiguration und die Load Balancer-Bereitstellung für Ihren Cluster. Sie können das Netzwerkverhalten beeinflussen, indem Sie NodeClass-Objekte definieren und bestimmte Annotationen auf Ihre Service- und Ingress-Ressourcen anwenden, während Sie gleichzeitig das automatisierte Betriebsmodell beibehalten, das EKS Auto Mode bereitstellt.
Netzwerkfähigkeit
EKS Auto Mode verfügt über eine neue Netzwerkfunktion, die das Netzwerk von Knoten und Pods verwaltet. Sie können es konfigurieren, indem Sie ein NodeClass-Kubernetes-Objekt erstellen.
Die Konfigurationsoptionen für das vorherige AWS VPC-CNI gelten nicht für den EKS-Automatikmodus.
Konfiguration des Netzwerks mit einer NodeClass
Die NodeClass-Ressource in EKS Auto Mode ermöglicht es Ihnen, bestimmte Aspekte der Netzwerkfunktionen anzupassen. Über NodeClass können Sie Sicherheitsgruppen auswählen, die Platzierung von Knoten in VPC-Subnetzen steuern, SNAT-Richtlinien festlegen, Netzwerkrichtlinien konfigurieren und die Protokollierung von Netzwerkereignissen aktivieren. Dieser Ansatz behält das automatisierte Betriebsmodell von EKS Auto Mode bei und bietet gleichzeitig Flexibilität für die Anpassung des Netzwerks.
Sie können eine NodeClass verwenden, um:
-
Sicherheitsgruppe für Knoten auswählen
-
Steuern, wie Knoten in VPC-Subnetzen platziert werden
-
SNAT-Richtlinie für den Knoten auf
randomoderdisabledfestlegen -
Aktivieren Sie die Kubernetes-Netzwerkrichtlinien, einschließlich:
-
Einstellen der Netzwerkrichtlinie auf „Standardmäßig ablehnen“ oder „Standardmäßig zulassen“
-
Aktivieren Sie die Protokollierung von Netzwerkereignissen in einer Datei.
-
-
Trennen Sie den Pod-Datenverkehr vom Knotendatenverkehr, indem Sie Pods an verschiedene Subnetze anfügen.
Erfahren Sie, wie Sie ein Amazon EKS erstellen. NodeClass
Überlegungen
EKS Auto Mode unterstützt:
-
EKS-Netzwerkrichtlinien.
-
Die
HostPort- undHostNetwork-Optionen für Kubernetes-Pods. -
Knoten und Pods in öffentlichen oder privaten Subnetzen.
-
Zwischenspeichern von DNS-Abfragen auf dem Knoten.
-
Statische Netzwerkschnittstellenkonfiguration für EFA-Workloads. Weitere Informationen finden Sie unter Konfiguration der statischen Netzwerkschnittstelle.
EKS Auto Mode unterstützt Folgendes nicht:
-
Sicherheitsgruppen pro Pod (SGPP). Um separate Sicherheitsgruppen auf den Pod-Verkehr im Auto-Modus anzuwenden, verwenden Sie stattdessen
podSecurityGroupSelectorTermsin.NodeClassWeitere Informationen finden Sie unter Separate Subnetze und Sicherheitsgruppen für Pods. -
Benutzerdefinierte Netzwerke in
ENIConfig. Sie können Pods in mehreren Subnetzen platzieren oder sie mit Separate Subnetze und Sicherheitsgruppen für Pods exklusiv vom Knoten-Datenverkehr isolieren. -
Warm-IP-, Warm-Präfix- und Warm-ENI-Konfigurationen.
-
Konfiguration für minimale IP-Ziele.
-
Andere Konfigurationen, die von der AWS Open-Source-VPC CNI unterstützt werden.
-
Konfigurationen der Netzwerkrichtlinien, wie beispielsweise die Anpassung des Conntrack-Timers (Standardwert ist 300 Sekunden).
-
Exportieren von Netzwerkereignisprotokollen nach. CloudWatch
-
Alternative CNI-Plugins (wie Cilium oder Calico) und alternative Netzwerkrichtlinien-Plugins. Amazon EKS Auto Mode verwendet die zuvor beschriebene integrierte Netzwerkfunktion. Weitere Informationen finden Sie unter Überlegungen zum Amazon EKS-Automatikmodus.
Netzwerk-Ressourcenmanagement
EKS Auto Mode kümmert sich um die Verwaltung von Präfix, IP-Adressierung und Netzwerkschnittstellen, indem er die NodeClass Ressourcen für Netzwerkkonfigurationen überwacht. Der Service führt mehrere wichtige Vorgänge automatisch aus:
Präfix-Delegierung
Der EKS-Automatikmodus verwendet standardmäßig die Präfixdelegierung (/28-Präfixe) für das Pod-Netzwerk und verwaltet einen vordefinierten warmen Pool von IP-Ressourcen, der je nach Anzahl der geplanten Pods skaliert wird. Wenn eine Pod-Subnetzfragmentierung erkannt wird, stellt der automatische Modus sekundäre IP-Adressen (/32) bereit. Aufgrund dieses standardmäßigen Pod-Netzwerkalgorithmus berechnet der Auto-Modus die maximale Anzahl der Pods pro Knoten auf der Grundlage der Anzahl der pro Instance-Typ unterstützten ENIs und IPs (im schlimmsten Fall einer Fragmentierung wird davon ausgegangen). Weitere Informationen zu Max. ENIs und IPs pro Instance-Typ finden Sie im EC2-Benutzerhandbuch unter Maximale IP-Adressen pro Netzwerkschnittstelle. Instance-Familien der neueren Generation (Nitro v6 und höher) haben im Allgemeinen mehr ENIs und IPs pro Instance-Typ, und der automatische Modus passt die Berechnung der maximalen Pods entsprechend an.
Für IPv6-Cluster wird nur die Präfixdelegierung verwendet. Der automatische Modus wendet dieselbe IPv4-based Berechnung an und begrenzt die maximale Anzahl von Pods auf 110 pro Knoten. Wenn dieser niedriger als 110 ist, wird der berechnete Wert verwendet.
Abkühlungs-Management
Der Service implementiert einen Abkühlungs-Pool für Präfixe oder sekundäre IPv4-Adressen, die nicht mehr verwendet werden. Nach Ablauf der Ruhephase werden diese Ressourcen wieder an die VPC zurückgegeben. Wenn Pods diese Ressourcen jedoch während der Ruhephase wiederverwenden, werden sie aus dem Abkühlungs-Pool wiederhergestellt.
IPv6-Support
Bei IPv6-Clustern stellt EKS Auto Mode ein /80-IPv6-Präfix pro Knoten in der primären Netzwerkschnittstelle bereit. Bei Verwendung podSubnetSelectorTerms wird das Präfix stattdessen einer sekundären Netzwerkschnittstelle im Pod-Subnetz zugewiesen.
Der Service gewährleistet außerdem die ordnungsgemäße Verwaltung und Garbage Collection aller Netzwerkschnittstellen.
Lastausgleich
Sie konfigurieren AWS Elastic Load Balancer, die von EKS Auto Mode bereitgestellt werden, mithilfe von Anmerkungen zu Service- und Ingress-Ressourcen.
Für weitere Informationen siehe Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren oder Verwendung von Service-Annotationen zur Konfiguration von Network Load Balancers.
Überlegungen zum Load Balancing mit EKS Auto Mode
-
Der Standard- Zielmodus ist der IP-Modus, nicht der Instance-Modus.
-
EKS Auto Mode unterstützt nur den Sicherheitsgruppenmodus für Network Load Balancers.
-
AWS unterstützt nicht die Migration von Load Balancern vom selbstverwalteten AWS Load Balancer-Controller zur Verwaltung durch EKS Auto Mode.
-
Das Feld
networking.ingress.ipBlockwird in derTargetGroupBinding-Spezifikation nicht unterstützt. -
Wenn Ihre Worker-Knoten benutzerdefinierte Sicherheitsgruppen verwenden (kein
eks-cluster-sg--Benennungsmuster), benötigt Ihre Cluster-Rolle zusätzliche IAM-Berechtigungen. Die EKS-managed Standardrichtlinie erlaubt EKS nur, benannte Sicherheitsgruppen zu ändern.eks-cluster-sg-Ohne die Erlaubnis, Ihre benutzerdefinierten Sicherheitsgruppen zu ändern, kann EKS die erforderlichen Eingangsregeln nicht hinzufügen, die es dem ALB/NLB Datenverkehr ermöglichen, Ihre Pods zu erreichen.
Überlegungen zu CoreDNS
Der EKS-Automatikmodus verwendet nicht die herkömmliche CoreDNS-Bereitstellung, um die DNS-Auflösung innerhalb des Clusters bereitzustellen. Stattdessen verwenden Auto-Mode-Knoten CoreDNS, das als Systemdienst direkt auf jedem Knoten ausgeführt wird. Wenn Sie einen herkömmlichen Cluster in den Auto-Modus überführen, können Sie die CoreDNS-Bereitstellung aus Ihrem Cluster entfernen, sobald Ihre Workloads auf die Knoten im Auto-Modus verschoben wurden.
Wichtig
Wenn Sie vorhaben, einen Cluster mit Knoten im automatischen Modus und ohne Knoten im automatischen Modus zu verwalten, müssen Sie die CoreDNS-Bereitstellung beibehalten. Non-Auto Modusknoten verlassen sich für die DNS-Auflösung auf die herkömmlichen CoreDNS-Pods, da sie nicht auf den DNS-Dienst auf Knotenebene zugreifen können, den der automatische Modus bereitstellt.