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.

Präfix-Modus für Windows

In Amazon EKS wird jedem Pod, der auf einem Windows-Host ausgeführt wird, standardmäßig vom VPC-Ressourcencontroller eine sekundäre IP-Adresse zugewiesen. Diese IP-Adresse ist eine VPC-routable Adresse, die aus dem Subnetz des Hosts zugewiesen wird. Unter Linux verfügt jede an die Instance angehängte ENI über mehrere Steckplätze, die mit einer sekundären IP-Adresse oder einem /28-CIDR (einem Präfix) gefüllt werden können. Windows-Hosts unterstützen jedoch nur eine einzelne ENI und ihre verfügbaren Steckplätze. Wenn Sie nur sekundäre IP-Adressen verwenden, kann die Anzahl der Pods, die Sie auf einem Windows-Host ausführen können, künstlich begrenzt werden, selbst wenn eine Fülle von IP-Adressen für die Zuweisung zur Verfügung steht.

Um die Pod-Dichte auf Windows-Hosts zu erhöhen, insbesondere bei Verwendung kleinerer Instanztypen, können Sie die Präfixdelegierung für Windows-Knoten aktivieren. Wenn die Präfixdelegierung aktiviert ist, werden /28-IPv4-Präfixe ENI-Slots und nicht sekundären IP-Adressen zugewiesen. Die Präfixdelegierung kann aktiviert werden, indem der enable-windows-prefix-delegation: "true" Eintrag zur Konfigurationstabelle hinzugefügt wirdamazon-vpc-cni. Dies ist dieselbe Konfigurationstabelle, in der Sie einen enable-windows-ipam: "true" Eintrag für die Aktivierung der Windows-Unterstützung festlegen müssen.

Bitte folgen Sie den Anweisungen im EKS-Benutzerhandbuch, um den Präfix-Delegationsmodus für Windows-Knoten zu aktivieren.

Abbildung: Vergleich des sekundären IP-Modus mit dem Präfix-Delegationsmodus

Die maximale Anzahl von IP-Adressen, die Sie einer Netzwerkschnittstelle zuweisen können, hängt vom Instanztyp und dessen Größe ab. Jedes einer Netzwerkschnittstelle zugewiesene Präfix belegt einen verfügbaren Steckplatz. Eine c5.large Instance hat beispielsweise ein Limit an 10 Steckplätzen pro Netzwerkschnittstelle. Der erste Steckplatz einer Netzwerkschnittstelle wird immer von der primären IP-Adresse der Schnittstelle belegt, sodass Ihnen 9 Steckplätze für Präfixe und and/or sekundäre IP-Adressen zur Verfügung stehen. Wenn diesen Steckplätzen Präfixe zugewiesen sind, kann der Knoten (9 * 16) 144 IP-Adressen unterstützen, wohingegen er nur 9 IP-Adressen unterstützen kann, wenn ihnen sekundäre IP-Adressen zugewiesen sind. Weitere Informationen finden Sie in der Dokumentation zu IP-Adressen pro Netzwerkschnittstelle pro Instanztyp und zur Zuweisung von Präfixen zu Netzwerkschnittstellen.

Während der Initialisierung des Worker-Knotens weist der VPC Resource Controller der primären ENI ein oder mehrere Präfixe zu, um den Pod-Start zu beschleunigen, indem er einen warmen Pool der IP-Adressen verwaltet. Die Anzahl der Präfixe, die im Warm Pool gespeichert werden sollen, kann durch Einstellen der folgenden Konfigurationsparameter in der Konfigurationstabelle gesteuert werden. amazon-vpc-cni

Da weitere Pods auf dem Knoten geplant sind, werden zusätzliche Präfixe für das bestehende ENI angefordert. Wenn ein Pod auf dem Knoten geplant ist, versucht VPC Resource Controller zunächst, eine IPv4-Adresse aus den vorhandenen Präfixen auf dem Knoten zuzuweisen. Wenn das nicht möglich ist, wird ein neues IPv4-Präfix angefordert, solange das Subnetz über die erforderliche Kapazität verfügt.

Abbildung: Arbeitsablauf bei der Zuweisung einer IPv4-Adresse zum Pod

Empfehlungen

Verwenden Sie die Präfixdelegierung, wenn

Verwenden Sie die Präfix-Delegierung, wenn Sie Probleme mit der Pod-Dichte auf den Worker-Knoten haben. Um Fehler zu vermeiden, empfehlen wir, die Subnetze auf zusammenhängende Adressblöcke mit dem Präfix /28 zu untersuchen, bevor Sie in den Präfixmodus migrieren. Einzelheiten zur Subnetzreservierung finden Sie im Abschnitt „Subnetzreservierungen verwenden, um eine Subnetzfragmentierung zu vermeiden (IPv4)“.

In der Standardeinstellung ist der Knoten unter Windows max-pods auf eingestellt. 110 Für die überwiegende Mehrheit der Instanztypen sollte dies ausreichend sein. Wenn Sie dieses Limit erhöhen oder verringern möchten, fügen Sie dem Bootstrap-Befehl in Ihren Benutzerdaten Folgendes hinzu:

-KubeletExtraArgs '--max-pods=example-value'

Weitere Informationen zu den Bootstrap-Konfigurationsparametern für Windows-Knoten finden Sie in der Dokumentation hier.

Vermeiden Sie die Präfixdelegierung, wenn

