**Contribuisci a migliorare questa pagina** 

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Assegnazione dei gruppi di sicurezza ai singoli pod
<a name="security-groups-for-pods"></a>

 **Si applica a**: nodi Linux con EC2 istanze Amazon

 **Si applica a**: sottoreti private

I gruppi di sicurezza per Pods integrano i gruppi EC2 di sicurezza Amazon con Kubernetes Pods. Puoi utilizzare i gruppi EC2 di sicurezza Amazon per definire regole che consentano il traffico di rete in entrata e in uscita da e verso i Pods da distribuire ai nodi in esecuzione su molti EC2 tipi di istanze Amazon e Fargate. Per una descrizione dettagliata di questa funzionalità, consulta il post di blog [Introduzione ai gruppi di sicurezza per i pod](https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods).

## Compatibilità con il plugin CNI di Amazon VPC per le funzionalità di Kubernetes
<a name="security-groups-for-pods-compatability"></a>

È possibile utilizzare gruppi di sicurezza per pod con le seguenti funzionalità:
+ IPv4 Source Network Address Translation - Per ulteriori informazioni, consulta. [Abilitare l’accesso a Internet in uscita per i pod](external-snat.md)
+ IPv6 indirizzi a cluster, pod e servizi - Per ulteriori informazioni, consulta. [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md)
+ Limitazione del traffico tramite le policy di rete di Kubernetes: per ulteriori informazioni, consulta [Limita il traffico di Pod con le policy di rete di Kubernetes](cni-network-policy.md).

## Considerazioni
<a name="sg-pods-considerations"></a>

Prima di implementare i gruppi di sicurezza per i pod, considera i limiti e le condizioni seguenti:
+ I gruppi di sicurezza per Pods non possono essere utilizzati con nodi Windows o EKS Auto Mode.
+ I gruppi di sicurezza per Pods possono essere utilizzati con cluster configurati per la `IPv6` famiglia che contiene EC2 nodi Amazon utilizzando la versione 1.16.0 o successiva del plug-in Amazon VPC CNI. È possibile utilizzare i gruppi di sicurezza per i pod con cluster configurati per la famiglia `IPv6` che contengono solo nodi Fargate, utilizzando la versione 1.7.7 o successive del plugin CNI di Amazon VPC. Per ulteriori informazioni, consulta [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md) 
+ I gruppi di sicurezza per Pods sono supportati dalla maggior parte delle famiglie di EC2 istanze [Amazon basate su Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances), ma non da tutte le generazioni di una famiglia. Ad esempio, sono supportate la famiglia e le generazioni dell’istanza `m5`, `c5`, `r5`, `m6g`, `c6g` e `r6g`. Non è supportato alcun tipo di istanza nella famiglia `t`. Per un elenco completo dei tipi di istanze supportati, consulta il file [limits.go su.](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/v1.5.0/pkg/aws/vpc/limits.go) GitHub I nodi devono essere uno dei tipi di istanza elencati che contengono `IsTrunkingCompatible: true` nel file.
+ Se si utilizzano allo stesso tempo una rete personalizzata e gruppi di sicurezza per i pod, il gruppo di sicurezza specificato dai gruppi di sicurezza per pod è utilizzato in alternativa al gruppo di sicurezza specificato in `ENIConfig`.
+ Se si utilizza la versione `1.10.2` o precedente del plugin CNI di Amazon VPC e si include l’impostazione `terminationGracePeriodSeconds` nelle specifiche del pod, il valore per l’impostazione non può essere zero.
+ Se si utilizza la versione `1.10` o precedente del plugin CNI di Amazon VPC o la versione `1.11` con l’impostazione predefinita `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, i servizi Kubernetes di tipo `NodePort` e `LoadBalancer` che utilizzano le destinazioni di istanza con `externalTrafficPolicy` impostato su `Local` non sono supportati con i pod a cui si assegnano i gruppi di sicurezza. Per ulteriori informazioni sull'utilizzo di un load balancer con target di istanza, consultare [Esecuzione del routing del traffico TCP e UDP con Network Load Balancer](network-load-balancing.md).
+ La fonte NAT è disabilitata per il traffico in uscita dai pod con gruppi di sicurezza assegnati, in modo che siano applicate le regole dei gruppi di sicurezza in uscita, se si utilizza la versione `1.10` o precedente del plugin CNI di Amazon VPC o la versione `1.11` con l’impostazione predefinita `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`. Per accedere a Internet, è necessario avviare pod con gruppi di sicurezza assegnati su nodi distribuiti in una sottorete privata configurata con un gateway NAT o un’istanza. I pod con gruppi di sicurezza assegnati distribuiti alle sottoreti pubbliche non sono in grado di accedere a Internet.

  Se si utilizza la versione `1.11` o successiva del plugin con `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, il traffico del pod destinato all’esterno del VPC è convertito nell’indirizzo IP dell’interfaccia di rete primaria dell’istanza. Per questo traffico sono utilizzate le regole nei gruppi di sicurezza per l’interfaccia di rete primaria, anziché le regole nei gruppi di sicurezza dei pod.
