**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.

# Anpassung der sekundären Netzwerkschnittstelle in Amazon-EKS-Knoten
<a name="cni-custom-network-tutorial"></a>

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
<a name="custom-networking-create-cluster"></a>

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
<a name="custom-networking-configure-vpc"></a>

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
<a name="custom-networking-configure-kubernetes"></a>

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 <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata:
        name: $az_1
      spec:
        securityGroups:
          - $cluster_security_group_id
        subnet: $new_subnet_id_1
      EOF
      ```

      ```
      cat >$az_2.yaml <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata:
        name: $az_2
      spec:
        securityGroups:
          - $cluster_security_group_id
        subnet: $new_subnet_id_2
      EOF
      ```

      Für einen Produktions-Cluster können Sie die folgenden Änderungen an den vorherigen Befehlen vornehmen:
      + Ersetzen Sie \$1cluster\$1security\$1group\$1id durch die ID einer vorhandenen [Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html), die Sie für jeden `ENIConfig` verwenden möchten.
      + Wir empfehlen, Ihrer `ENIConfigs` denselben Namen zu geben wie der Availability Zone, in der Sie die `ENIConfig` verwenden, falls möglich. Unter Umständen müssen Sie für Ihre `ENIConfigs` andere Namen verwenden als für die Availability Zones. Wenn Sie beispielsweise mehr als zwei Subnetze in derselben Availability Zone haben und beide mit benutzerdefinierten Netzwerken verwenden möchten, benötigen Sie mehrere `ENIConfigs` für dieselbe Availability Zone. Da jede `ENIConfig` einen eindeutigen Namen erfordert, können Sie nur einer Ihrer `ENIConfigs` den Namen der Availability Zone geben.

        Wenn Ihre `ENIConfig` Namen nicht alle mit Availability Zone-Namen identisch sind, ersetzen Sie \$1az\$11 und \$1az\$12 in den vorherigen Befehlen durch Ihre eigenen Namen und [kommentieren Sie Ihre Knoten mit](#custom-networking-annotate-eniconfig) den später in diesem Tutorial. ENIConfig
**Anmerkung**  
Wenn Sie keine gültige Sicherheitsgruppe für die Verwendung mit einem Produktionscluster angeben und Folgendes verwenden:
      + Version `1.8.0` oder höher des Amazon-VPC-CNI-Plugin für Kubernetes verwenden, dann werden die Sicherheitsgruppen verwendet, die mit der primären Elastic-Network-Schnittstelle des Knotens verknüpft sind.
      + eine Version des Amazon-VPC-CNI-Plugins für Kubernetes vor `1.8.0`, dann wird die Standardsicherheitsgruppe für die VPC sekundären Netzwerkschnittstellen zugewiesen.
**Wichtig**  
 `AWS_VPC_K8S_CNI_EXTERNALSNAT=false` ist eine Standardeinstellung in der Konfiguration für das Amazon-VPC-CNI-Plugin für Kubernetes. Wenn Sie die Standardeinstellung verwenden, verwendet Datenverkehr, der für IP-Adressen bestimmt ist, die sich nicht innerhalb eines Ihrer VPC zugeordneten CIDR-Blöcke befinden, die Sicherheitsgruppen und Subnetze der primären Netzwerkschnittstelle Ihres Knotens. Die in Ihrem `ENIConfigs` definierten Subnetze und Sicherheitsgruppen, die zum Erstellen sekundärer Netzwerkschnittstellen verwendet werden, werden für diesen Datenverkehr nicht verwendet. Weitere Informationen zu dieser Einstellung finden Sie unter [Aktivierung des ausgehenden Internetzugangs für Pods](external-snat.md).
Wenn Sie auch Sicherheitsgruppen für Pods verwenden, wird die in einer `SecurityGroupPolicy` angegebene Sicherheitsgruppe anstelle der Sicherheitsgruppe verwendet, die im `ENIConfigs` angegeben ist. Weitere Informationen finden Sie unter [Einzelnen Pods Sicherheitsgruppen zuweisen](security-groups-for-pods.md).

   1. Wenden Sie alle benutzerdefinierten Ressourcendateien, die Sie zuvor erstellt haben, mit den folgenden Befehlen auf Ihren Cluster an:

      ```
      kubectl apply -f $az_1.yaml
      kubectl apply -f $az_2.yaml
      ```

1. Bestätigen Sie, dass Ihre `ENIConfigs` erstellt wurden.

   ```
   kubectl get ENIConfigs
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   NAME         AGE
   us-west-2a   117s
   us-west-2d   105s
   ```

1. Wenn Sie benutzerdefinierte Netzwerke in einem Produktions-Cluster aktivieren und Ihren `ENIConfigs` einen anderen Namen gegeben haben als die Availability Zone, für die Sie diese verwenden, springen Sie zum [nächsten Schritt](#custom-networking-deploy-nodes), um Amazon-EC2-Knoten bereitzustellen.

   Aktivieren Sie Kubernetes, um die `ENIConfig` für eine Availability Zone für alle neuen Amazon-EC2-Knoten zu verwenden, die in Ihrem Cluster erstellt wurden.

   1. Gehen Sie für den Test-Cluster in diesem Tutorial zum [nächsten Schritt](#custom-networking-automatically-apply-eniconfig).

      Prüfen Sie bei einem Produktionscluster, ob eine Anmerkung mit dem Schlüssel `k8s.amazonaws.com/eniConfig` für die ` [ENI\$1CONFIG\$1ANNOTATION\$1DEF](https://github.com/aws/amazon-vpc-cni-k8s#eni_config_annotation_def) ` Umgebungsvariable in der Containerspezifikation für vorhanden ist. `aws-node` DaemonSet

      ```
      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF
      ```

      Wenn eine Ausgabe zurückgegeben wird, ist die Anmerkung vorhanden. Wenn keine Ausgabe zurückgegeben wird, ist die Variable nicht gesetzt. Für einen Produktions-Cluster können Sie entweder diese Einstellung oder die Einstellung im folgenden Schritt verwenden. Wenn Sie diese Einstellung verwenden, überschreibt sie die Einstellung im folgenden Schritt. In diesem Tutorial wird die Einstellung im nächsten Schritt verwendet.

   1.  Aktualisieren Sie Ihre `aws-node` DaemonSet , sodass die Option `ENIConfig` für eine Availability Zone automatisch auf alle neuen Amazon EC2 EC2-Knoten angewendet wird, die in Ihrem Cluster erstellt wurden.

      ```
      kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone
      ```

## Schritt 4: Bereitstellen von Amazon-EC2-Knoten
<a name="custom-networking-deploy-nodes"></a>

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    <none>   8m49s   v1.22.9-eks-810597c
      ip-192-168-0-92.us-west-2.compute.internal    Ready    <none>   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    <none>           <none>
   kube-system   aws-node-k96wp             1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
   kube-system   coredns-657694c6f4-smcgr   1/1     Running   0          56m     192.168.1.23    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   coredns-657694c6f4-stwv9   1/1     Running   0          56m     192.168.1.28    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-jgshq           1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-wx9vk           1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
   ```

   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
<a name="custom-network-delete-resources"></a>

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
   ```