**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.
# Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten
**Gilt für**: Linux- und Windows-Knoten mit Amazon-EC2-Instances
**Gilt für**: Öffentliche und private Subnetze
Jede Amazon-EC2-Instance unterstützt eine maximale Anzahl von elastischen Netzwerkschnittstellen und eine maximale Anzahl von IP-Adressen, die jeder Netzwerkschnittstelle zugewiesen werden können. Jeder Knoten benötigt eine IP-Adresse für jede Netzwerkschnittstelle. Alle anderen verfügbaren IP-Adressen können `Pods` zugewiesen werden. Jeder `Pod` benötigt seine eigene IP-Adresse. Daher verfügen Sie möglicherweise über Knoten, die über verfügbare Datenverarbeitungs- und Speicherressourcen verfügen, aber keine weiteren `Pods` aufnehmen können, da der Knoten nicht mehr über IP-Adressen verfügt, die `Pods` zugewiesen werden können.
Sie können die Anzahl der IP-Adressen erhöhen, die Knoten `Pods` zuweisen können, indem Sie IP-Präfixe zuweisen, anstatt Ihren Knoten einzelne sekundäre IP-Adressen zuzuweisen. Jedes Präfix enthält mehrere IP-Adressen. Wenn Sie Ihren Cluster nicht für die IP-Präfixzuweisung konfigurieren, muss Ihr Cluster mehr Amazon-EC2-Anwendungsprogrammierschnittstellen (API)-Aufrufe durchführen, um die für die Pod-Konnektivität erforderlichen Netzwerkschnittstellen und IP-Adressen zu konfigurieren. Mit zunehmender Cluster-Größe kann die Häufigkeit dieser API-Aufrufe zu längeren Pod- und Instance-Startzeiten führen. Dies führt zu Skalierungsverzögerungen, um die Nachfrage nach großen und spitzen Workloads zu decken, und erhöht den Kosten- und Verwaltungsaufwand, da Sie zusätzliche Cluster und VPCs bereitstellen müssen, um die Skalierungsanforderungen zu erfüllen. Weitere Informationen finden Sie unter [Kubernetes-Skalierbarkeitsschwellenwerte](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) auf GitHub.
## Kompatibilität mit den Amazon-VPC-CNI-Plugin für Kubernetes-Features
Sie können IP-Präfixe mit den folgenden Feature verwenden:
+ IPv4-Quellennetzwerk-Adressübersetzung – Weitere Informationen finden Sie unter [Aktivierung des ausgehenden Internetzugangs für Pods](external-snat.md).
+ IPv6-Adressen für Cluster, Pods und Services – Weitere Informationen finden Sie unter [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md).
+ Einschränkung des Datenverkehrs mithilfe von Kubernetes-Netzwerkrichtlinien – Weitere Informationen finden Sie unter [Begrenzen Sie den Pod-Datenverkehr mit Kubernetes-Netzwerkrichtlinien.](cni-network-policy.md).
Die folgende Liste enthält Informationen zu den geltenden Einstellungen für das Amazon-VPC-CNI-Plugin. Weitere Informationen zu den einzelnen Einstellungen finden Sie unter [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) auf GitHub.
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## Überlegungen
Beachten Sie bei der Verwendung von diesem Feature Folgendes:
+ Jeder Amazon-EC2-Instance-Typ unterstützt eine maximale Anzahl von Pods. Wenn Ihre verwaltete Knotengruppe aus mehreren Instance-Typen besteht, wird die kleinste maximale Anzahl von Pods für eine Instance im Cluster auf alle Knoten im Cluster angewendet.
+ Standardmäßig ist die maximale Anzahl von `Pods`, die Sie auf einem Knoten ausführen können, 110, aber Sie können diese Anzahl ändern. Wenn Sie die Anzahl ändern und eine verwaltete Knotengruppe haben, führt die nächste AMI- oder Startvorlagenaktualisierung Ihrer Knotengruppe dazu, dass neue Knoten mit dem geänderten Wert erstellt werden.
+ Beim Übergang von der Zuweisung von IP-Adressen zur Zuweisung von IP-Präfixen empfehlen wir, dass Sie neue Knotengruppen erstellen, um die Anzahl der verfügbaren IP-Adressen zu erhöhen, anstatt die vorhandenen Knoten fortlaufend zu ersetzen. Die Ausführung von Pods in einem Knoten, dem sowohl IP-Adressen als auch Präfixe zugewiesen sind, kann zu Inkonsistenzen bei der angekündigten IP-Adresskapazität führen, was sich auf die zukünftigen Workloads auf dem Knoten auswirkt. Die empfohlene Vorgehensweise für die Umstellung finden Sie im Abschnitt [Prefix-Delegierungsmodus für Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html) im *Leitfaden für bewährte Methoden für Amazon EKS*.
+ Der Geltungsbereich der Sicherheitsgruppe befindet sich auf Knotenebene. Weitere Informationen finden Sie unter [Sicherheitsgruppe](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
+ Einer Netzwerkschnittstelle zugewiesene IP-Präfixe unterstützen eine hohe Pod-Dichte pro Knoten und haben die beste Startzeit.
+ IP-Präfixe und IP-Adressen sind mit standardmäßigen elastischen Amazon-EC2-Netzwerkschnittstellen verknüpft. Pods, die bestimmte Sicherheitsgruppen erfordern, wird die primäre IP-Adresse einer Zweigstellen-Netzwerkschnittstelle zugewiesen. Sie können Pods, die IP-Adressen erhalten, oder IP-Adressen von IP-Präfixen mit Pods kombinieren, die Zweigstellen-Netzwerkschnittstellen auf demselben Knoten erhalten.
+ Nur für Cluster mit Linux-Knoten.
+ Nachdem Sie das Add-On so konfiguriert haben, dass Netzwerkschnittstellen Präfixe zugewiesen werden, können Sie Ihr Add-On für Amazon-VPC-CNI-Plugin für Kubernetes nicht auf eine niedrigere Version als `1.9.0` (oder `1.10.1`) herabstufen, ohne alle Knoten in allen Knotengruppen in Ihrem Cluster zu entfernen.
+ Wenn Sie auch Sicherheitsgruppen für Pods mit `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` und `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false` verwenden, werden bei der Kommunikation Ihrer Pods mit Endpunkten außerhalb Ihrer VPC die Sicherheitsgruppen des Knotens verwendet und nicht die Sicherheitsgruppen, die Sie Ihren Pods zugewiesen haben.
Wenn Sie auch [Sicherheitsgruppen für Pods](security-groups-for-pods.md) mit `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict` verwenden, werden die `Pod’s`-Sicherheitsgruppen verwendet, wenn Ihr `Pods` mit Endpunkten außerhalb Ihres VPC kommunizieren.
# Anzahl der verfügbaren IP-Adressen für Ihren Amazon-EKS-Knoten erhöhen
Sie können die Anzahl der IP-Adressen erhöhen, die Knoten Pods zuweisen können, indem Sie IP-Präfixe zuweisen, anstatt Ihren Knoten einzelne sekundäre IP-Adressen zuzuweisen.
## Voraussetzungen
+ Sie benötigen einen vorhandenen Cluster. Informationen zum Bereitstellen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md).
+ Die Subnetze, in denen sich Ihre Amazon-EKS-Knoten befinden, müssen über ausreichend zusammenhängende `/28` (für `IPv4`-Cluster) oder `/80` (für `IPv6`-Cluster) CIDR-Blöcke (Classless Inter-Domain Routing) verfügen. Sie können nur Linux-Knoten in einem `IPv6`-Cluster haben. Die Verwendung von IP-Präfixen kann fehlschlagen, wenn IP-Adressen im Subnetz-CIDR verstreut sind. Wir empfehlen Folgendes:
+ Verwendung einer Subnetz-CIDR-Reservierung, sodass selbst dann, wenn IP-Adressen innerhalb des reservierten Bereichs noch verwendet werden, die IP-Adressen nach ihrer Veröffentlichung nicht neu zugewiesen werden. Dadurch wird sichergestellt, dass Präfixe für die Zuweisung ohne Segmentierung verfügbar sind.
+ Verwenden Sie neue Subnetze, die speziell für die Ausführung der Workloads verwendet werden, denen IP-Präfixe zugewiesen sind. Sowohl Windows- als auch Linux-Workloads können bei der Zuordnung von IP-Präfixen im selben Subnetz ausgeführt werden.
+ Um Ihren Knoten IP-Präfixe zuzuweisen, müssen Ihre Knoten AWS Nitro-basiert sein. Instances, die nicht Nitro-basiert sind, weisen weiterhin einzelne sekundäre IP-Adressen zu, weisen jedoch eine deutlich geringere Anzahl von IP-Adressen auf, die Pods zugewiesen werden können als Nitro-basierte Instances.
+ **Nur für Cluster mit Linux-Knoten** – Wenn Ihr Cluster für die `IPv4`-Familie konfiguriert ist, muss Version `1.9.0` oder höher des Amazon-VPC-CNI-Plugins für das Kubernetes-Add-On installiert sein. Sie können Ihre aktuelle Version mit dem folgenden Befehl überprüfen.
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
Wenn Ihr Cluster für die `IPv6`-Familie konfiguriert ist, müssen Sie die Version `1.10.1` des Add-ons installiert haben. Wenn Ihre Plugin-Version älter ist als die erforderlichen Versionen, müssen Sie sie aktualisieren. Weitere Informationen finden Sie in den Aktualisierungsabschnitten von [Assign IPs to Pods with the Amazon VPC CNI](managing-vpc-cni.md).
+ **Nur für Cluster mit Windows-Knoten**
+ Sie müssen den Windows-Support für Ihren Cluster aktiviert haben. Weitere Informationen finden Sie unter [Bereitstellung von Windows-Knoten in EKS-Clustern](windows-support.md).
## Knoten IP-Adress-Präfixe zuweisen
Konfigurieren Sie Ihren Cluster, um Knoten IP-Adresspräfixe zuzuweisen. Führen Sie den Vorgang durch, der dem Betriebssystem Ihres Knotens entspricht.
### Linux
1. Aktivieren Sie den Parameter, um Netzwerkschnittstellen für das Amazon VPC CNI Präfixe zuzuweisen. DaemonSet Wenn Sie einen Cluster bereitstellen, wird die Version `1.10.1` oder eine neuere Version des Amazon-VPC-CNI-Plugins für Kubernetes-Add-On mit diesem bereitgestellt. Wenn Sie den Cluster mit der `IPv6`-Familie erstellt haben, wurde für diese Einstellung standardmäßig `true` festgelegt. Wenn Sie den Cluster mit der `IPv4`-Familie erstellt haben, wurde für diese Einstellung standardmäßig `false` festgelegt.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**Wichtig**
Auch wenn Ihr Subnetz über verfügbare IP-Adressen verfügt, wird in den Protokollen des Amazon-VPC-CNI-Plugins für Kubernetes der folgende Fehler angezeigt, wenn im Subnetz keine zusammenhängenden `/28`-Blöcke verfügbar sind:
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Dies kann aufgrund der Fragmentierung vorhandener sekundärer IP-Adressen auftreten, die über ein Subnetz verteilt sind. Um diesen Fehler zu beheben, erstellen Sie entweder ein neues Subnetz und starten Sie Pods dort, oder verwenden Sie eine CIDR-Reservierung für das EC2 Amazon-Subnetz, um Speicherplatz innerhalb eines Subnetzes für die Verwendung mit Präfixzuweisung zu reservieren. Weitere Informationen erhalten Sie unter [Subnetz-CIDR-Reservierungen](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) im Amazon-VPC-Benutzerhandbuch.
1. Wenn Sie planen, eine verwaltete Knotengruppe ohne Startvorlage bereitzustellen oder mit einer Startvorlage, in der Sie keine AMI-ID angegeben haben, und Sie eine Version des Amazon-VPC-CNI-Plugins für Kubernetes verwenden, die mindestens der in den Voraussetzungen gelisteten Version entspricht, fahren Sie mit dem nächsten Schritt fort. Verwaltete Knotengruppen berechnen automatisch die maximale Anzahl von Pods für Sie.
Wenn Sie eine selbstverwaltete Knotengruppe oder eine verwaltete Knotengruppe mit einer Startvorlage bereitstellen, in der Sie eine AMI-ID angegeben haben, müssen Sie die von Amazon EKS empfohlene Anzahl der maximalen Pods für Ihre Knoten ermitteln. Folgen Sie den Anweisungen in den von und fügen Sie Schritt 3 `--cni-prefix-delegation-enabled` hinzu. Notieren Sie sich die Ausgabe zur Verwendung in einem späteren Schritt.
**Wichtig**
Verwaltete Knotengruppen erzwingen eine maximale Anzahl für den Wert von `maxPods`. Für Instances mit weniger als 30 V ist CPUs die maximale Anzahl 110 und für alle anderen Instances ist die maximale Anzahl 250. Diese maximale Anzahl wird angewendet, unabhängig davon, ob die Präfixdelegierung aktiviert ist oder nicht.
1. Wenn Sie einen für `IPv6` konfigurierten Cluster verwenden, fahren Sie mit dem nächsten Schritt fort.
Geben Sie die Parameter in einer der folgenden Optionen an. Um zu ermitteln, welche Option für Sie die richtige ist und welchen Wert Sie dafür angeben müssen, finden Sie unter [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET und MINIMUM\$1IP\$1TARGET on](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md). GitHub
Sie können die Beispielwerte durch einen Wert größer als Null ersetzen.
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` oder `MINIMUM_IP_TARGET` – Wenn einer der Werte festgelegt ist, überschreibt er alle Werte, die für `WARM_PREFIX_TARGET` festgelegt wurden.
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. Erstellen Sie einen der folgenden Typen von Knotengruppen mit mindestens einem Amazon EC2 Nitro Amazon Linux 2023 Instance-Typ. Eine Liste der Nitro-Instance-Typen finden Sie unter [Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) im EC2 Amazon-Benutzerhandbuch. Diese Funktion wird unter Windows nicht unterstützt. Für die Optionen, die *110* enthalten, ersetzen Sie es entweder durch den Wert aus Schritt 3 (empfohlen) oder Ihren eigenen Wert.
+ **Selbstverwaltet** – Stellen Sie die Knotengruppe gemäß den Anweisungen unter [Erstellen selbstverwalteter Amazon-Linux-Knoten](launch-workers.md) bereit. Bevor Sie den CloudFormation Stack erstellen, öffnen Sie die Vorlagendatei und passen Sie sie wie folgt `NodeLaunchTemplate` an `UserData`
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
Wenn Sie `eksctl` zum Erstellen der Knotengruppe verwenden, können Sie den folgenden Befehl verwenden.
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **Verwaltet** – Stellen Sie Ihre Knotengruppe mit einer der folgenden Optionen bereit:
+ **Ohne Startvorlage oder mit einer Startvorlage ohne angegebene AMI-ID** – Führen Sie das Verfahren unter [Verwaltete Knotengruppe für Ihren Cluster erstellen](create-managed-node-group.md) durch. Verwaltete Knotengruppen berechnen automatisch den von Amazon EKS empfohlenen `max-pods`-Wert für Sie.
+ **Mit einer Startvorlage mit einer angegebenen AMI-ID** – Geben Sie in Ihrer Startvorlage eine Amazon EKS-optimierte AMI-ID oder ein benutzerdefiniertes AMI an, das auf dem Amazon EKS-optimierten AMI basiert, [stellen Sie dann die Knotengruppe mithilfe einer Startvorlage bereit](launch-templates.md) und geben Sie die folgenden Benutzerdaten an in der Startvorlage. Diese Benutzerdaten übergeben ein `NodeConfig` Objekt, das vom `nodeadm` Tool auf dem Knoten gelesen werden soll. Weitere Informationen zu `nodeadm` finden Sie in [der nodeadm-Dokumentation.](https://awslabs.github.io/amazon-eks-ami/nodeadm)
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
Wenn Sie `eksctl` zum Erstellen der Knotengruppe verwenden, können Sie den folgenden Befehl verwenden.
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Wenn Sie ein benutzerdefiniertes AMI erstellt haben, das nicht auf dem für Amazon EKS optimierten AMI erstellt wurde, müssen Sie die Konfiguration selbst erstellen.
**Anmerkung**
Wenn Sie Pods auch IP-Adressen aus einem anderen Subnetz als dem der Instance zuweisen möchten, müssen Sie die Funktion in diesem Schritt aktivieren. Weitere Informationen finden Sie unter [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md).
### Windows
1. Aktivieren Sie die Zuweisung von IP-Präfixen.
1. Öffnen Sie die `amazon-vpc-cni` `ConfigMap` zum Bearbeiten.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Fügen Sie dem Abschnitt `data` die folgende Zeile hinzu.
```
enable-windows-prefix-delegation: "true"
```
1. Speichern Sie die Datei und schließen Sie den Editor.
1. Vergewissern Sie sich, dass die Anmerkung der `ConfigMap` hinzugefügt wurde.
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
Wenn die zurückgegebene Ausgabe nicht `true` ist, ist möglicherweise ein Fehler aufgetreten. Versuchen Sie erneut, den Schritt abzuschließen.
**Wichtig**
Auch wenn Ihr Subnetz über verfügbare IP-Adressen verfügt, wird in den Protokollen des Amazon-VPC-CNI-Plugins für Kubernetes der folgende Fehler angezeigt, wenn im Subnetz keine zusammenhängenden `/28`-Blöcke verfügbar sind:
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Dies kann aufgrund der Fragmentierung vorhandener sekundärer IP-Adressen auftreten, die über ein Subnetz verteilt sind. Um diesen Fehler zu beheben, erstellen Sie entweder ein neues Subnetz und starten Sie Pods dort, oder verwenden Sie eine CIDR-Reservierung für das EC2 Amazon-Subnetz, um Speicherplatz innerhalb eines Subnetzes für die Verwendung mit Präfixzuweisung zu reservieren. Weitere Informationen erhalten Sie unter [Subnetz-CIDR-Reservierungen](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) im Amazon-VPC-Benutzerhandbuch.
1. (Optional) Geben Sie eine zusätzliche Konfiguration an, um das Verhalten Ihres Clusters vor der Skalierung und der dynamischen Skalierung zu steuern. Weitere Informationen finden Sie unter [Konfigurationsoptionen mit aktiviertem Präfix-Delegierungsmodus](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md) unter Windows. GitHub
1. Öffnen Sie die `amazon-vpc-cni` `ConfigMap` zum Bearbeiten.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Ersetzen Sie die Beispielwerte durch einen Wert größer als Null und fügen Sie die benötigten Einträge zum `data` Abschnitt von hinzu`ConfigMap`. Wenn Sie für `warm-ip-target` oder `minimum-ip-target` einen Wert festlegen, überschreibt der Wert jeden Wert, der für `warm-prefix-target` festgelegt wurde.
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. Speichern Sie die Datei und schließen Sie den Editor.
1. Erstellen Sie Windows-Knotengruppen mit mindestens einem Amazon EC2 Nitro-Instance-Typ. Eine Liste der Nitro-Instance-Typen finden Sie unter [Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) im EC2 Amazon-Benutzerhandbuch. Standardmäßig beträgt die maximale Anzahl von Pods, die Sie auf einem Knoten bereitstellen können, 110. Wenn Sie diese Zahl erhöhen oder verringern möchten, geben Sie in den Benutzerdaten für die Bootstrap-Konfiguration Folgendes an. Ersetzen Sie *max-pods-quantity* durch Ihren Wert für die maximale Anzahl von Pods.
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
Wenn Sie verwaltete Knotengruppen bereitstellen, muss diese Konfiguration zur Startvorlage hinzugefügt werden. Weitere Informationen finden Sie unter [Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md). Weitere Informationen zu den Konfigurationsparametern für das Windows-Bootstrap-Skript finden Sie unter [Bootstrap-Skript-Konfigurationsparameter](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Bestimmung der maximalen Anzahl von Pods und verfügbaren IP-Adressen
1. Nachdem Ihre Knoten bereitgestellt wurden, zeigen Sie die Knoten in Ihrem Cluster an.
```
kubectl get nodes
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. Beschreiben Sie einen der Knoten, um den Wert von `max-pods` für den Knoten und die Anzahl der verfügbaren IP-Adressen zu bestimmen. Ersetzen Sie *192.168.30.193* durch die `IPv4`-Adresse im Namen eines Ihrer Knoten, der in der Ausgabe des vorherigen Schritts zurückgegeben wurde.
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
Eine Beispielausgabe sieht wie folgt aus.
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
In der vorherigen Ausgabe `110` ist dies die maximale Anzahl von Pods, die Kubernetes auf dem Knoten bereitstellen wird, obwohl *144* IP-Adressen verfügbar sind.