+ Per utilizzare le policy di rete Calico con pod associati ai gruppi di sicurezza, è necessario utilizzare la versione `1.11.0` o successiva del plugin CNI di Amazon VPC e impostare `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`. In caso contrario, il flusso di traffico da e verso i Pod con gruppi di sicurezza associati non è soggetto all'applicazione delle policy di rete di Calico e si limita esclusivamente all'applicazione dei gruppi EC2 di sicurezza di Amazon. Per aggiornare la versione di CNI di Amazon VPC, consulta la sezione [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md) 
+ I pod in esecuzione su EC2 nodi Amazon che utilizzano gruppi di sicurezza in cluster che utilizzano [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)sono supportati solo con la versione `1.11.0` o successiva del plug-in Amazon VPC CNI e con =. `POD_SECURITY_GROUP_ENFORCING_MODE` `standard` Per aggiornare la versione del plug-in CNI di Amazon VPC, consulta la sezione [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md) 
+ I gruppi di sicurezza per pod potrebbero portare a un aumento della latenza di avvio dei pod per quelli con un alto tasso di abbandono. Ciò è dovuto alla limitazione della velocità nel controller delle risorse.
+ [L'ambito del gruppo EC2 di sicurezza è a livello di POD. Per ulteriori informazioni, consulta Security group.](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)

  Se hai impostato `POD_SECURITY_GROUP_ENFORCING_MODE=standard` e `AWS_VPC_K8S_CNI_EXTERNALSNAT=false`, il traffico destinato agli endpoint esterni al VPC utilizza i gruppi di sicurezza del nodo, non i gruppi di sicurezza del pod.

# Configurazione del plugin CNI di Amazon VPC per Kubernetes per gruppi di sicurezza per i pod Amazon EKS
<a name="security-groups-pods-deployment"></a>

Se si utilizzano pod con istanze Amazon EC2, devi configurare il plugin CNI di Amazon VPC per Kubernetes per gruppi di sicurezza

Se si utilizzano solo i pod di Fargate e non si dispone di nodi Amazon EC2 nel cluster, consulta [Utilizzo di una policy di gruppo di sicurezza per un pod Amazon EKS](sg-pods-example-deployment.md).

1. Controlla la versione corrente del plugin CNI di Amazon VPC per Kubernetes con il comando seguente:

   ```
   kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
   ```

   Di seguito viene riportato un output di esempio:

   ```
   v1.7.6
   ```

   Se la versione del plugin CNI di Amazon VPC per Kubernetes è precedente a `1.7.7`, aggiorna il plugin alla versione `1.7.7` o successiva. Per ulteriori informazioni, consulta [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md) 

1. Aggiungi la policy IAM gestita da [AmazonEKSVPCResourceController](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSVPCResourceController)al [ruolo del cluster](cluster-iam-role.md#create-service-role) associato al cluster Amazon EKS. La policy consente al ruolo di gestire le interfacce di rete, i relativi indirizzi IP privati e i relativi allegati e distacchi da e verso le istanze di rete.

   1. Recupera il nome del ruolo IAM del cluster e archivialo in una variabile. Sostituisci *my-cluster* con il nome del tuo cluster.

      ```
      cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
      ```

   1. Collegare la policy al ruolo.

      ```
      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
      ```

1. Abilita il componente aggiuntivo CNI di Amazon VPC per gestire le interfacce di rete per i pod, impostando la variabile`ENABLE_POD_ENI` su `true` in DaemonSet `aws-node`. Una volta impostato questo parametro su `true`, per ciascun nodo nel cluster il componente aggiuntivo crea una risorsa `cninode` personalizzata. Il controller di risorse VPC crea e allega un'interfaccia di rete speciale chiamata *interfaccia di rete trunk* con la descrizione `aws-k8s-trunk-eni`.

   ```
   kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
   ```
**Nota**  
L'interfaccia di rete trunk è inclusa nel numero massimo di interfacce di rete supportate dal tipo di istanza. Per un elenco del numero massimo di interfacce di rete supportate da ciascun tipo di istanza, consulta [Indirizzi IP per interfaccia di rete per tipo di istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) nella *Guida per l’utente di Amazon EC2*. Se il nodo ha già allegato il numero massimo di interfacce di rete standard, il controller di risorse VPC riserverà uno spazio. Sarà necessario ridurre verticalmente i pod in esecuzione abbastanza da consentire al controller di scollegare ed eliminare un’interfaccia di rete standard, creare l’interfaccia di rete trunk e allegarla all’istanza.

1. Con il seguente comando è possibile vedere quale nodo ha una risorsa `CNINode` personalizzata. Se viene restituito l'output `No resources found`, attendere alcuni secondi e riprovare. La fase precedente richiede il riavvio del plugin CNI di Amazon VPC per pod Kubernetes, che richiede alcuni secondi.

   ```
   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"}]
   ```

   Se si utilizzano versioni VPC CNI precedenti alla `1.15`, sono state utilizzate le etichette dei nodi anziché la risorsa `CNINode` personalizzata. Con il seguente comando, è possibile vedere quale nodo ha l’etichetta del nodo `aws-k8s-trunk-eni` impostata su `true`. Se viene restituito l'output `No resources found`, attendere alcuni secondi e riprovare. La fase precedente richiede il riavvio del plugin CNI di Amazon VPC per pod Kubernetes, che richiede alcuni secondi.

   ```
   kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
   ```

   Una volta creata l’interfaccia di rete trunk, ai pod possono essere assegnati indirizzi IP secondari dalla rete trunk o dalle interfacce di rete standard. L'interfaccia trunk viene eliminata automaticamente se il nodo viene eliminato.

   Quando si distribuisce un gruppo di sicurezza per un pod in un passaggio successivo, il controller di risorse VPC crea un’interfaccia di rete speciale denominata *interfaccia di rete di filiali* con una descrizione di `aws-k8s-branch-eni` e vi associa i gruppi di sicurezza. Le interfacce di rete di filiali vengono create in aggiunta alle interfacce di rete standard e trunk allegate al nodo.

   Se si utilizzano sonde liveness o readiness, è inoltre necessario disabilitare il *demultiplexing precoce TCP*, in modo che `kubelet` possa connettersi a pod su interfacce di rete di filiali tramite TCP. Per disabilitare *demultiplexing precoce TCP*, esegui il comando seguente:

   ```
   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"}]}}}}'
   ```
**Nota**  
Se non utilizzi il plugin CNI di Amazon VPC `1.11.0` o successivo per il componente aggiuntivo di Kubernetes e impostarlo `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, come descritto nel passaggio successivo, non devi eseguire il comando precedente.

1. Se il cluster utilizza `NodeLocal DNSCache` o desideri utilizzare la policy di rete Colico con i pod che dispongono dei propri gruppi di sicurezza, o se disponi di servizi Kubernetes di tipo `NodePort` e `LoadBalancer` che utilizzano le destinazioni di istanza con `externalTrafficPolicy` impostato su `Local` per pod a cui desideri assegnare i gruppi di sicurezza, dovrai utilizzare la versione `1.11.0` o successiva del plugin CNI di Amazon VPC per il componente aggiuntivo di Kubernetes e dovrai abilitare la seguente impostazione:

   ```
   kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
   ```

   IMPORTANTE: **le regole del gruppo di sicurezza dei pod non si applicano al traffico tra pod o tra pod e servizi, esempio `kubelet` o `nodeLocalDNS`, che si trovano sullo stesso nodo. I pod che utilizzano gruppi di sicurezza differenti sullo stesso nodo non possono comunicare perché sono configurati in sottoreti diverse e l’instradamento è disabilitato tra tali sottoreti. ** Traffico in uscita dai pod verso gli indirizzi esterni al VPC è l’indirizzo di rete convertito nell’indirizzo IP dell’interfaccia di rete primaria dell’istanza (a meno che non sia stato impostato `AWS_VPC_K8S_CNI_EXTERNALSNAT=true`). Per questo traffico sono utilizzate le regole nei gruppi di sicurezza per l’interfaccia di rete primaria, anziché le regole nei gruppi di sicurezza dei pod. \$1\$1 Affinché questa impostazione si applichi ai pod esistenti, è necessario riavviare i pod o i nodi su cui i pod sono in esecuzione.

1. Per scoprire come utilizzare una politica di gruppo di sicurezza per il pod, consulta [Utilizzo di una policy di gruppo di sicurezza per un pod Amazon EKS](sg-pods-example-deployment.md).

# Utilizzo di una policy di gruppo di sicurezza per un pod Amazon EKS
<a name="sg-pods-example-deployment"></a>

Per utilizzare i gruppi di sicurezza per i pod, è necessario disporre di un gruppo di sicurezza esistente. I passaggi seguenti mostrano l’utilizzo delle policy di gruppo di sicurezza per un pod. Se non diversamente indicato, completa tutti i passaggi nello stesso terminale, poiché nei passaggi successivi sono utilizzate variabili che non persistono tra i terminali.

Se disponi di un Pod con istanze Amazon EC2, devi configurare il plugin prima di utilizzare questa procedura. Per ulteriori informazioni, consulta [Configurazione del plugin CNI di Amazon VPC per Kubernetes per gruppi di sicurezza per i pod Amazon EKS](security-groups-pods-deployment.md).

1. Crea un namespace Kubernetes in cui distribuire le risorse . È possibile sostituire *my-namespace* con il nome di uno spazio dei nomi che si desidera utilizzare.

   ```
   kubectl create namespace my-namespace
   ```

1.  Implementa una `SecurityGroupPolicy` Amazon EKS nel cluster.

   1. Copia i seguenti contenuti sul dispositivo. Puoi sostituirlo *podSelector* con `serviceAccountSelector` se preferisci selezionare i Pod in base alle etichette degli account di servizio. É necessario specificare uno selettore. Un `podSelector` vuoto (ad esempio: `podSelector: {}`) seleziona tutti i pod nel namespace. Puoi *my-role* cambiare il nome del tuo ruolo. Un `serviceAccountSelector` vuoto seleziona tutti gli account di servizio nel namespace. Puoi sostituirlo *my-security-group-policy* con un nome per te `SecurityGroupPolicy` e *my-namespace* con lo spazio dei nomi in cui desideri crearlo. `SecurityGroupPolicy`

      È necessario sostituirlo *my\$1pod\$1security\$1group\$1id* con l'ID di un gruppo di sicurezza esistente. Se non disponi ancora di un gruppo di sicurezza dovrai crearne uno. Per ulteriori informazioni, consulta [Gruppi di sicurezza Amazon EC2 per le istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) nella [Guida per l'utente di Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). È possibile specificare 1-5 gruppi IDs di sicurezza. Se si specificano più ID, la combinazione di tutte le regole in tutti i gruppi di sicurezza sarà valida per i pod selezionati.

      ```
      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
      ```
**Importante**  
Il gruppo di sicurezza o i gruppi specificati per i pod devono soddisfare i criteri seguenti:  
Devono essere esistenti. Se non lo sono, quando si distribuisce un pod che corrisponde al selettore, il pod rimane bloccato nel processo di creazione. Se si descrive il pod, si otterrà un messaggio di errore simile al seguente: `An error occurred (InvalidSecurityGroupID.NotFound) when calling the CreateNetworkInterface operation: The securityGroup ID 'sg-05b1d815d1EXAMPLE' does not exist`.
Devono consentire la comunicazione in ingresso dal gruppo di sicurezza applicato ai nodi (per `kubelet`) su tutte le porte per cui sono state configurate le sonde.
Devono consentire la comunicazione in uscita tramite le porte 53 `TCP` e `UDP` a un gruppo di sicurezza assegnato ai pod (o ai nodi su cui sono eseguiti i pod) che eseguono CoreDNS. Il gruppo di sicurezza per i pod CoreDNS deve consentire il traffico in ingresso tramite le porte 53 `TCP` e `UDP` dal gruppo di sicurezza specificato.
Devono disporre delle regole in entrata e in uscita necessarie per comunicare con altri pod.
Devono disporre di regole che consentano ai pod di comunicare con il piano di controllo Kubernetes se si utilizza il gruppo di sicurezza con Fargate. Il modo più semplice per eseguire questa operazione consiste nello specificare il gruppo di sicurezza del cluster come uno dei gruppi di sicurezza.
Le policy dei gruppi di sicurezza si applicano solo ai nuovi pod pianificati. Non incidono sui pod in esecuzione.

   1. Implementare la policy.

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

1. Implementa un'applicazione di esempio con un'etichetta che corrisponda al valore *my-role* per *podSelector* specificato nel passaggio precedente.

   1. Copia i seguenti contenuti sul dispositivo. Sostituisci i valori di esempio con i tuoi, quindi esegui il comando modificato. Se lo sostituisci*my-role*, assicurati che sia uguale al valore specificato per il selettore in un passaggio precedente.

      ```
      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. Implementare l'applicazione con il seguente comando. Quando si implementa l’applicazione, il plugin CNI di Amazon VPC per Kubernetes corrisponde all’etichetta `role` e i gruppi di sicurezza specificati nel passaggio precedente sono applicati al pod.

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

1. Visualizza i pod implementati con l’applicazione esemplificativa. Nella parte restante di questo argomento, questo terminale è indicato come `TerminalA`.

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

   Di seguito viene riportato un output di esempio.

   ```
   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>
   ```
**Nota**  
Prova questi suggerimenti se qualche pod è bloccato.  
Se qualche pod è bloccato nello stato `Waiting`, esegui `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace `. Se visualizzi `Insufficient permissions: Unable to create Elastic Network Interface.`, verifica di avere aggiunto la policy IAM al ruolo cluster IAM in un passaggio precedente.
Se qualche pod è bloccato nello stato `Pending`, verifica che il tipo di istanza del nodo sia elencato in [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go) e che non sia già stato raggiunto il prodotto del numero massimo di interfacce di rete di filiali supportate dal tipo di istanza moltiplicato per il numero di nodi nel gruppo di nodi. Ad esempio, una istanza `m5.large` supporta nove interfacce di rete di filiali. Se il gruppo di nodi dispone di cinque nodi, è possibile creare un massimo di 45 interfacce di rete di filiali per il gruppo di nodi. Il 46° pod che si tenta di implementare si troverà in uno stato di `Pending` finché non viene eliminato un altro pod a cui sono associati gruppi di sicurezza.

   Se si esegue `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` e si visualizza un messaggio simile al seguente, può essere ignorato in modo sicuro. Questo messaggio potrebbe essere visualizzato quando il plugin CNI di Amazon VPC per Kubernetes tenta di impostare la rete host e fallisce durante la creazione dell’interfaccia di rete. Il plug-in registra questo evento fino a quando non viene creata l'interfaccia di rete.

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

   Non è possibile superare il numero massimo di pod eseguibili sul tipo di istanza. Per un elenco del numero massimo di Pod che puoi eseguire su ogni tipo di istanza, consulta [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) on. GitHub Quando si elimina un pod a cui sono associati gruppi di sicurezza o si elimina il nodo su cui è in esecuzione il pod, il controller di risorse VPC elimina l’interfaccia di rete di filiali. Se elimini un cluster con pod che utilizzano pod per gruppi di sicurezza, il controller non elimina le interfacce di rete delle diramazioni, per cui dovrai eliminarle personalmente. Per ulteriori informazioni sull’eliminazione delle interfacce di rete, consulta [Eliminazione di un’interfaccia di rete](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#delete_eni) nella Guida per l’utente Amazon EC2.

1. In un terminale separato, accedi alla shell di uno dei pod. Nella parte restante di questo argomento, questo terminale è indicato come `TerminalB`. Sostituiscilo *5df6f7687b-4fbjm* con l'ID di uno dei Pod restituiti nell'output del passaggio precedente.

   ```
   kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
   ```

1. Confermare il funzionamento dell'applicazione di esempio dalla shell in `TerminalB`.

   ```
   curl my-app
   ```

   Di seguito viene riportato un output di esempio.

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

   L’output è stato ricevuto in quanto tutti i pod che eseguono l’applicazione sono associati al gruppo di sicurezza creato. Tale gruppo contiene una regola che abilita il traffico tra tutti i pod a cui è associato il gruppo di sicurezza. Il traffico DNS è consentito in uscita da tale gruppo di sicurezza al gruppo di sicurezza del cluster associato ai nodi. I nodi eseguono i pod CoreDNS, su cui i pod hanno eseguito la ricerca del nome.

1. Da `TerminalA`, rimuovere le regole del gruppo di sicurezza che consentono la comunicazione DNS dal gruppo di sicurezza al gruppo di sicurezza del cluster. Se non hai aggiunto le regole DNS al gruppo di sicurezza del cluster in un passaggio precedente, sostituiscile *\$1my\$1cluster\$1security\$1group\$1id* con l'ID del gruppo di sicurezza in cui hai creato le regole.

   ```
   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. Tentare di accedere nuovamente all'applicazione da `TerminalB`.

   ```
   curl my-app
   ```

   Di seguito viene riportato un output di esempio.

   ```
   curl: (6) Could not resolve host: my-app
   ```

   Il tentativo ha esito negativo perché il pod non è più in grado di accedere ai pod CoreDNS a cui è associato il gruppo di sicurezza del cluster. Il gruppo di sicurezza del cluster non dispone più delle relative regole che consentono la comunicazione DNS dal gruppo di sicurezza associato al pod.

   Se si tenta di accedere all’applicazione utilizzando gli indirizzi IP restituiti in un passaggio precedente per uno dei pod, si riceve comunque una risposta perché tutte le porte sono consentite tra i pod a cui è associato il gruppo di sicurezza e non è necessaria una ricerca del nome.

1. Dopo avere eseguito diverse prove, è possibile rimuovere la policy del gruppo di sicurezza, l’applicazione e il gruppo di sicurezza di esempio creati. Esegui i comandi seguenti da `TerminalA`.

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