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

Helfen Sie mit, diese Seite zu verbessern

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.

Möchten Sie zu diesem Benutzerhandbuch beitragen? Wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet. Ihre Beiträge werden dazu beitragen, dass unser Benutzerhandbuch für alle besser wird.

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.

Bereitstellen Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk

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

Standardmäßig, wenn Amazon VPC CNI plugin for Kubernetes erstellt sekundäre elastische Netzwerkschnittstellen (Netzwerkschnittstellen) für Ihren EC2 Amazon-Knoten und erstellt sie im selben 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:

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

  • Aus Sicherheitsgründen ist Ihr Pods Möglicherweise müssen Sie ein anderes Subnetz oder eine andere Sicherheitsgruppe als die primäre Netzwerkschnittstelle des Knotens verwenden.

  • Die Knoten sind in öffentlichen Subnetzen konfiguriert, und Sie möchten die Pods in privaten Subnetzen. Die einem öffentlichen Subnetz zugeordnete Routing-Tabelle enthält eine Route zu einem Internet-Gateway. Die einem privaten Subnetz zugeordnete Routentabelle enthält keine Route zu einem Internet-Gateway.

Überlegungen

Im Folgenden finden Sie Überlegungen zur Verwendung der Funktion.

  • Wenn das benutzerdefinierte Netzwerk aktiviert ist, werden der primären Netzwerkschnittstelle keine IP-Adressen zugewiesen Pods. Nur IP-Adressen von sekundären Netzwerkschnittstellen werden zugewiesen Pods.

  • Wenn Ihr Cluster die IPv6 Familie verwendet, können Sie kein benutzerdefiniertes Netzwerk 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 die in Subnetzen bereitgestellt werden, die für sekundäre Netzwerkschnittstellen spezifiziert sind, können andere Subnetze und Sicherheitsgruppen als die primäre Netzwerkschnittstelle des Knotens verwenden. Die Subnetze und Sicherheitsgruppen müssen sich in derselben VPC wie der Knoten befinden.

  • Bei Fargate werden Subnetze über das Fargate-Profil gesteuert. Weitere Informationen finden Sie unter Definieren Sie welche Pods verwende AWS Fargate, wenn es gestartet wird.