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

Hilf mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle 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.

Bereitstellung pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk

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

Wenn der Amazon VPC CNI plugin for Kubernetes sekundäre elastische Netzwerkschnittstellen (Netzwerkschnittstellen) für Ihren EC2 Amazon-Knoten erstellt, werden diese standardmäßig im selben Subnetz wie die primäre Netzwerkschnittstelle des Knotens erstellt. 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 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.

Überlegungen

Im Folgenden finden Sie Überlegungen zur Verwendung der Funktion.

  • 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 Ordnen Sie Clustern IPv6 Adressen zu, pods, und Dienste.

  • Auch wenn die Pods Bereitstellung in Subnetzen, die für sekundäre Netzwerkschnittstellen spezifiziert sind, andere Subnetze und Sicherheitsgruppen als die primäre Netzwerkschnittstelle des Knotens verwenden kann, müssen sich die Subnetze und Sicherheitsgruppen in denselben Bereichen VPC wie der Knoten befinden.

  • Bei Fargate werden Subnetze über das Fargate-Profil gesteuert. Weitere Informationen finden Sie unter Definieren Sie, welche Pods Verwendung AWS Fargate beim Start verwendet wird.