Wenn Ihr Subnetz stark fragmentiert ist und nicht genügend IP-Adressen zur Verfügung stehen, um /28-Präfixe zu erstellen, vermeiden Sie den Präfixmodus. Das Präfix-Anhängen kann fehlschlagen, wenn das Subnetz, aus dem das Präfix generiert wird, fragmentiert ist (ein stark ausgelastetes Subnetz mit verstreuten sekundären IP-Adressen). Dieses Problem kann vermieden werden, indem ein neues Subnetz erstellt und ein Präfix reserviert wird.

Konfigurieren Sie Parameter für die Präfixdelegierung, um IPv4-Adressen zu erhalten

warm-prefix-targetwarm-ip-target, und minimum-ip-target kann zur Feinabstimmung des Verhaltens von Vorskalierung und dynamischer Skalierung mit Präfixen verwendet werden. Standardmäßig werden die folgenden Werte verwendet:

warm-ip-target: "1"
minimum-ip-target: "3"

Durch die Feinabstimmung dieser Konfigurationsparameter können Sie ein optimales Gleichgewicht zwischen der Beibehaltung der IP-Adressen und der Sicherstellung einer verringerten Pod-Latenz aufgrund der Zuweisung von IP-Adressen erreichen. Weitere Informationen zu diesen Konfigurationsparametern finden Sie in der Dokumentation hier.

Verwenden Sie Subnetzreservierungen, um eine Subnetzfragmentierung (IPv4) zu vermeiden

Wenn EC2 einer ENI ein /28-IPv4-Präfix zuweist, muss es sich um einen zusammenhängenden Block von IP-Adressen aus Ihrem Subnetz handeln. Wenn das Subnetz, aus dem das Präfix generiert wird, fragmentiert ist (ein häufig verwendetes Subnetz mit verstreuten sekundären IP-Adressen), schlägt das Präfix-Anhängen möglicherweise fehl und es wird das folgende Knotenereignis angezeigt:

InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

Um eine Fragmentierung zu vermeiden und über ausreichend zusammenhängenden Speicherplatz zum Erstellen von Präfixen zu verfügen, verwenden Sie CIDR-Reservierungen für VPC-Subnetze, um IP-Speicherplatz innerhalb eines Subnetzes für die ausschließliche Verwendung durch Präfixe zu reservieren. Sobald Sie eine Reservierung erstellt haben, werden die IP-Adressen aus den reservierten Blöcken keinen anderen Ressourcen zugewiesen. Auf diese Weise kann VPC Resource Controller während des Zuweisungsaufrufs an den Knoten ENI verfügbare Präfixe abrufen.

Es wird empfohlen, ein neues Subnetz zu erstellen, Speicherplatz für Präfixe zu reservieren und die Präfixzuweisung für Worker-Knoten zu aktivieren, die in diesem Subnetz laufen. Wenn das neue Subnetz nur für Pods reserviert ist, die in Ihrem EKS-Cluster mit aktivierter Präfixdelegierung ausgeführt werden, können Sie den Schritt der Präfixreservierung überspringen.

Ersetzen Sie alle Knoten, wenn Sie vom sekundären IP-Modus in den Präfix-Delegationsmodus oder umgekehrt migrieren

Es wird dringend empfohlen, neue Knotengruppen zu erstellen, um die Anzahl der verfügbaren IP-Adressen zu erhöhen, anstatt bestehende Worker-Knoten fortlaufend auszutauschen.

Wenn Sie selbstverwaltete Knotengruppen verwenden, wären die Schritte für den Übergang wie folgt:

Bei der Verwendung verwalteter Knotengruppen wären die Schritte für den Übergang wie folgt:

Für Windows empfehlen wir, Pods nicht gleichzeitig im sekundären IP-Modus und im Präfix-Delegationsmodus auszuführen. Eine solche Situation kann auftreten, wenn Sie beim Ausführen von Windows-Workloads vom sekundären IP-Modus in den Präfix-Delegationsmodus migrieren oder umgekehrt.

Dies hat zwar keine Auswirkungen auf Ihre laufenden Pods, es kann jedoch zu Inkonsistenzen in Bezug auf die IP-Adresskapazität des Knotens kommen. Stellen Sie sich zum Beispiel einen t3.xlarge-Knoten vor, der über 14 Steckplätze für sekundäre IPv4-Adressen verfügt. Wenn Sie 10 Pods verwenden, werden 10 Steckplätze auf der ENI von sekundären IP-Adressen belegt. Nachdem Sie die Präfix-Delegierung aktiviert haben, wäre die dem Kube-API-Server angegebene Kapazität (14 Steckplätze * 16 IP-Adressen pro Präfix) 244, aber die tatsächliche Kapazität in diesem Moment wäre (4 verbleibende Steckplätze * 16 Adressen pro Präfix) 64. Diese Inkonsistenz zwischen der angekündigten Kapazität und der tatsächlichen Kapazität (verbleibende Steckplätze) kann zu Problemen führen, wenn Sie mehr Pods betreiben, als IP-Adressen für die Zuweisung verfügbar sind.

Davon abgesehen können Sie die oben beschriebene Migrationsstrategie verwenden, um Ihre Pods sicher von einer sekundären IP-Adresse auf Adressen umzustellen, die aus Präfixen stammen. Wenn Sie zwischen den Modi wechseln, laufen die Pods normal weiter und:

Debugging-Probleme mit der Präfix-Delegierung

Sie können unseren Debugging-Leitfaden hier verwenden, um sich eingehend mit dem Problem zu befassen, mit dem Sie bei der Präfixdelegierung unter Windows konfrontiert sind.