**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.
# Subnetzauswahl für Pod-IP-Adressen konfigurieren
**Gilt für**: Linux-Knoten mit Amazon-EC2 -Instances
Das Amazon VPC CNI-Plugin für Kubernetes erstellt sekundäre Elastic Network Interfaces (ENIs) auf Ihren Knoten und weist Pods IP-Adressen von diesen ENIs zu. Standardmäßig erstellt das VPC-CNI sekundäre ENIs im selben Subnetz wie die primäre Netzwerkschnittstelle des Knotens. Sie können mit den folgenden Methoden steuern, welche Subnetze die VPC-CNI für Pod-IP-Adressen verwendet:
+ **Verbesserte Subnetzerkennung** — Die VPC-CNI erkennt und verwendet automatisch Subnetze, mit denen in derselben VPC und Availability `kubernetes.io/role/cni` Zone gekennzeichnet ist. Erfordert VPC CNI Version 1.18.0 oder höher. Wir empfehlen diese Methode für die meisten Anwendungsfälle.
+ **Benutzerdefiniertes Netzwerk** — Geben Sie mithilfe `ENIConfig` benutzerdefinierter Ressourcen manuell Subnetze und Sicherheitsgruppen pro Availability Zone an. Weitere Informationen finden Sie unter [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md).
**Anmerkung**
Benutzerdefiniertes Netzwerk hat Vorrang, wenn beide Funktionen aktiviert sind.
## Verbesserte Subnetzerkennung
VPC CNI Version 1.18.0 und höher aktiviert standardmäßig die erweiterte Subnetzerkennung (). `ENABLE_SUBNET_DISCOVERY=true` Die VPC-CNI erkennt automatisch Subnetze in derselben VPC und Availability Zone wie der Knoten und verwendet sie dann, um sekundäre ENIs zu erstellen und Pod-IP-Adressen zuzuweisen. Dadurch wird der verfügbare IP-Adressraum ohne manuelle Konfiguration erweitert. `ENIConfig`
Um zu überprüfen, ob die Funktion aktiviert ist:
```
kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY
```
Um diese Funktion zu deaktivieren, stellen Sie `ENABLE_SUBNET_DISCOVERY=false` das ein `aws-node` DaemonSet.
## Verhalten von Subnetz-Tags (`Kubernetes). io/role`/cni)
Das `kubernetes.io/role/cni` Tag steuert, wie das VPC-CNI Subnetze für ENI-Operationen und die Pod-IP-Zuweisung behandelt. Das Tag hat unterschiedliche Auswirkungen, je nachdem, ob die VPC-CNI eine neue ENI erstellt oder eine bestehende abgleicht.
**Wichtig**
Die Cluster-scoped und die ausschließenden Tagging-Mechanismen sind nur ab `v1.22.2` der Version VPC CNI verfügbar. Vor dieser Version war nur das standardmäßige Opt-In-Verhalten über das Tag verfügbar. `kubernetes.io/role/cni=1`
### Tag-Werte
In der folgenden Tabelle wird zusammengefasst, wie sich die einzelnen Tag-Werte auf das Verhalten des Subnetzes auswirken:
| Tag-Wert | Neue ENI-Erstellung | Bestehende ENI-Abstimmung |
| --- | --- | --- |
| `1` | **Opt-in**: Die VPC CNI erstellt neue ENIs in diesem Subnetz. | Die ENI bleibt für die Pod-IP-Zuweisung verfügbar. |
| `0` | **Ausgeschlossen**: Das VPC-CNI erstellt keine neuen ENIs in diesem Subnetz. | **Ausgeschlossen**: Das VPC-CNI schließt vorhandene ENIs in diesem Subnetz von der Pod-IP-Zuweisung aus. Aus dieser ENI werden keine neuen Pod-IPs zugewiesen. |
| Abwesend (kein Tag) | **Wird nicht für neue ENIs verwendet**: Das VPC-CNI wählt keine sekundären Subnetze ohne das Tag für die Erstellung neuer ENI aus. Das primäre Subnetz (das Subnetz, in dem der Knoten gestartet wurde) wird aus Gründen der Abwärtskompatibilität auch ohne das Tag weiterhin für die Erstellung neuer ENI verwendet. | **Keine Unterbrechung**: Bestehende ENIs in Subnetzen ohne Tags bleiben für die Pod-IP-Zuweisung verfügbar. Die VPC CNI entfernt oder schließt diese ENIs nicht aus. |
### Schöpfung versus Versöhnungsverhalten
Die VPC CNI wendet bei der Erstellung neuer ENIs und beim Abgleich vorhandener ENIs bewusst unterschiedliche Richtlinien an:
+ **Erstellung (Fail-closed für sekundäre Subnetze)**: Wenn die VPC-CNI eine neue sekundäre ENI erstellen muss, verwendet sie nur sekundäre Subnetze, mit denen explizit gekennzeichnet ist. `kubernetes.io/role/cni=1` Unmarkierte sekundäre Subnetze werden niemals für die Erstellung neuer ENI ausgewählt. Dadurch wird sichergestellt, dass neue Netzwerkschnittstellen nur in Subnetzen platziert werden, die Administratoren ausdrücklich genehmigt haben.
+ **Abgleich (Fail-Open für Subnetze ohne Tags): Wenn das VPC-CNI startet oder bestehende ENIs abgleicht, die bereits mit dem Knoten verbunden sind, werden ENIs nicht ausgeschlossen, da in ihrem Subnetz das Tag** fehlt. `kubernetes.io/role/cni` Dadurch wird verhindert, dass der Betrieb von Pods unterbrochen wird, die bereits IP-Adressen dieser ENIs verwenden.
Das VPC CNI verwendet dieses Design bewusst. Der gewaltsame Ausschluss einer bereits angeschlossenen ENI aus einem Subnetz ohne Tags würde Pods, die derzeit IP-Adressen dieser ENI verwenden, zum Erliegen bringen.
**Wichtig**
Um zu verhindern, dass ein Subnetz neue Pod-IPs — auch von bestehenden ENIs — bereitstellt, kennzeichnen Sie das Subnetz mit. `kubernetes.io/role/cni=0` Ein fehlendes Tag verhindert nur die Erstellung **neuer** ENI in diesem Subnetz. Bestehende ENIs werden dadurch nicht von der Zuteilung ausgeschlossen.
### Behandlung primärer Subnetze
Das VPC-CNI enthält immer das primäre Subnetz des Knotens (das Subnetz, in dem der Knoten gestartet wurde) für die ENI-Erstellung, auch ohne das Tag. `kubernetes.io/role/cni` Dadurch wird die Abwärtskompatibilität mit vorhandenen Clustern aufrechterhalten. Das Verhalten des primären Subnetzes:
+ Für die ENI-Erstellung unabhängig vom Vorhandensein des Tags enthalten (sofern nicht markiert`0`).
+ Wenn das VPC CNI mit markiert ist`kubernetes.io/role/cni=0`, schließt es das primäre Subnetz sowohl von der neuen ENI-Erstellung als auch von der bestehenden ENI-Zuweisung aus.
### Cluster-scoped Subnetzfilterung
Wenn ein Subnetz mit markiert ist`kubernetes.io/role/cni=1`, sucht das VPC-CNI zusätzlich anhand des Schlüsselformats nach clusterspezifischen Tags. `cni.networking.k8s.aws/cluster/` Wenn ein Subnetz Cluster-Tags in diesem Format hat, verwendet nur der Cluster, dessen Name übereinstimmt, dieses Subnetz. Subnetze mit `kubernetes.io/role/cni=1` und ohne clusterspezifische Tags sind für alle Cluster in der VPC verfügbar.
Um beispielsweise ein Subnetz auf einen bestimmten Cluster zu beschränken:
```
aws ec2 create-tags --resources subnet-example \
--tags Key=kubernetes.io/role/cni,Value=1 Key=cni.networking.k8s.aws/cluster/my-cluster,Value=shared
```
Dies ist nützlich, wenn sich mehrere EKS-Cluster eine VPC teilen und Sie möchten, dass jeder Cluster unterschiedliche Subnetze für Pod-IP-Adressen verwendet.
## Empfohlener Workflow
So fügen Sie neue Subnetze für Pod-IP-Adressen hinzu:
1. Erstellen Sie neue Subnetze in derselben VPC und Availability Zone wie Ihre Knoten.
1. Kennzeichnen Sie die Subnetze mit. `kubernetes.io/role/cni=1`
1. Stellen Sie sicher, dass die Subnetze über die entsprechenden Routing-Tabellen und Netzwerk-ACLs verfügen.
1. Stellen Sie sicher, dass das VPC-CNI die neuen Subnetze erkennt und mit der Nutzung beginnt.
Um ein Subnetz aus der Pod-IP-Zuweisung zu entfernen:
1. Kennzeichnen Sie das Subnetz mit. `kubernetes.io/role/cni=0`
1. Warten Sie, bis Pods, die IP-Adressen aus diesem Subnetz verwenden, beendet oder auf natürliche Weise neu geplant werden.
1. Stellen Sie sicher, dass das VPC-CNI keine neuen Pod-IPs mehr von ENIs in diesem Subnetz zuweist.
**Wichtig**
Entfernen Sie das `kubernetes.io/role/cni` Tag nicht, um die Nutzung eines Subnetzes zu beenden. Durch das Entfernen des Tags wird die Erstellung neuer ENIs verhindert, bestehende ENIs werden jedoch **nicht** von der Zuweisung ausgeschlossen. Um ein Subnetz aktiv auszuschließen, kennzeichnen Sie es mit. `kubernetes.io/role/cni=0`
## Überlegungen
+ Für die erweiterte Subnetzerkennung ist Amazon VPC CNI Version 1.18.0 oder höher erforderlich.
+ Für die Funktion ist eine `ec2:DescribeSubnets` Genehmigung in der VPC CNI IAM-Rolle erforderlich. Die `AmazonEKS_CNI_Policy` verwaltete Richtlinie beinhaltet diese Berechtigung. Die selbstverwaltete IPv6-IAM-Richtlinie beinhaltet sie **nicht**. Wenn Sie eine selbstverwaltete IAM-Richtlinie verwenden (z. B. für IPv6-Cluster), fügen Sie `ec2:DescribeSubnets` sie manuell hinzu, um die Subnetzerkennung zu aktivieren.
+ Die Funktion funktioniert sowohl im sekundären IP-Adressmodus als auch im Präfix-Delegierungsmodus.
+ Alle erkannten Subnetze müssen sich in derselben VPC wie der Knoten befinden.
+ Das VPC CNI erstellt ENIs nur in Subnetzen, die sich in derselben Availability Zone wie der Knoten befinden.
+ Die VPC-CNI gibt unabhängig von Tag-Änderungen keine ENIs frei, denen noch IP-Adressen zugewiesen sind.
+ Wenn Sie gemeinsam genutzte VPCs (kontoübergreifende Subnetze) verwenden, kennzeichnen Sie die Subnetze in dem Teilnehmerkonto, in dem der Cluster gestartet wird.
+ Sie können die erweiterte Subnetzerkennung zusammen mit Sicherheitsgruppen für Pods, Netzwerkrichtlinien, Präfixdelegierung und SNAT verwenden.