**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.
# Weitere Informationen zu VPC-CNI-Modi und deren Konfiguration
Das Amazon-VPC-CNI-Plugin für Kubernetes bietet Netzwerke für Pods. Verwenden Sie die folgende Tabelle, um mehr über die verfügbaren Netzwerk-Feature zu erfahren.
| Netzwerk-Feature | Weitere Informationen |
| --- | --- |
| Konfiguration Ihres Clusters zur Zuweisung von IPv6-Adressen an Cluster, Pods und Services | [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md) |
| Verwendung der IPv4-Quellnetzwerk-Adressübersetzung für Pods | [Aktivierung des ausgehenden Internetzugangs für Pods](external-snat.md) |
| Einschränkung des Netzwerk-Datenverkehrs zu und von Ihren Pods | [Pod-Netzwerk-Datenverkehr mit Kubernetes-Netzwerkrichtlinien einschränken](cni-network-policy-configure.md) |
| Anpassung der sekundären Netzwerkschnittstelle in Knoten | [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md) |
| Erhöhung der IP-Adressen für Ihren Knoten | [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md) |
| Verwendung von Sicherheitsgruppen für den Netzwerkverkehr von Pods | [Einzelnen Pods Sicherheitsgruppen zuweisen](security-groups-for-pods.md) |
| Verwendung mehrerer Netzwerkschnittstellen für Pods | [Anfügen mehrerer Netzwerkschnittstellen an Pods](pod-multiple-network-interfaces.md) |
# Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste
**Gilt für**: Pods mit EC2 Amazon-Instances und Fargate Pods
Standardmäßig weist Kubernetes Ihren Pods und Services `IPv4`-Adressen zu. Anstatt Ihren Pods und Services `IPv4`-Adressen zuzuweisen, können Sie Ihren Cluster so konfigurieren, dass er ihnen `IPv6`-Adressen zuweist. Amazon EKS unterstützt keine Dual-Stack-Pods oder -Services, obwohl Kubernetes dies tut. Daher können Sie Ihren Pods und Services nicht sowohl `IPv4`- als auch `IPv6`-Adressen zuweisen.
Sie wählen aus, welche IP-Familie Sie für Ihren Cluster verwenden möchten, wenn Sie ihn erstellen. Sie können die Familie nach dem Erstellen des Clusters nicht mehr ändern.
Ein Tutorial zum Bereitstellen eines Amazon-EKS-`IPv6`-Clusters finden Sie unter [Bereitstellen eines `IPv6`-Clusters von Amazon EKS und verwalteter Amazon-Linux-Knoten](deploy-ipv6-cluster.md).
Nachfolgend finden Sie einige Überlegungen zur Verwendung des Features:
## `IPv6`-Feature-Support
+ **Kein Windows-Support**: Windows-Pods und -Services werden nicht unterstützt.
+ **Nitro-basierte EC2 Knoten erforderlich**: Sie können sie nur `IPv6` mit AWS Nitro-basierten Amazon EC2 - oder Fargate-Knoten verwenden.
+ **EC2 und unterstützte Fargate-Knoten**: Sie können sie `IPv6` [Einzelnen Pods Sicherheitsgruppen zuweisen](security-groups-for-pods.md) mit EC2 Amazon-Knoten und Fargate-Knoten verwenden.
+ **Outposts werden nicht unterstützt**: Sie können `IPv6` nicht mit [Bereitstellung von Amazon EKS On-Premises mit AWS Outposts](eks-outposts.md) verwenden.
+ **FSx for Lustre wird nicht unterstützt**: Das [Verwendung von leistungsstarkem App-Speicher mit Amazon FSx für Lustre](fsx-csi.md) wird nicht unterstützt.
+ **Benutzerdefinierte Netzwerke werden nicht unterstützt**: Wenn Sie zuvor [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md) verwendet haben, um die Erschöpfung von IP-Adressen zu verringern, können Sie stattdessen `IPv6` verwenden. Sie können benutzerdefinierte Netzwerke nicht mit `IPv6` verwenden. Wenn Sie benutzerdefinierte Netzwerke für die Netzwerkisolierung verwenden, müssen Sie möglicherweise weiterhin benutzerdefinierte Netzwerke und die `IPv4`-Produktfamilie für Ihre Cluster verwenden.
## Zuweisung von IP-Adressen
+ **Kubernetes- Services**: Kubernetes-Services werden lediglich `IPv6`-Adressen zugewiesen. Ihnen sind keine IPv4 Adressen zugewiesen.
+ **Pods**: Pods werden eine IPv6 Adresse und eine lokale IPv4 Hostadresse zugewiesen. Die hostlokale IPv4 Adresse wird mithilfe eines hostlokalen CNI-Plug-ins zugewiesen, das mit VPC CNI verkettet ist, und die Adresse wird nicht an die Kubernetes-Steuerebene gemeldet. Es wird nur verwendet, wenn ein Pod mit externen IPv4 Ressourcen in einer anderen Amazon VPC oder im Internet kommunizieren muss. Die hostlokale IPv4 Adresse wird SNATed (per VPC CNI) an die primäre IPv4 Adresse der primären ENI des Worker-Knotens weitergeleitet.
+ **Pods und Services**: Pods und Services erhalten nur `IPv6`-Adressen, keine `IPv4`-Adressen. Wenn Pods mit externen `IPv4`-Endpunkten kommunizieren müssen, verwenden sie NAT auf dem Knoten selbst. [Diese integrierte NAT-Fähigkeit macht und überflüssig. DNS64 NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64) Für Datenverkehr, der einen öffentlichen Internetzugang erfordert, wird die Quellnetzwerkadresse des Pods in eine öffentliche IP-Adresse übersetzt.
+ **Weiterleitung von Adressen**: Wenn ein Pod außerhalb der VPC kommuniziert, bleibt seine ursprüngliche `IPv6`-Adresse erhalten (sie wird nicht in die `IPv6`-Adresse des Knotens übersetzt). Dieser Datenverkehr wird direkt über ein Internet-Gateway oder ein nur für den Ausgang bestimmtes Internet-Gateway weitergeleitet.
+ **Knoten**: Allen Knoten wird eine `IPv4`- und `IPv6`-Adresse zugewiesen.
+ **Fargate-Pods**: Jeder Fargate-Pod erhält eine `IPv6`-Adresse vom CIDR, die für das Subnetz angegeben ist, in dem er bereitgestellt wird. Die zugrunde liegende Hardwareeinheit, auf der Fargate Pods ausgeführt werden, erhält eine eindeutige `IPv4` `IPv6` Adresse von den CIDRs , die dem Subnetz zugewiesen sind, in dem die Hardwareeinheit bereitgestellt wird.
## Vorgehensweise zur Verwendung von `IPv6` mit EKS
+ **Neuen Cluster erstellen**: Sie müssen einen neuen Cluster erstellen und angeben, dass Sie die `IPv6`-Familie für diesen Cluster verwenden möchten. Sie können die `IPv6`-Familie nicht für einen Cluster aktivieren, den Sie von einer früheren Version aktualisiert haben. Anweisungen zum Erstellen eines neuen Clusters finden Sie unter Überlegungen.
+ **Aktuelles VPC CNI verwenden**: Stellen Sie Amazon VPC CNI Version `1.10.1` oder höher bereit. Diese Version oder höher wird standardmäßig bereitgestellt. Nachdem Sie das Add-On bereitgestellt haben, können Sie Ihr Amazon-VPC-CNI-Add-On nicht auf eine niedrigere Version als `1.10.1` herabstufen, ohne zuerst alle Knoten in allen Knotengruppen in Ihrem Cluster zu entfernen.
+ **VPC CNI konfigurieren für `IPv6`**: Wenn Sie EC2 Amazon-Knoten verwenden, müssen Sie das Amazon VPC CNI-Add-on mit IP-Präfix-Delegierung und konfigurieren. `IPv6` Wenn Sie beim Erstellen Ihres Clusters die `IPv6`-Familie wählen, wird die Version `1.10.1` des Add-ons standardmäßig auf diese Konfiguration festgelegt. Dies ist sowohl bei einem selbstverwalteten als auch bei Amazon EKS Add-on der Fall. Weitere Informationen über die IP-Präfix-Delegation finden Sie unter [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md).
+ **`IPv4`- und `IPv6`-Adressen konfigurieren**: Wenn Sie einen Cluster erstellen, müssen die VPC und die von Ihnen angegebenen Subnetze über einen `IPv6`-CIDR-Block verfügen, der der VPC und den von Ihnen angegebenen Subnetzen zugewiesen ist. Sie müssen auch über einen `IPv4`-CIDR-Block verfügen. Dies liegt daran, dass eine VPC, selbst wenn Sie nur `IPv6` verwenden möchten, immer noch einen `IPv4`-CIDR-Block benötigt, um zu funktionieren. Weitere Informationen finden Sie unter [Einen IPv6 CIDR-Block mit Ihrer VPC verknüpfen](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) im Amazon VPC-Benutzerhandbuch.
+ **Automatische Zuweisung von IPv6 Adressen zu Knoten:** Wenn Sie Ihre Knoten erstellen, müssen Sie Subnetze angeben, die für die automatische `IPv6` Zuweisung von Adressen konfiguriert sind. Andernfalls können Sie Ihre Knoten nicht bereitstellen. Diese Konfiguration ist standardmäßig deaktiviert. Weitere Informationen finden Sie unter [Ändern des IPv6 Adressierungsattributs für Ihr Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) im Amazon VPC-Benutzerhandbuch.
+ **Routing-Tabellen für die Verwendung von `IPv6` festlegen**: Die Routing-Tabellen, die Ihren Subnetzen zugewiesen sind, müssen Routen für `IPv6`-Adressen haben. Weitere Informationen finden Sie unter [Migrieren zu IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) im Amazon VPC-Benutzerhandbuch.
+ **Sicherheitsgruppen für `IPv6` festlegen**: Ihre Sicherheitsgruppen müssen `IPv6`-Adressen zulassen. Weitere Informationen finden Sie unter [Migrieren zu IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) im Amazon VPC-Benutzerhandbuch.
+ **Load Balancer einrichten**: Verwenden Sie Version `2.3.1` oder höher des Load Balancer Controllers, um den AWS Lastenausgleich von HTTP-Anwendungen mithilfe des [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md) oder des Netzwerkverkehrs mithilfe der [Weiterleitung von TCP- und UDP-Datenverkehr mit Network Load Balancers](network-load-balancing.md) To `IPv6` Pods durchzuführen, wobei sich einer der Load Balancer im IP-Modus, aber nicht im Instanzmodus befindet. Weitere Informationen finden Sie unter [Internetverkehr mit AWS Load Balancer Controller weiterleiten](aws-load-balancer-controller.md).
+ **`IPv6`-IAM-Richtlinie hinzufügen**: Sie müssen eine `IPv6`-IAM-Richtlinie an die IAM- oder CNI-IAM-Rolle Ihres Knotens anfügen. Zwischen den beiden empfehlen wir, dass Sie sie an eine CNI IAM-Rolle anfügen. Weitere Informationen erhalten Sie unter [Erstellen Sie eine IAM-Richtlinie für Cluster, die die `IPv6`-Familie verwendet](cni-iam-role.md#cni-iam-role-create-ipv6-policy) und [Schritt 1: Amazon-VPC-CNI-Plugin für die Kubernetes-IAM-Rolle erstellen](cni-iam-role.md#cni-iam-role-create-role).
+ **Evaluieren Sie alle Komponenten**: Führen Sie vor der Bereitstellung von `IPv6` Clustern eine gründliche Bewertung Ihrer Anwendungen, Amazon EKS-Add-ons und AWS Services durch, die Sie integrieren. Dies soll sicherstellen, dass mit `IPv6` alles wie erwartet funktioniert.
# Bereitstellen eines `IPv6`-Clusters von Amazon EKS und verwalteter Amazon-Linux-Knoten
In diesem Tutorial stellen Sie eine `IPv6` Amazon VPC, einen Amazon EKS-Cluster mit der `IPv6` Familie und eine verwaltete Knotengruppe mit Amazon EC2 Amazon Linux-Knoten bereit. Sie können keine Amazon EC2 Windows-Knoten in einem `IPv6` Cluster bereitstellen. Sie können Fargate-Knoten auch in Ihrem Cluster bereitstellen, obwohl diese Anweisungen in diesem Thema der Einfachheit halber nicht enthalten sind.
## Voraussetzungen
Führen Sie die folgenden Schritte aus, bevor Sie mit dem Tutorial beginnen:
Installieren und konfigurieren Sie die folgenden Tools und Ressourcen, die Sie zum Erstellen und Verwalten eines Amazon-EKS-Clusters benötigen.
+ Wir empfehlen Ihnen, sich mit allen Einstellungen vertraut zu machen und einen Cluster mit den Einstellungen bereitzustellen, die Ihren Anforderungen entsprechen. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md), [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md) und in den [Überlegungen](cni-ipv6.md) zu diesem Thema. Sie können nur einige Einstellungen aktivieren, wenn Sie Ihren Cluster erstellen.
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Der von Ihnen verwendete IAM-Sicherheitsprinzipal muss über Berechtigungen für die Arbeit mit Amazon EKS-IAM-Rollen, serviceverknüpften Rollen AWS CloudFormation, einer VPC und verwandten Ressourcen verfügen. Weitere Informationen finden Sie unter [Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) und [Verwendung von serviceverknüpften Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) im IAM-Benutzerhandbuch.
+ Wenn Sie eksctl verwenden, installieren Sie Version `0.215.0` oder höher auf Ihrem Computer. Informationen zum Installieren oder Aktualisieren finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software). Wenn Sie die verwenden AWS CloudShell, müssen Sie möglicherweise [Version 2.12.3 oder höher oder 1.27.160 oder höher der AWS CLI installieren, da es sich bei der](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) in der installierten AWS Standard-CLI-Version AWS CloudShell möglicherweise um eine frühere Version handelt.
Sie können eksctl oder die CLI verwenden, um einen `IPv6`-Cluster bereitzustellen.
## Stellen Sie einen Cluster mit eksctl bereit IPv6
1. Erstellen Sie die Datei `ipv6-cluster.yaml`. Kopieren Sie den folgenden Befehl auf Ihr Gerät. Nehmen Sie nach Bedarf die folgenden Änderungen am Befehl vor und führen Sie anschließend den geänderten Befehl aus:
+ Ersetzen Sie *my-cluster* durch Ihren Cluster-Namen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein.
+ *region-code*Ersetzen Sie durch eine beliebige AWS Region, die von Amazon EKS unterstützt wird. Eine Liste der AWS Regionen finden Sie unter [Amazon EKS-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/eks.html) im AWS Allgemeinen Referenzhandbuch.
+ Der Wert für `version` mit der Version Ihres Clusters. Weitere Informationen finden Sie unter [Unterstützte Versionen von Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Ersetzen Sie *my-nodegroup* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten.
+ Ersetzen Sie *t3.medium* durch jeden beliebigen [Instance-Typ von AWS Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
cat >ipv6-cluster.yaml <
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Vergewissern Sie sich, dass Standard-Services `IPv6`-Adressen zugewiesen wurden.
```
kubectl get services -n kube-system -o wide
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Optional) [Stellen Sie eine Beispielanwendung](sample-deployment.md) bereit oder stellen Sie den [AWS Load Balancer Controller](aws-load-balancer-controller.md) und eine Beispielanwendung bereit, um eine Lastenverteilung für HTTP-Anwendungen mit [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md) oder Netzwerkverkehr mit [Weiterleitung von TCP- und UDP-Datenverkehr mit Network Load Balancers](network-load-balancing.md) in `IPv6`-Pods durchzuführen.
1. Nachdem Sie mit dem Cluster und den Knoten fertig sind, die Sie für dieses Tutorial erstellt haben, sollten Sie die Ressourcen, die Sie erstellt haben, mit dem folgenden Befehl bereinigen.
```
eksctl delete cluster my-cluster
```
## Bereitstellen eines IPv6 Clusters mit AWS CLI
**Wichtig**
Sie müssen alle Schritte in diesem Verfahren als derselbe Benutzer ausführen. Führen Sie den folgenden Befehl aus, um den aktuellen Benutzer zu überprüfen:
```
aws sts get-caller-identity
```
Sie müssen alle Schritte in diesem Verfahren in derselben Shell ausführen. In mehreren Schritten in den vorherigen Schritten werden festgelegte Variablen verwendet. Schritte, die Variablen verwenden, funktionieren nicht ordnungsgemäß, wenn die Variablenwerte in einer anderen Shell festgelegt sind. Wenn Sie das [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)folgende Verfahren verwenden, denken Sie daran, dass Ihre Shell-Sitzung beendet wird, wenn Sie etwa 20 bis 30 Minuten lang nicht mit der Tastatur oder dem Zeiger damit interagieren. Laufende Prozesse zählen nicht als Interaktionen.
Die Anweisungen sind für die Bash-Shell geschrieben und müssen möglicherweise in anderen Shells angepasst werden.
Ersetzen Sie alle Beispielwerte in den Schritten dieses Verfahrens mit eigenen Werten.
1. Führen Sie die folgenden Befehle aus, um einige in späteren Schritten verwendete Variablen festzulegen. *region-code*Ersetzen Sie es durch die AWS Region, in der Sie Ihre Ressourcen bereitstellen möchten. Der Wert kann eine beliebige AWS Region sein, die von Amazon EKS unterstützt wird. Eine Liste der AWS Regionen finden Sie unter [Amazon EKS-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/eks.html) im AWS Allgemeinen Referenzhandbuch. Ersetzen Sie *my-cluster* durch Ihren Cluster-Namen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Ersetzen Sie *my-nodegroup* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Ersetzen Sie *111122223333* durch Ihre Konto-ID.
```
export region_code=region-code
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
```
1. Erstellen Sie eine Amazon VPC mit öffentlichen und privaten Subnetzen, die die Anforderungen von Amazon EKS und `IPv6` erfüllt.
1. Führen Sie den folgenden Befehl aus, um eine Variable für Ihren AWS CloudFormation Stack-Namen festzulegen. Sie können *my-eks-ipv6-vpc* mit einem beliebigen Namen ersetzen, den Sie wählen.
```
export vpc_stack_name=my-eks-ipv6-vpc
```
1. Erstellen Sie eine `IPv6` VPC mithilfe einer AWS CloudFormation Vorlage.
```
aws cloudformation create-stack --region $region_code --stack-name $vpc_stack_name \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
Das Erstellen des Stacks nimmt einige Minuten in Anspruch. Führen Sie den folgenden Befehl aus. Fahren Sie erst mit dem nächsten Schritt fort, wenn die Ausgabe des Befehls `CREATE_COMPLETE` ist.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name --query Stacks[].StackStatus --output text
```
1. Rufen Sie IDs die öffentlichen Subnetze ab, die erstellt wurden.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text
```
Eine Beispielausgabe sieht wie folgt aus.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE
```
1. Aktivieren Sie die Option „`IPv6`-Adressen automatisch zuweisen“ für die erstellten öffentlichen Subnetze.
```
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-0a1a56c486EXAMPLE --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-099e6ca77aEXAMPLE --assign-ipv6-address-on-creation
```
1. Rufen Sie die Namen der Subnetze und Sicherheitsgruppen, die mit der Vorlage erstellt wurden, aus dem bereitgestellten AWS CloudFormation Stack ab und speichern Sie sie in Variablen, um sie in einem späteren Schritt zu verwenden.
```
security_groups=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SecurityGroups`].OutputValue' --output text)
public_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text)
private_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPrivate`].OutputValue' --output text)
subnets=${public_subnets},${private_subnets}
```
1. Erstellen Sie eine Cluster-IAM-Rolle und fügen Sie ihr die erforderliche von Amazon EKS IAM verwaltete Richtlinie hinzu. Von Amazon EKS verwaltete Kubernetes-Cluster rufen in Ihrem Namen andere AWS Services auf, um die Ressourcen zu verwalten, die Sie mit dem Service verwenden.
1. Führen Sie den folgenden Befehl aus, um die Datei `eks-cluster-role-trust-policy.json` zu erstellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Führen Sie den folgenden Befehl aus, um eine Variable für Ihren Rollennamen festzulegen. Sie können *myAmazonEKSClusterRole* mit einem beliebigen Namen ersetzen, den Sie wählen.
```
export cluster_role_name=myAmazonEKSClusterRole
```
1. Erstellen Sie die Rolle.
```
aws iam create-role --role-name $cluster_role_name --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Rufen Sie den ARN der IAM-Rolle ab und speichern Sie ihn für einen späteren Schritt in einer Variablen.
```
CLUSTER_IAM_ROLE=$(aws iam get-role --role-name $cluster_role_name --query="Role.Arn" --output text)
```
1. Hängen Sie die erforderliche von Amazon EKS verwaltete IAM-Richtlinie an die Rolle an.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name $cluster_role_name
```
1. Erstellen Sie Ihren Cluster.
```
aws eks create-cluster --region $region_code --name $cluster_name --kubernetes-version 1.XX \
--role-arn $CLUSTER_IAM_ROLE --resources-vpc-config subnetIds=$subnets,securityGroupIds=$security_groups \
--kubernetes-network-config ipFamily=ipv6
```
1. HINWEIS: Sie erhalten möglicherweise eine Fehlermeldung, dass eine der Availability Zones in Ihrer Anfrage nicht über genügend Kapazität zum Erstellen eines Amazon-EKS-Clusters verfügt. Wenn dies der Fall ist, enthält die Fehlerausgabe die Availability Zones, die einen neuen Cluster unterstützen können. Versuchen Sie, Ihren Cluster mit mindestens zwei Subnetzen erneut zu erstellen, die sich in den unterstützten Availability Zones für Ihr Konto befinden. Weitere Informationen finden Sie unter [Unzureichende Kapazität](troubleshooting.md#ice).
Die Erstellung des Clusters dauert mehrere Minuten. Führen Sie den folgenden Befehl aus. Fahren Sie erst mit dem nächsten Schritt fort, wenn die Ausgabe aus dem Befehl `ACTIVE` ist.
```
aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status
```
1. Erstellen oder aktualisieren Sie eine `kubeconfig`-Datei für Ihren Cluster, sodass Sie mit Ihrem Cluster kommunizieren können.
```
aws eks update-kubeconfig --region $region_code --name $cluster_name
```
Standardmäßig wird die `config`-Datei in `~/.kube` erstellt oder die Konfiguration des neuen Clusters wird einer vorhandenen `config`-Datei in `~/.kube` hinzugefügt.
1. Erstellen Sie eine Knoten-IAM-Rolle.
1. Führen Sie den folgenden Befehl aus, um die Datei `vpc-cni-ipv6-policy.json` zu erstellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Erstellen Sie die IAM-Richtlinie.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Führen Sie den folgenden Befehl aus, um die Datei `node-role-trust-relationship.json` zu erstellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Führen Sie den folgenden Befehl aus, um eine Variable für Ihren Rollennamen festzulegen. Sie können *AmazonEKSNodeRole* mit einem beliebigen Namen ersetzen, den Sie wählen.
```
export node_role_name=AmazonEKSNodeRole
```
1. Erstellen Sie die IAM-Rolle.
```
aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Fügen Sie die IAM-Richtlinie an die IAM-Rolle an.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name $node_role_name
```
**Wichtig**
Der Einfachheit halber wird in diesem Tutorial die Richtlinie an diese IAM-Rolle angehängt. In einem Produktions-Cluster empfehlen wir jedoch, die Richtlinie an eine separate IAM-Rolle anzuhängen. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md).
1. Hängen Sie die beiden erforderlichen IAM-verwalteten Richtlinien an die IAM-Rolle an.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name $node_role_name
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name $node_role_name
```
1. Rufen Sie den ARN der IAM-Rolle ab und speichern Sie ihn für einen späteren Schritt in einer Variablen.
```
node_iam_role=$(aws iam get-role --role-name $node_role_name --query="Role.Arn" --output text)
```
1. Erstellen Sie eine verwaltete Knotengruppe.
1. Sehen Sie sich IDs die Subnetze an, die Sie in einem vorherigen Schritt erstellt haben.
```
echo $subnets
```
Eine Beispielausgabe sieht wie folgt aus.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE,subnet-0377963d69EXAMPLE,subnet-0c05f819d5EXAMPLE
```
1. Erstellen Sie die Knotengruppe. Ersetzen Sie *0a1a56c486EXAMPLE*, *099e6ca77aEXAMPLE*, *0377963d69EXAMPLE* und *0c05f819d5EXAMPLE* mit den im vorherigen Schritt zurückgegebenen Werten. Achten Sie darauf, die Kommas zwischen den Subnetzen IDs aus der vorherigen Ausgabe im folgenden Befehl zu entfernen. Sie können *t3.medium* mit jedem beliebigen [AWS -Nitro-System-Instance-Ty](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances)p ersetzen.
```
aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--subnets subnet-0a1a56c486EXAMPLE subnet-099e6ca77aEXAMPLE subnet-0377963d69EXAMPLE subnet-0c05f819d5EXAMPLE \
--instance-types t3.medium --node-role $node_iam_role
```
Das Erstellen der Knotengruppe nimmt einige Minuten in Anspruch. Führen Sie den folgenden Befehl aus. Fahren Sie nicht mit dem nächsten Schritt fort, bis die zurückgegebene Ausgabe `ACTIVE` ist.
```
aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--query nodegroup.status --output text
```
1. Vergewissern Sie sich, dass den Standard-Pods in der `IP`-Spalte `IPv6`-Adressen zugewiesen wurden.
```
kubectl get pods -n kube-system -o wide
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-rslts 1/1 Running 1 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Vergewissern Sie sich, dass den Standard-Services in der `IP`-Spalte `IPv6`-Adressen zugewiesen wurden.
```
kubectl get services -n kube-system -o wide
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Optional) [Stellen Sie eine Beispielanwendung](sample-deployment.md) bereit oder stellen Sie den [AWS Load Balancer Controller](aws-load-balancer-controller.md) und eine Beispielanwendung bereit, um eine Lastenverteilung für HTTP-Anwendungen mit [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md) oder Netzwerkverkehr mit [Weiterleitung von TCP- und UDP-Datenverkehr mit Network Load Balancers](network-load-balancing.md) in `IPv6`-Pods durchzuführen.
1. Nachdem Sie mit dem Cluster und den Knoten fertig sind, die Sie für dieses Tutorial erstellt haben, sollten Sie die Ressourcen, die Sie erstellt haben, mit den folgenden Befehlen bereinigen. Stellen Sie sicher, dass Sie keine der Ressourcen außerhalb dieses Tutorials verwenden, bevor Sie sie löschen.
1. Wenn Sie diesen Schritt in einer anderen Shell als die vorherigen Schritte ausführen, legen Sie die Werte aller in den vorherigen Schritten verwendeten Variablen fest und ersetzen Sie die Beispielwerte mit den Werten, die Sie angegeben haben, als Sie die vorherigen Schritte ausgeführt haben. Wenn Sie diesen Schritt in derselben Shell ausführen, in der Sie die vorherigen Schritte ausgeführt haben, fahren Sie mit dem nächsten Schritt fort.
```
export region_code=region-code
export vpc_stack_name=my-eks-ipv6-vpc
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
export node_role_name=AmazonEKSNodeRole
export cluster_role_name=myAmazonEKSClusterRole
```
1. Löschen Sie Ihre Knotengruppe.
```
aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name
```
Dies dauert in der Regel einige Minuten. Führen Sie den folgenden Befehl aus. Fahren Sie nicht mit dem nächsten Schritt fort, bis die Ausgabe zurückgegeben wurde.
```
aws eks list-nodegroups --region $region_code --cluster-name $cluster_name --query nodegroups --output text
```
1. Löschen Sie den Cluster.
```
aws eks delete-cluster --region $region_code --name $cluster_name
```
Das Löschen des Clusters nimmt einige Minuten in Anspruch. Stellen Sie vor dem Fortfahren sicher, dass der Cluster mit dem folgenden Befehl gelöscht wird.
```
aws eks describe-cluster --region $region_code --name $cluster_name
```
Fahren Sie erst mit dem nächsten Schritt fort, wenn Ihre Ausgabe der folgenden Ausgabe ähnelt.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
```
1. Löschen Sie die IAM-Ressourcen, die Sie erstellt haben. Ersetzen Sie *AmazonEKS\$1CNI\$1IPv6\$1Policy* mit dem von Ihnen gewählten Namen, wenn Sie einen anderen Namen als den in den vorherigen Schritten verwendeten gewählt haben.
```
aws iam detach-role-policy --role-name $cluster_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-role --role-name $cluster_role_name
aws iam delete-role --role-name $node_role_name
```
1. Löschen Sie den AWS CloudFormation Stack, der die VPC erstellt hat.
```
aws cloudformation delete-stack --region $region_code --stack-name $vpc_stack_name
```
# Aktivierung des ausgehenden Internetzugangs für Pods
**Gilt für**: Linux-`IPv4`-Fargate-Knoten, Linux-Knoten mit Amazon-EC2-Instances
Wenn Sie Ihren Cluster mit der `IPv6`-Familie bereitgestellt haben, treffen die Informationen in diesem Thema nicht auf Ihren Cluster zu, da für `IPv6`-Adressen keine Netzwerkübersetzung möglich ist. Weitere Informationen zur Verwendung von `IPv6` mit Ihrem Cluster finden Sie unter [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md).
Standardmäßig wird jedem Pod in Ihrem Cluster eine [private](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) `IPv4`-Adresse aus einem Classless Inter-Domain Routing (CIDR)-Block zugewiesen, der mit der VPC verknüpft ist, in welcher der Pod bereitgestellt wird. Pods im selben VPC kommunizieren miteinander und verwenden diese privaten IP-Adressen als Endpunkte. Wenn ein Pod mit einer `IPv4`-Adresse kommuniziert, die nicht Teil eines mit Ihrer VPC verknüpften CIDR-Blocks ist, übersetzt das Amazon-VPC-CNI-Plugin (für sowohl [Linux](https://github.com/aws/amazon-vpc-cni-k8s#amazon-vpc-cni-k8s) oder [Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge)) die `IPv4`-Adresse des standardmäßig in die primäre private `IPv4`-Adresse der primären [Elastic-Network-Schnittstelle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics) des Knotens, auf dem der Pod ausgeführt wird [\$1](#snat-exception).
**Anmerkung**
Bei Windows-Knoten sind zusätzliche Details zu beachten. Standardmäßig ist das [VPC CNI-Plugin für Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge) mit einer Netzwerkkonfiguration definiert, in der der Datenverkehr zu einem Ziel innerhalb derselben VPC für SNAT ausgeschlossen ist. Dies bedeutet, dass für die interne VPC-Kommunikation SNAT deaktiviert ist und die einem Pod zugewiesene IP-Adresse innerhalb der VPC routingfähig ist. Beim Datenverkehr zu einem Ziel außerhalb der VPC wird die Quell-Pod-IP jedoch per SNAT an die primäre IP-Adresse der Instance-ENI angepasst. Diese Standardkonfiguration für Windows stellt sicher, dass der Pod auf die gleiche Weise wie die Host-Instance auf Netzwerke außerhalb Ihrer VPC zugreifen kann.
Folgen dieses Verhaltens:
+ Ihre Pods können nur dann mit Internetressourcen kommunizieren, wenn dem Knoten, auf dem er ausgeführt wird, eine [öffentliche](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) oder [elastische](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) IP-Adresse zugeordnet ist und er sich in einem [öffentlichen Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics) befindet. Eine [Routing-Tabelle,](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) die einem öffentlichen Subnetz zugeordnet ist, verfügt über eine Route zu einem Internet-Gateway. Wir empfehlen, Knoten nach Möglichkeit in privaten Subnetzen bereitzustellen.
+ Bei früheren Versionen des Plug-ins können Ressourcen`1.8.0`, die sich in Netzwerken befinden oder VPCs die über [VPC-Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), eine [Transit-VPC oder [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) mit Ihrer Cluster-VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) verbunden sind, keine Kommunikation mit Ihren Pods hinter sekundären elastischen Netzwerkschnittstellen initiieren. Ihre Pods können jedoch eine Kommunikation an diese Ressourcen initiieren und Antworten von ihnen erhalten.
Wenn eine der folgenden Aussagen in Ihrer Umgebung zutrifft, ändern Sie die Standardkonfiguration mit dem folgenden Befehl.
+ Sie haben Ressourcen in Netzwerken oder VPCs die über [VPC-Peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), eine [Transit-VPC oder [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) mit Ihrer Cluster-VPC](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) verbunden sind und die die Kommunikation mit Ihren Pods über eine `IPv4` Adresse initiieren müssen und Ihre Plugin-Version ist älter als. `1.8.0`
+ Ihre Pods befinden sich in einem [privaten Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics) und müssen ausgehend mit dem Internet kommunizieren. Das Subnetz hat eine Route zu einem [NAT-Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
```
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
```
**Anmerkung**
Die `AWS_VPC_K8S_CNI_EXTERNALSNAT`- und `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS`-CNI-Konfigurationsvariablen gelten nicht für Windows-Knoten. Die Deaktivierung von SNAT wird für Windows nicht unterstützt. Wenn Sie eine Liste von `IPv4` CIDRs aus SNAT ausschließen möchten, können Sie dies definieren, indem Sie den `ExcludedSnatCIDRs` Parameter im Windows-Bootstrap-Skript angeben. Weitere Informationen zur Verwendung dieses Parameters finden Sie unter [Bootstrap-Skript-Konfigurationsparameter](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Host-Netzwerk
\$1 Wenn die Spezifikation eines Pods `hostNetwork=true` enthält (Standard ist `false`), wird seine IP-Adresse nicht in eine andere Adresse übersetzt. Dies ist standardmäßig der Fall für die `kube-proxy` und Amazon-VPC-CNI-Plugin für Kubernetes-Pods, die in Ihrem Cluster ausgeführt werden. Für diese Pods ist die IP-Adresse dieselbe wie die primäre IP-Adresse des Knotens. Daher wird die IP-Adresse des Pods nicht übersetzt. Weitere Informationen zur `hostNetwork` Einstellung eines Pods finden Sie unter [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) in der Kubernetes-API-Referenz.
# Begrenzen Sie den Pod-Datenverkehr mit Kubernetes-Netzwerkrichtlinien.
## -Übersicht
Standardmäßig gibt es in Kubernetes keine Einschränkungen für IP-Adressen, Ports oder Verbindungen zwischen Pods in Ihrem Cluster oder zwischen Ihren Pods und Ressourcen in anderen Netzwerken. Sie können die Kubernetes-*Netzwerkrichtlinie* verwenden, um Netzwerk-Datenerkehr zu und von Ihren Pods einzuschränken. Weitere Informationen finden Sie unter [Netzwerk-Richtlinien](https://kubernetes.io/docs/concepts/services-networking/network-policies/) in der Kubernetes-Dokumentation.
## Standardnetzwerkrichtlinie
Sie können den Standard verwenden`NetworkPolicy`, um den pod-to-pod Verkehr im Cluster zu segmentieren. Diese Netzwerkrichtlinien arbeiten auf den Ebenen 3 und 4 des OSI-Netzwerkmodells, sodass Sie den Datenverkehrsfluss auf IP-Adresse- oder Portebene innerhalb Ihres Amazon EKS-Clusters steuern können. Standardnetzwerkrichtlinien beziehen sich auf die Namespace-Ebene.
### Anwendungsfälle
+ Segmentieren Sie den Netzwerkverkehr zwischen Workloads, um sicherzustellen, dass nur verwandte Anwendungen miteinander kommunizieren können.
+ Isolieren Sie Mandanten auf Namespace-Ebene mithilfe von Richtlinien, um die Netzwerktrennung durchzusetzen.
### Beispiel
In der folgenden Richtlinie ist der ausgehende Datenverkehr aus den *Webapp-Pods* im *Sun-Namespace eingeschränkt*.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-egress-policy
namespace: sun
spec:
podSelector:
matchLabels:
role: webapp
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: moon
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
name: stars
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
```
Die Richtlinie gilt für Pods mit dem Label `role: webapp` im Namespace. `sun`
+ Zulässiger Verkehr: Pods mit dem Label `role: frontend` im `moon` Namespace am TCP-Port `8080`
+ Zulässiger Verkehr: Pods mit der Labelrolle: Frontend im `stars` Namespace am TCP-Port `8080`
+ Blockierter Verkehr: Jeglicher andere ausgehende Datenverkehr von `webapp` Pods wird implizit verweigert
## Netzwerkrichtlinie für Administratoren (oder Cluster)
![\[Abbildung der Bewertungsreihenfolge für Netzwerkrichtlinien in EKS\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/evaluation-order.png)
Sie können den verwenden`ClusterNetworkPolicy`, um einen Netzwerksicherheitsstandard durchzusetzen, der für den gesamten Cluster gilt. Anstatt wiederholt eine eigene Richtlinie für jeden Namespace zu definieren und zu verwalten, können Sie eine einzige Richtlinie verwenden, um die Netzwerkzugriffskontrollen für verschiedene Workloads im Cluster unabhängig von ihrem Namespace zentral zu verwalten.
### Anwendungsfälle
+ Verwalten Sie die Netzwerkzugriffskontrollen für alle (oder eine Teilmenge von) Workloads in Ihrem EKS-Cluster zentral.
+ Definieren Sie einen standardmäßigen Netzwerksicherheitsstatus für den gesamten Cluster.
+ Erweitern Sie die organisatorischen Sicherheitsstandards auf betrieblich effizientere Weise auf den gesamten Clusterbereich.
### Beispiel
In der folgenden Richtlinie können Sie den Clusterverkehr von anderen Namespaces explizit blockieren, um den Netzwerkzugriff auf einen sensiblen Workload-Namespace zu verhindern.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Wichtige Hinweise
Netzwerkrichtlinien im Amazon VPC CNI-Plugin für Kubernetes werden in den unten aufgeführten Konfigurationen unterstützt.
+ Version 1.21.0 (oder höher) des Amazon VPC CNI-Plug-ins für Standard- und Admin-Netzwerkrichtlinien.
+ Für `IPv4`- oder `IPv6`-Adressen konfigurierter Cluster.
+ Sie können Netzwerkrichtlinien mit [Sicherheitsgruppen für Pods](security-groups-for-pods.md) verwenden. Mit Netzwerkrichtlinien können Sie die gesamte Kommunikation innerhalb eines Clusters steuern. Mit Sicherheitsgruppen für Pods können Sie den Zugriff auf AWS Dienste von Anwendungen innerhalb eines Pods aus steuern.
+ Sie können Netzwerkrichtlinien mit *benutzerdefinierten Netzwerken* und *Präfixdelegierung* verwenden.
## Überlegungen
**Architektur**
+ Wenn Sie Netzwerkrichtlinien des Amazon VPC CNI-Plug-ins für Kubernetes mit dem Amazon VPC CNI-Plugin für Kubernetes auf Ihren Cluster anwenden, können Sie die Richtlinien nur auf Amazon Linux-Knoten anwenden. EC2 Sie können nicht in Fargate- oder Windows-Knoten angewendet werden.
+ Netzwerkrichtlinien gelten nur für `IPv4`- oder `IPv6`-Adressen, jedoch nicht für beide. In einem `IPv4`-Cluster weist die VPC CNI den Pods `IPv4`-Adressen zu und wendet `IPv4`-Richtlinien an. In einem `IPv6`-Cluster weist die VPC CNI den Pods `IPv6`-Adressen zu und wendet `IPv6`-Richtlinien an. Alle auf einen `IPv6`-Cluster angewendeten `IPv4`-Netzwerkrichtlinien werden ignoriert. Alle auf einen `IPv4`-Cluster angewendeten `IPv6`-Netzwerkrichtlinien werden ignoriert.
**Netzwerkrichtlinien**
+ Netzwerkrichtlinien werden ausschließlich auf Pods angewendet, die Teil einer Bereitstellung sind. Auf eigenständige Pods, für die kein `metadata.ownerReferences` festgelegt ist, können keine Netzwerkrichtlinien angewendet werden.
+ Sie können mehrere Netzwerkrichtlinien auf denselben Pods anwenden. Wenn zwei oder mehr Richtlinien konfiguriert werden, die denselben Pods auswählen, werden alle Richtlinien auf den Pod angewendet.
+ Die maximale Anzahl an Kombinationen aus Ports und Protokollen für einen einzelnen IP-Adressbereich (CIDR) beträgt 24 über alle Ihre Netzwerkrichtlinien hinweg. Selektoren wie die Auflösung zu einem oder mehreren. `namespaceSelector` CIDRs Wenn mehrere Selektoren zu einem einzigen CIDR führen oder Sie denselben direkten CIDR mehrfach in denselben oder verschiedenen Netzwerkrichtlinien angeben, werden diese alle auf dieses Limit angerechnet.
+ Für jeden Ihrer Kubernetes-Services muss der Port des Services mit dem Port des Containers identisch sein. Wenn Sie benannte Ports verwenden, verwenden Sie denselben Namen auch in der Servicespezifikation.
**Netzwerkrichtlinien für Administratoren**
1. **Richtlinien auf Admin-Ebene (zuerst bewertet)**: Alle Richtlinien auf Admin-Ebene ClusterNetworkPolicies werden vor allen anderen Richtlinien bewertet. Innerhalb der Admin-Ebene werden Richtlinien in der Reihenfolge ihrer Priorität verarbeitet (Nummer mit der niedrigsten Priorität zuerst). Der Aktionstyp bestimmt, was als Nächstes passiert.
+ **Aktion ablehnen (höchste Priorität)**: Wenn eine Admin-Richtlinie mit einer Ablehnungsaktion auf Traffic trifft, wird dieser Verkehr sofort blockiert, unabhängig von anderen Richtlinien. Es werden keine weiteren ClusterNetworkPolicy NetworkPolicy OD-Regeln verarbeitet. Dadurch wird sichergestellt, dass unternehmensweite Sicherheitskontrollen nicht durch Richtlinien auf Namespace-Ebene außer Kraft gesetzt werden können.
+ **Aktion zulassen**: Nach der Auswertung der Ablehnungsregeln werden Administratorrichtlinien mit Zulassen-Aktionen in der Reihenfolge ihrer Priorität verarbeitet (die niedrigste Priorität zuerst). Wenn eine Aktion „Zulassen“ zutrifft, wird der Datenverkehr akzeptiert und es findet keine weitere Richtlinienbewertung statt. Diese Richtlinien können auf der Grundlage von Label-Selektoren Zugriff auf mehrere Namespaces gewähren und ermöglichen so eine zentrale Kontrolle darüber, welche Workloads auf bestimmte Ressourcen zugreifen können.
+ **Aktion weiterleiten**: Bei der Weiterleitung von Aktionen in den Richtlinien der Admin-Ebene wird die Entscheidungsfindung an untergeordnete Ebenen delegiert. Wenn der Traffic mit einer Pass-Regel übereinstimmt, werden bei der Evaluierung alle verbleibenden Regeln auf Admin-Ebene für diesen Traffic übersprungen und direkt zur NetworkPolicy Stufe weitergeleitet. Auf diese Weise können Administratoren die Kontrolle über bestimmte Datenverkehrsmuster explizit an Anwendungsteams delegieren. Sie können beispielsweise Pass-Regeln verwenden, um die Verwaltung des Datenverkehrs innerhalb des Namespaces an Namespace-Administratoren zu delegieren und gleichzeitig strenge Kontrollen des externen Zugriffs aufrechtzuerhalten.
1. **Netzwerkrichtlinienebene**: Wenn keine Richtlinie auf Admin-Ebene mit „Verweigern“ oder „Zulassen“ übereinstimmt oder wenn eine Pass-Aktion gefunden wurde, werden Ressourcen mit NetworkPolicy Namespace-Bereich als Nächstes bewertet. Diese Richtlinien ermöglichen eine detaillierte Steuerung innerhalb der einzelnen Namespaces und werden von Anwendungsteams verwaltet. Namespace-bezogene Richtlinien können nur restriktiver sein als Admin-Richtlinien. Sie können die Ablehnungsentscheidung einer Admin-Richtlinie nicht außer Kraft setzen, aber sie können den Datenverkehr weiter einschränken, der durch Admin-Richtlinien zugelassen oder weitergeleitet wurde.
1. **Admin-Richtlinien der Baseline-Stufe**: Wenn keine Admin- oder Namespace-bezogenen Richtlinien dem Traffic entsprechen, wird die Baseline-Stufe bewertet. ClusterNetworkPolicies Diese bieten standardmäßige Sicherheitsvorkehrungen, die durch Richtlinien im Namespace-Bereich außer Kraft gesetzt werden können. So können Administratoren unternehmensweite Standardeinstellungen festlegen und den Teams gleichzeitig die Flexibilität geben, sie nach Bedarf anzupassen. Basisrichtlinien werden in der Reihenfolge ihrer Priorität bewertet (niedrigste Priorität zuerst).
1. **Standardverweigerung (wenn keine Richtlinien zutreffen)**: Dieses deny-by-default Verhalten stellt sicher, dass nur explizit zugelassene Verbindungen zugelassen werden, wodurch ein hohes Maß an Sicherheit gewährleistet wird.
**Migration**
+ Falls Ihr Cluster derzeit eine Drittanbieterlösung zur Verwaltung von Kubernetes-Netzwerkrichtlinien verwendet, können Sie dieselben Richtlinien mit dem Amazon-VPC-CNI-Plugin für Kubernetes nutzen. Sie müssen jedoch Ihre vorhandene Lösung entfernen, damit sie nicht dieselben Richtlinien verwaltet.
**Warnung**
Wir empfehlen, nach dem Entfernen einer Netzwerkrichtlinienlösung alle Knoten zu ersetzen, auf welche die Netzwerkrichtlinienlösung angewendet wurde. Der Grund dafür ist, dass die Datenverkehrsregeln möglicherweise von einem Pod der Lösung zurückgelassen werden, wenn dieser plötzlich beendet wird.
**Installation**
+ Das Netzwerkrichtlinienfeature erstellt und erfordert die Definition einer benutzerdefinierten `PolicyEndpoint`-Ressource (Custom Resource Definition, CRD) namens `policyendpoints.networking.k8s.aws`. `PolicyEndpoint`-Objekte der benutzerdefinierten Ressource werden von Amazon EKS verwaltet. Ändern oder löschen Sie diese Ressourcen nicht.
+ Wenn Sie Pods ausführen, die die IAM-Anmeldeinformationen der Instanzrolle verwenden oder eine Verbindung zum EC2 IMDS herstellen, achten Sie darauf, dass Netzwerkrichtlinien den EC2 Zugriff auf das IMDS blockieren würden. Möglicherweise müssen Sie eine Netzwerkrichtlinie hinzufügen, um den Zugriff auf IMDS zu ermöglichen. EC2 Weitere Informationen finden Sie unter [Instance-Metadaten und Benutzerdaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) im EC2 Amazon-Benutzerhandbuch.
Pods, die *IAM-Rollen für Dienstkonten* oder *EKS Pod Identity* verwenden, greifen nicht auf EC2 IMDS zu.
+ Das Amazon-VPC-CNI-Plugin für Kubernetes wendet keine Netzwerkrichtlinien auf zusätzliche Netzwerkschnittstellen für jeden Pod an, sondern nur auf die primäre Schnittstelle für jeden Pod (`eth0`). Das hat Auswirkungen auf folgende Architekturen:
+ `IPv6`-Pods, bei denen die Variable `ENABLE_V4_EGRESS` auf `true` festgelegt ist. Diese Variable ermöglicht es der `IPv4` Ausgangsfunktion, die IPv6 Pods mit Endpunkten zu verbinden, z. B. mit `IPv4` Endpunkten außerhalb des Clusters. Die `IPv4` Ausgangsfunktion erstellt eine zusätzliche Netzwerkschnittstelle mit einer lokalen Loopback-Adresse. IPv4
+ Bei Verwendung verketteter Netzwerk-Plugins wie Multus. Da diese Plugins jedem Pod Netzwerkschnittstellen hinzufügen, werden Netzwerkrichtlinien nicht auf die verketteten Netzwerk-Plugins angewendet.
# Pod-Netzwerk-Datenverkehr mit Kubernetes-Netzwerkrichtlinien einschränken
Sie können eine Kubernetes-Netzwerkrichtlinie verwenden, um den Netzwerk-Datenverkehr zu und von Ihren Pods einzuschränken. Weitere Informationen finden Sie unter [Netzwerk-Richtlinien](https://kubernetes.io/docs/concepts/services-networking/network-policies/) in der Kubernetes-Dokumentation.
Um dieses Feature nutzen zu können, müssen Sie Folgendes konfigurieren:
1. Richten Sie die Richtlinien-Durchsetzung beim Pod-Startup ein. Dies erfolgt im `aws-node`-Container des VPC-CNI-`DaemonSet`.
1. Aktivieren Sie den Netzwerkrichtlinienparameter für das Add-On.
1. Cluster für die Verwendung der Kubernetes-Netzwerkrichtlinie konfigurieren
Lesen Sie die Überlegungen noch einmal durch, bevor Sie beginnen. Weitere Informationen finden Sie unter [Überlegungen](cni-network-policy.md#cni-network-policy-considerations).
## Voraussetzungen
Für das Feature gelten folgende Voraussetzungen:
### Minimale Cluster-Version
Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Erste Schritte mit Amazon EKS](getting-started.md). Auf dem Cluster muss eine der in der folgenden Tabelle aufgeführten Kubernetes-Versionen und Plattform-Versionen ausgeführt werden. Beachten Sie, dass alle Kubernetes- und Plattformversionen, die über die aufgeführten hinausgehen, ebenfalls unterstützt werden. Sie können Ihre aktuelle Kubernetes-Version überprüfen, indem Sie *my-cluster* den folgenden Befehl durch den Namen Ihres Clusters ersetzen und dann den geänderten Befehl ausführen:
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Kubernetes-Version | Plattformversion |
| --- | --- |
| `1.27.4` | `eks.5` |
| `1.26.7` | `eks.6` |
### VPC-CNI-Mindestversion
Um sowohl Standard-Kubernetes-Netzwerkrichtlinien als auch Admin-Netzwerkrichtlinien zu erstellen, müssen Sie die Version `1.21` des VPC-CNI-Plug-ins ausführen. Sie können Ihre aktuelle Version mit dem folgenden Befehl überprüfen:
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Wenn Ihre Version älter als `1.21` ist, finden Sie unter [Aktualisieren der Amazon VPC CNI (Amazon-EKS-Add-On)](vpc-add-on-update.md) Informationen zum Aktualisieren des Plugins auf Version `1.21` oder höher.
### Linux-Kernel-Mindestversion
Ihre Knoten müssen eine Linux-Kernelversion ab Version `5.10` haben. Sie können Ihre Kernelversion mit `uname -r` überprüfen. Wenn Sie die neuesten Versionen von Amazon EKS-optimiertem Amazon Linux, Amazon EKS-optimiertem beschleunigtem Amazon Linux und Bottlerocket AMIs verwenden AMIs, verfügen diese bereits über die erforderliche Kernelversion.
Amazon-EKS-optimierte Amazon-Linux-AMI-Versionen ab `v20231116` verfügen über Kernel-Version `5.10`.
## Schritt 1: Richtlinien-Durchsetzung beim Startup des Pods einrichten
Das Amazon-VPC-CNI-Plugin für Kubernetes konfiguriert die Netzwerkrichtlinien für Pods parallel zur Pod-Bereitstellung. Bis alle Richtlinien für den neuen Pod konfiguriert sind, starten die Container im neuen Pod mit einer *Standard-Zulassungsrichtlinie*. Dies wird als *Standardmodus* bezeichnet. Eine Standard-Zulassungsrichtlinie bedeutet, dass der gesamte eingehende und ausgehende Datenverkehr zu und von den neuen Pods zugelassen wird. Beispielsweise werden für die Pods keine Firewall-Regeln durchgesetzt (der gesamte Datenverkehr ist zulässig), bis der neue Pod mit den aktiven Richtlinien aktualisiert wird.
Wenn die `NETWORK_POLICY_ENFORCING_MODE`-Variable auf `strict` gesetzt ist, starten Pods, die VPC CNI verwenden, mit einer *Standard-Verweigerungsrichtlinie*, anschließend werden die Richtlinien konfiguriert. Dies wird als *strikter Modus* bezeichnet. Im strikten Modus müssen Sie für jeden Endpunkt in Ihrem Cluster, auf den Ihre Pods zugreifen müssen, eine Netzwerkrichtlinie haben. Beachten Sie, dass diese Anforderung für die CoreDNS-Pods gilt. Die Standard-Verweigerungsrichtlinie ist für Pods mit Host-Netzwerk nicht konfiguriert.
Sie können die Standard-Netzwerkrichtlinie ändern, indem Sie die Umgebungsvariable `NETWORK_POLICY_ENFORCING_MODE` im `aws-node`-Container des VPC-CNI-`DaemonSet` auf `strict` setzen.
```
env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: "strict"
```
## Schritt 2: Netzwerk-Richtlinienparameter für das Add-On aktivieren
Das Netzwerkrichtlinien-Feature verwendet standardmäßig den Port `8162` auf dem Knoten für Metriken. Außerdem verwendet die Funktion den Port `8163` für Gesundheitstests. Wenn Sie eine andere Anwendung auf die Knoten oder innerhalb von Pods ausführen, die diese Ports verwenden müssen, kann die App nicht ausgeführt werden. Ab der VPC CNI-Version `v1.14.1` oder höher können Sie diese Ports ändern.
Führen Sie die folgenden Schritte aus, um den Netzwerk-Richtlinienparameter für das Add-On zu aktivieren.
### AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann **Edit** (Bearbeiten).
1. Auf der Seite **`Amazon VPC CNI` konfigurieren**:
1. Wählen Sie in der Liste **Version** eine Version vom Typ `v1.14.0-eksbuild.3` oder höher aus.
1. Erweitern Sie **Optionale Konfigurationseinstellungen**.
1. Geben Sie den JSON-Schlüssel `"enableNetworkPolicy":` und den Wert `"true"` in **Konfigurationswerte** ein. Der resultierende Text muss ein gültiges JSON-Objekt sein. Wenn dieser Schlüssel und dieser Wert die einzigen Daten im Textfeld sind, setzen Sie den Schlüssel und den Wert in geschweifte Klammern `{ }`.
Im folgenden Beispiel ist das Netzwerkrichtlinien-Feature aktiviert, und Metriken und Integritätsprüfungen sind auf die Standardportnummern eingestellt:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"healthProbeBindAddr": "8163",
"metricsBindAddr": "8162"
}
}
```
### Helm
Wenn Sie das Amazon-VPC-CNI-Plugin für Kubernetes über `helm` installiert haben, können Sie die Konfiguration aktualisieren, um die Ports zu ändern.
1. Führen Sie den folgenden Befehl aus, um die Ports zu ändern. Legen Sie die Portnummer im Wert für Schlüssel `nodeAgent.metricsBindAddr` bzw. Schlüssel `nodeAgent.healthProbeBindAddr` fest.
```
helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
### kubectl
1. Öffnen Sie das `DaemonSet` `aws-node` in Ihrem Editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ersetzen Sie die Portnummern in den folgenden Befehlsargumenten im `args:` im `aws-network-policy-agent`-Container im `aws-node`-DaemonSet-Manifest von VPC CNI.
```
- args:
- --metrics-bind-addr=:8162
- --health-probe-bind-addr=:8163
```
## Schritt 3: Cluster für die Verwendung von Kubernetes-Netzwerkrichtlinien konfigurieren
Sie können dies für ein Amazon-EKS-Add-On oder ein selbstverwaltetes Add-On einstellen.
### Amazon-EKS-Add-On
Mithilfe der AWS CLI können Sie den Cluster für die Verwendung von Kubernetes-Netzwerkrichtlinien konfigurieren, indem Sie den folgenden Befehl ausführen. Ersetzen Sie `my-cluster` durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
```
Gehen Sie wie folgt vor, um dies mit der AWS Management Console zu konfigurieren:
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann **Edit** (Bearbeiten).
1. Auf der Seite **`Amazon VPC CNI` konfigurieren**:
1. Wählen Sie in der Liste **Version** eine Version vom Typ `v1.14.0-eksbuild.3` oder höher aus.
1. Erweitern Sie **Optionale Konfigurationseinstellungen**.
1. Geben Sie den JSON-Schlüssel `"enableNetworkPolicy":` und den Wert `"true"` in **Konfigurationswerte** ein. Der resultierende Text muss ein gültiges JSON-Objekt sein. Wenn dieser Schlüssel und dieser Wert die einzigen Daten im Textfeld sind, setzen Sie den Schlüssel und den Wert in geschweifte Klammern `{ }`. Das folgende Beispiel veranschaulicht, dass die Netzwerkrichtlinie aktiviert ist:
```
{ "enableNetworkPolicy": "true" }
```
Der folgende Screenshot zeigt ein Beispiel für dieses Szenario.
![\[ zeigt das VPC-CNI-Add-On mit Netzwerkrichtlinie in der optionalen Konfiguration.\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/console-cni-config-network-policy.png)
### Selbstverwaltetes Add-On
Wenn Sie das Amazon-VPC-CNI-Plugin für Kubernetes über `helm` installiert haben, können Sie die Konfiguration aktualisieren, um die Netzwerkrichtlinie zu aktivieren.
1. Führen Sie den folgenden Befehl aus, um die Netzwerkrichtlinie zu aktivieren.
```
helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
1. Öffnen Sie das `ConfigMap` `amazon-vpc-cni` in Ihrem Editor.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Fügen Sie `data` in `ConfigMap` die folgende Zeile hinzu:
```
enable-network-policy-controller: "true"
```
Sobald Sie die Zeile hinzugefügt haben, sollte `ConfigMap` wie das folgende Beispiel aussehen.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Öffnen Sie das `DaemonSet` `aws-node` in Ihrem Editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ersetzen Sie im Befehlsargument `--enable-network-policy=false` in `args:` im Container `aws-network-policy-agent` im DaemonSet-Manifest `aws-node` von VPC CNI den Wert `false` durch `true`.
```
- args:
- --enable-network-policy=true
```
## Schritt 4. Nächste Schritte
Nachdem Sie die Konfiguration abgeschlossen haben, überprüfen Sie, ob die `aws-node`-Pods in Ihrem Cluster ausgeführt werden.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Eine Beispielausgabe sieht wie folgt aus.
```
aws-node-gmqp7 2/2 Running 1 (24h ago) 24h
aws-node-prnsh 2/2 Running 1 (24h ago) 24h
```
In den `aws-node`-Pods der Versionen `1.14` und höher befinden sich zwei Container. In früheren Versionen und wenn die Netzwerkrichtlinie deaktiviert ist, gibt es nur einen einzigen Container in den `aws-node`-Pods.
Sie können nun Kubernetes-Netzwerkrichtlinien in Ihrem Cluster bereitstellen.
Um Kubernetes-Netzwerkrichtlinien zu implementieren, können Sie Kubernetes `NetworkPolicy` oder `ClusterNetworkPolicy` Objekte erstellen und diese in Ihrem Cluster bereitstellen. `NetworkPolicy`Objekte sind auf einen Namespace beschränkt, während `ClusterNetworkPolicy` Objekte auf den gesamten Cluster oder mehrere Namespaces beschränkt werden können. Sie implementieren Richtlinien, um Datenverkehr zwischen Pods auf der Grundlage von Bezeichnungsselektoren, Namespaces und IP-Adressbereichen zuzulassen oder zu verweigern. Weitere Informationen zum Erstellen von `NetworkPolicy`-Objekten finden Sie unter [Netzwerkrichtlinien](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) in der Kubernetes-Dokumentation.
Die Durchsetzung von Kubernetes-`NetworkPolicy`-Objekten wird mithilfe des Extended Berkeley Packet Filter (eBPF) implementiert. Im Vergleich zu `iptables`-basierten Implementierungen bietet er geringere Latenzzeiten und Leistungsmerkmale, einschließlich einer geringeren CPU-Auslastung und der Vermeidung sequenzieller Suchvorgänge. Darüber hinaus bieten eBPF-Proben Zugriff auf kontextreiche Daten, die bei der Fehlersuche in komplexen Problemen auf Kernel-Ebene helfen und die Beobachtbarkeit verbessern. Amazon EKS unterstützt einen eBPF-basierten Exporter, der die Proben nutzt, um Richtlinienergebnisse auf jedem Knoten zu protokollieren und die Daten an externe Protokollsammler zu exportieren, um bei der Fehlersuche zu helfen. Weitere Informationen finden Sie in der [eBPF-Dokumentation](https://ebpf.io/what-is-ebpf/#what-is-ebpf).
# Deaktivierung der Kubernetes-Netzwerkrichtlinien für den Netzwerk-Datenverkehr von Amazon EKS Pods
Deaktivierung von Kubernetes-Netzwerkrichtlinien zur Beendigung der Einschränkung des Netzwerk-Datenverkehr von Amazon EKS Pods
1. Auflistung aller Kubernetes-Netzwerkrichtlinien
```
kubectl get netpol -A
```
1. Löschen Sie jede Kubernetes-Netzwerkrichtlinie. Sie müssen alle Netzwerkrichtlinien löschen, bevor Sie Netzwerkrichtlinien deaktivieren können.
```
kubectl delete netpol
```
1. Öffnen Sie das aws-node DaemonSet in Ihrem Editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ersetzen Sie im Befehlsargument `--enable-network-policy=true` in `args:` im Container `aws-network-policy-agent` im DaemonSet-Manifest `aws-node` von VPC CNI den Wert `true` durch `false`.
```
- args:
- --enable-network-policy=true
```
# Fehlerbehebung bei Kubernetes-Netzwerkrichtlinien für Amazon EKS
Dies ist die Anleitung zur Fehlerbehebung für die Netzwerkrichtlinien-Feature von Amazon VPC CNI.
Dieser Leitfaden behandelt:
+ Installationsinformationen, CRD- und RBAC-Berechtigungen [Neue `policyendpoints` CRD und Berechtigungen](#network-policies-troubleshooting-permissions)
+ Protokolle, die bei der Diagnose von Netzwerkrichtlinienproblemen [Netzwerkrichtlinien-Protokolle](#network-policies-troubleshooting-flowlogs) untersucht werden müssen
+ Ausführung der eBPF-SDK-Tool-Sammlung zur Fehlerbehebung
+ Bekannte Probleme und Lösungen [Bekannte Probleme und Lösungen](#network-policies-troubleshooting-known-issues)
**Anmerkung**
Beachten Sie, dass Netzwerkrichtlinien nur auf Pods angewendet werden, die von Kubernetes-*Bereitstellungen* erstellt werden. Weitere Einschränkungen der Netzwerkrichtlinien im VPC CNI finden Sie unter [Überlegungen](cni-network-policy.md#cni-network-policy-considerations).
Sie können Fehler bei Netzwerkverbindungen, die Netzwerkrichtlinien verwenden, beheben und untersuchen, indem Sie die [Netzwerkrichtlinien-Protokolle](#network-policies-troubleshooting-flowlogs) lesen und Tools aus dem [eBPF-SDK](#network-policies-ebpf-sdk) ausführen.
## Neue `policyendpoints` CRD und Berechtigungen
+ CRD: `policyendpoints.networking.k8s.aws`
+ Kubernetes API: `apiservice` mit dem Namen `v1.networking.k8s.io`
+ Kubernetes-Ressource: `Kind: NetworkPolicy`
+ RBAC: `ClusterRole` mit dem Namen `aws-node` (VPC CNI), `ClusterRole` mit dem Namen `eks:network-policy-controller` (Netzwerkrichtlinien-Controller in der EKS-Cluster-Steuerebene)
Für die Netzwerkrichtlinie erstellt das VPC CNI ein neues `CustomResourceDefinition` (CRD) mit dem Namen `policyendpoints.networking.k8s.aws`. Das VPC-CNI muss über Berechtigungen zum Erstellen der CRD und zum Erstellen CustomResources (CR) dieser und der anderen von der VPC CNI () installierten CRD verfügen. `eniconfigs.crd.k8s.amazonaws.com` [Beide CRDs sind in der Datei unter verfügbar. `crds.yaml`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) GitHub Insbesondere muss das VPC CNI über die Verb-Berechtigungen „get“, „list“ und „watch“ für `policyendpoints` verfügen.
Die Kubernetes-*Netzwerkrichtlinie* ist Teil des `apiservice` mit dem Namen `v1.networking.k8s.io`, und dieser `apiversion: networking.k8s.io/v1` befindet sich in Ihren YAML-Richtliniendateien. Die VPC CNI `DaemonSet` muss über die erforderlichen Berechtigungen verfügen, um diesen Teil der Kubernetes-API nutzen zu können.
Die VPC-CNI-Berechtigungen befinden sich in einem `ClusterRole` mit dem Namen `aws-node`. Beachten Sie, dass `ClusterRole`-Objekte nicht in Namespaces gruppiert sind. Nachfolgend wird der `aws-node` eines Clusters dargestellt:
```
kubectl get clusterrole aws-node -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: aws-vpc-cni
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: aws-node
app.kubernetes.io/version: v1.19.4
helm.sh/chart: aws-vpc-cni-1.19.4
k8s-app: aws-node
name: aws-node
rules:
- apiGroups:
- crd.k8s.amazonaws.com
resources:
- eniconfigs
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- namespaces
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- get
- apiGroups:
- ""
- events.k8s.io
resources:
- events
verbs:
- create
- patch
- list
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- apiGroups:
- vpcresources.k8s.aws
resources:
- cninodes
verbs:
- get
- list
- watch
- patch
```
Zudem wird in der Steuerebene jedes EKS-Clusters ein neuer Controller ausgeführt. Der Controller verwendet die Berechtigungen des `ClusterRole` mit dem Namen `eks:network-policy-controller`. Nachfolgend wird der `eks:network-policy-controller` eines Clusters dargestellt:
```
kubectl get clusterrole eks:network-policy-controller -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/name: amazon-network-policy-controller-k8s
name: eks:network-policy-controller
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/finalizers
verbs:
- update
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- patch
- update
- apiGroups:
- networking.k8s.io
resources:
- networkpolicies
verbs:
- get
- list
- patch
- update
- watch
```
## Netzwerkrichtlinien-Protokolle
Jede Entscheidung des VPC CNI, ob Verbindungen durch Netzwerkrichtlinien zugelassen oder verweigert werden, wird in *Ablaufprotokollen* festgehalten. Die Netzwerkrichtlinien-Protokolle auf jedem Knoten enthalten die Flussprotokolle für jeden Pod, der über eine Netzwerkrichtlinie verfügt. Netzwerkrichtlinien-Protokolle werden unter `/var/log/aws-routed-eni/network-policy-agent.log` gespeichert. Das folgende Beispiel stammt aus einer `network-policy-agent.log`-Datei:
```
{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}
```
Netzwerkrichtlinien-Protokolle sind standardmäßig deaktiviert. Um die Netzwerkrichtlinien-Protokolle zu aktivieren, führen Sie die folgenden Schritte aus:
**Anmerkung**
Netzwerkrichtlinien-Protokolle erfordern eine zusätzliche 1 vCPU für den `aws-network-policy-agent`-Container im `aws-node`-`DaemonSet`-Manifest von VPC CNI.
### Amazon-EKS-Add-On
** AWS-Managementkonsole **
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann **Edit** (Bearbeiten).
1. Auf der Seite ***Amazon VPC CNI* konfigurieren**:
1. Wählen Sie `v1.14.0-eksbuild.3` oder eine neuere **Version** in der Dropdown-Liste aus.
1. Erweitern Sie **Optionale Konfigurationseinstellungen**.
1. Geben Sie den JSON-Schlüssel der obersten Ebene `"nodeAgent":` ein, und der Wert ist ein Objekt mit dem Schlüssel `"enablePolicyEventLogs":` und dem Wert `"true"` in **Konfigurationswerte**. Der resultierende Text muss ein gültiges JSON-Objekt sein. Das folgende Beispiel zeigt, dass Netzwerkrichtlinien und Netzwerkrichtlinien-Protokolle aktiviert sind und die Netzwerkrichtlinien-Protokolle an CloudWatch Logs gesendet werden:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true"
}
}
```
Der folgende Screenshot zeigt ein Beispiel für dieses Szenario.
![\[zeigt das VPC CNI-Add-on mit Netzwerkrichtlinien und CloudWatch Protokollen in der optionalen Konfiguration an.\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/console-cni-config-network-policy-logs.png)
AWS CLI
1. Führen Sie den folgenden AWS CLI-Befehl aus. Ersetzen Sie `my-cluster` durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'
```
### Selbstverwaltetes Add-On
Helm
Wenn Sie das Amazon-VPC-CNI-Plugin für Kubernetes über `helm` installiert haben, können Sie die Konfiguration aktualisieren, um die Netzwerkrichtlinien-Protokolle zu schreiben.
1. Führen Sie den folgenden Befehl aus, um die Netzwerkrichtlinie zu aktivieren.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
kubectl
Wenn Sie das Amazon-VPC-CNI-Plugin für Kubernetes über `kubectl` installiert haben, können Sie die Konfiguration aktualisieren, um die Netzwerkrichtlinien-Protokolle zu schreiben.
1. Öffnen Sie das `DaemonSet` `aws-node` in Ihrem Editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ersetzen Sie das `false` durch `true` im Befehlsargument `--enable-policy-event-logs=false` im `args:` im `aws-network-policy-agent`-Container im VPC CNI `aws-node` `DaemonSet`-Manifest.
```
- args:
- --enable-policy-event-logs=true
```
### Netzwerkrichtlinien-Protokolle an Amazon CloudWatch Logs senden
Sie können die Netzwerkrichtlinienprotokolle mithilfe von Diensten wie Amazon CloudWatch Logs überwachen. Sie können die folgenden Methoden verwenden, um die Netzwerkrichtlinienprotokolle an Logs zu CloudWatch senden.
Bei EKS-Clustern befinden sich die Richtlinien-Protokolle unter `/aws/eks/cluster-name/cluster/` und bei selbstverwalteten K8S-Clustern sind die Protokolle unter `/aws/k8s-cluster/cluster/` platziert.
#### Senden von Netzwerkrichtlinien-Protokollen mit dem Amazon-VPC-CNI-Plugin für Kubernetes
Wenn Sie die Netzwerkrichtlinie aktivieren, wird den `aws-node`-Pods ein zweiter Container für einen *Konten-Agent* hinzugefügt. Dieser Node-Agent kann die CloudWatch Netzwerkrichtlinien-Protokolle an Logs senden.
**Anmerkung**
Nur die Netzwerkrichtlinien-Protokolle werden vom Knoten-Agent gesendet. Andere von VPC CNI erstellte Protokolle sind nicht enthalten.
##### Voraussetzungen
+ Fügen Sie der IAM-Rolle, die Sie für VPC CNI verwenden, die folgenden Berechtigungen als Abschnitt oder separate Richtlinie hinzu.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
##### Amazon-EKS-Add-On
** AWS-Managementkonsole **
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus. Wählen Sie dann den Namen des Clusters aus, für den Sie das Amazon-VPC-CNI-Add-on konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie das Kästchen oben rechts in der Add-On-Box aus und wählen Sie dann **Edit** (Bearbeiten).
1. Auf der Seite ***Amazon VPC CNI* konfigurieren**:
1. Wählen Sie `v1.14.0-eksbuild.3` oder eine neuere **Version** in der Dropdown-Liste aus.
1. Erweitern Sie **Optionale Konfigurationseinstellungen**.
1. Geben Sie den JSON-Schlüssel der obersten Ebene `"nodeAgent":` ein, und der Wert ist ein Objekt mit dem Schlüssel `"enableCloudWatchLogs":` und dem Wert `"true"` in **Konfigurationswerte**. Der resultierende Text muss ein gültiges JSON-Objekt sein. Das folgende Beispiel zeigt, dass Netzwerkrichtlinien und Netzwerkrichtlinien-Protokolle aktiviert sind und die Protokolle an CloudWatch Logs gesendet werden:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true",
"enableCloudWatchLogs": "true",
}
}
```
Der folgende Screenshot zeigt ein Beispiel für dieses Szenario.
![\[zeigt das VPC CNI-Add-on mit Netzwerkrichtlinien und CloudWatch Protokollen in der optionalen Konfiguration an.\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png)
** AWS -CLI**
1. Führen Sie den folgenden AWS CLI-Befehl aus. Ersetzen Sie `my-cluster` durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'
```
##### Selbstverwaltetes Add-On
**Helm**
Wenn Sie das Amazon VPC CNI-Plugin für Kubernetes über installiert haben, können Sie die Konfiguration aktualisieren`helm`, um Netzwerkrichtlinienprotokolle an Logs zu senden. CloudWatch
1. Führen Sie den folgenden Befehl aus, um Netzwerkrichtlinien-Protokolle zu aktivieren und sie an Logs zu senden. CloudWatch
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
**kubectl**
1. Öffnen Sie das `DaemonSet` `aws-node` in Ihrem Editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Ersetzen Sie das `false` durch `true` zwei Befehlsargumenten `--enable-policy-event-logs=false` im `--enable-cloudwatch-logs=false` im `args:` im `aws-network-policy-agent`-Container im VPC CNI `aws-node` `DaemonSet`-Manifest.
```
- args:
- --enable-policy-event-logs=true
- --enable-cloudwatch-logs=true
```
#### Netzwerkrichtlinien-Protokolle mit einem Fluent Bit-`DaemonSet` senden
Wenn Sie Fluent Bit in einem `DaemonSet` zum Senden von Protokollen von Ihren Knoten verwenden, können Sie eine Konfiguration hinzufügen, um die Netzwerkrichtlinien-Protokolle aus den Netzwerkrichtlinien einzubeziehen. Sie können die folgende Beispielkonfiguration verwenden:
```
[INPUT]
Name tail
Tag eksnp.*
Path /var/log/aws-routed-eni/network-policy-agent*.log
Parser json
DB /var/log/aws-routed-eni/flb_npagent.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
## Enthaltenes eBPF-SDK
Das Amazon-VPC-CNI-Plugin für Kubernetes installiert die eBPF-SDK-Tool-Sammlung auf den Knoten. Sie können die eBPF-SDK-Tools verwenden, um Probleme mit Netzwerkrichtlinien zu identifizieren. Der folgende Befehl listet zum Beispiel die Programme auf, die auf dem Knoten ausgeführt werden.
```
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
```
Zum Ausführen dieses Befehls können Sie eine beliebige Methode verwenden, um eine Verbindung mit dem Knoten herzustellen.
## Bekannte Probleme und Lösungen
In den folgenden Abschnitten werden bekannte Probleme mit dem Netzwerkrichtlinien-Feature von Amazon VPC CNI und deren Lösungen beschrieben.
### Netzwerkrichtlinien-Protokolle wurden generiert, obwohl sie auf enable-policy-event-logs „false“ gesetzt sind
**Problem**: EKS VPC CNI generiert Netzwerkrichtlinien-Protokolle, auch wenn die `enable-policy-event-logs`-Einstellung auf `false` gesetzt ist.
**Lösung**: Diese `enable-policy-event-logs`-Einstellung deaktiviert nur die Protokolle zur „Entscheidung“ über Richtlinien, jedoch nicht die gesamte Protokollierung des Netzwerkrichtlinien-Agenten. Dieses Verhalten ist in der [aws-network-policy-agent README-Datei](https://github.com/aws/aws-network-policy-agent/) unter GitHub dokumentiert. Um die Protokollierung vollständig zu deaktivieren, müssen Sie möglicherweise andere Protokollierungskonfigurationen anpassen.
### Probleme bei der Bereinigung der Netzwerk-Richtlinienzuordnung
**Problem**: Probleme mit dem Netzwerk `policyendpoint` bestehen weiterhin und werden nicht bereinigt, nachdem Pods gelöscht wurden.
**Lösung**: Dieses Problem wurde durch ein Problem mit dem VPC CNI-Add-on Version 1.19.3-eksbuild.1 verursacht. Aktualisieren Sie auf eine neuere Version des VPC-CNI-Add-Ons, um dieses Problem zu beheben.
### Netzwerkrichtlinien werden nicht angewendet
**Problem**: Das Netzwerkrichtlinien-Feature ist im Amazon-VPC-CNI-Plugin aktiviert, aber die Netzwerkrichtlinien werden nicht korrekt angewendet.
Wenn Sie eine Netzwerkrichtlinie `kind: NetworkPolicy` erstellen und diese keine Auswirkungen auf den Pod hat, überprüfen Sie, ob das Policyendpoint-Objekt im selben Namespace wie der Pod erstellt wurde. Wenn in den Namespaces keine `policyendpoint`-Objekte vorhanden sind, konnte der Netzwerkrichtlinien-Controller (Teil des EKS-Clusters) keine Netzwerkrichtlinien-Regeln für den Netzwerkrichtlinien-Agenten (Teil des VPC CNI) erstellen.
**Lösung**: Die Lösung besteht darin, die Berechtigungen des VPC CNI (`ClusterRole` : `aws-node`) und des Netzwerkrichtlinien-Controllers (`ClusterRole` : `eks:network-policy-controller`) anzupassen und diese Aktionen in jedem Tool zur Durchsetzung von Richtlinien, wie beispielsweise Kyverno, zuzulassen. Stellen Sie sicher, dass Kyverno-Richtlinien die Erstellung von `policyendpoint`-Objekten nicht blockieren. Informationen zu den erforderlichen Berechtigungen in [Neue `policyendpoints` CRD und Berechtigungen](#network-policies-troubleshooting-permissions) finden Sie im vorherigen Abschnitt.
### Pods kehren nach dem Löschen der Richtlinie im strikten Modus nicht in den Standard-Verweigerungsstatus zurück
**Problem**: Wenn Netzwerkrichtlinien im strikten Modus aktiviert sind, beginnen Pods mit einer Standard-Verweigerungsrichtlinie. Nachdem die Richtlinien angewendet wurden, wird der Datenverkehr zu den angegebenen Endpunkten zugelassen. Beim Löschen der Richtlinien kehrt der Pod jedoch nicht in den Standard-Verweigerungsstatus zurück, sondern in den Standard-Zulassungsstatus.
**Problem**: Dieses Problem wurde in der VPC CNI-Version 1.19.3 behoben, welche die Version 1.2.0 des Netzwerkrichtlinien-Agenten enthielt. Nach der Korrektur und bei aktiviertem strengen Modus kehrt der Pod nach dem Entfernen der Richtlinien wie erwartet in den Standard-Verweigerungsstatus zurück.
### Sicherheitsgruppen für Startup-Verzögerung von Pods
**Problem**: Bei Verwendung des Features „Sicherheitsgruppen für Pods“ in EKS kommt es zu einer erhöhten Startup-Verzögerung der Pods.
**Lösung**: Die Latenz ist auf die Ratenbegrenzung im Resource Controller durch die API-Drosselung auf der `CreateNetworkInterface` API zurückzuführen, die der VPC-Ressourcencontroller verwendet, um Verzweigungen ENIs für die Pods zu erstellen. Überprüfen Sie die API-Limits Ihres Kontos für diesen Vorgang und beantragen Sie gegebenenfalls eine Limit-Erhöhung.
### FailedScheduling aufgrund unzureichender vpc.amazonaws.com/pod-eni
**Problem**: Die Planung von Pods schlägt fehl mit folgendem Fehler: `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.`
**Lösung**: Wie beim vorherigen Problem erhöht die Zuweisung von Sicherheitsgruppen zu Pods die Latenz bei der Pod-Planung und kann über den CNI-Schwellenwert für die Zeit zum Hinzufügen jeder ENI hinausgehen, was zu Fehlern beim Starten von Pods führen kann. Dies ist das erwartete Verhalten bei der Verwendung von Sicherheitsgruppen für Pods. Berücksichtigen Sie beim Entwerfen Ihrer Workload-Architektur die Auswirkungen auf die Planung.
### IPAM-Konnektivitätsprobleme und Segmentierungsfehler
**Problem**: Es treten mehrere Fehler auf, darunter Probleme mit der IPAM-Konnektivität, Drosselungsanfragen und Segmentierungsfehler:
+ `Checking for IPAM connectivity …`
+ `Throttling request took 1.047064274s`
+ `Retrying waiting for IPAM-D`
+ `panic: runtime error: invalid memory address or nil pointer dereference`
**Lösung**: Dieses Problem tritt auf, wenn Sie `systemd-udev` auf AL2 023 installieren, da die Datei neu geschrieben wird und eine Richtlinie verletzt wird. Dies kann bei der Aktualisierung auf ein anderes `releasever` mit einem aktualisierten Paket oder bei der manuellen Aktualisierung des Pakets selbst auftreten. Vermeiden Sie die Installation oder Aktualisierung `systemd-udev` auf AL2 023-Knoten.
### Fehler beim Auffinden des Geräts anhand des Namens
**Problem**: Fehlermeldung: `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}`
**Lösung**: Dieses Problem wurde in den neuesten Versionen des Amazon-VPC-CNI-Netzwerkrichtlinien-Agenten (v1.2.0) erkannt und behoben. Aktualisieren Sie auf die neueste Version von VPC CNI, um dieses Problem zu beheben.
### CVE-Schwachstellen im Multus-CNI-Image
**Problem**: Der erweiterte EKS ImageScan CVE-Bericht identifiziert Sicherheitslücken in der Multus CNI-Image-Version v4.1.4-eksbuild.2\$1thick.
**Lösung**: Aktualisieren Sie auf die neue Version des Multus-CNI-Images und das neue Netzwerkrichtlinien-Controller-Image, die keine Schwachstellen aufweisen. Der Scanner kann aktualisiert werden, um die in der vorherigen Version gefundenen Schwachstellen zu beheben.
### Ablaufinformationen DENY-Urteile in Protokollen
**Probleme**: Netzwerkrichtlinien-Protokolle zeigen DENY-Urteile an: `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}`
**Lösung**: Dieses Problem wurde in der neuen Version des Netzwerkrichtlinien-Controllers behoben. Aktualisieren Sie auf die neueste EKS-Plattformversion, um Protokollierungsprobleme zu beheben.
### Pod-to-pod Kommunikationsprobleme nach der Migration von Calico
**Problem**: Nach dem Upgrade eines EKS-Clusters auf Version 1.30 und dem Wechsel von Calico zu Amazon VPC CNI für Netzwerkrichtlinien schlägt die pod-to-pod Kommunikation fehl, wenn Netzwerkrichtlinien angewendet werden. Die Kommunikation wird wiederhergestellt, wenn die Netzwerkrichtlinien gelöscht werden.
**Lösung**: Der Netzwerkrichtlinien-Agent im VPC CNI kann nicht so viele Ports wie Calico spezifizieren. Verwenden Sie stattdessen Port-Bereiche in den Netzwerkrichtlinien. Die Höchstzahl der eindeutigen Kombinationen von Ports für jedes Protokoll in jedem `ingress:`- oder `egress:`-Selektor in einer Netzwerkrichtlinie beträgt 24. Verwenden Sie Port-Bereiche, um die Anzahl der eindeutigen Ports zu reduzieren und diese Einschränkung zu vermeiden.
### Netzwerkrichtlinien-Agent unterstützt keine eigenständigen Pods
**Problem**: Netzwerkrichtlinien, die auf eigenständige Pods angewendet werden, können zu inkonsistentem Verhalten führen.
**Lösung**: Der Netzwerkrichtlinien-Agent unterstützt derzeit nur Pods, die als Teil einer Bereitstellung/eines Replikatsatzes bereitgestellt werden. Wenn Netzwerkrichtlinien auf eigenständige Pods angewendet werden, kann es zu Unstimmigkeiten im Verhalten kommen. [Dies ist oben auf dieser Seite, in und in der Ausgabe [Überlegungen](cni-network-policy.md#cni-network-policy-considerations) \$1327 am dokumentiert. aws-network-policy-agent GitHub ](https://github.com/aws/aws-network-policy-agent/issues/327) GitHub Stellen Sie Pods als Teil einer Bereitstellung oder eines Replikatsatzes bereit, um ein konsistentes Verhalten der Netzwerkrichtlinien zu gewährleisten.
# Stars-Demo der Netzwerkrichtlinie für Amazon EKS
Diese Demo erstellt einen Front-End-, Back-End- und Client-Service in Ihrem Amazon-EKS-Cluster. Außerdem wird in der Demo eine grafische Benutzeroberfläche für die Verwaltung erstellt, in der die verfügbaren Wege für ein- und ausgehenden Datenverkehr zwischen den einzelnen Services dargestellt werden. Wir empfehlen, die Demo in einem Cluster durchzuführen, in dem keine Produktions-Workloads ausgeführt werden.
Bevor Sie Netzwerkrichtlinien erstellen, können alle Services bidirektional kommunizieren. Nachdem Sie die Netzwerkrichtlinien angewendet haben, können Sie feststellen, dass der Client nur mit dem Front-End-Service kommuniziert und das Back-End nur Datenverkehr vom Front-End akzeptiert.
1. Wenden Sie die Services für Front-End, Back-End, Client und Verwaltungs-Benutzeroberfläche an:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
```
1. Zeigen Sie alle Pods im Cluster an.
```
kubectl get pods -A
```
Eine Beispielausgabe sieht wie folgt aus.
In Ihrer Ausgabe sollten Pods in den Namespaces aufgeführt sein, die in der folgenden Ausgabe angezeigt werden. Die *NAMEN* Ihrer Pods und die Anzahl der Pods in der Spalte `READY` unterscheiden sich von den Angaben in der folgenden Ausgabe. Fahren Sie erst dann fort, wenn Pods mit ähnlichen Namen angezeigt werden und bei allen `Running` in der Spalte `STATUS` aufgeführt wird.
```
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
client client-xlffc 1/1 Running 0 5m19s
[...]
management-ui management-ui-qrb2g 1/1 Running 0 5m24s
stars backend-sz87q 1/1 Running 0 5m23s
stars frontend-cscnf 1/1 Running 0 5m21s
[...]
```
1. Zum Herstellen einer Verbindung mit der Verwaltungsbenutzeroberfläche stellen Sie eine Verbindung mit der `EXTERNAL-IP` des Services her, der auf Ihrem Cluster ausgeführt wird.
```
kubectl get service/management-ui -n management-ui
```
1. Öffnen Sie den Pfad aus dem vorherigen Schritt in einem Browser. Die Verwaltungs-Benutzeroberfläche sollte angezeigt werden. Der **C-**-Knoten ist der Client-Service, der **F**-Knoten ist der Front-End-Service und der **B-**-Knoten ist der Back-End-Service. Jeder Knoten verfügt über vollständigen Kommunikationszugriff auf alle anderen Knoten, wie durch die fett markierten, farbigen Zeilen angegeben.
![\[Öffnen der Netzwerkrichtlinie\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/stars-default.png)
1. Wenden Sie die folgende Netzwerkrichtlinie sowohl in den `stars`- als auch in den `client`-Namespaces an, um die Services voneinander zu isolieren:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny
spec:
podSelector:
matchLabels: {}
```
Sie können die folgenden Befehle verwenden, um die Richtlinie auf beide Namespaces anzuwenden:
```
kubectl apply -n stars -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
```
1. Aktualisieren Sie Ihren Browser. Wie Sie feststellen können, kann die Benutzeroberfläche der Verwaltung keinen der Knoten mehr erreichen, sodass diese nicht in der Benutzeroberfläche angezeigt werden.
1. Wenden Sie die folgenden verschiedenen Netzwerkrichtlinien an, um der Verwaltungsbenutzeroberfläche den Zugriff auf die Services zu erlauben: Wenden Sie diese Richtlinie an, um die Benutzeroberfläche zuzulassen:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Wenden Sie diese Richtlinie an, um den Client zuzulassen:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: client
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Sie können die folgenden Befehle verwenden, um beide Richtlinien anzuwenden:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
```
1. Aktualisieren Sie Ihren Browser. Wie Sie feststellen, können die Knoten nun wieder über die Verwaltungs-Benutzeroberfläche erreicht werden, sie können jedoch nicht miteinander kommunizieren.
![\[Benutzeroberflächen-Zugriff – Netzwerkrichtlinie\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/stars-no-traffic.png)
1. Wenden Sie die folgende Netzwerkrichtlinie an, um Verkehr vom Front-End-Service zum Back-End-Service zuzulassen:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: backend-policy
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
```
1. Aktualisieren Sie Ihren Browser. Wie Sie feststellen, kann das Front-End mit dem Back-End kommunizieren.
![\[Richtlinie für Datenverkehr zwischen Front-End und Back-End\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/stars-front-end-back-end.png)
1. Wenden Sie die folgende Netzwerkrichtlinie an, um Datenverkehr vom Client zum Front-End-Service zuzulassen:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: frontend-policy
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 80
```
1. Aktualisieren Sie Ihren Browser. Wie Sie feststellen, kann der Client mit dem Front-End-Service kommunizieren. Der Front-End-Service kann nach wie vor mit dem Back-End-Service kommunizieren.
![\[Endgültige Netzwerkrichtlinie\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/stars-final.png)
1. (Optional) Wenn Sie die Demo abgeschlossen haben, können Sie die zugehörigen Ressourcen löschen.
```
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
```
Auch nach dem Löschen der Ressourcen können noch Netzwerkrichtlinien-Endpunkte auf den Knoten vorhanden sein, die die Vernetzung in Ihrem Cluster auf unerwartete Weise stören können. Die einzige sichere Möglichkeit, diese Regeln zu entfernen, besteht darin, die Knoten neu zu starten oder alle Knoten zu beenden und sie zu recyceln. Um alle Knoten zu beenden, legen Sie entweder die Anzahl der gewünschten Auto Scaling-Gruppen auf 0 und anschließend wieder auf die gewünschte Zahl fest oder beenden einfach die Knoten.
# Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk
**Gilt für**: Linux-`IPv4`-Fargate-Knoten, Linux-Knoten mit Amazon-EC2-Instances
![\[Diagramm eines Knotens mit mehreren Netzwerkschnittstellen\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/cn-image.png)
Standardmäßig erstellt das Amazon-VPC-CNI-Plugin für Kubernetes sekundäre [Elastic-Network-Schnittstellen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (Netzwerkschnittstellen) für Ihren Amazon-EC2-Knoten im gleichen 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:
+ Es gibt eine begrenzte Anzahl von `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.
**Tipp**
Sie können Ihrem Amazon-EKS-Cluster auch direkt ein neues oder vorhandenes Subnetz hinzufügen, ohne benutzerdefinierte Netzwerke zu verwenden. Weitere Informationen finden Sie unter [Hinzufügen eines vorhandenen VPC-Subnetzes zu einem Amazon-EKS-Cluster über die Management-Konsole](eks-networking.md#add-existing-subnet).
## Überlegungen
Nachfolgend finden Sie einige Überlegungen zur Verwendung dieses Features.
+ 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 [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md).
+ Auch wenn Pods in Subnetzen für sekundäre Netzwerkschnittstellen bereitgestellte andere Subnetz- und Sicherheitsgruppen verwenden können als die primäre Netzwerkschnittstelle des Knotens, müssen sich die Subnetze und Sicherheitsgruppen in derselben VPC befinden wie der Knoten.
+ Bei Fargate werden Subnetze über das Fargate-Profil verwaltet. Weitere Informationen finden Sie unter [Festlegung, welche Pods beim Start AWS Fargate verwenden](fargate-profile.md).
# Anpassung der sekundären Netzwerkschnittstelle in Amazon-EKS-Knoten
Führen Sie die folgenden Schritte aus, bevor Sie mit dem Tutorial beginnen:
+ Überlegungen überprüfen
+ Vertrautheit mit der Funktionsweise des Amazon-VPC-CNI-Plugins für Kubernetes, das sekundäre Netzwerkschnittstellen erstellt und Pods IP-Adressen zuweist. Weitere Informationen finden Sie unter [ENI-Zuweisung](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation) auf GitHub.
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Wir empfehlen, dass Sie die Schritte in diesem Thema in einer Bash-Shell ausführen. Wenn Sie keine Bash-Shell verwenden, erfordern einige Skript-Befehle wie Zeilenfortsetzungszeichen und die Art und Weise, wie Variablen gesetzt und verwendet werden, eine Anpassung für Ihre Shell. Darüber hinaus können die Zitier- und Escape-Regeln für Ihre Shell unterschiedlich sein. Weitere Informationen finden Sie unter [Verwenden von Anführungszeichen mit Zeichenfolgen in der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle.
Für dieses Tutorial empfehlen wir die Verwendung der Beispielwerte, außer es gibt eine Annotation, diese zu ersetzen. Sie können alle Beispielwert ersetzen, wenn Sie die Schritte für einen Produktions-Cluster ausführen. Wir empfehlen, alle Schritte auf demselben Terminal auszuführen. Grund dafür ist, dass Variablen während der Schritte festgelegt und verwendet werden und diese in anderen Terminals nicht vorhanden sind.
Die Befehle in diesem Thema werden anhand der Konventionen formatiert, die unter [Verwenden der AWS CLI-Beispiele](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html) aufgeführt sind. Wenn Sie Befehle über die Befehlszeile für Ressourcen ausführen, die sich in einer anderen AWS Region als der AWS Standardregion befinden, die in dem von Ihnen verwendeten AWS [CLI-Profil](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles) definiert ist, müssen Sie die Befehle ergänzen `--region us-west-2` und durch Ihre AWS Region `us-west-2` ersetzen.
Wenn Sie benutzerdefinierte Netzwerke in Ihrem Produktions-Cluster bereitstellen möchten, fahren Sie mit [Schritt 2: Konfigurieren Ihrer VPC](#custom-networking-configure-vpc) fort.
## Schritt 1: Erstellen einer Test-VPC und eines Clusters
Mit den folgenden Verfahren können Sie eine Test-VPC und einen Cluster erstellen und benutzerdefinierte Netzwerke für diesen Cluster konfigurieren. Wir empfehlen, den Test-Cluster nicht für Produktions-Workloads zu verwenden, da in diesem Thema verschiedene nicht zugehörige Features nicht behandelt werden, die Sie vielleicht in Ihrem Produktions-Cluster verwenden. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md).
1. Führen Sie den folgenden Befehl aus, um die `account_id`-Variable zu definieren.
```
account_id=$(aws sts get-caller-identity --query Account --output text)
```
1. Erstellen Sie eine VPC.
1. Wenn Sie die Bereitstellung auf einem Testsystem durchführen, erstellen Sie eine VPC mithilfe einer Amazon AWS CloudFormation EKS-Vorlage.
```
aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
--parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
```
1. Die Erstellung des AWS CloudFormation Stacks dauert einige Minuten. Führen Sie den folgenden Befehl aus, um den Status der Bereitstellung des Stacks zu überprüfen.
```
aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus --output text
```
Fahren Sie erst mit dem nächsten Schritt fort, wenn die Ausgabe des Befehls `CREATE_COMPLETE` ist.
1. Definieren Sie Variablen mit den Werten des privaten Subnetzes, das durch die Vorlage IDs erstellt wurde.
```
subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
```
1. Definieren Sie Variablen mit den Availability Zones der im vorherigen Schritt abgerufenen Subnetze.
```
az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
```
1. Erstellen Sie eine Cluster-IAM-Rolle.
1. Führen Sie den folgenden Befehl aus, um eine JSON-Datei für eine IAM-Vertrauensrichtlinie zu erstellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Erstellen Sie die Amazon-EKS-Cluster-IAM-Rolle. Falls erforderlich, stellen Sie `eks-cluster-role-trust-policy.json` den Pfad auf Ihrem Computer voran, in den Sie im vorherigen Schritt die Datei geschrieben haben. Der Befehl verknüpft die im vorherigen Schritt erstellte Vertrauensrichtlinie mit der Rolle. Um eine IAM-Rolle zu erstellen, muss dem [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der die Rolle erstellt, die `iam:CreateRole`-Aktion (Berechtigung) zugewiesen werden.
```
aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Fügen Sie der Rolle die von Amazon EKS verwaltete Richtlinie mit dem Namen [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) hinzu. Um eine IAM-Richtlinie an einen [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) anzuhängen, muss dem Prinzipal, der die Richtlinie anhängt, eine der folgenden IAM-Aktionen (Berechtigungen) zugewiesen werden: `iam:AttachUserPolicy` oder `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Erstellen Sie einen Amazon-EKS-Cluster und konfigurieren Sie Ihr Gerät für die Kommunikation mit diesem.
1. Erstellen Sie einen Cluster.
```
aws eks create-cluster --name my-custom-networking-cluster \
--role-arn arn:aws: iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
--resources-vpc-config subnetIds="$subnet_id_1","$subnet_id_2"
```
**Anmerkung**
Sie erhalten möglicherweise eine Fehlermeldung, dass eine der Availability Zones in Ihrer Anfrage nicht über genügend Kapazität zum Erstellen eines Amazon-EKS-Clusters verfügt. Wenn dies der Fall ist, enthält die Fehlerausgabe die Availability Zones, die einen neuen Cluster unterstützen können. Versuchen Sie, Ihren Cluster mit mindestens zwei Subnetzen erneut zu erstellen, die sich in den unterstützten Availability Zones für Ihr Konto befinden. Weitere Informationen finden Sie unter [Unzureichende Kapazität](troubleshooting.md#ice).
1. Die Erstellung des Clusters dauert mehrere Minuten. Führen Sie den folgenden Befehl aus, um den Status der Bereitstellung des Clusters zu überprüfen.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
```
Fahren Sie erst mit dem nächsten Schritt fort, wenn die Ausgabe des Befehls `"ACTIVE"` ist.
1. Konfigurieren Sie `kubectl` für die Kommunikation mit Ihrem Cluster.
```
aws eks update-kubeconfig --name my-custom-networking-cluster
```
## Schritt 2: Konfigurieren Ihrer VPC
Für dieses Tutorial wird die VPC in [Schritt 1: Erstellen einer Test-VPC und eines Clusters](#custom-networking-create-cluster) erstellt. Passen Sie für einen Produktions-Cluster die Schritte entsprechend Ihrer VPC an, indem Sie alle Beispielwerte durch eigene Werte ersetzen.
1. Stellen Sie sicher, dass das derzeit installierte Amazon-VPC-CNI-Plugin für Kubernetes die neueste Version ist. Informationen zur Ermittlung der neuesten Version für den Amazon-EKS-Add-On-Typ und zur Aktualisierung Ihrer Version auf diese Version finden Sie unter [Aktualisierung eines Amazon-EKS-Add-Ons](updating-an-add-on.md). Informationen dazu, wie Sie die neueste Version für den selbstverwalteten Add-On-Typ ermitteln und Ihre Version darauf aktualisieren können, finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md).
1. Rufen Sie die ID Ihrer Cluster-VPC ab und speichern Sie diese zur Verwendung in späteren Schritten in einer Variable.
```
vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
```
1. Ordnen Sie einen zusätzlichen Classless Inter-Domain Routing (CIDR)-Block der VPC Ihres Clusters zu. Der CIDR-Block kann sich nicht mit vorhandenen zugewiesenen CIDR-Blöcken überschneiden.
1. Zeigen Sie die aktuellen CIDR-Blöcke an, die Ihrer VPC zugeordnet sind.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id \
--query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Eine Beispielausgabe sieht wie folgt aus.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
+-----------------+--------------+
```
1. Ordnen Sie Ihrer VPC zusätzliche CIDR-Blöcke zu. Ersetzen Sie den CIDR-Blockwert im folgenden Befehl. Weitere Informationen finden Sie unter [Zusätzliche IPv4 CIDR-Blöcke mit Ihrer VPC verknüpfen](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr) im Amazon VPC-Benutzerhandbuch.
```
aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
```
1. Bestätigen Sie, dass der neue Block zugeordnet ist.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Eine Beispielausgabe sieht wie folgt aus.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
| 192.168.1.0/24 | associated |
+-----------------+--------------+
```
Fahren Sie erst mit dem nächsten Schritt fort, wenn der `State` Ihres neuen CIDR-Blocks `associated` ist.
1. Erstellen Sie so viele Subnetze, wie Sie in jeder Availability Zone verwenden möchten, in denen sich Ihre vorhandenen Subnetze befinden. Geben Sie einen CIDR-Block an, der sich innerhalb des CIDR-Blocks befindet, den Sie in einem vorherigen Schritt Ihrer VPC zugeordnet haben.
1. Erstellen Sie neue Subnetze. Ersetzen Sie die CIDR-Blockwerte im folgenden Befehl. Die Subnetze müssen in einem anderen VPC-CIDR-Block erstellt werden als Ihre vorhandenen Subnetze, jedoch in denselben Availability Zones wie Ihre vorhandenen Subnetze. In diesem Beispiel wird ein Subnetz im neuen CIDR-Block jeder Availability Zone erstellt, in der die aktuellen privaten Subnetze vorhanden sind. Die IDs erstellten Subnetze werden in Variablen gespeichert, um sie in späteren Schritten zu verwenden. Die `Name`-Werte entsprechen den Werten, die den Subnetzen zugewiesen wurden, die in einem vorherigen Schritt mit der Amazon-EKS-VPC-Vorlage erstellt wurden. Namen sind nicht erforderlich. Sie können verschiedene Namen verwenden.
```
new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
```
**Wichtig**
Standardmäßig sind Ihre neuen Subnetze implizit mit der [Haupt-Routing-Tabelle](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables) Ihrer VPCs verknüpft. Diese Routing-Tabelle ermöglicht die Kommunikation zwischen allen Ressourcen, die in der VPC bereitgestellt werden. Sie erlaubt jedoch keine Kommunikation mit Ressourcen mit IP-Adressen, die sich außerhalb der mit Ihrer VPC verknüpften CIDR-Blöcke befinden. Sie können Ihre eigene Routing-Tabelle Ihren Subnetzen zuordnen, um dieses Verhalten zu ändern. Weitere Informationen finden Sie unter [Subnetz-Routing-Tabellen](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables) im Amazon-VPC-Benutzerhandbuch.
1. Zeigen Sie die aktuellen Subnetze in Ihrer VPC an.
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
--query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
--output table
```
Eine Beispielausgabe sieht wie folgt aus.
```
----------------------------------------------------------------------
| DescribeSubnets |
+------------------+--------------------+----------------------------+
| AvailabilityZone | CidrBlock | SubnetId |
+------------------+--------------------+----------------------------+
| us-west-2d | 192.168.0.0/27 | subnet-example1 |
| us-west-2a | 192.168.0.32/27 | subnet-example2 |
| us-west-2a | 192.168.0.64/27 | subnet-example3 |
| us-west-2d | 192.168.0.96/27 | subnet-example4 |
| us-west-2a | 192.168.1.0/27 | subnet-example5 |
| us-west-2d | 192.168.1.32/27 | subnet-example6 |
+------------------+--------------------+----------------------------+
```
Sie können sehen, dass die Subnetze im CIDR-Block `192.168.1.0`, den Sie erstellt haben, in denselben Availability Zones liegen wie die Subnetze im CIDR-Block `192.168.0.0`.
## Schritt 3: Konfigurieren von Kubernetes-Ressourcen
1. Setzen Sie die `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` Umgebungsvariable auf `true` in der `aws-node` DaemonSet.
```
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
```
1. Rufen Sie die ID der [Cluster-Sicherheitsgruppe](sec-group-reqs.md) ab und speichern Sie diese in einer Variablen zur Verwendung im nächsten Schritt. Amazon EKS erstellt diese Sicherheitsgruppe automatisch, wenn Sie Ihren Cluster erstellen.
```
cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
```
1. Erstellen Sie eine benutzerdefinierte `ENIConfig`-Ressource für jedes Subnetz, in dem Sie Pods bereitstellen möchten.
1. Erstellen Sie für jede Konfiguration der Netzwerkschnittstelle eine eindeutige Datei.
Die folgenden Befehle erstellen separate `ENIConfig`-Dateien für die beiden Subnetze, die in einem vorherigen Schritt erstellt wurden. Der Wert für `name` muss eindeutig sein. Der Name entspricht der Availability Zone, in der sich das Subnetz befindet. Die Cluster-Sicherheitsgruppe ist dem `ENIConfig` zugeordnet.
```
cat >$az_1.yaml <$az_2.yaml <
1. Erstellen Sie eine Knoten-IAM-Rolle.
1. Führen Sie den folgenden Befehl aus, um eine JSON-Datei für eine IAM-Vertrauensrichtlinie zu erstellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Erstellen Sie eine IAM-Rolle und speichern Sie den zurückgegebenen Amazon-Ressourcennamen (ARN) in einer Variablen zur Verwendung in einem späteren Schritt.
```
node_role_arn=$(aws iam create-role --role-name myCustomNetworkingNodeRole --assume-role-policy-document file://"node-role-trust-relationship.json" \
--query Role.Arn --output text)
```
1. Hängen Sie die drei erforderlichen verwalteten IAM-Richtlinien an die IAM-Rolle an.
```
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name myCustomNetworkingNodeRole
```
**Wichtig**
Der Einfachheit halber wird in diesem Tutorial die Richtlinie [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) dieser Knoten-IAM-Rolle angefügt. In einem Produktions-Cluster empfehlen wir jedoch, die Richtlinie einer separaten IAM-Rolle zuzuordnen, die nur mit dem Amazon-VPC-CNI-Plugin für Kubernetes verwendet wird. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md).
1. Erstellen Sie einen der folgenden Typen von Knotengruppen. Informationen zum Bestimmen des Instance-Typs, den Sie bereitstellen möchten, finden Sie unter [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md). Füllen Sie für dieses Tutorial die Option **Verwaltet**, **Ohne Startvorlage oder mit Startvorlage ohne angegebene AMI-ID** aus. Wenn Sie die Knotengruppe für Produktions-Workloads verwenden möchten, empfehlen wir Ihnen, sich vor der Bereitstellung der Knotengruppe mit allen Optionen für [verwaltete](create-managed-node-group.md) und [selbstverwaltete Knotengruppen](worker.md) vertraut zu machen.
+ **Verwaltet** – Stellen Sie Ihre Knotengruppe mit einer der folgenden Optionen bereit:
+ **Ohne Startvorlage oder mit Startvorlage ohne angegebene AMI-ID** – Führen Sie den folgenden Befehl aus. Verwenden Sie für dieses Tutorial die Beispielwerte: Ersetzen Sie für eine Produktionsknotengruppe alle Beispielwerte durch Ihre eigenen Werte. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten.
```
aws eks create-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup \
--subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
```
+ **Mit einer Startvorlage mit einer angegebenen AMI-ID**
1. Bestimmen Sie die von Amazon EKS empfohlene maximale Anzahl an Pods für Ihre Knoten. Befolgen Sie die Anweisungen in den von und fügen Sie in diesem Thema `--cni-custom-networking-enabled` zu Schritt 3 hinzu. Notieren Sie die Ausgabe zur Verwendung im nächsten Schritt.
1. 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 in der Startvorlage an. Diese Benutzerdaten übergeben Argumente an die `NodeConfig` Spezifikation. Weitere Informationen zu NodeConfig finden Sie in der [NodeConfig API-Referenz](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig). Sie können `20` entweder durch den Wert aus dem vorherigen Schritt (empfohlen) oder Ihren eigenen Wert ersetzen.
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
...
kubelet:
config:
maxPods: 20
```
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.
+ **Selbstverwaltet**
1. Bestimmen Sie die von Amazon EKS empfohlene maximale Anzahl an Pods für Ihre Knoten. Befolgen Sie die Anweisungen in und fügen Sie `--cni-custom-networking-enabled` zu Schritt 3 in diesem Thema hinzu. Notieren Sie die Ausgabe zur Verwendung im nächsten Schritt.
1. Stellen Sie die Knotengruppe mithilfe der Anweisungen in [Selbstverwaltete Amazon-Linux-Knoten erstellen](launch-workers.md) bereit.
**Anmerkung**
Wenn Sie möchten, dass Knoten in einem Produktions-Cluster eine deutlich höhere Anzahl von Pods unterstützen, führen Sie das Skript in erneut aus. Fügen Sie außerdem die Option `--cni-prefix-delegation-enabled` zu dem Befehl hinzu. Beispielsweise wird `110` für einen `m5.large`-Instance-Typ zurückgegeben. Anweisungen, wie Sie diese Funktion aktivieren, finden Sie unter [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md). Sie können diese Funktion mit benutzerdefinierten Netzwerken verwenden.
1. Die Erstellung der Knotengruppe dauert mehrere Minuten. Sie können den Status der Erstellung einer verwalteten Knotengruppe mit dem folgenden Befehl überprüfen.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Fahren Sie erst mit dem nächsten Schritt fort, wenn die zurückgegebene Ausgabe `ACTIVE` ist.
1. Für das Tutorial können Sie diesen Schritt überspringen.
Wenn Sie Ihre `ENIConfigs` für einen Produktions-Cluster nicht genauso benannt haben wie die Availability Zone, für die Sie diese verwenden, müssen Sie in Ihren Knoten den Namen `ENIConfig` anmerken, die mit dem Knoten verwendet werden soll. Dieser Schritt ist nicht erforderlich, wenn Sie in jeder Availability Zone nur ein Subnetz haben und Ihre `ENIConfigs` denselben Namen haben wie Ihre Availability Zones. Dies liegt daran, dass das Amazon VPC CNI-Plugin für Kubernetes automatisch das korrekte `ENIConfig` dem Knoten zuordnet, wenn Sie dies in einem [vorherigen Schritt](#custom-networking-automatically-apply-eniconfig) aktiviert haben.
1. Rufen Sie die Liste der Knoten in Ihrem Cluster ab.
```
kubectl get nodes
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-0-126.us-west-2.compute.internal Ready 8m49s v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal Ready 8m34s v1.22.9-eks-810597c
```
1. Bestimmen Sie, in welcher Availability Zone sich jeder Knoten befindet. Führen Sie den folgenden Befehl für jeden Knoten aus, der im vorherigen Schritt zurückgegeben wurde, und ersetzen Sie die IP-Adressen basierend auf der vorherigen Ausgabe.
```
aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
--query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
```
Eine Beispielausgabe sieht wie folgt aus.
```
[
{
"AvailabilityZone": "us-west-2d",
"SubnetId": "subnet-Example5"
}
]
```
1. Kommentieren Sie jeden Knoten mit der `ENIConfig`, die Sie für die Subnetz-ID und die Availability Zone erstellt haben. Sie können einen Knoten nur mit einer `ENIConfig` kommentieren, aber es können mehrere Knoten mit derselben `ENIConfig` kommentiert werden. Ersetzen Sie die Beispielwerte durch Ihre eigenen Werte.
```
kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
```
1. Wenn Sie Knoten in einem Produktions-Cluster hatten, in dem Pods ausgeführt wurden, bevor Sie zur Verwendung des benutzerdefinierten Netzwerk-Features gewechselt haben, führen Sie die folgenden Schritte aus:
1. Stellen Sie sicher, dass es verfügbare Knoten gibt, das benutzerdefinierte Netzwerkfeature verwenden.
1. Sperren und entleeren Sie die Knoten, um die Pods herunterzufahren. Weitere Informationen finden Sie unter [Sicheres Entleeren eines Knotens](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) in der Kubernetes-Dokumentation.
1. Beenden Sie die Knoten. Wenn sich die Knoten in einer vorhandenen verwalteten Knotengruppe befinden, können Sie die Knotengruppe löschen. Führen Sie den folgenden Befehl aus.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
Nur neue Knoten, die mit der Bezeichnung `k8s.amazonaws.com/eniConfig` registriert sind, verwenden das neue benutzerdefinierte Netzwerkfeature.
1. Bestätigen Sie, dass Pos eine IP-Adresse aus einem CIDR-Block zugewiesen wird, der einem der in einem vorherigen Schritt erstellten Subnetze zugeordnet ist.
```
kubectl get pods -A -o wide
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal
kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
```
Sie können feststellen, dass den coredns-Pods IP-Adressen aus dem `192.168.1.0`-CIDR-Block zugewiesen werden, den Sie Ihrer VPC hinzugefügt haben. Ohne benutzerdefiniertes Netzwerk wären diesen Adressen aus dem CIDR-Block `192.168.0.0` zugewiesen worden, da dies der einzige ursprünglich mit der VPC verbundene CIDR-Block war.
Wenn die Pods eines `spec` `hostNetwork=true` enthalten, wird diesem die primäre IP-Adresse des Knotens zugewiesen. Es wird keine Adresse aus den hinzugefügten Subnetzen zugewiesen. Standardmäßig ist dieser Wert auf `false` festgelegt. Dieser Wert wird für die `kube-proxy` und Amazon-VPC-CNI-Plugin für Kubernetes (`aws-node`)-Pods, die auf Ihrem Cluster ausgeführt werden, auf `true` gesetzt. Aus diesem Grund werden den `kube-proxy`- und `aws-node`-Pods des Plugins in der vorherigen Ausgabe keine Adressen 192.168.1.x zugewiesen. Weitere Informationen zu den `hostNetwork` Einstellungen eines Pods finden Sie unter [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) in der Kubernetes-API-Referenz.
## Schritt 5: Löschen von Tutorial-Ressourcen
Nachdem Sie das Tutorial abgeschlossen haben, empfehlen wir, dass Sie die erstellten Ressourcen löschen. Sie können dann die Schritte anpassen, um benutzerdefinierte Netzwerke für einen Produktions-Cluster zu aktivieren.
1. Wenn die von Ihnen erstellte Knotengruppe nur zum Testen gedacht ist, löschen Sie sie.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
1. Selbst wenn die AWS CLI-Ausgabe besagt, dass der Cluster gelöscht wurde, ist der Löschvorgang möglicherweise nicht abgeschlossen. Der Löschvorgang dauert einige Minuten. Bestätigen Sie, dass der Vorgang abgeschlossen ist, indem Sie den folgenden Befehl ausführen.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Fahren Sie erst fort, wenn die zurückgegebene Ausgabe der folgenden Ausgabe entspricht.
```
An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
```
1. Wenn die von Ihnen erstellte Knotengruppe nur zum Testen gedacht ist, löschen Sie den Knoten IAM-Rolle.
1. Trennen Sie die Richtlinien von der Rolle.
```
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws: iam::aws:policy/AmazonEKS_CNI_Policy
```
1. Löschen Sie die Rolle.
```
aws iam delete-role --role-name myCustomNetworkingNodeRole
```
1. Löschen Sie den Cluster.
```
aws eks delete-cluster --name my-custom-networking-cluster
```
Bestätigen Sie, dass der Cluster gelöscht ist, indem Sie den folgenden Befehl ausführen.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
```
Wird eine Ausgabe ähnlich der folgenden zurückgegeben, wurde der Cluster erfolgreich gelöscht.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
```
1. Löschen Sie die Cluster-IAM-Rolle.
1. Trennen Sie die Richtlinien von der Rolle.
```
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
1. Löschen Sie die Rolle.
```
aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Löschen Sie die Subnetze, die Sie in einem vorherigen Schritt erstellt haben.
```
aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2
```
1. Löschen Sie die VPC, die Sie erstellt haben.
```
aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
```
# 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.
# Einzelnen Pods Sicherheitsgruppen zuweisen
**Gilt für**: Linux-Knoten mit EC2 Amazon-Instances
**Gilt für**: Private Subnetze
Sicherheitsgruppen für Pods integrieren EC2 Amazon-Sicherheitsgruppen in Kubernetes Pods. Sie können EC2 Amazon-Sicherheitsgruppen verwenden, um Regeln zu definieren, die eingehenden und ausgehenden Netzwerkverkehr zu und von Pods zulassen, die Sie auf Knoten bereitstellen, die auf vielen EC2 Amazon-Instance-Typen und Fargate laufen. Eine ausführliche Erläuterung dieser Funktion finden Sie im Blogbeitrag [Einführung in Sicherheitsgruppen für Pods](https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods).
## Kompatibilität mit den Amazon-VPC-CNI-Plugin für Kubernetes-Features
Sie können Sicherheitsgruppen für Pods mit den folgenden Features verwenden:
+ IPv4 Übersetzung der Quellnetzwerkadresse — Weitere Informationen finden Sie unter. [Aktivierung des ausgehenden Internetzugangs für Pods](external-snat.md)
+ IPv6 Adressen für Cluster, Pods und Dienste — 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).
## Überlegungen
Berücksichtigen Sie vor der Bereitstellung von Sicherheitsgruppen für Pods die folgenden Einschränkungen und Bedingungen:
+ Sicherheitsgruppen für Pods können nicht mit Windows-Knoten oder dem EKS-Automodus verwendet werden.
+ Sicherheitsgruppen für Pods können mit Clustern verwendet werden, die für die `IPv6` Familie konfiguriert sind und EC2 Amazon-Knoten enthalten. Verwenden Sie dazu Version 1.16.0 oder höher des Amazon VPC CNI-Plug-ins. Sie können Sicherheitsgruppen für Pods mit für die `IPv6`-Familie konfigurierten Clustern verwenden, die nur Fargate-Knoten enthalten. Hierfür muss mindestens die Version 1.7.7 des Amazon-VPC-CNI-Plugins verwendet werden. Weitere Informationen finden Sie unter [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md).
+ Sicherheitsgruppen für Pods werden von den meisten [Nitro-basierten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) EC2 Amazon-Instance-Familien unterstützt, allerdings nicht von allen Generationen einer Familie. Beispielsweise werden die Instance-Familien und -generationen `m5`, `c5`, `r5`, `m6g`, `c6g` und `r6g` unterstützt. Es werden keine Instance-Typen in der `t`-Familie unterstützt. Eine vollständige Liste der unterstützten Instance-Typen finden Sie in der Datei [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/v1.5.0/pkg/aws/vpc/limits.go) unter. GitHub Ihre Knoten müssen von einem der aufgelisteten Instance-Typen sein, die in der Datei mit `IsTrunkingCompatible: true` gekennzeichnet sind.
+ Wenn Sie benutzerdefinierte Netzwerk- und Sicherheitsgruppen für Pods zusammen verwenden, wird die durch Sicherheitsgruppen für Pods angegebene Sicherheitsgruppe anstelle der im `ENIConfig` angegebenen Sicherheitsgruppe verwendet.
+ Wenn Sie Version `1.10.2` oder älter des Amazon-VPC-CNI-Plugins verwenden und die Einstellung `terminationGracePeriodSeconds` in Ihre Pod-Spezifikation aufnehmen, darf der Wert der Einstellung nicht Null sein.
+ Wenn Sie Version `1.10` oder neuer des Amazon-VPC-CNI-Plugins verwenden oder Version `1.11` mit `POD_SECURITY_GROUP_ENFORCING_MODE` = `strict`, welches die Standardeinstellung ist, dann werden Kubernetes-Services vom Typ `NodePort` und `LoadBalancer`, die Instance-Ziele verwenden, für die `externalTrafficPolicy` auf `Local` eingestellt ist, nicht für Pods unterstützt, denen Sie Sicherheitsgruppen zuweisen. Weitere Informationen zur Verwendung eines Load Balancers mit Instance-Zielen finden Sie unter [Weiterleitung von TCP- und UDP-Datenverkehr mit Network Load Balancers](network-load-balancing.md).
+ Wenn Sie Version `1.10` des Amazon-VPC-CNI-Plugins oder höher verwenden oder Version `1.11` mit `POD_SECURITY_GROUP_ENFORCING_MODE` = `strict`, welches die Standardeinstellung ist, ist die Quell-NAT für von Pods mit zugewiesenen Sicherheitsgruppen ausgehenden Datenverkehr deaktiviert, damit Sicherheitsgruppenregeln für ausgehenden Datenverkehr angewendet werden können. Um auf das Internet zuzugreifen, müssen Pods mit zugewiesenen Sicherheitsgruppen auf Knoten gestartet werden, die in einem privaten Subnetz bereitgestellt werden, das mit einem NAT-Gateway oder einer NAT-Instance konfiguriert ist. Pods mit zugewiesenen Sicherheitsgruppen, welche in öffentlichen Subnetzen bereitgestellt werden, können nicht auf das Internet zugreifen.
Wenn Sie Version `1.11` oder höher des Plug-Ins mit `POD_SECURITY_GROUP_ENFORCING_MODE` = `standard` verwenden, wird der für außerhalb der VPC bestimmte Pod-Datenverkehr in die IP-Adresse der primären Netzwerkschnittstelle der Instance übersetzt. Für diesen Datenverkehr werden die Regeln in den Sicherheitsgruppen für die primäre Netzwerkschnittstelle anstelle der Regeln in den Pods-Sicherheitsgruppen verwendet.
+ Um die Calico-Netzwerkrichtlinie mit Pods zu verwenden, denen Sicherheitsgruppen zugewiesen sind, müssen Sie Version `1.11.0` oder höher des Amazon-VPC-CNI-Plugins verwenden und `POD_SECURITY_GROUP_ENFORCING_MODE` = `standard` festlegen. Andernfalls unterliegt der Verkehrsfluss zu und von Pods mit zugehörigen Sicherheitsgruppen nicht der Durchsetzung der Calico-Netzwerkrichtlinien und ist nur auf die Durchsetzung von EC2 Amazon-Sicherheitsgruppen beschränkt. Informationen zum Aktualisieren Ihrer Version von Amazon VPC CNI finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md).
+ Pods, die auf EC2 Amazon-Knoten ausgeführt werden und Sicherheitsgruppen in Clustern verwenden, die diese verwenden, [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)werden nur mit Version `1.11.0` oder höher des Amazon VPC CNI-Plug-ins und mit `POD_SECURITY_GROUP_ENFORCING_MODE` = unterstützt. `standard` Informationen zum Aktualisieren Ihrer Version des Amazon-VPC-CNI-Plug-ins finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md).
+ Sicherheitsgruppen für Pods können bei Pods mit hoher Fluktuation zu einer höheren Pod-Startup-Latenz führen. Dies ist auf eine Ratenbegrenzung im Ressourcencontroller zurückzuführen.
+ [Der Geltungsbereich der EC2 Sicherheitsgruppe befindet sich auf Pod-Ebene. Weitere Informationen finden Sie unter Sicherheitsgruppe.](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
Wenn Sie `POD_SECURITY_GROUP_ENFORCING_MODE=standard` und `AWS_VPC_K8S_CNI_EXTERNALSNAT=false` festlegen, verwendet der für Endpunkte außerhalb der VPC bestimmte Datenverkehr die Sicherheitsgruppen des Knotens und nicht die Sicherheitsgruppen des Pods.
# Konfiguration des Amazon-VPC-CNI-Plugins für Kubernetes für Sicherheitsgruppen für Amazon-EKS-Pods
Wenn Sie Pods mit Amazon-EC2-Instances verwenden, müssen Sie das Amazon-VPC-CNI-Plugin für Kubernetes für Sicherheitsgruppen konfigurieren.
Wenn Sie ausschließlich Fargate-Pods verwenden und über keine Amazon-EC2-Knoten in Ihrem Cluster verfügen, lesen Sie [Sicherheitsgruppenrichtlinie für einen Amazon-EKS-Pod verwenden](sg-pods-example-deployment.md).
1. Überprüfen Sie die aktuelle Version Ihres Amazon-VPC-CNI-Plugins für Kubernetes mit dem folgenden Befehl:
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Eine Beispielausgabe sieht wie folgt aus.
```
v1.7.6
```
Wenn Ihre Amazon-VPC-CNI-Plugin für Kubernetes-Version älter als `1.7.7` ist, aktualisieren Sie das Plugin auf Version `1.7.7` oder höher. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md).
1. Fügen Sie die verwaltete IAM-Richtlinie [AmazonEKSVPCResourceController](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSVPCResourceController) der [Cluster-Rolle](cluster-iam-role.md#create-service-role) hinzu, die Ihrem Amazon-EKS-Cluster zugeordnet ist. Die Richtlinie ermöglicht es der Rolle, Netzwerkschnittstellen, ihre privaten IP-Adressen sowie deren An- und Abkopplung an und von Netzwerk-Instances zu verwalten.
1. Rufen Sie den Namen Ihrer Cluster-IAM-Rolle ab und speichern Sie ihn in einer Variablen. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters.
```
cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
```
1. Fügen Sie der Rolle die -Richtlinie an.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
```
1. Aktivieren Sie das Amazon-VPC-CNI-Add-On, um Netzwerkschnittstellen für Pods zu verwalten, indem Sie die Variable `ENABLE_POD_ENI` im `aws-node` DaemonSet auf `true` setzen. Wenn diese Einstellung auf `true` festgelegt wurde, erstellt das Add-On für jeden Knoten im Cluster eine benutzerdefinierte `cninode`-Ressource. Der VPC-Ressourcen-Controller erstellt und verknüpft eine spezielle Netzwerkschnittstelle, die als *Trunk-Netzwerkschnittstelle* mit der Beschreibung `aws-k8s-trunk-eni` bezeichnet wird.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
```
**Anmerkung**
Die Trunk-Netzwerkschnittstelle ist in der maximalen Anzahl von Netzwerkschnittstellen enthalten, die vom Instance-Typ unterstützt werden. Eine Liste der maximalen Anzahl von Netzwerkschnittstellen, die von jedem Instance-Typ unterstützt werden, finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) im *Amazon-EC2-Benutzerhandbuch*. Wenn an Ihren Knoten bereits die maximale Anzahl an Standardnetzwerkschnittstellen angeschlossen ist, reserviert der VPC-Ressourcencontroller einen Speicherplatz. Sie müssen Ihre ausgeführten Pods so weit herunterskalieren, dass der Controller eine Standard-Netzwerkschnittstelle trennen und löschen, die Trunk-Netzwerkschnittstelle erstellen und an die Instance anhängen kann.
1. Mit dem folgenden Befehl können Sie ermitteln, welche Ihrer Knoten über eine benutzerdefinierte Ressource vom Typ `CNINode` verfügen. Wenn `No resources found` zurückgegeben wird, warten Sie einige Sekunden und versuchen Sie es dann erneut. Der vorherige Schritt erfordert einen Neustart des Amazon-VPC-CNI-Plugins für Kubernetes-Pods, was einige Sekunden in Anspruch nimmt.
```
kubectl get cninode -A
NAME FEATURES
ip-192-168-64-141.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
ip-192-168-7-203.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
```
Wenn Sie VPC-CNI-Versionen verwenden, die älter als `1.15` sind, wurden anstelle der benutzerdefinierten `CNINode`-Ressource Knotenbezeichnungen verwendet. Mit dem folgenden Befehl können Sie ermitteln, bei welchen Ihrer Knoten die Knoten-Bezeichnung `aws-k8s-trunk-eni` auf `true` festgelegt ist. Wenn `No resources found` zurückgegeben wird, warten Sie einige Sekunden und versuchen Sie es dann erneut. Der vorherige Schritt erfordert einen Neustart des Amazon-VPC-CNI-Plugins für Kubernetes-Pods, was einige Sekunden in Anspruch nimmt.
```
kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
```
Nachdem die Trunk-Netzwerkschnittstelle erstellt wurde, werden Pods sekundäre IP-Adressen von der Trunk- oder Standardnetzwerkschnittstelle zugewiesen. Die Trunk-Schnittstelle wird automatisch gelöscht, wenn der Knoten gelöscht wird.
Wenn Sie in einem späteren Schritt eine Sicherheitsgruppe für einen Pod bereitstellen, erstellt der VPC-Ressourcen-Controller eine spezielle Netzwerkschnittstelle, die als *Zweigstellennetzwerkschnittstelle* bezeichnet wird, mit einer Beschreibung von `aws-k8s-branch-eni` und ordnet ihr die Sicherheitsgruppen zu. Neben den an den Knoten angeschlossenen Standard- und Amtsnetzschnittstellen werden Nebenstellennetzschnittstellen erstellt.
Wenn Sie Aktivitäts- oder Bereitschaftsprüfungen verwenden, müssen Sie auch *frühe TCP Demux* deaktivieren, damit das `kubelet` über TCP eine Verbindung zu Pods auf Zweig-Netzwerkschnittstellen herstellen kann. Führen Sie den folgenden Befehl aus, um das *frühe TCP Demux* zu deaktivieren:
```
kubectl patch daemonset aws-node -n kube-system \
-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
```
**Anmerkung**
Wenn Sie `1.11.0` oder höher des Amazon-VPC-CNI-Plugins für das Kubernetes-Add-On verwenden und `POD_SECURITY_GROUP_ENFORCING_MODE` = `standard` festlegen, wie im nächsten Schritt beschrieben, müssen Sie den vorherigen Befehl nicht ausführen.
1. Wenn Ihr Cluster `NodeLocal DNSCache` verwendet oder Sie die Calico-Netzwerkrichtlinie mit Ihren Pods verwenden möchten, die über eigene Sicherheitsgruppen verfügen, oder wenn Sie Kubernetes-Services vom Typ `NodePort` und `LoadBalancer` haben, die Instance-Ziele mit einem auf `Local` festgelegten `externalTrafficPolicy` für Pods verwenden, denen Sie Sicherheitsgruppen zuweisen möchten, müssen Sie Version `1.11.0` oder höher des Amazon-VPC-CNI-Plugins für das Kubernetes-Add-On verwenden und die folgende Einstellung aktivieren:
```
kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
```
WICHTIG: ** Pod-Sicherheitsgruppenregeln werden nicht auf den Datenverkehr zwischen Pods oder zwischen Pods und Services wie `kubelet` oder `nodeLocalDNS` angewendet, die sich auf demselben Knoten befinden. Pods, die verschiedene Sicherheitsgruppen auf demselben Knoten verwenden, können nicht kommunizieren, da sie in verschiedenen Subnetzen konfiguriert sind und das Routing zwischen diesen Subnetzen deaktiviert ist. ** Für ausgehenden Datenverkehr von Pods an Adressen außerhalb der VPC wird die Netzwerkadresse in die IP-Adresse der primären Netzwerkschnittstelle der Instance übersetzt (es sei denn, Sie haben auch `AWS_VPC_K8S_CNI_EXTERNALSNAT=true` festgelegt). Für diesen Datenverkehr werden die Regeln in den Sicherheitsgruppen für die primäre Netzwerkschnittstelle anstelle der Regeln in den Pods-Sicherheitsgruppen verwendet. \$1\$1 Damit diese Einstellung auf vorhandene Pods angewendet wird, müssen Sie die Pods oder die Knoten, auf denen die Pods ausgeführt werden, neu starten.
1. Informationen zur Verwendung einer Sicherheitsgruppenrichtlinie für Ihren Pod finden Sie unter [Sicherheitsgruppenrichtlinie für einen Amazon-EKS-Pod verwenden](sg-pods-example-deployment.md).
# Sicherheitsgruppenrichtlinie für einen Amazon-EKS-Pod verwenden
Um Sicherheitsgruppen für Pods zu verwenden, benötigen Sie eine bereits vorhandene Sicherheitsgruppe. In den folgenden Schritten wird gezeigt, wie Sie die Sicherheitsgruppenrichtlinie für ein Pod verwenden. Wenn nicht anders angegeben, führen Sie alle Schritte vom selben Terminal aus, da Variablen in den folgenden Schritten verwendet werden, die nicht über Terminals hinweg bestehen bleiben.
Wenn Sie über einen Pod mit Amazon-EC2-Instances verfügen, müssen Sie das Plugin konfigurieren, bevor Sie dieses Verfahren anwenden können. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für Kubernetes für Sicherheitsgruppen für Amazon-EKS-Pods](security-groups-pods-deployment.md).
1. Erstellen Sie einen Kubernetes-Namespace, in dem -Ressourcen bereitgestellt werden sollen. Sie können es *my-namespace* durch den Namen eines Namespaces ersetzen, den Sie verwenden möchten.
```
kubectl create namespace my-namespace
```
1. Stellen Sie ein Amazon EKS `SecurityGroupPolicy` in Ihrem Cluster bereit.
1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Sie können es durch *podSelector* ersetzen, `serviceAccountSelector` wenn Sie Pods lieber anhand der Dienstkontobezeichnungen auswählen möchten. Sie müssen den einen oder anderen Selektor angeben. Ein leeres `podSelector` (Beispiel: `podSelector: {}`) wählt alle Pods im Namespace aus. Sie können *my-role* den Namen Ihrer Rolle ändern. Ein leeres `serviceAccountSelector` wählt alle Servicekonten im Namespace aus. Sie können ihn *my-security-group-policy* durch einen Namen für sich `SecurityGroupPolicy` und *my-namespace* durch den Namespace ersetzen, `SecurityGroupPolicy` in dem Sie die Datei erstellen möchten.
Sie müssen es *my\$1pod\$1security\$1group\$1id* durch die ID einer vorhandenen Sicherheitsgruppe ersetzen. Wenn Sie nicht über eine vorhandene Sicherheitsgruppe verfügen, müssen Sie eine erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Sicherheitsgruppen für Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) im [Amazon-EC2-Benutzerhandbuch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). Sie können eine Sicherheitsgruppe von 1 bis 5 angeben IDs. Falls Sie mehr als eine ID angeben, gilt die Kombination aller Regeln in allen Sicherheitsgruppen für die ausgewählten Pods.
```
cat >my-security-group-policy.yaml <sample-application.yaml <
my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal
```
**Anmerkung**
Probieren Sie diese Tipps aus, wenn Pods hängen bleiben.
Wenn Pods im `Waiting`-Stauts hängen bleiben, führen Sie `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` aus. Wenn Sie `Insufficient permissions: Unable to create Elastic Network Interface.` sehen, bestätigen Sie, dass Sie die IAM-Richtlinie in einem vorherigen Schritt zur IAM-Cluster-Rolle hinzugefügt haben.
Wenn Pods im `Pending`-Status hängen bleiben, überprüfen Sie, ob der Instance-Typ Ihres Knotens in [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go) aufgeführt ist, und dass die maximale Anzahl der vom Instance-Typ unterstützten Zweigstellen-Netzwerkschnittstellen multipliziert mit der Anzahl der Knoten in Ihrer Knotengruppe noch nicht erreicht wurde. Eine `m5.large`-Instance unterstützt beispielsweise neun Zweigstellen-Netzwerkschnittstellen. Wenn Ihre Knotengruppe fünf Knoten hat, können maximal 45 Zweigstellen-Netzwerkschnittstellen für die Knotengruppe erstellt werden. Der 46. Pod, den Sie bereitstellen möchten, bleibt im `Pending`-Status, bis ein anderer Pod mit zugehörigen Sicherheitsgruppen gelöscht wird.
Wenn Sie `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` ausführen und eine Meldung ähnlich der folgenden Meldung angezeigt wird, kann sie problemlos ignoriert werden. Diese Meldung kann angezeigt werden, wenn das Amazon-VPC-CNI-Plugin für Kubernetes versucht, das Host-Netzwerk einzurichten und die Erstellung der Netzwerkschnittstelle fehlschlägt. Das Plug-In protokolliert dieses Ereignis, bis die Netzwerkschnittstelle erstellt wird.
```
Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for Pod "my-deployment-5df6f7687b-4fbjm": networkPlugin
cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container
```
Die maximale Anzahl von Pods, die auf dem Instance-Typ ausgeführt werden können, darf nicht überschritten werden. Eine Liste der maximalen Anzahl von Pods, die Sie auf jedem Instance-Typ ausführen können, finden Sie unter [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) on. GitHub Wenn Sie einen Pod mit zugeordneten Sicherheitsgruppen oder den Knoten löschen, auf dem der Pod ausgeführt wird, löscht der VPC-Ressourcen-Controller die Zweigstellen-Netzwerkschnittstelle. Wenn Sie einen Cluster mit Pods löschen, indem Sie Pods für Sicherheitsgruppen verwenden, löscht der Controller die Netzwerkschnittstellen der Zweigstelle nicht, sodass Sie diese selbst löschen müssen. Informationen zum Löschen von Netzwerkschnittstellen finden Sie unter [Löschen einer Netzwerkschnittstelle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#delete_eni) im Amazon-EC2-Benutzerhandbuch.
1. Setzen Sie in einem separaten Terminal eine Shell in einen der Pods ein. Für den Rest dieses Themas wird dieses Terminal als `TerminalB` bezeichnet. *5df6f7687b-4fbjm*Ersetzen Sie es durch die ID eines der Pods, die in Ihrer Ausgabe aus dem vorherigen Schritt zurückgegeben wurden.
```
kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
```
1. Überprüfen Sie in der Shell von `TerminalB`, dass die Beispielanwendung funktioniert.
```
curl my-app
```
Eine Beispielausgabe sieht wie folgt aus.
```
Welcome to nginx!
[...]
```
Sie haben diese Ausgabe erhalten, weil alle Pods, auf denen die Anwendung ausgeführt wird, der Sicherheitsgruppe zugeordnet sind, die Sie erstellt haben. Diese Gruppe enthält eine Regel, die den gesamten Datenverkehr zwischen allen Pods zulässt, die der Sicherheitsgruppe zugeordnet ist. DNS-Datenverkehr wird von dieser Sicherheitsgruppe an die Cluster-Sicherheitsgruppe übertragen, die mit Ihren Knoten verknüpft ist. Auf den Knoten werden die CoreDNS-Pods ausgeführt, bei denen Ihre Pods eine Namenssuche durchgeführt haben.
1. Entfernen Sie von `TerminalA` aus die Sicherheitsgruppenregeln, die die DNS-Kommunikation mit der Cluster-Sicherheitsgruppe ermöglichen, aus Ihrer Sicherheitsgruppe. Wenn Sie die DNS-Regeln nicht in einem vorherigen Schritt zur Clustersicherheitsgruppe hinzugefügt haben, *\$1my\$1cluster\$1security\$1group\$1id* ersetzen Sie sie durch die ID der Sicherheitsgruppe, in der Sie die Regeln erstellt haben.
```
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
```
1. Versuchen Sie über `TerminalB` noch einmal, auf die Anwendung zuzugreifen.
```
curl my-app
```
Eine Beispielausgabe sieht wie folgt aus.
```
curl: (6) Could not resolve host: my-app
```
Der Versuch schlägt fehl, da der Pod nicht mehr auf die CoreDNS-Pods zugreifen kann, denen die Cluster-Sicherheitsgruppe zugeordnet ist. Die Cluster-Sicherheitsgruppe verfügt nicht mehr über die Sicherheitsgruppenregeln, die eine DNS-Kommunikation von der Sicherheitsgruppe, die Ihrem Pod zugeordnet ist, erlauben.
Wenn Sie versuchen, über die IP-Adressen auf die Anwendung zuzugreifen, die für einen der Pods in einem vorherigen Schritt zurückgegeben wurden, erhalten Sie dennoch eine Antwort, da zwischen Pods, denen die Sicherheitsgruppe zugeordnet ist, alle Ports erlaubt sind, und eine Namenssuche daher nicht erforderlich ist.
1. Wenn Sie mit dem Experimentieren fertig sind, können Sie die von Ihnen erstellte Sicherheitsgruppen-Richtlinie, Anwendung und Sicherheitsgruppe entfernen. Führen Sie die folgenden Befehle über `TerminalA` aus.
```
kubectl delete namespace my-namespace
aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id
wait
sleep 45s
aws ec2 delete-security-group --group-id $my_pod_security_group_id
```
# Anfügen mehrerer Netzwerkschnittstellen an Pods
Standardmäßig weist das Amazon-VPC-CNI-Plugin jedem Pod eine IP-Adresse zu. Diese IP-Adresse ist an eine *elastische Netzwerkschnittstelle* angefügt, die den gesamten ein- und ausgehenden Datenverkehr für den Pod verarbeitet. Um die Bandbreite und die Leistung pro Sekunde zu erhöhen, können Sie das *Multi-NIC-Feature* des VPC CNI verwenden, um einen Multi-Homed-Pod zu konfigurieren. Ein Multi-Homed-Pod ist ein einzelner Kubernetes-Pod, der mehrere Netzwerkschnittstellen (und mehrere IP-Adressen) verwendet. Durch den Betrieb eines Multi-Homed-Pods können Sie den Anwendungsdatenverkehr mithilfe gleichzeitiger Verbindungen auf mehrere Netzwerkschnittstellen verteilen. Dies ist besonders nützlich für Anwendungsfälle in den Bereichen Künstliche Intelligenz (KI), Machine Learning (ML) und High Performance Computing (HPC).
Das folgende Diagramm zeigt einen mehrfach vernetzten Pod, der auf einem Worker-Knoten ausgeführt wird und bei dem mehrere Netzwerkschnittstellenkarten () NICs verwendet werden.
![\[Ein Multi-Homed-Pod mit zwei Netzwerkschnittstellen, wobei eine Netzwerkschnittstelle an ENA und eine Netzwerkschnittstelle an ENA und EFA angefügt ist.\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/multi-homed-pod.png)
## Hintergrund
Bei Amazon EC2 ist eine *elastic network interface* eine logische Netzwerkkomponente in einer VPC, die eine virtuelle Netzwerkkarte darstellt. Bei vielen EC2 Instance-Typen teilen sich die Netzwerkschnittstellen hardwaremäßig eine einzige Netzwerkschnittstellenkarte (NIC). Diese einzelne Netzwerkkarte verfügt über eine maximale Bandbreite und eine maximale Paketrate pro Sekunde.
Wenn das Multi-NIC-Feature aktiviert ist, weist die VPC CNI IP-Adressen nicht wie standardmäßig vorgesehen in großen Mengen zu. Stattdessen weist das VPC CNI bei Bedarf einer Netzwerkschnittstelle auf jeder Netzwerkkarte eine IP-Adresse zu, wenn ein neuer Pod gestartet wird. Dieses Verhalten verringert die Geschwindigkeit, mit der IP-Adressen erschöpft werden, was durch die Verwendung von Multi-Homed-Pods erhöht wird. Da die VPC CNI IP-Adressen bei Bedarf zuweist, kann der Start von Pods auf Instances mit aktiviertem Multi-NIC-Feature länger dauern.
## Überlegungen
+ Stellen Sie sicher, dass in Ihrem Kubernetes-Cluster die VPC-CNI-Version `1.20.0` oder höher ausgeführt wird. Das Multi-NIC-Feature ist nur in der Version `1.20.0` VPC CNI oder höher verfügbar.
+ Aktivieren Sie die `ENABLE_MULTI_NIC`-Umgebungsvariable im VPC-CNI-Plugin. Sie können den folgenden Befehl ausführen, um die Variable festzulegen und eine Bereitstellung von zu starten DaemonSet.
+ `kubectl set env daemonset aws-node -n kube-system ENABLE_MULTI_NIC=true`
+ Stellen Sie sicher, dass Sie Worker-Knoten mit mehreren Netzwerkschnittstellenkarten (NICs) erstellen. Eine Liste der EC2 Instances mit mehreren Netzwerkschnittstellenkarten finden Sie unter [Netzwerkkarten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) im ** EC2 Amazon-Benutzerhandbuch**.
+ Wenn das Multi-NIC-Feature aktiviert ist, weist die VPC CNI IP-Adressen nicht wie standardmäßig vorgesehen in großen Mengen zu. Da die VPC CNI IP-Adressen bei Bedarf zuweist, kann der Start von Pods auf Instances mit aktiviertem Multi-NIC-Feature länger dauern. Weitere Informationen finden Sie im vorhergehenden Abschnitt [Hintergrund](#pod-multi-nic-background).
+ Bei aktiviertem Multi-NIC-Feature verfügen Pods standardmäßig nicht über mehrere Netzwerkschnittstellen. Sie müssen jede Workload so konfigurieren, dass sie Multi-NIC verwendet. Fügen Sie die `k8s.amazonaws.com/nicConfig: multi-nic-attachment`-Annotationen zu den Workloads hinzu, die über mehrere Netzwerkschnittstellen verfügen sollen.
### Überlegungen zu `IPv6`
+ **Benutzerdefinierte IAM-Richtlinie** – Erstellen und verwenden Sie für `IPv6`-Cluster die folgende benutzerdefinierte IAM-Richtlinie für das VPC CNI. Diese Richtlinie gilt speziell für Multi-NICs. Weitere allgemeine Informationen zur Verwendung des VPC CNI mit `IPv6`-Clustern finden Sie unter [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSCNIPolicyIPv6MultiNIC",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeInstances",
"ec2:AssignIpv6Addresses",
"ec2:DetachNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstanceTypes",
"ec2:UnassignIpv6Addresses",
"ec2:AttachNetworkInterface",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSCNIPolicyENITagIPv6MultiNIC",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:network-interface/*"
}
]
}
```
+ `IPv6` **Übergangsmechanismus nicht verfügbar** – Bei Verwendung des Multi-NIC-Feature weist die VPC CNI den Pods in einem `IPv6`-Cluster keine `IPv4`-Adresse zu. Andernfalls weist die VPC CNI jedem Pod eine hostlokale `IPv4`-Adresse zu, damit ein Pod mit externen `IPv4`-Ressourcen in einer anderen Amazon VPC oder im Internet kommunizieren kann.
## Usage
Nachdem das Multi-NIC-Feature in der VPC CNI aktiviert wurde und die `aws-node`-Pods neu gestartet wurden, können Sie jede Workload so konfigurieren, dass sie Multi-Homed ist. Nachfolgend finden Sie ein Beispiel für eine YAML-Konfiguration mit der erforderlichen Annotation:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-deployment
namespace: ecommerce
labels:
app: orders
spec:
replicas: 3
selector:
matchLabels:
app: orders
template:
metadata:
annotations:
k8s.amazonaws.com/nicConfig: multi-nic-attachment
labels:
app: orders
spec:
...
```
## Häufig gestellte Fragen
### **1. Was ist eine Netzwerkkarte (NIC)?**
Eine Netzwerkschnittstellenkarte (NIC), auch einfach Netzwerkkarte genannt, ist ein physisches Gerät, das die Netzwerkkonnektivität für die zugrunde liegende Cloud-Computing-Hardware ermöglicht. Bei modernen EC2 Servern bezieht sich dies auf die Nitro-Netzwerkkarte. Eine Elastic Network Interface (ENI) ist eine virtuelle Darstellung dieser zugrunde liegenden Netzwerkkarte.
Einige EC2 Instance-Typen verfügen über mehrere, NICs um die Bandbreite und die Leistung der Paketrate zu erhöhen. In solchen Fällen können Sie den zusätzlichen Netzwerkkarten sekundäre ENIs Karten zuweisen. Beispielsweise kann ENI Nr. 1 als Schnittstelle für die an den Netzwerkkartenindex 0 angefügten Netzwerkkarte dienen, während ENI Nr. 2 als Schnittstelle für die an einen separaten Netzwerkkartenindex angefügten Netzwerkkarte dienen kann.
### **2. Was ist ein Multi-Homed-Pod?**
Ein Multi-Homed-Pod ist ein einzelner Kubernetes-Pod mit mehreren Netzwerkschnittstellen (und damit mehreren IP-Adressen). Jede Pod-Netzwerkschnittstelle ist mit einem [Elastic Network Interface (ENI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) verknüpft. Dabei ENIs handelt es sich um logische Repräsentationen von separaten NICs auf dem zugrunde liegenden Worker-Knoten. Durch mehrere Netzwerkschnittstellen verfügt ein Multi-Homed-Pod über zusätzliche Datenübertragungskapazität, was wiederum die Datenübertragungsrate erhöht.
**Wichtig**
Das VPC CNI kann mehrfach vernetzte Pods nur für Instance-Typen konfigurieren, die mehrere haben. NICs
### **3. Warum sollte ich dieses Feature nutzen?**
Wenn Sie die Netzwerkleistung Ihrer Kubernetes-basierten Workloads skalieren müssen, können Sie die Multi-NIC-Funktion verwenden, um mehrfach vernetzte Pods auszuführen, die eine Schnittstelle zu allen NICs Basisgeräten herstellen, an die ein ENA-Gerät angeschlossen ist. Durch die Nutzung zusätzlicher Netzwerkkarten erhöhen Sie die Bandbreitenkapazität und die Paketratenleistung Ihrer Anwendungen, indem Sie den Anwendungsdatenverkehr auf mehrere gleichzeitige Verbindungen verteilen. Dies ist besonders nützlich für Anwendungsfälle in den Bereichen Künstliche Intelligenz (KI), Machine Learning (ML) und High Performance Computing (HPC).
### **4. Wie verwende ich dieses Feature?**
1. Zunächst müssen Sie sicherstellen, dass Ihr Kubernetes-Cluster VPC CNI Version 1.20 oder höher verwendet. Die Schritte zum Aktualisieren der VPC CNI als EKS-Add-On finden Sie unter [Aktualisieren der Amazon VPC CNI (Amazon-EKS-Add-On)](vpc-add-on-update.md).
1. Anschließend müssen Sie den Multi-NIC-Support in der VPC CNI mithilfe der `ENABLE_MULTI_NIC`-Umgebungsvariablen aktivieren.
1. Danach müssen Sie sicherstellen, dass Sie Knoten mit mehreren Netzwerkkarten erstellen und verbinden. Eine Liste der EC2 Instance-Typen mit mehreren Netzwerkkarten finden Sie unter [Netzwerkkarten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) im * EC2 Amazon-Benutzerhandbuch*.
1. Abschließend konfigurieren Sie jede Workload so, dass sie entweder mehrere Netzwerkschnittstellen (Multi-Homed-Pods) oder eine einzelne Netzwerkschnittstelle verwendet.
### **5. Wie konfiguriere ich meine Workloads so, dass sie mehrere NICs auf einem unterstützten Worker-Node verwenden?**
Um Multi-Homed-Pods zu verwenden, müssen Sie die folgende Annotation hinzufügen: `k8s.amazonaws.com/nicConfig: multi-nic-attachment`. Dadurch wird eine ENI von jeder NIC in der zugrunde liegenden Instance an den Pod angehängt (Eins-zu-Viele-Zuordnung zwischen einem Pod und dem NICs).
Wenn diese Annotation fehlt, geht das VPC CNI davon aus, dass Ihr Pod nur eine Netzwerkschnittstelle benötigt, und weist ihm eine IP von einem ENI auf einer beliebigen verfügbaren Netzwerkkarte zu.
### **6. Welche Netzwerkschnittstellen-Adapter werden von diesem Feature unterstützt?**
Sie können jeden Netzwerkschnittstellen-Adapter verwenden, wenn Sie mindestens einen ENA für den IP-Datenverkehr an die zugrunde liegende Netzwerkkarte angefügt haben. Weitere Informationen zu ENA finden Sie unter [Elastic Network Adapter (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) im * EC2 Amazon-Benutzerhandbuch*.
Unterstützte Netzwerkgeräte-Konfigurationen:
+ **ENA**-Schnittstellen bieten alle herkömmlichen IP-Netzwerk- und Routing-Funktionen, die zur Unterstützung von IP-Netzwerken für eine VPC erforderlich sind. Weitere Informationen finden Sie unter [Enhanced Networking with ENA auf Ihren EC2 Instances aktivieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html).
+ **EFA** **(EFA** **mit ENA)**-Schnittstellen bieten sowohl das ENA-Gerät für IP-Netzwerke als auch das EFA-Gerät für die Kommunikation mit niedriger Latenz und hohem Durchsatz.
**Wichtig**
Wenn an eine Netzwerkkarte **nur-EFA**-Adapter angeschlossen ist, wird diese vom VPC CNI bei der Bereitstellung der Netzwerkkonnektivität für einen Multi-Homed-Pod übersprungen. Wenn Sie jedoch einen reinen **EFA-Adapter mit einem **ENA-Adapter**** auf einer Netzwerkkarte kombinieren, wird der VPC-CNI auch ENIs auf diesem Gerät verwaltet. Informationen zur Verwendung von Nur-EFA-Schnittstellen mit EKS-Clustern finden Sie unter [Ausführung von Machine-Learning-Trainings in Amazon EKS mit Elastic Fabric Adapter](node-efa.md).
### **7. Kann ich überprüfen, ob ein Knoten in meinem Cluster ENA-Support bietet?**
Ja, Sie können die AWS CLI oder EC2 API verwenden, um Netzwerkinformationen über eine EC2 Instance in Ihrem Cluster abzurufen. Dadurch erhalten Sie detaillierte Informationen darüber, ob die Instance ENA-Support bietet. Im folgenden Beispiel ersetzen Sie es `` durch die EC2 Instanz-ID eines Knotens.
AWS CLI-Beispiel:
```
aws ec2 describe-instances --instance-ids --query "Reservations[].Instances[].EnaSupport"
```
Beispielausgabe:
```
[ true ]
```
### **8. Kann ich die verschiedenen IP-Adressen sehen, die einem Pod zugeordnet sind?**
Nein, nicht so einfach. Sie können jedoch `nsenter` vom Knoten aus verwenden, um gängige Netzwerk-Tools wie `ip route show` auszuführen und die zusätzlichen IP-Adressen und Schnittstellen anzuzeigen.
### **9. Kann ich die Anzahl der Netzwerkschnittstellen für meine Pods steuern?**
Nein. Wenn Ihr Workload so konfiguriert ist, dass mehrere NICs auf einer unterstützten Instance verwendet werden, erhält ein einzelner Pod automatisch eine IP-Adresse von jeder Netzwerkkarte auf der Instance. Alternativ verfügen Single-Homed-Pods über eine Netzwerkschnittstelle, die an eine Netzwerkkarte der Instance angefügt ist.
**Wichtig**
Netzwerkkarten, an die *ausschließlich* ein **nur-EFA**-Gerät angeschlossen ist, werden vom VPC CNI übersprungen.
### **10. Kann ich meine Pods so konfigurieren, dass sie eine bestimmte Netzwerkkarte verwenden?**
Nein, dies wird nicht unterstützt. Wenn ein Pod über die entsprechende Annotation verfügt, konfiguriert die VPC CNI ihn automatisch so, dass er jede Netzwerkkarte mit einem ENA-Adapter auf dem Worker-Knoten verwendet.
### **11. Ist dieses Feature mit den anderen VPC CNI-Netzwerk-Features kompatibel?**
Ja, das Multi-NIC-Feature in VPC CNI ist sowohl mit *benutzerdefinierten Netzwerken* als auch mit der *erweiterten Subnetzermittlung* kompatibel. Allerdings verwenden die Multi-Homed-Pods keine benutzerdefinierten Subnetze oder Sicherheitsgruppen. Stattdessen weist die VPC CNI den Multi-Homed-Pods IP-Adressen und Netzwerkschnittstellen zu, die dieselbe Subnetz- und Sicherheitsgruppen-Konfiguration wie der Knoten aufweisen. Weitere Informationen zu benutzerdefinierten Netzwerken finden Sie unter [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md).
Das Multi-NIC-Feature in VPC CNI ist nicht mit *Sicherheitsgruppen für Pods* kompatibel und kann nicht mit diesen kombiniert werden.
### **12. Kann ich mit diesem Feature Netzwerkrichtlinien verwenden?**
Ja, Sie können Kubernetes-Netzwerkrichtlinien mit mehreren Netzwerkkarten verwenden. Kubernetes-Netzwerkrichtlinien beschränken den Netzwerk-Datenverkehr zu und von Ihren Pods. Weitere Informationen zur Anwendung von Netzwerkrichtlinien mit dem VPC CNI finden Sie unter [Begrenzen Sie den Pod-Datenverkehr mit Kubernetes-Netzwerkrichtlinien.](cni-network-policy.md).
### **13. Ist der Support für mehrere Netzwerkkarten in EKS Auto Mode aktiviert?**
Multi-NIC wird für Cluster im EKS Auto Mode nicht unterstützt.