Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk - Amazon EKS
Überlegungen

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 auf, 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.

Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk

Gilt für: Linux-IPv4-Fargate-Knoten, Linux-Knoten mit Amazon-EC2-Instances

Diagramm eines Knotens mit mehreren Netzwerkschnittstellen

Standardmäßig erstellt das Amazon-VPC-CNI-Plugin für Kubernetes sekundäre Elastic-Network-Schnittstellen (Netzwerkschnittstellen) für Ihren Amazon-EC2-Knoten im gleichen Subnetz wie die primäre Netzwerkschnittstelle des Knotens. Es verknüpft auch dieselben Sicherheitsgruppen mit der sekundären Netzwerkschnittstelle, die mit der primären Netzwerkschnittstelle verknüpft sind. Aus einem oder mehreren der folgenden Gründe möchten Sie möglicherweise, dass das Plugin sekundäre Netzwerkschnittstellen in einem anderen Subnetz erstellt oder Sie möchten den sekundären Netzwerkschnittstellen oder beiden verschiedene Sicherheitsgruppen zuordnen:

  • Es gibt eine begrenzte Anzahl von IPv4-Adressen, die in dem Subnetz verfügbar sind, in dem sich die primäre Netzwerkschnittstelle befindet. Dies könnte die Anzahl der Pods einschränken, die Sie in dem Subnetz erstellen können. Durch Verwendung eines anderen Subnetzes für sekundäre Netzwerkschnittstellen können Sie die Anzahl der verfügbaren IPv4-Adressen für Pods erhöhen.

  • Aus Sicherheitsgründen müssen Ihre Pods unter Umständen andere Sicherheitsgruppen oder Subnetze verwenden als die primäre Netzwerkschnittstelle des Knotens.

  • Die Knoten sind in öffentlichen Subnetzen konfiguriert und die Pods sollen in privaten Subnetzen platziert werden. Die einem öffentlichen Subnetz zugeordnete Routing-Tabelle enthält eine Route zu einem Internet-Gateway. Die einem privaten Subnetz zugeordnete Routing-Tabelle enthält keine Route zu einem Internet-Gateway.

Tipp

Sie können Ihrem Amazon-EKS-Cluster auch direkt ein neues oder vorhandenes Subnetz hinzufügen, ohne benutzerdefinierte Netzwerke zu verwenden. Weitere Informationen finden Sie unter Hinzufügen eines vorhandenen VPC-Subnetzes zu einem Amazon-EKS-Cluster über die Management-Konsole.

Überlegungen

Nachfolgend finden Sie einige Überlegungen zur Verwendung dieses Features.

  • Wenn benutzerdefinierte Netzwerke aktiviert sind, werden Pods keine IP-Adressen zugewiesen, die der primären Netzwerkschnittstelle zugewiesen sind. Pods werden nur IP-Adressen von sekundären Netzwerkschnittstellen zugewiesen.

  • Wenn Ihr Cluster die IPv6-Familie verwendet, können Sie keine benutzerdefinierten Netzwerke verwenden.

  • Wenn Sie vorhaben, benutzerdefinierte Netzwerke zu verwenden, um die IPv4-Adresserschöpfung zu verhindern, können Sie stattdessen einen Cluster über die IPv6-Familie erstellen. Weitere Informationen finden Sie unter Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste.

  • Auch wenn Pods in Subnetzen für sekundäre Netzwerkschnittstellen bereitgestellte andere Subnetz- und Sicherheitsgruppen verwenden können als die primäre Netzwerkschnittstelle des Knotens, müssen sich die Subnetze und Sicherheitsgruppen in derselben VPC befinden wie der Knoten.

  • Bei Fargate werden Subnetze über das Fargate-Profil verwaltet. Weitere Informationen finden Sie unter Festlegung, welche Pods beim Start AWS Fargate verwenden.