

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

# Einzelnen Pods Sicherheitsgruppen zuweisen
<a name="security-groups-for-pods"></a>

 **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
<a name="security-groups-for-pods-compatability"></a>

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
<a name="sg-pods-considerations"></a>

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
<a name="security-groups-pods-deployment"></a>

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
<a name="sg-pods-example-deployment"></a>

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 <<EOF
      apiVersion: vpcresources.k8s.aws/v1beta1
      kind: SecurityGroupPolicy
      metadata:
        name: my-security-group-policy
        namespace: my-namespace
      spec:
        podSelector:
          matchLabels:
            role: my-role
        securityGroups:
          groupIds:
            - my_pod_security_group_id
      EOF
      ```
**Wichtig**  
Die Sicherheitsgruppe oder -gruppen, die Sie für Ihre Pods angeben, müssen die folgenden Kriterien erfüllen:  
Sie müssen vorhanden sein. Wenn sie nicht vorhanden sind, bleibt Ihr Pod im Erstellungsprozess hängen, wenn Sie einen Pod bereitstellen, der dem Selektor entspricht. Wenn Sie den Pod beschreiben, wird eine Fehlermeldung ähnlich der folgenden angezeigt: `An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID 'sg-05b1d815d1EXAMPLE' does not exist`.
Diese müssen eingehende Kommunikation von der auf Ihre Knoten angewendeten Sicherheitsgruppe (für `kubelet`) über alle Ports erlauben, für die Sie Tests konfiguriert haben.
Diese müssen ausgehende Kommunikation über die `TCP`- und `UDP`-Ports 53 zu einer Sicherheitsgruppe zulassen, die dem Pods (oder den Knoten, auf denen die Pods ausgeführt werden) zugeordnet ist, auf denen CoreDNS ausgeführt wird. Die Sicherheitsgruppe für Ihre CoreDNS-Pods muss eingehenden `TCP`- und `UDP`-Port-53-Datenverkehr von der von Ihnen angegebenen Sicherheitsgruppe zulassen.
Sie müssen über die erforderlichen eingehenden und ausgehenden Regeln verfügen, um mit anderen Pods kommunizieren zu können, mit denen sie kommunizieren müssen.
Sie müssen über Regeln verfügen, die es den Pods ermöglichen, mit der Kubernetes-Steuerebene zu kommunizieren, wenn Sie die Sicherheitsgruppe mit Fargate verwenden. Am einfachsten erreichen Sie dies, indem Sie die Cluster-Sicherheitsgruppe als eine der Sicherheitsgruppen angeben.
Sicherheitsgruppenrichtlinien gelten nur für neu geplante Pods. Sie haben keinen Einfluss auf ausgeführte Pods.

   1. Die Richtlinie bereitstellen.

      ```
      kubectl apply -f my-security-group-policy.yaml
      ```

1. Stellen Sie eine Beispielanwendung mit einem Label bereit, die dem *my-role*-Wert für *podSelector* entspricht, den Sie in einem vorherigen Schritt angegeben haben.

   1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Ersetzen Sie die Beispielwerte durch Ihre eigenen, und führen Sie dann den geänderten Befehl aus. Wenn Sie ersetzen*my-role*, stellen Sie sicher, dass es sich um denselben Wert handelt, den Sie in einem vorherigen Schritt für den Selektor angegeben haben.

      ```
      cat >sample-application.yaml <<EOF
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: my-deployment
        namespace: my-namespace
        labels:
          app: my-app
      spec:
        replicas: 4
        selector:
          matchLabels:
            app: my-app
        template:
          metadata:
            labels:
              app: my-app
              role: my-role
          spec:
            terminationGracePeriodSeconds: 120
            containers:
            - name: nginx
              image: public.ecr.aws/nginx/nginx:1.23
              ports:
              - containerPort: 80
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: my-app
        namespace: my-namespace
        labels:
          app: my-app
      spec:
        selector:
          app: my-app
        ports:
          - protocol: TCP
            port: 80
            targetPort: 80
      EOF
      ```

   1. Stellen Sie die Anwendung mit dem folgenden Befehl bereit. Wenn Sie die Anwendung bereitstellen, stimmt das Amazon-VPC-CNI-Plugin für Kubernetes mit dem `role`-Label überein und die Sicherheitsgruppen, die Sie im vorherigen Schritt angegeben haben, werden auf den Pod angewendet.

      ```
      kubectl apply -f sample-application.yaml
      ```

1. Zeigen Sie die Pods an, die mit der Beispielanwendung bereitgestellt wurden. Für den Rest dieses Themas wird dieses Terminal als `TerminalA` bezeichnet.

   ```
   kubectl get pods -n my-namespace -o wide
   ```

   Eine Beispielausgabe sieht wie folgt aus.

   ```
   NAME                             READY   STATUS    RESTARTS   AGE     IP               NODE                                            NOMINATED NODE   READINESS GATES
   my-deployment-5df6f7687b-4fbjm   1/1     Running   0          7m51s   192.168.53.48    ip-192-168-33-28.region-code.compute.internal   <none>           <none>
   my-deployment-5df6f7687b-j9fl4   1/1     Running   0          7m51s   192.168.70.145   ip-192-168-92-33.region-code.compute.internal   <none>           <none>
   my-deployment-5df6f7687b-rjxcz   1/1     Running   0          7m51s   192.168.73.207   ip-192-168-92-33.region-code.compute.internal   <none>           <none>
   my-deployment-5df6f7687b-zmb42   1/1     Running   0          7m51s   192.168.63.27    ip-192-168-33-28.region-code.compute.internal   <none>           <none>
   ```
**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.

   ```
   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   [...]
   ```

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