**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à.
# Ulteriori informazioni sulle modalità e sulla configurazione di CNI di VPC
Il plugin CNI di Amazon VPC fornisce una rete per pod. Utilizza la tabella seguente per ulteriori informazioni sulle funzionalità di rete disponibili.
| Caratteristica di rete | Ulteriori informazioni |
| --- | --- |
| Configura il cluster per assegnare indirizzi IPv6 a cluster, pod e servizi | [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md) |
| Utilizza la traduzione degli indirizzi di rete di origine IPv4 per i pod | [Abilitare l’accesso a Internet in uscita per i pod](external-snat.md) |
| Limita il traffico di rete verso e dai pods | [Limitare il traffico di rete dei Pod con le policy di rete Kubernetes](cni-network-policy-configure.md) |
| Personalizza l’interfaccia di rete secondaria nei nodi | [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md) |
| Aumenta gli indirizzi IP per il nodo | [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md) |
| Utilizza gruppi di sicurezza per il traffico di rete dei pod | [Assegnazione dei gruppi di sicurezza ai singoli pod](security-groups-for-pods.md) |
| Utilizza interfacce di rete multiple per pod | [Collegamento di interfacce di rete multiple ai pod](pod-multiple-network-interfaces.md) |
# Scopri IPv6 gli indirizzi di cluster, pod e servizi
**Si applica a**: Pods con EC2 istanze Amazon e Fargate Pod
Per impostazione predefinita, Kubernetes assegna indirizzi `IPv4` a pod e servizi. Invece di assegnare indirizzi `IPv4` a pod e servizi, è possibile configurare il cluster in modo da assegnare loro indirizzi `IPv6`. Amazon EKS non supporta pod o servizi con doppio stack, anche se Kubernetes lo fa. Di conseguenza, non è possibile assegnare sia indirizzi `IPv4` che `IPv6` a pod e servizi.
È possibile selezionare la famiglia IP che si desidera utilizzare per il cluster al momento della creazione. Non sarà possibile modificare la famiglia dopo aver creato il cluster.
Per un tutorial sull’implementazione di un cluster `IPv6` di Amazon EKS, consultare [Implementare un cluster `IPv6` Amazon EKS e nodi Amazon Linux gestiti](deploy-ipv6-cluster.md).
Di seguito sono riportate alcune considerazioni sull’utilizzo della funzionalità:
## `IPv6` Supporto funzionalità
+ **Nessun supporto per Windows**: i Pod e i servizi Windows non sono supportati.
+ ** EC2 Nodi basati su Nitro**: puoi utilizzarli solo `IPv6` con nodi AWS Amazon o EC2 Fargate basati su Nitro.
+ **EC2 e nodi Fargate supportati**: puoi utilizzarlo `IPv6` con EC2 nodi [Assegnazione dei gruppi di sicurezza ai singoli pod](security-groups-for-pods.md) Amazon e nodi Fargate.
+ **Outpost non supportati**: non è possibile usare `IPv6` con [Implementazione di Amazon EKS on-premises con AWS Outposts](eks-outposts.md).
+ **FSx for Lustre non è supportato: non** [Usa l’archiviazione delle app ad alte prestazioni con Amazon FSx per Lustre](fsx-csi.md) è supportato.
+ **Rete personalizzata non supportata**: per ridurre l’esaurimento dell’indirizzo IP, è possibile utilizzare [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md) anche se in precedenza è stato usato `IPv6`. Non è possibile utilizzare una rete personalizzata con `IPv6`. Se si utilizza una rete personalizzata per l’isolamento della rete, potrebbe essere necessario continuare a utilizzare la rete personalizzata e la famiglia `IPv4` per i cluster.
## Assegnazioni dell’indirizzo IP
+ **Servizi Kubernetes**: ai servizi Kubernetes viene assegnato solo un indirizzo `IPv6`. A loro non vengono assegnati IPv4 indirizzi.
+ **Pod: ai** pod vengono assegnati un IPv6 indirizzo e un indirizzo locale dell'host IPv4 . L' IPv4 indirizzo locale dell'host viene assegnato utilizzando un plug-in CNI locale dell'host concatenato con VPC CNI e l'indirizzo non viene segnalato al piano di controllo di Kubernetes. Viene utilizzato solo quando un pod deve comunicare con IPv4 risorse esterne in un altro Amazon VPC o su Internet. L' IPv4 indirizzo locale dell'host arriva SNATed (tramite VPC CNI) all' IPv4 indirizzo principale dell'ENI primario del nodo di lavoro.
+ **Pod e servizi**: i pod e i servizi ricevono solo indirizzi `IPv6`, non quelli `IPv4`. Quando i Pod devono comunicare con endpoint `IPv4` esterni, utilizzano il NAT sul nodo stesso. [Questa funzionalità NAT integrata elimina la necessità di e. DNS64 NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64) Per il traffico che richiede un accesso pubblico a Internet, il traffico del pod è l’indirizzo di rete di origine tradotto in un indirizzo IP pubblico.
+ **Indirizzi di instradamento**: quando un Pod comunica all’esterno del VPC, il suo indirizzo `IPv6` originale viene preservato (non tradotto nell’indirizzo `IPv6` del nodo). Questo traffico viene instradato direttamente attraverso un gateway Internet o gateway Internet egress-only.
+ **Nodi**: a tutti i nodi viene assegnato un indirizzo `IPv4` e `IPv6`.
+ **Pod Fargate**: ogni Pod Fargate riceve un indirizzo `IPv6` dal CIDR specificato per la sottorete in cui è stato implementato. L'unità hardware sottostante che esegue i Fargate Pods riceve un `IPv6` indirizzo univoco `IPv4` e assegnato alla sottorete in cui è installata l'unità hardware. CIDRs
## Come utilizzare `IPv6` con EKS
+ **Creare un nuovo cluster**: è necessario creare un nuovo cluster e specificare che si vuole utilizzare la famiglia `IPv6` per quel cluster. Non è possibile abilitare la famiglia `IPv6` per un cluster aggiornato da una versione precedente. Per istruzioni su come creare un nuovo cluster, consultare Considerations.
+ **Usare un CNI di VPC recente**: implementare la versione CNI di Amazon VPC o successiva `1.10.1`. Per impostazione predefinita, viene distribuita questa versione o una versione successiva. Dopo aver implementato il componente aggiuntivo, non sarà possibile eseguire il downgrade del componente aggiuntivo CNI di Amazon VPC a una versione inferiore a `1.10.1` senza rimuovere tutti i nodi in tutti i gruppi di nodi nel cluster.
+ **Configura VPC CNI per `IPv6`**: Se utilizzi EC2 nodi Amazon, devi configurare il componente aggiuntivo Amazon VPC CNI con delega del prefisso IP e. `IPv6` Se durante la creazione del cluster si sceglie la famiglia `IPv6`, la versione `1.10.1` del componente aggiuntivo utilizza per impostazione predefinita questa configurazione. Questo è il caso di un componente aggiuntivo autogestito o Amazon EKS. Per ulteriori informazioni sulla delega dei prefissi IP, consultare [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md).
+ **Configurare indirizzi `IPv4` e `IPv6`**: quando si crea un cluster, il VPC e le sottoreti specificate devono avere un intervallo CIDR `IPv6` assegnato al VPC e alle sottoreti specificate. Devono inoltre disporre di un blocco CIDR `IPv4` assegnato. Questo perché, anche se si desidera utilizzare solo `IPv6`, il funzionamento di un VPC richiede comunque un blocco CIDR `IPv4`. Per ulteriori informazioni, consulta [Associare un blocco IPv6 CIDR al tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) nella Amazon VPC User Guide.
+ **Assegna automaticamente IPv6 gli indirizzi ai nodi:** quando crei i nodi, devi specificare le sottoreti configurate per l'assegnazione automatica degli indirizzi. `IPv6` In caso contrario, non sarà possibile implementare i nodi. Per impostazione predefinita, questa configurazione è disabilitata. Per ulteriori informazioni, consulta [Modificare l'attributo di IPv6 indirizzamento per la sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) nella Amazon VPC User Guide.
+ **Impostare le tabelle di routing per usare `IPv6`**: le tabelle di routing assegnate alle sottoreti devono avere percorsi per gli indirizzi `IPv6`. Per ulteriori informazioni, consulta [Migrare a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) nella Guida per l'utente di Amazon VPC.
+ **Impostare gruppi di sicurezza per `IPv6`**: i gruppi di sicurezza devono consentire gli indirizzi `IPv6`. Per ulteriori informazioni, consulta [Migrare a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) nella Guida per l'utente di Amazon VPC.
+ **Configura il load balancer**: utilizza la versione `2.3.1` o successiva del Load Balancer Controller per bilanciare il AWS carico delle applicazioni HTTP utilizzando il traffico di rete o utilizzando [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md) i `IPv6` to Pods con entrambi i sistemi di bilanciamento [Esecuzione del routing del traffico TCP e UDP con Network Load Balancer](network-load-balancing.md) del carico in modalità IP, ma non in modalità istanza. Per ulteriori informazioni, consulta [Indirizza il traffico Internet con AWS Load Balancer Controller](aws-load-balancer-controller.md).
+ **Aggiungere una policy IAM `IPv6`**: è necessario allegare una policy IAM `IPv6` al ruolo IAM del nodo o del CNI. Tra i due, consigliamo di allegarlo a un ruolo IAM CNI. Per ulteriori informazioni, consultare [Creare una policy IAM per i cluster che utilizzano la famiglia `IPv6`](cni-iam-role.md#cni-iam-role-create-ipv6-policy) e [Passaggio 1: Creazione di un ruolo IAM per il plug-in CNI di Amazon VPC per Kubernetes](cni-iam-role.md#cni-iam-role-create-role).
+ **Valuta tutti i componenti**: esegui una valutazione approfondita delle tue applicazioni, dei componenti aggiuntivi di Amazon EKS e AWS dei servizi con cui ti integri prima di distribuire `IPv6` i cluster. Questo per garantire che tutto funzioni come previsto con `IPv6`.
# Implementare un cluster `IPv6` Amazon EKS e nodi Amazon Linux gestiti
In questo tutorial, distribuisci un `IPv6` Amazon VPC, un cluster Amazon EKS con `IPv6` la famiglia e un gruppo di nodi gestiti con nodi Amazon EC2 Amazon Linux. Non puoi distribuire nodi Amazon EC2 Windows in un `IPv6` cluster. È inoltre possibile implementare nodi Fargate nel cluster, sebbene tali istruzioni non siano fornite in questo argomento per semplicità.
## Prerequisiti
Prima di iniziare questo tutorial, completare le seguenti operazioni:
Installare e configurare gli strumenti e le risorse elencati di seguito, che sono necessari per creare e gestire un cluster Amazon EKS.
+ Ѐ consigliabile acquisire familiarità con tutte le impostazioni e implementare un cluster con le impostazioni che soddisfano i requisiti specifici. Per ulteriori informazioni, consultare [Crea un cluster Amazon EKS.](create-cluster.md), [Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti](managed-node-groups.md) e le [considerazioni](cni-ipv6.md) per questo argomento. Alcune impostazioni possono essere abilitate solo quando viene creato il cluster.
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. La versione può essere uguale oppure immediatamente precedente o successiva alla versione di Kubernetes del cluster. Ad esempio, se la versione del cluster è `1.29`, puoi usare `kubectl` versione `1.28`, `1.29` o `1.30`. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
+ Il responsabile della sicurezza IAM che stai utilizzando deve disporre delle autorizzazioni per lavorare con i ruoli IAM di Amazon EKS, i ruoli collegati ai servizi AWS CloudFormation, un VPC e le risorse correlate. Per ulteriori informazioni, consultare le pagine [Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) e [Using service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) nella Guida per l’utente di IAM.
+ Se si utilizza eksctl, installare la versione `0.215.0` o successiva sul computer. Per installarlo o aggiornarlo, consulta la sezione [Installation](https://eksctl.io/installation) nella documentazione di `eksctl`.
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*. Se si utilizza la AWS CloudShell, potrebbe essere necessario [installare la versione 2.12.3 o successiva o 1.27.160 o successiva della CLI AWS , poiché la versione CLI](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) predefinita installata in potrebbe essere una versione precedente. AWS AWS CloudShell
È possibile utilizzare eksctl o la CLI per implementare un cluster `IPv6`.
## Distribuisci un cluster con eksctl IPv6
1. Crea il file `ipv6-cluster.yaml`. Copia il comando seguente sul tuo dispositivo. Apportare le seguenti modifiche al comando, se necessario, quindi esegui il comando modificato:
+ Sostituisci *my-cluster* con un nome da assegnare al cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno della AWS regione e AWS dell'account in cui stai creando il cluster.
+ Sostituisci *region-code* con qualsiasi AWS regione supportata da Amazon EKS. Per un elenco di AWS regioni, consulta gli [endpoint e le quote di Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) nella guida di riferimento AWS generale.
+ Il valore per `version` con la versione del tuo cluster. Per ulteriori informazioni, consultare la pagina [Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Sostituisci *my-nodegroup* con un nome per il gruppo di nodi. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura.
+ Sostituisci *t3.medium* con qualsiasi [tipo di istanza di AWS Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
cat >ipv6-cluster.yaml <
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Confermare che ai servizi di default siano assegnati indirizzi `IPv6`.
```
kubectl get services -n kube-system -o wide
```
Di seguito viene riportato un output di esempio.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Facoltativo) [Implementare un’applicazione di esempio](sample-deployment.md) o implementare [AWS Load Balancer Controller](aws-load-balancer-controller.md) e un’applicazione di esempio per eseguire il bilanciamento del carico delle applicazioni HTTP con [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md) o del traffico di rete con [Esecuzione del routing del traffico TCP e UDP con Network Load Balancer](network-load-balancing.md) verso i pod `IPv6`.
1. Una volta terminato con il cluster e i nodi creati per questo tutorial, è necessario eliminare le risorse create con il seguente comando.
```
eksctl delete cluster my-cluster
```
## Implementa un IPv6 cluster con CLI AWS
**Importante**
È necessario che tutti i passaggi di questa guida siano completati dallo stesso utente. Esegui il comando seguente per controllare l'utente corrente:
```
aws sts get-caller-identity
```
È necessario completare tutti i passaggi di questa procedura nella stessa shell. Diversi passaggi utilizzano le variabili impostate nelle fasi precedenti. Le fasi che utilizzano le variabili non funzioneranno correttamente se i relativi valori sono impostati in una shell diversa. Se utilizzate il [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)per completare la procedura seguente, ricordate che se non interagite con esso utilizzando la tastiera o il puntatore per circa 20-30 minuti, la sessione di shell termina. I processi in esecuzione non sono considerati interazioni.
Le istruzioni sono scritte per la shell Bash e per altre shell potrebbero essere necessarie ulteriori regolazioni.
Sostituire tutti i valori di esempio nelle fasi di questa procedura con i propri valori.
1. Emettere i seguenti comandi per impostare alcune variabili utilizzate nelle fasi successive. Sostituiscilo *region-code* con la AWS regione in cui desideri distribuire le risorse. Il valore può essere qualsiasi AWS regione supportata da Amazon EKS. Per un elenco di AWS regioni, consulta gli [endpoint e le quote di Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) nella guida di riferimento AWS generale. Sostituisci *my-cluster* con un nome da assegnare al cluster. Il nome può contenere solo caratteri alfanumerici (con distinzione tra lettere maiuscole e minuscole) e trattini. Deve iniziare con un carattere alfanumerico e non può avere una lunghezza superiore a 100 caratteri. Il nome deve essere univoco all'interno della AWS regione e AWS dell'account in cui stai creando il cluster. Sostituisci *my-nodegroup* con un nome per il gruppo di nodi. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura. Sostituisci *111122223333* con l'ID del tuo account.
```
export region_code=region-code
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
```
1. Creare un Amazon VPC con sottoreti pubbliche e private che soddisfino i requisiti Amazon EKS e `IPv6`.
1. Esegui il comando seguente per impostare una variabile per il nome AWS CloudFormation dello stack. Puoi sostituire *my-eks-ipv6-vpc* con un nome a tua scelta.
```
export vpc_stack_name=my-eks-ipv6-vpc
```
1. Crea un `IPv6` VPC utilizzando un AWS CloudFormation modello.
```
aws cloudformation create-stack --region $region_code --stack-name $vpc_stack_name \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
La creazione dello stack richiede alcuni minuti. Eseguire il seguente comando seguente. Non passare alla fase successiva finché l’output del comando non è `CREATE_COMPLETE`.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name --query Stacks[].StackStatus --output text
```
1. Recupera le IDs sottoreti pubbliche che sono state create.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text
```
Di seguito viene riportato un output di esempio.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE
```
1. Abilitare l'opzione di assegnazione automatica dell'indirizzo `IPv6` per le sottoreti pubbliche create.
```
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-0a1a56c486EXAMPLE --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-099e6ca77aEXAMPLE --assign-ipv6-address-on-creation
```
1. Recupera i nomi delle sottoreti e dei gruppi di sicurezza creati dal modello dallo AWS CloudFormation stack distribuito e memorizzali in variabili da utilizzare in un passaggio successivo.
```
security_groups=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SecurityGroups`].OutputValue' --output text)
public_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text)
private_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPrivate`].OutputValue' --output text)
subnets=${public_subnets},${private_subnets}
```
1. Crea un ruolo IAM del cluster e collegalo alla policy gestita IAM richiesta dall’AMI per Amazon EKS. I cluster Kubernetes gestiti da Amazon EKS effettuano chiamate ad altri AWS servizi per tuo conto per gestire le risorse che utilizzi con il servizio.
1. Per creare il file `eks-cluster-role-trust-policy.json`, emetti il seguente comando:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Eseguire questo comando per impostare una variabile per il nome del ruolo. Puoi sostituire *myAmazonEKSClusterRole* con un nome a tua scelta.
```
export cluster_role_name=myAmazonEKSClusterRole
```
1. Crea il ruolo.
```
aws iam create-role --role-name $cluster_role_name --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Recuperare l'ARN del ruolo IAM e memorizzarlo in una variabile per una fase successiva.
```
CLUSTER_IAM_ROLE=$(aws iam get-role --role-name $cluster_role_name --query="Role.Arn" --output text)
```
1. Allega la policy IAM gestita da Amazon EKS richiesta al ruolo.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name $cluster_role_name
```
1. Creare il cluster.
```
aws eks create-cluster --region $region_code --name $cluster_name --kubernetes-version 1.XX \
--role-arn $CLUSTER_IAM_ROLE --resources-vpc-config subnetIds=$subnets,securityGroupIds=$security_groups \
--kubernetes-network-config ipFamily=ipv6
```
1. NOTA: è possibile ricevere un messaggio di errore indicante che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l’output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consulta [Capacità insufficiente](troubleshooting.md#ice).
La creazione del cluster richiede diversi minuti. Eseguire il seguente comando seguente. Non passare alla fase successiva fino a quando l’output del comando non è `ACTIVE`.
```
aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status
```
1. Creare o aggiornare un file `kubeconfig` per il cluster in modo che sia possibile comunicare con il cluster.
```
aws eks update-kubeconfig --region $region_code --name $cluster_name
```
Per impostazione predefinita, il file `config` viene creato in `~/.kube` o la configurazione del nuovo cluster viene aggiunta a un file `config` esistente in `~/.kube`.
1. Creare un ruolo IAM del nodo.
1. Per creare il file `vpc-cni-ipv6-policy.json`, emetti il seguente comando:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Creare la policy IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Per creare il file `node-role-trust-relationship.json`, emetti il seguente comando:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Eseguire questo comando per impostare una variabile per il nome del ruolo. Puoi sostituire *AmazonEKSNodeRole* con un nome a tua scelta.
```
export node_role_name=AmazonEKSNodeRole
```
1. Creare il ruolo IAM.
```
aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Allegare la policy IAM al ruolo IAM.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name $node_role_name
```
**Importante**
Per semplicità, in questo tutorial la policy è allegata a questo ruolo IAM. Tuttavia, in un cluster di produzione, si consiglia di allegare la policy a un ruolo IAM separato. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
1. Allegare al ruolo IAM le due policy gestite IAM richieste.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name $node_role_name
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name $node_role_name
```
1. Recuperare l'ARN del ruolo IAM e memorizzarlo in una variabile per una fase successiva.
```
node_iam_role=$(aws iam get-role --role-name $node_role_name --query="Role.Arn" --output text)
```
1. Creare un gruppo di nodi gestito.
1. Visualizza le IDs sottoreti che hai creato in un passaggio precedente.
```
echo $subnets
```
Di seguito viene riportato un output di esempio.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE,subnet-0377963d69EXAMPLE,subnet-0c05f819d5EXAMPLE
```
1. Creare il gruppo di nodi. Sostituisci *0a1a56c486EXAMPLE*, *099e6ca77aEXAMPLE*, *0377963d69EXAMPLE*, and *0c05f819d5EXAMPLE* con i valori restituiti nell'output della fase precedente. Assicurati di rimuovere le virgole tra le sottoreti IDs dall'output precedente nel comando seguente. Puoi sostituire *t3.medium* con qualsiasi [tipo di istanza di AWS Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--subnets subnet-0a1a56c486EXAMPLE subnet-099e6ca77aEXAMPLE subnet-0377963d69EXAMPLE subnet-0c05f819d5EXAMPLE \
--instance-types t3.medium --node-role $node_iam_role
```
La creazione del gruppo di nodi richiede alcuni minuti. Eseguire il seguente comando seguente. Non passare alla fase successiva finché l’output restituito non è `ACTIVE`.
```
aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--query nodegroup.status --output text
```
1. Confermare che ai pod predefiniti siano assegnati indirizzi `IPv6` nella colonna `IP`.
```
kubectl get pods -n kube-system -o wide
```
Di seguito viene riportato un output di esempio.
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-rslts 1/1 Running 1 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Confermare che ai servizi di default siano assegnati gli indirizzi `IPv6` nella colonna `IP`.
```
kubectl get services -n kube-system -o wide
```
Di seguito viene riportato un output di esempio.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Facoltativo) [Implementare un’applicazione di esempio](sample-deployment.md) o implementare [AWS Load Balancer Controller](aws-load-balancer-controller.md) e un’applicazione di esempio per eseguire il bilanciamento del carico delle applicazioni HTTP con [Instradare il traffico di applicazioni e HTTP con Application Load Balancer](alb-ingress.md) o del traffico di rete con [Esecuzione del routing del traffico TCP e UDP con Network Load Balancer](network-load-balancing.md) verso i pod `IPv6`.
1. Una volta terminato con il cluster e i nodi creati per questo tutorial, è necessario eliminare le risorse create con i seguenti comandi. Assicurarsi di non utilizzare nessuna delle risorse al di fuori di questo tutorial prima di eliminarle.
1. Se si sta completando questo passaggio in una shell diversa da quella in cui sono state completate le fasi precedenti, impostare i valori di tutte le variabili utilizzate nelle fasi precedenti sostituendo i valori di esempio con quelli specificate durante le fasi precedenti. Se si sta completando questo passaggio nella stessa shell in cui sono state completate le fasi precedenti, andare alla fase successiva.
```
export region_code=region-code
export vpc_stack_name=my-eks-ipv6-vpc
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
export node_role_name=AmazonEKSNodeRole
export cluster_role_name=myAmazonEKSClusterRole
```
1. Eliminare il gruppo di nodi.
```
aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name
```
L'eliminazione richiede pochi minuti. Eseguire il seguente comando seguente. Non passare alla fase successiva se viene restituito un output.
```
aws eks list-nodegroups --region $region_code --cluster-name $cluster_name --query nodegroups --output text
```
1. Elimina il cluster.
```
aws eks delete-cluster --region $region_code --name $cluster_name
```
L'eliminazione del cluster richiede alcuni minuti. Prima di continuare, accertarsi che il cluster sia eliminato con il comando seguente:
```
aws eks describe-cluster --region $region_code --name $cluster_name
```
Non procedere alla fase successiva finché l’output non è simile al seguente:
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
```
1. Eliminare le risorse IAM create. Sostituisci *AmazonEKS\$1CNI\$1IPv6\$1Policy* con il nome scelto, se è stato scelto un nome diverso da quello usato nei passaggi precedenti.
```
aws iam detach-role-policy --role-name $cluster_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-policy --policy-arn arn:aws: iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-role --role-name $cluster_role_name
aws iam delete-role --role-name $node_role_name
```
1. Elimina lo AWS CloudFormation stack che ha creato il VPC.
```
aws cloudformation delete-stack --region $region_code --stack-name $vpc_stack_name
```
# Abilitare l’accesso a Internet in uscita per i pod
**Si applica a**: nodi Fargate Linux `IPv4`, nodi Linux con istanze Amazon EC2
Le informazioni contenute in questa sezione non sono applicabili al cluster se l’implementazione è avvenuta tramite la famiglia `IPv6`, in quanto gli indirizzi `IPv6` non sono convertiti in rete. Per ulteriori informazioni sull’uso di `IPv6` con il cluster, consulta [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md).
Per impostazione predefinita, a ciascun pod nel cluster viene assegnato un indirizzo `IPv4` [privato](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) da un routing interdominio senza classi (CIDR) associato al VPC in cui è implementato il pod. I pod nello stesso VPC comunicano tra loro utilizzando questi indirizzi IP privati come endpoint. Quando un pod comunica a un qualsiasi indirizzo `IPv4` che non è incluso in un intervallo CIDR associato al VPC, il plugin CNI di Amazon VPC (per [Linux](https://github.com/aws/amazon-vpc-cni-k8s#amazon-vpc-cni-k8s) o [Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge)) converte l’indirizzo `IPv4` del pod nell’indirizzo `IPv4` privato principale dell’[interfaccia di rete elastica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics) principale del nodo su cui è in esecuzione il pod, ovvero [\$1](#snat-exception) per impostazione predefinita.
**Nota**
Per i nodi Windows, ci sono ulteriori dettagli da considerare. Per impostazione predefinita, il [plugin CNI VPC per Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge) è definito con una configurazione di rete in cui il traffico verso una destinazione all’interno dello stesso VPC è escluso per SNAT. Ciò significa che la comunicazione VPC interna ha SNAT disabilitata e l’indirizzo IP assegnato al pod è indirizzabile all’interno del VPC. Tuttavia, il traffico verso una destinazione esterna al VPC ha l’IP di origine del pod tradotto tramite SNAT nell’indirizzo IP primario dell’interfaccia di rete elastica (ENI) dell’istanza. Questa configurazione predefinita per Windows garantisce che il pod possa accedere alle reti esterne al VPC allo stesso modo dell’istanza host.
A causa di questo comportamento:
+ I pod possono comunicare con le risorse Internet solo se il nodo su cui sono in esecuzione dispone di un indirizzo IP [pubblico](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) o [elastico](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) a esso assegnato e si trova in una [sottorete pubblica](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics). La [tabella di routing](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) associata a una sottorete pubblica dispone di un instradamento verso un gateway Internet. Per questo motivo, ti consigliamo di implementare i nodi nelle sottoreti private, quando possibile.
+ Per le versioni precedenti del plug-in`1.8.0`, le risorse che si trovano in rete o VPCs che sono connesse al VPC del cluster tramite [peering VPC, un VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) di transito o [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) non possono avviare la comunicazione con [i](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) Pod tramite interfacce di rete elastiche secondarie. I pod possono tuttavia avviare comunicazioni con tali risorse e ricevere risposte.
Se una delle seguenti affermazioni è vera nel tuo ambiente, modifica la configurazione predefinita con il comando che segue.
+ [Hai risorse in rete o VPCs collegate al tuo VPC del cluster tramite [peering VPC, un VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) di transito o [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) che devono avviare la comunicazione con i tuoi Pod utilizzando un `IPv4` indirizzo e la versione del plug-in è precedente a.](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) `1.8.0`
+ I pod si trovano in una [sottorete privata](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics) e devono comunicare in uscita a Internet. La sottorete dispone di una route a un [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
```
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
```
**Nota**
Le variabili di configurazione `AWS_VPC_K8S_CNI_EXTERNALSNAT` e `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` di CNI non sono applicabili ai nodi Windows. La disabilitazione di SNAT non è supportata per Windows. Per quanto riguarda l'esclusione di un elenco `IPv4` CIDRs da SNAT, è possibile definirla specificando il parametro nello script di bootstrap di Windows. `ExcludedSnatCIDRs` Per ulteriori informazioni su questo parametro, consulta la sezione [Parametri di configurazione dello script di bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Rete host
\$1Se la specifica di un pod contiene `hostNetwork=true` (il valore predefinito è `false`), il suo indirizzo IP non viene convertito in un indirizzo diverso. Per impostazione predefinita, questo comportamento è presente per i pod di `kube-proxy` e del plugin CNI di Amazon VPC per Kubernetes in esecuzione sul cluster. Per questi pod, l’indirizzo IP corrisponde a quello principale del nodo, poiché l’indirizzo IP del pod non viene convertito. Per ulteriori informazioni sull'`hostNetwork`impostazione di un Pod, consulta [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) nel riferimento all'API Kubernetes.
# Limita il traffico di Pod con le policy di rete di Kubernetes
## Panoramica di
Per impostazione predefinita, in Kubernetes non ci sono restrizioni per indirizzi IP, porte o connessioni tra qualsiasi Pod nel cluster o tra i pod e le risorse in qualsiasi altra rete. È possibile utilizzare la *policy di rete* di Kubernetes per limitare il traffico di rete da e verso i pod. Per ulteriori informazioni, consulta [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) nella documentazione Kubernetes.
## Politica di rete standard
È possibile utilizzare lo standard `NetworkPolicy` per segmentare il pod-to-pod traffico nel cluster. Queste policy di rete operano ai livelli 3 e 4 del modello di rete OSI, consentendoti di controllare il flusso di traffico a livello di indirizzo IP o di porta all'interno del tuo cluster Amazon EKS. Le policy di rete standard sono limitate al livello di namespace.
### Casi d’uso
+ Segmenta il traffico di rete tra i carichi di lavoro per garantire che solo le applicazioni correlate possano comunicare tra loro.
+ Isola i tenant a livello di namespace utilizzando policy per imporre la separazione della rete.
### Esempio
*Nella policy riportata di seguito, il traffico in uscita dai pod delle *webapp nello spazio dei nomi sun* è limitato.*
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-egress-policy
namespace: sun
spec:
podSelector:
matchLabels:
role: webapp
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: moon
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
name: stars
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
```
La politica si applica ai pod con l'etichetta nello spazio dei nomi. `role: webapp` `sun`
+ Traffico consentito: pod con l'etichetta `role: frontend` nello spazio dei nomi sulla porta TCP `moon` `8080`
+ Traffico consentito: pod con il ruolo di etichetta: frontend nello spazio dei nomi sulla porta TCP `stars` `8080`
+ Traffico bloccato: tutto il resto del traffico in uscita dai pod viene negato implicitamente `webapp`
## Politica di rete dell'amministratore (o del cluster)
![\[Illustrazione dell'ordine di valutazione delle politiche di rete in EKS\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/evaluation-order.png)
È possibile utilizzare il `ClusterNetworkPolicy` per applicare uno standard di sicurezza di rete che si applica all'intero cluster. Invece di definire e mantenere ripetutamente una policy distinta per ogni namespace, è possibile utilizzare un'unica policy per gestire centralmente i controlli di accesso alla rete per i diversi carichi di lavoro del cluster, indipendentemente dal relativo namespace.
### Casi d’uso
+ Gestisci centralmente i controlli di accesso alla rete per tutti (o un sottoinsieme di) carichi di lavoro nel tuo cluster EKS.
+ Definisci una posizione di sicurezza di rete predefinita in tutto il cluster.
+ Estendi gli standard di sicurezza organizzativi all'ambito del cluster in un modo più efficiente dal punto di vista operativo.
### Esempio
Nella politica riportata di seguito, puoi bloccare in modo esplicito il traffico del cluster proveniente da altri namespace per impedire l'accesso di rete a uno spazio dei nomi di carico di lavoro riservato.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Note importanti
Le politiche di rete nel plug-in Amazon VPC CNI per Kubernetes sono supportate nelle configurazioni elencate di seguito.
+ Versione 1.21.0 (o successiva) del plug-in Amazon VPC CNI per policy di rete standard e amministrative.
+ Cluster configurato per indirizzi `IPv4` o `IPv6`.
+ È possibile utilizzare le policy di rete con i [gruppi di sicurezza per pod](security-groups-for-pods.md). Con le policy di rete, è possibile controllare tutte le comunicazioni all’interno del cluster. Con i gruppi di sicurezza per Pods, puoi controllare l'accesso ai AWS servizi dalle applicazioni all'interno di un Pod.
+ È possibile utilizzare le policy di rete con le *reti personalizzate* e la *delega del prefisso*.
## Considerazioni
**Architettura**
+ Quando applichi il plug-in Amazon VPC CNI per le policy di rete Kubernetes al tuo cluster con il plug-in Amazon VPC CNI per Kubernetes, puoi applicare le policy solo ai nodi Amazon Linux. EC2 Non è possibile applicare le policy ai nodi Fargate o Windows.
+ Le policy di rete si applicano solo a indirizzi `IPv4` o `IPv6`, ma non a entrambi. In un cluster `IPv4`, il CNI di VPC assegna l’indirizzo `IPv4` ai pod e applica le policy `IPv4`. In un cluster `IPv6`, il CNI di VPC assegna l’indirizzo `IPv6` ai pod e applica le policy `IPv6`. Tutte le regole di policy di rete `IPv4` applicate a un cluster `IPv6` vengono ignorate. Tutte le regole di policy di rete `IPv6` applicate a un cluster `IPv4` vengono ignorate.
**Policy di rete**
+ Le policy di rete vengono applicate solo ai pod che fanno parte di un’implementazione. Ai pod autonomi che non dispongono di un set `metadata.ownerReferences` non possono essere applicate policy di rete.
+ È possibile applicare più policy di rete allo stesso pod. Quando sono configurate due o più policy che selezionano lo stesso pod, al pod vengono applicate tutte le policy.
+ Il numero massimo di combinazioni di porte e protocolli per un singolo intervallo di indirizzi IP (CIDR) è 24 per tutte le policy di rete. `namespaceSelector` CIDRsSelettori come resolve to one o più. Se più selettori si risolvono in un unico CIDR o si specifica lo stesso CIDR diretto più volte nella stessa policy di rete o in diverse policy di rete, tutti questi fattori vengono conteggiati ai fini di questo limite.
+ Per ognuno dei servizi di Kubernetes, la porta del servizio deve essere uguale a quella del container. Se si utilizzano porte con un nome assegnato, è necessario utilizzare lo stesso nome anche nelle specifiche del servizio.
**Politiche di rete di amministrazione**
1. **Politiche del livello di amministrazione (valutate per prime)**: tutte le politiche di livello amministratore ClusterNetworkPolicies vengono valutate prima di qualsiasi altra politica. All'interno del livello di amministrazione, le politiche vengono elaborate in ordine di priorità (prima il numero di priorità più basso). Il tipo di azione determina cosa succede dopo.
+ **Nega azione (priorità massima)**: quando una politica di amministrazione con un'azione Rifiuta corrisponde al traffico, tale traffico viene immediatamente bloccato indipendentemente da qualsiasi altra politica. Non vengono elaborate ClusterNetworkPolicy ulteriori NetworkPolicy regole. Ciò garantisce che i controlli di sicurezza a livello di organizzazione non possano essere sostituiti da politiche a livello di namespace.
+ **Consenti azioni**: dopo la valutazione delle regole Deny, le politiche di amministrazione con le azioni Consenti vengono elaborate in ordine di priorità (inizia con il numero di priorità più basso). Quando un'azione Consenti corrisponde, il traffico viene accettato e non viene effettuata alcuna ulteriore valutazione delle politiche. Queste politiche possono concedere l'accesso su più namespace in base a selettori di etichette, fornendo un controllo centralizzato su quali carichi di lavoro possono accedere a risorse specifiche.
+ **Pass action**: le azioni Pass Action nelle policy del livello di amministrazione delegano il processo decisionale ai livelli inferiori. Quando il traffico corrisponde a una regola Pass, la valutazione salta tutte le regole rimanenti del livello di amministratore per quel traffico e passa direttamente al livello. NetworkPolicy Ciò consente agli amministratori di delegare in modo esplicito il controllo di determinati modelli di traffico ai team applicativi. Ad esempio, è possibile utilizzare le regole Pass per delegare la gestione del traffico all'interno del namespace agli amministratori del namespace, mantenendo al contempo controlli rigorosi sull'accesso esterno.
1. Livello **di policy di rete: se nessuna politica del livello** di amministratore corrisponde a Deny o Allow, o se è stata soddisfatta un'azione Pass, vengono successivamente valutate le risorse con ambito namespace. NetworkPolicy Queste politiche forniscono un controllo granulare all'interno dei singoli namespace e sono gestite dai team delle applicazioni. Le politiche con ambito namespace possono essere solo più restrittive delle politiche di amministrazione. Non possono ignorare la decisione di rifiuto di una politica di amministrazione, ma possono limitare ulteriormente il traffico consentito o approvato dalle politiche di amministrazione.
1. **Politiche di amministrazione di livello base**: se nessuna politica di amministrazione o con ambito del namespace corrisponde al traffico, viene valutato il livello di base. ClusterNetworkPolicies Queste forniscono posizioni di sicurezza predefinite che possono essere sostituite da policy con ambito namespace, consentendo agli amministratori di impostare impostazioni predefinite a livello di organizzazione e offrendo al contempo ai team la flessibilità necessaria per personalizzarle in base alle esigenze. Le politiche di base vengono valutate in ordine di priorità (per primo il numero di priorità più basso).
1. **Negazione predefinita (se nessuna policy corrisponde)**: questo deny-by-default comportamento garantisce che siano consentite solo le connessioni esplicitamente consentite, mantenendo un solido livello di sicurezza.
**Migrazione**
+ Se il cluster utilizza attualmente una soluzione di terze parti per la gestione delle policy di rete di Kubernetes, è possibile utilizzare le stesse policy con il plug-in CNI di Amazon VPC per Kubernetes. Tuttavia, è necessario rimuovere la soluzione esistente in modo che non gestisca le stesse policy.
**avvertimento**
Dopo aver rimosso una soluzione di policy di rete, si consiglia di sostituire tutti i nodi a cui era stata applicata la soluzione di policy di rete. Questo perché le regole del traffico potrebbero essere ignorate da un pod della soluzione se questa si interrompe all’improvviso.
**Installazione**
+ La funzionalità di policy di rete crea e richiede una `PolicyEndpoint` Custom Resource Definition (CRD) denominata `policyendpoints.networking.k8s.aws`. Gli oggetti `PolicyEndpoint` della Custom Resource sono gestiti da Amazon EKS. È sconsigliabile modificare o eliminare queste risorse.
+ Se esegui pod che utilizzano le credenziali IAM del ruolo di istanza o ti connetti all' EC2 IMDS, fai attenzione a verificare le politiche di rete che bloccherebbero l'accesso all'IMDS. EC2 Potrebbe essere necessario aggiungere una policy di rete per consentire l'accesso all'IMDS. EC2 Per ulteriori informazioni, consulta [Metadati dell'istanza e dati utente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) nella Amazon EC2 User Guide.
I pod che utilizzano *ruoli IAM per gli account di servizio* o *EKS Pod Identity* non accedono EC2 a IMDS.
+ Il plug-in CNI di Amazon VPC per Kubernetes non applica le policy di rete alle interfacce di rete aggiuntive per ogni pod, ma solo all’interfaccia principale per ogni pod (`eth0`). Ciò influisce sulle seguenti architetture:
+ Pod `IPv6` con la variabile `ENABLE_V4_EGRESS` impostata su `true`. Questa variabile abilita la `IPv4` funzione di uscita per connettere i IPv6 pod a `IPv4` endpoint come quelli esterni al cluster. La funzione `IPv4` di uscita funziona creando un'interfaccia di rete aggiuntiva con un indirizzo di loopback locale. IPv4
+ In caso di utilizzo di plugin di rete concatenati come Multus. Poiché questi plug-in aggiungono interfacce di rete a ciascun pod, le policy di rete non vengono applicate ai plug-in di rete concatenati.
# Limitare il traffico di rete dei Pod con le policy di rete Kubernetes
È possibile utilizzare le policy di rete di Kubernetes per limitare il traffico di rete da e verso i pod. Per ulteriori informazioni, consulta [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) nella documentazione Kubernetes.
È necessario configurare quanto segue per utilizzare questa funzionalità:
1. Impostare l’applicazione delle policy all’avvio del Pod. Si effettua nel container `aws-node` del CNI `DaemonSet` di VPC.
1. Abilitare il parametro della policy di rete per il componente aggiuntivo.
1. Configurare il cluster per l’utilizzo della policy di rete di Kubernetes
Prima di iniziare, esaminare le seguenti informazioni. Per ulteriori informazioni, consulta [Considerazioni](cni-network-policy.md#cni-network-policy-considerations).
## Prerequisiti
Di seguito sono indicati i prerequisiti per la funzionalità:
### Versione minima del cluster
Un cluster Amazon EKS esistente. Per implementarne uno, consulta [Nozioni di base su Amazon EKS](getting-started.md). Il cluster deve eseguire una delle versioni Kubernetes e della piattaforma elencate nella tabella seguente. Sono supportate anche tutte le versioni di Kubernetes e della piattaforma successive a quelle elencate. Puoi controllare la tua versione attuale di Kubernetes *my-cluster* sostituendo il seguente comando con il nome del cluster e quindi eseguendo il comando modificato:
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Versione di Kubernetes | Versione della piattaforma |
| --- | --- |
| `1.27.4` | `eks.5` |
| `1.26.7` | `eks.6` |
### Versione minima VPC CNI
Per creare sia policy di rete Kubernetes standard che policy di rete di amministrazione, devi eseguire `1.21` la versione del plugin VPC CNI. È possibile verificare la versione attuale con il seguente comando.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Se la versione è precedente alla `1.21`, consulta la pagina [Aggiornamento di CNI di Amazon VPC (componente aggiuntivo Amazon EKS)](vpc-add-on-update.md) per eseguire l’aggiornamento alla versione `1.21` o successiva.
### Versione minima del kernel Linux
I nodi devono avere una versione del kernel Linux `5.10` o successiva. È possibile verificare la versione del kernel con `uname -r`. Se utilizzi le versioni più recenti di Amazon Linux ottimizzato per Amazon EKS, Amazon Linux accelerato ottimizzato per Amazon EKS e Bottlerocket AMIs, dispongono già della versione AMIs del kernel richiesta.
La versione `v20231116` o successive delle AMI Amazon Linux accelerate ottimizzate per Amazon EKS dispone della versione del kernel `5.10`.
## Passaggio 1: Impostare l’applicazione delle policy all’avvio del Pod
Il plug-in CNI di Amazon VPC per Kubernetes configura le policy di rete per i pod parallelamente al provisioning dei pod. Fino a quando tutte le policy non saranno configurate per il nuovo pod, i container nel nuovo si avvieranno con una *policy di autorizzazione predefinita*. Questa è chiamata *modalità standard*. Una policy di autorizzazione predefinita prevede che tutto il traffico in entrata e in uscita sia consentito da e verso i nuovi pod. Ad esempio, ai pod non verrà applicata alcuna regola del firewall (tutto il traffico è consentito) finché il nuovo pod non verrà aggiornato con le policy attive.
Con la variabile `NETWORK_POLICY_ENFORCING_MODE` impostata su `strict`, i pod che utilizzano il CNI di VPC iniziano con una *policy di negazione predefinita*, poi vengono configurate le policy. Questa è detta *modalità rigorosa*. In modalità rigorosa, è necessario disporre di una policy di rete per ogni endpoint a cui i pod devono accedere nel cluster. Questo requisito si applica ai pod CoreDNS. La policy di negazione predefinita non è configurata per i pod con rete host.
È possibile modificare la policy di rete predefinita impostando la variabile di ambiente `NETWORK_POLICY_ENFORCING_MODE` su `strict` nel container `aws-node` del CNI di VPC `DaemonSet`.
```
env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: "strict"
```
## Passaggio 2: Abilitare il parametro della policy di rete per il componente aggiuntivo
Per impostazione predefinita, per i parametri la funzionalità di policy di rete utilizza la porta `8162` sul nodo. Inoltre, la funzionalità utilizza la porta `8163` per le sonde sanitarie. Se esegui un’altra applicazione sui nodi o all’interno dei pod che deve utilizzare queste porte, l’app non viene eseguita. Dalla versione VPC CNI `v1.14.1` o successiva, puoi modificare queste porte.
Per abilitare il parametro della policy di rete per il componente aggiuntivo, procedere come indicato di seguito.
### Console di gestione AWS
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Selezionare la casella nella parte superiore destra della casella del componente aggiuntivo e scegli **Modifica**.
1. Nella pagina **Configura `Amazon VPC CNI`**:
1. Selezionare una `v1.14.0-eksbuild.3` o versione successiva nell’elenco **Versione**.
1. Scegliere **Impostazioni di configurazione facoltative**.
1. Inserisci la chiave JSON `"enableNetworkPolicy":` e il valore `"true"` nei **Valori di configurazione**. Il testo risultante deve essere un oggetto JSON valido. Se questa chiave e questo valore sono gli unici dati nella casella di testo, racchiudi la chiave e il valore tra parentesi graffe `{ }`.
L’esempio seguente ha la funzionalità delle policy di rete abilitata e i parametri e le sonde dell’integrità sono impostati sui numeri di porta predefiniti:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"healthProbeBindAddr": "8163",
"metricsBindAddr": "8162"
}
}
```
### Helm
Se il plug-in CNI di Amazon VPC per Kubernetes è stato installato attraverso `helm`, è possibile aggiornare la configurazione per scrivere le porte.
1. Esegui il seguente comando per modificare le porte. Imposta il numero di porta nel valore, rispettivamente, della chiave `nodeAgent.metricsBindAddr` o `nodeAgent.healthProbeBindAddr`.
```
helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
### kubectl
1. Apri la `DaemonSet` del `aws-node` nell’editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sostituire i numeri di porta negli argomenti del comando seguente nel `args:` del container `aws-network-policy-agent` nel manifesto del daemonset `aws-node` della CNI del VPC.
```
- args:
- --metrics-bind-addr=:8162
- --health-probe-bind-addr=:8163
```
## Passaggio 3: Configurare il cluster per l’utilizzo delle policy di rete di Kubernetes
È possibile impostarlo per un componente aggiuntivo di Amazon EKS o come un componente aggiuntivo autogestito.
### Componenti aggiuntivi di Amazon EKS
Utilizzando la AWS CLI, puoi configurare il cluster per utilizzare le politiche di rete Kubernetes eseguendo il comando seguente. Sostituire `my-cluster` con il nome del cluster e l’ARN del ruolo IAM con il ruolo che si sta utilizzando.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
```
Per configurarlo utilizzando la console di AWS gestione, segui i passaggi seguenti:
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Selezionare la casella nella parte superiore destra della casella del componente aggiuntivo e scegli **Modifica**.
1. Nella pagina **Configura `Amazon VPC CNI`**:
1. Selezionare una `v1.14.0-eksbuild.3` o versione successiva nell’elenco **Versione**.
1. Scegliere **Impostazioni di configurazione facoltative**.
1. Inserisci la chiave JSON `"enableNetworkPolicy":` e il valore `"true"` nei **Valori di configurazione**. Il testo risultante deve essere un oggetto JSON valido. Se questa chiave e questo valore sono gli unici dati nella casella di testo, racchiudi la chiave e il valore tra parentesi graffe `{ }`. Di seguito è riportato l’esempio dell’abilitazione della policy di rete:
```
{ "enableNetworkPolicy": "true" }
```
Lo screenshot seguente mostra un esempio di tale scenario.
![\[ che mostra il componente aggiuntivo CNI di VPC con policy di rete nella configurazione facoltativa.\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/console-cni-config-network-policy.png)
### Componenti aggiuntivi autogestiti
Se il plug-in CNI di Amazon VPC per Kubernetes è stato installato attraverso `helm`, è possibile aggiornare la configurazione per abilitare la policy di rete.
1. Esegui il comando seguente per abilitare la policy di rete.
```
helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
1. Apri la `ConfigMap` del `amazon-vpc-cni` nell’editor.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Aggiungi la seguente riga ai `data` nella `ConfigMap`.
```
enable-network-policy-controller: "true"
```
Dopo aver aggiunto la riga, la `ConfigMap` dovrebbe essere simile al seguente esempio.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Apri la `DaemonSet` del `aws-node` nell’editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sostituire il valore `false` con `true` nell’argomento del comando `--enable-network-policy=false` in `args:` nel container `aws-network-policy-agent` nel manifesto del daemonset `aws-node` della CNI di VPC.
```
- args:
- --enable-network-policy=true
```
## Passaggio 4. Fasi successive
Dopo aver completato la configurazione, confermare che i pod `aws-node` siano in esecuzione sul cluster.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Di seguito viene riportato un output di esempio.
```
aws-node-gmqp7 2/2 Running 1 (24h ago) 24h
aws-node-prnsh 2/2 Running 1 (24h ago) 24h
```
Nei pod `aws-node` sono presenti 2 container nelle versioni `1.14` e successive. Nelle versioni precedenti e se le policy di rete sono disabilitate, nei pod `aws-node` è presente un solo container.
Ora è possibile implementare le policy di rete di Kubernetes per il cluster.
Per implementare le policy di rete Kubernetes, puoi creare Kubernetes `NetworkPolicy` o `ClusterNetworkPolicy` oggetti e distribuirli nel tuo cluster. `NetworkPolicy`gli oggetti sono limitati a un namespace, mentre gli `ClusterNetworkPolicy` oggetti possono essere estesi all'intero cluster o a più namespace. Le policy vengono implementate per consentire o negare il traffico tra Pod in base a selettori di etichette, namespace e intervalli di indirizzi IP. Per ulteriori informazioni sulla creazione di oggetti `NetworkPolicy`, consultare [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) nella documentazione di Kubernetes.
L’applicazione di oggetti `NetworkPolicy` di Kubernetes viene implementata con Extended Berkeley Packet Filter (eBPF). Relativo alle implementazioni basate su `iptables`, offre caratteristiche di latenza e prestazioni inferiori, tra cui un utilizzo ridotto della CPU e l’evitamento delle ricerche sequenziali. Inoltre, le sonde eBPF forniscono l’accesso a dati contestuali che aiutano a eseguire il debug di problemi complessi a livello di kernel e a migliorare l’osservabilità. Amazon EKS supporta un esportatore basato su eBPF che sfrutta le sonde per registrare i risultati delle policy su ogni nodo ed esportare i dati in raccoglitori di log esterni per facilitare il debug. Per ulteriori informazioni, consulta [eBPF documentation](https://ebpf.io/what-is-ebpf/#what-is-ebpf).
# Disattiva le politiche di rete Kubernetes per il traffico di rete Amazon EKS Pod
Disattiva le policy di rete Kubernetes per interrompere la limitazione del traffico di rete Amazon EKS Pod
1. Elenca tutte le politiche di rete Kubernetes.
```
kubectl get netpol -A
```
1. Elimina ogni policy di rete Kubernetes. È necessario eliminare tutte le politiche di rete prima di disabilitarle.
```
kubectl delete netpol
```
1. Apri aws-node DaemOnset nel tuo editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sostituisci il valore `true` con `false` nell'argomento del comando `--enable-network-policy=true` in `args:` nel container `aws-network-policy-agent` nel manifesto del daemonset `aws-node` della CNI di VPC.
```
- args:
- --enable-network-policy=true
```
# Risoluzione dei problemi delle politiche di rete Kubernetes per Amazon EKS
Questa è la guida alla risoluzione dei problemi per la funzionalità di policy di rete di CNI di Amazon VPC.
Questa guida illustra:
+ informazioni su installazione, autorizzazioni di CRD e RBAC [Nuovo CRD `policyendpoints` e autorizzazioni](#network-policies-troubleshooting-permissions)
+ log da esaminare durante la diagnosi dei problemi relativi alle politiche di rete [Log delle policy di rete](#network-policies-troubleshooting-flowlogs)
+ esecuzione della raccolta di strumenti SDK eBPF per la risoluzione dei problemi
+ Problemi noti e risoluzioni [Problemi noti e risoluzioni](#network-policies-troubleshooting-known-issues)
**Nota**
Tieni presente che le politiche di rete vengono applicate solo ai pod creati da *Implementazioni* di Kubernetes. Per ulteriori limitazioni delle politiche di rete nel CNI di VPC, consultare [Considerazioni](cni-network-policy.md#cni-network-policy-considerations).
È possibile risolvere i problemi e analizzare le connessioni di rete che utilizzano le policy di rete leggendo i [log della policy di rete](#network-policies-troubleshooting-flowlogs) ed eseguendo gli strumenti da [eBPF SDK](#network-policies-ebpf-sdk).
## Nuovo CRD `policyendpoints` e autorizzazioni
+ CRD: `policyendpoints.networking.k8s.aws`
+ API di Kubernetes: `apiservice` ha chiamato `v1.networking.k8s.io`
+ Risorsa di Kubernetes: `Kind: NetworkPolicy`
+ RBAC: `ClusterRole` ha chiamato `aws-node` (CNI di VPC), `ClusterRole` ha chiamato `eks:network-policy-controller` (controller delle politiche di rete nel piano di controllo del cluster EKS)
Per la politica di rete, CNI di VPC crea un nuovo `CustomResourceDefinition` (CRD) chiamato `policyendpoints.networking.k8s.aws`. Il CNI VPC deve disporre delle autorizzazioni per creare il CRD e creare CustomResources (CR) di questo e dell'altro CRD installato dal VPC CNI (). `eniconfigs.crd.k8s.amazonaws.com` [Entrambi sono disponibili nel file su. CRDs `crds.yaml`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) GitHub In particolare, CNI di VPC deve disporre delle autorizzazioni verbali “ottieni”, “elenco” e “guarda” per `policyendpoints`.
La *politica di rete* di Kubernetes fa parte dei `apiservice` chiamato `v1.networking.k8s.io` e ciò è `apiversion: networking.k8s.io/v1` nei file YAML della politica. `DaemonSet` di CNI di VPC deve disporre delle autorizzazioni per utilizzare questa parte dell’API Kubernetes.
Le autorizzazioni di CNI di VPC sono disponibili in un `ClusterRole` chiamato `aws-node`. Si noti che gli oggetti `ClusterRole` non sono raggruppati in namespace. Di seguito, è illustrato il `aws-node` di un cluster:
```
kubectl get clusterrole aws-node -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: aws-vpc-cni
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: aws-node
app.kubernetes.io/version: v1.19.4
helm.sh/chart: aws-vpc-cni-1.19.4
k8s-app: aws-node
name: aws-node
rules:
- apiGroups:
- crd.k8s.amazonaws.com
resources:
- eniconfigs
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- namespaces
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- get
- apiGroups:
- ""
- events.k8s.io
resources:
- events
verbs:
- create
- patch
- list
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- apiGroups:
- vpcresources.k8s.aws
resources:
- cninodes
verbs:
- get
- list
- watch
- patch
```
Inoltre, un nuovo controller è avviato nel piano di controllo di ciascun cluster EKS. Il controller utilizza le autorizzazioni del `ClusterRole` chiamato `eks:network-policy-controller`. Di seguito, è illustrato il `eks:network-policy-controller` di un cluster:
```
kubectl get clusterrole eks:network-policy-controller -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/name: amazon-network-policy-controller-k8s
name: eks:network-policy-controller
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/finalizers
verbs:
- update
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- patch
- update
- apiGroups:
- networking.k8s.io
resources:
- networkpolicies
verbs:
- get
- list
- patch
- update
- watch
```
## Log delle policy di rete
Ciascuna decisione da parte di CNI di VPC relativamente al fatto che le connessioni sono consentite o negate da una policy di rete è registrata da *log di flusso*. I log delle policy di rete su ogni nodo includono i log di flusso per ogni pod che dispone di una policy di rete. I log delle policy di rete sono archiviati in `/var/log/aws-routed-eni/network-policy-agent.log`. Di seguito è riportato un esempio del file `network-policy-agent.log`:
```
{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}
```
I log della policy di rete sono disabilitati per impostazione predefinita. Per abilitare i log della policy di rete, segui i passaggi riportati di seguito:
**Nota**
I log delle policy di rete richiedono 1 vCPU aggiuntiva per il container `aws-network-policy-agent` nel manifesto `aws-node` `DaemonSet` di CNI di VPC.
### Componenti aggiuntivi di Amazon EKS
** Console di gestione AWS **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Selezionare la casella nella parte superiore destra della casella del componente aggiuntivo e scegli **Modifica**.
1. Nella pagina **Configura *Amazon VPC CNI***:
1. Seleziona una `v1.14.0-eksbuild.3` o versione successiva nell'elenco a discesa **Versione**.
1. Scegli **Impostazioni di configurazione facoltative**.
1. Inserisci la chiave JSON di primo livello `"nodeAgent":` e il valore, che è un oggetto con una chiave`"enablePolicyEventLogs":` e un valore di `"true"` nei **Valori di configurazione**. Il testo risultante deve essere un oggetto JSON valido. L'esempio seguente mostra i criteri di rete e i registri dei criteri di rete sono abilitati e i registri dei criteri di rete vengono inviati a CloudWatch Logs:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true"
}
}
```
Lo screenshot seguente mostra un esempio di tale scenario.
![\[mostrando il componente aggiuntivo VPC CNI con policy di rete e CloudWatch log nella configurazione opzionale.\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/console-cni-config-network-policy-logs.png)
AWS CLI
1. Esegui il seguente comando AWS CLI. Sostituisci `my-cluster` con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'
```
### Componenti aggiuntivi autogestiti
Helm
Se il plugin CNI di Amazon VPC per Kubernetes è stato installato attraverso`helm`, è possibile aggiornare la configurazione per scrivere i log della policy di rete.
1. Esegui il comando seguente per abilitare la policy di rete.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
kubectl
Se il plugin CNI di Amazon VPC per Kubernetes è stato installato attraverso`kubectl`, è possibile aggiornare la configurazione per scrivere i log della policy di rete.
1. Apri la `DaemonSet` del `aws-node` nell’editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sostituisci il valore `false` con `true` nell’argomento del comando `--enable-policy-event-logs=false` in `args:` nel container `aws-network-policy-agent` nel manifesto `aws-node` `DaemonSet` di CNI di VPC.
```
- args:
- --enable-policy-event-logs=true
```
### Invia i log delle policy di rete ad Amazon CloudWatch Logs
Puoi monitorare i log delle politiche di rete utilizzando servizi come Amazon CloudWatch Logs. Puoi utilizzare i seguenti metodi per inviare i log delle politiche di rete a Logs. CloudWatch
Per i cluster EKS, i log delle policy si troveranno in `/aws/eks/cluster-name/cluster/`, mentre per i cluster K8S autogestiti i log verranno collocati in `/aws/k8s-cluster/cluster/`.
#### Invio dei log della policy di rete con il plugin CNI di Amazon VPC per Kubernetes
Se si abilitano le policy di rete, ai pod viene aggiunto un secondo container `aws-node` per un *agente del nodo*. Questo agente del nodo può inviare i registri delle politiche di rete a Logs. CloudWatch
**Nota**
Solo i log delle policy di rete vengono inviati dall'agente del nodo. Gli altri log creati dalla CNI di VPC non sono inclusi.
##### Prerequisiti
+ Aggiungi le seguenti autorizzazioni come strofa o policy separata al ruolo IAM che stai utilizzando per la CNI di VPC.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
##### Componenti aggiuntivi di Amazon EKS
** Console di gestione AWS **
1. Aprire la [Console Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Nel riquadro di navigazione a sinistra, seleziona **Cluster**, quindi seleziona il nome del cluster per cui desideri configurare il componente aggiuntivo CNI di Amazon VPC.
1. Selezionare la scheda **Componenti aggiuntivi**.
1. Selezionare la casella nella parte superiore destra della casella del componente aggiuntivo e scegli **Modifica**.
1. Nella pagina **Configura *Amazon VPC CNI***:
1. Seleziona una `v1.14.0-eksbuild.3` o versione successiva nell'elenco a discesa **Versione**.
1. Scegli **Impostazioni di configurazione facoltative**.
1. Inserisci la chiave JSON di primo livello `"nodeAgent":` e il valore, che è un oggetto con una chiave`"enableCloudWatchLogs":` e un valore di `"true"` nei **Valori di configurazione**. Il testo risultante deve essere un oggetto JSON valido. L'esempio seguente mostra i criteri di rete e i registri dei criteri di rete sono abilitati e i log vengono inviati a Logs: CloudWatch
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true",
"enableCloudWatchLogs": "true",
}
}
```
Lo screenshot seguente mostra un esempio di tale scenario.
![\[mostrando il componente aggiuntivo VPC CNI con policy di rete e CloudWatch log nella configurazione opzionale.\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png)
** AWS CLI**
1. Esegui il seguente comando AWS CLI. Sostituisci `my-cluster` con il nome del cluster e l'ARN del ruolo IAM con il ruolo che stai utilizzando.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws: iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'
```
##### Componenti aggiuntivi autogestiti
**Timone**
Se hai installato il plug-in Amazon VPC CNI per Kubernetes tramite`helm`, puoi aggiornare la configurazione per inviare i log delle politiche di rete a Logs. CloudWatch
1. Esegui il comando seguente per abilitare i log delle politiche di rete e inviarli a Logs. CloudWatch
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
**kubectl**
1. Apri la `DaemonSet` del `aws-node` nell’editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sostituisci `false` con `true` in due argomenti del comando `--enable-policy-event-logs=false` e `--enable-cloudwatch-logs=false` nel `args:` nel container `aws-network-policy-agent` nel manifesto `aws-node` `DaemonSet` di CNI di VPC.
```
- args:
- --enable-policy-event-logs=true
- --enable-cloudwatch-logs=true
```
#### Invio dei log delle policy di rete con Fluent Bit `DaemonSet`
Se stai utilizzando Fluent Bit in `DaemonSet` per inviare i log dai nodi, è possibile aggiungere una configurazione che includa i log delle policy di rete provenienti dalle policy di rete. È possibile utilizzare la configurazione di esempio seguente:
```
[INPUT]
Name tail
Tag eksnp.*
Path /var/log/aws-routed-eni/network-policy-agent*.log
Parser json
DB /var/log/aws-routed-eni/flb_npagent.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
## SDK ebPF incluso
Il plugin CNI di Amazon VPC per Kubernetes installa la raccolta di strumenti dell’SDK eBPF sui nodi. È possibile utilizzare gli strumenti dell’SDK eBPF per identificare i problemi relativi alle policy di rete. Ad esempio, il comando seguente elenca i programmi in esecuzione sul nodo.
```
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
```
Per eseguire questo comando, è possibile utilizzare qualsiasi metodo di connessione al nodo.
## Problemi noti e risoluzioni
Le seguenti sezioni descrivono i problemi noti con la funzionalità di policy di rete CNI di Amazon VPC e le relative soluzioni.
### Registri delle politiche di rete generati nonostante l'impostazione sia impostata su false enable-policy-event-logs
**Problema**: CNI di VPC EKS genera log delle politiche di rete anche quando l’impostazione `enable-policy-event-logs` è impostata su `false`.
**Soluzione**: l’impostazione `enable-policy-event-logs` disabilita solo i log delle “decisioni” delle politiche, ma non disabilita tutta la registrazione degli agenti della policy di rete. Questo comportamento è documentato nel [aws-network-policy-agent README](https://github.com/aws/aws-network-policy-agent/) on. GitHub Per disabilitare completamente la registrazione, potrebbe essere necessario modificare altre configurazioni di registrazione.
### Problemi di pulizia della mappa della policy di rete
**Problema**: la rete `policyendpoint` è ancora esistente e non è ripulita dopo l’eliminazione dei pod.
**Soluzione**: questo problema è stato causato da un problema con il componente aggiuntivo di CNI di VPC versione 1.19.3-eksbuild.1. Per risolvere questo problema, esegui l’aggiornamento a una versione più recente del componente aggiuntivo CNI di VPC.
### Le politiche di rete non sono applicate
**Problema**: la funzionalità della policy di rete è abilitata nel plugin CNI di Amazon VPC, ma le policy di rete non sono applicate correttamente.
Se crei una policy di rete `kind: NetworkPolicy` e questa non influisce sul pod, verifica che l’oggetto policyendpoint sia stato creato nello stesso namespace del pod. Se non ci sono oggetti `policyendpoint` nei namespace, il controller della policy di rete (parte del cluster EKS) non è stato in grado di creare regole di policy di rete per l’agente delle policy di rete (parte del CNI di VPC) da applicare.
**Soluzione**: la soluzione consiste nel correggere le autorizzazioni del CNI di VPC (`ClusterRole` : `aws-node`) e del controller delle policy di rete (`ClusterRole` : `eks:network-policy-controller`) e consentire queste azioni in qualsiasi strumento di applicazione delle policy come Kyverno. Assicurati che le policy di Kyverno non blocchino la creazione di oggetti `policyendpoint`. Vedi la sezione precedente per le autorizzazioni in cui sono necessarie le autorizzazioni in [Nuovo CRD `policyendpoints` e autorizzazioni](#network-policies-troubleshooting-permissions).
### I pod non tornano allo stato di negazione predefinito dopo l’eliminazione della policy in modalità rigida
**Problema**: quando i criteri di rete sono abilitati in modalità rigida, i pod iniziano con una politica di negazione predefinita. Dopo l’applicazione delle politiche, il traffico è consentito verso gli endpoint specificati. Tuttavia, quando le policy sono eliminate, il pod non torna allo stato di negazione predefinito, invece passa allo stato di autorizzazione predefinito.
**Soluzione**: questo problema è stato risolto in CNI di VPC versione 1.19.3, che includeva l’agente di policy di rete versione 1.2.0. Dopo la correzione, con la modalità rigida abilitata, una volta rimosse le policy, il pod tornerà allo stato di negazione predefinito come previsto.
### Latenza di avvio dei gruppi di sicurezza for pod
**Problema**: quando si utilizza la funzionalità dei gruppi di sicurezza per pod in EKS, la latenza di avvio dei pod aumenta.
**Soluzione**: la latenza è dovuta alla limitazione della velocità nel controller di risorse dovuta alla limitazione dell'API sull'`CreateNetworkInterface`API, che il controller di risorse VPC utilizza per creare un ramo per i pod. ENIs Verifica i limiti delle API del tuo account per questa operazione e, se necessario, valuta la possibilità di richiedere un aumento del limite.
### FailedScheduling a causa dell'insufficienza di vpc.amazonaws.com/pod-eni
**Problema**: i pod non riescono a pianificarsi con l’errore: `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.`
**Soluzione**: come nel problema precedente, l’assegnazione dei gruppi di sicurezza ai pod aumenta la latenza di pianificazione dei pod e può superare la soglia CNI necessaria per aggiungere ogni ENI, causando il mancato avvio dei pod. Questo è il comportamento previsto quando si utilizzano i gruppi di sicurezza per pod. Considera le implicazioni di pianificazione durante la progettazione dell’architettura del carico di lavoro.
### Problemi di connettività IPAM ed errori di segmentazione
**Problema**: si verificano molteplici errori, tra cui problemi di connettività IPAM, richieste di limitazione ed errori di segmentazione:
+ `Checking for IPAM connectivity …`
+ `Throttling request took 1.047064274s`
+ `Retrying waiting for IPAM-D`
+ `panic: runtime error: invalid memory address or nil pointer dereference`
**Soluzione**: questo problema si verifica se si installa `systemd-udev` su AL2 023, poiché il file viene riscritto con una politica non conforme. Ciò può accadere quando si esegue l’aggiornamento a un `releasever` diverso che ha un pacchetto aggiornato o si aggiorna manualmente il pacchetto stesso. Evita l'installazione o l'aggiornamento `systemd-udev` sui nodi AL2 023.
### Errore di ricerca del dispositivo in base al nome non riuscito
**Problema**: messaggio di errore: `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}`
**Soluzione**: questo problema è stato identificato e risolto nelle versioni più recenti dell’agente di policy di rete CNI di Amazon VPC (v1.2.0). Per risolvere questo problema, effettua l’aggiornamento alla versione più recente di CNI di VPC.
### Vulnerabilità di CVE nell’immagine Multus CNI
**Problema**: Enhanced EKS ImageScan CVE Report identifica le vulnerabilità nella versione dell'immagine Multus CNI v4.1.4-eksbuild.2\$1thick.
**Soluzione**: esegui l’aggiornamento alla nuova versione dell’immagine Multus CNI e alla nuova immagine del controller della policy di rete, che non presentano vulnerabilità. Lo scanner può essere aggiornato per risolvere le vulnerabilità rilevate nella versione precedente.
### Le informazioni sul flusso NEGANO i verdetti nei log
**Problema**: i log delle politiche di rete mostrano i verdetti di NEGAZIONE: `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}`
**Soluzione**: questo problema è stato risolto nella nuova versione di controller della policy di rete. Effettua l’aggiornamento alla versione più recente della piattaforma EKS per risolvere i problemi di registrazione.
### Pod-to-pod problemi di comunicazione dopo la migrazione da Calico
**Problema**: dopo l'aggiornamento di un cluster EKS alla versione 1.30 e il passaggio da Calico ad Amazon VPC CNI per le policy di rete pod-to-pod, la comunicazione fallisce quando vengono applicate le policy di rete. La comunicazione è ripristinata quando le policy di rete sono eliminate.
**Soluzione**: l’agente di policy di rete nel CNI di VPC non può avere tante porte specificate quante ne ha Calico. Invece, utilizza gli intervalli di porte nelle policy di rete. Il numero massimo di combinazioni univoche di porte per ogni protocollo `ingress:` o `egress:` selettore in una politica di rete è 24. Utilizza gli intervalli di porte per ridurre il numero di porte uniche ed evitare questa limitazione.
### L’agente della policy di rete non supporta i pod autonomi
**Problema**: le policy di rete applicate ai pod autonomi possono avere un comportamento incoerente.
**Soluzione**: attualmente l’agente della policy di rete supporta solo i pod distribuiti come parte di un set di implementazione/replica. Se le policy di rete sono applicate ai pod autonomi, potrebbero esserci delle incongruenze nel comportamento. Questo è documentato nella parte superiore di questa pagina[Considerazioni](cni-network-policy.md#cni-network-policy-considerations), nel e nel [aws-network-policy-agent GitHub numero \$1327 successivo](https://github.com/aws/aws-network-policy-agent/issues/327). GitHub Implementa i pod come parte di un’implementazione o di un set di replica per un comportamento coerente delle policy di rete.
# Demo delle policy di rete con Stars per Amazon EKS
La demo consente di creare un servizio di front-end, di back-end e client sul cluster Amazon EKS. Inoltre, la demo consente di creare un'interfaccia utente grafica di gestione che mostra i percorsi di ingresso e uscita disponibili tra ogni servizio. Ti consigliamo di completare la demo su un cluster su cui non esegui carichi di lavoro di produzione.
Prima di creare eventuali policy di rete, tutti i servizi sono in grado di comunicare in modo bidirezionale. Dopo l'applicazione delle policy di rete, puoi vedere che il client può comunicare solo con il servizio di front-end, mentre il back-end accetta traffico solo dal front-end.
1. Applica i servizi di front-end, back-end, client e dell'interfaccia utente di gestione:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
```
1. Visualizza tutti i pod nel cluster.
```
kubectl get pods -A
```
Di seguito viene riportato un output di esempio:
Nell'output, dovresti vedere i pod negli spazi dei nomi mostrati nel seguente output. I *NOMI* dei pod e il numero di pod nella colonna `READY` sono diversi da quelli del seguente output. Non continuare finché non consulta pod con nomi simili e tutti hanno il valore `Running` nella colonna `STATUS`.
```
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
client client-xlffc 1/1 Running 0 5m19s
[...]
management-ui management-ui-qrb2g 1/1 Running 0 5m24s
stars backend-sz87q 1/1 Running 0 5m23s
stars frontend-cscnf 1/1 Running 0 5m21s
[...]
```
1. Per connetterti all'interfaccia utente di gestione, connettiti all'`EXTERNAL-IP` del servizio in esecuzione sul cluster:
```
kubectl get service/management-ui -n management-ui
```
1. Apri un browser nella posizione del passaggio precedente. Dovresti visualizzare l'interfaccia utente di gestione seguente. Il nodo **C** è il servizio client, il nodo **F** è il servizio front-end e il nodo **B** è il servizio di back-end. Ogni nodo dispone di accesso di comunicazione completo a tutti gli altri nodi, come indicato dalle righe colorate in grassetto.
![\[Apri policy di rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/stars-default.png)
1. Applica la seguente policy di rete nei due spazi dei nomi `stars` e `client` per isolare tra loro i servizi:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny
spec:
podSelector:
matchLabels: {}
```
È possibile utilizzare i seguenti comandi per applicare la policy a entrambi gli spazi dei nomi:
```
kubectl apply -n stars -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
```
1. Aggiorna il tuo browser. Poiché l’interfaccia utente di gestione non può più raggiungere i nodi, essi non vengono visualizzati nell’interfaccia utente.
1. Applica le seguenti policy di rete per consentire all'interfaccia utente di gestione di accedere ai servizi. Applica questa policy per consentire all'interfaccia utente di:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Applica questa policy per consentire al client di:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: client
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
È possibile utilizzare i seguenti comandi per applicare la policy a entrambe le policy:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
```
1. Aggiorna il tuo browser. L'interfaccia utente di gestione può raggiungere nuovamente i nodi, ma i nodi non sono in grado di comunicare tra loro.
![\[Policy di rete accesso interfaccia utente\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/stars-no-traffic.png)
1. Applicare le seguenti policy di rete per consentire il traffico dal servizio front-end al servizio back-end:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: backend-policy
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
```
1. Aggiorna il tuo browser. Puoi vedere che il front-end può comunicare con il back-end.
![\[Policy da front-end a back-end\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/stars-front-end-back-end.png)
1. Applica la seguente policy di rete per consentire il traffico dal client al servizio di front-end:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: frontend-policy
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 80
```
1. Aggiorna il tuo browser. Puoi vedere che il client può comunicare con il servizio di front-end. Il servizio di front-end può ancora comunicare con il servizio di back-end.
![\[Policy di rete finale\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/stars-final.png)
1. (Facoltativo) Al termine della demo, puoi eliminare le relative risorse.
```
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
```
Anche dopo l'eliminazione delle risorse, sui nodi possono essere presenti endpoint di policy di rete che potrebbero interferire in modo imprevisto con la rete nel cluster. L'unico modo sicuro per rimuovere queste regole è riavviare i nodi o terminare tutti i nodi e riciclarli. Per terminare tutti i nodi, impostare il conteggio desiderato del Gruppo Auto Scaling su 0, quindi eseguire il backup al numero desiderato oppure terminare semplicemente i nodi.
# Implementazione dei pod in sottoreti alternative con reti personalizzate
**Si applica a**: nodi Fargate Linux `IPv4`, nodi Linux con istanze Amazon EC2
![\[Diagramma del nodo con più interfacce di rete\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/cn-image.png)
Per impostazione predefinita, il plug-in CNI di Amazon VPC per Kubernetes crea [interfacce di rete elastiche secondarie](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (interfacce di rete) per il nodo Amazon EC2 nella stessa sottorete dell’interfaccia di rete primaria del nodo. Inoltre, associa all’interfaccia di rete secondaria gli stessi gruppi di sicurezza associati a quella primaria. È possibile far sì che il plugin crei interfacce di rete secondarie in una sottorete diversa o associ gruppi di sicurezza diversi alle interfacce di rete secondarie, o entrambe le cose, in base a uno dei motivi riportati di seguito:
+ È disponibile un numero limitato di indirizzi `IPv4` nella sottorete in cui si trova l’interfaccia di rete primaria. Ciò potrebbe limitare il numero di Pod che è possibile creare nella sottorete. Utilizzando una sottorete diversa per le interfacce di rete secondarie, puoi aumentare il numero di indirizzi `IPv4` disponibili per i Pod.
+ Per motivi di sicurezza, i tuoi Pod dovrebbero usare sottoreti o gruppi di sicurezza diversi rispetto all’interfaccia di rete primaria del nodo.
+ I nodi sono configurati in sottoreti pubbliche e puoi collocare i Pod in sottoreti private. La tabella di instradamento associata a una sottorete pubblica include un percorso a un gateway Internet. La tabella di routing associata a una sottorete privata non include una route a un gateway Internet.
**Suggerimento**
Puoi anche aggiungere una sottorete nuova o esistente direttamente al cluster Amazon EKS, senza utilizzare reti personalizzate. Per ulteriori informazioni, consulta [Aggiunta di una sottorete VPC esistente a un cluster Amazon EKS dalla console di gestione](eks-networking.md#add-existing-subnet).
## Considerazioni
Di seguito sono riportate alcune considerazioni sull’utilizzo della funzionalità.
+ L’abilitazione di una rete personalizzata non consente di assegnare ai Pod gli indirizzi IP associati all’interfaccia di rete primaria. Solo gli indirizzi IP delle interfacce di rete secondarie vengono assegnati ai Pod.
+ Se il cluster utilizza la famiglia `IPv6`, non puoi usare la rete personalizzata.
+ Se si prevede di utilizzare una rete personalizzata esclusivamente per ridurre l’esaurimento dell’indirizzo `IPv4`, è invece possibile creare un cluster tramite la famiglia `IPv6`. Per ulteriori informazioni, consulta [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md).
+ I Pod implementati nelle sottoreti specificate per le interfacce di rete secondarie possono utilizzare sottoreti e gruppi di sicurezza diversi rispetto all’interfaccia di rete primaria del nodo, a patto che si trovino nello stesso VPC del nodo.
+ Per Fargate, le sottoreti sono controllate tramite il profilo Fargate. Per ulteriori informazioni, consulta [Definisci quali pod utilizzano AWS Fargate durante l’avvio](fargate-profile.md).
# Personalizzare l’interfaccia di rete secondaria nei nodi di Amazon EKS
Prima di iniziare questo tutorial, completa le seguenti operazioni:
+ Esaminare le considerazioni
+ Familiarità con il modo in cui il plug-in CNI di Amazon VPC per Kubernetes crea interfacce di rete secondarie e assegna indirizzi IP ai Pod. Per ulteriori informazioni, consulta [Allocazione di ENI](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation) su GitHub.
+ Versione `2.12.3` o successiva o versione `1.27.160` o successiva dell'interfaccia a riga di AWS comando (AWS CLI) installata e configurata sul dispositivo o. AWS CloudShell Per verificare la versione attuale, usa `aws --version | cut -d / -f2 | cut -d ' ' -f1`. I gestori di pacchetti come `yum` Homebrew per macOS sono spesso diverse versioni dell'ultima versione della CLI AWS . `apt-get` Per installare la versione più recente, consulta [Installazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurazione rapida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente dell'*interfaccia a riga di AWS comando*. La versione AWS CLI installata in AWS CloudShell potrebbe anche contenere diverse versioni precedenti alla versione più recente. Per aggiornarlo, consulta [Installazione della AWS CLI nella tua home directory nella Guida per](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) l'* AWS CloudShell utente*.
+ Lo strumento a riga di comando `kubectl` è installato sul dispositivo o AWS CloudShell. Per installare o aggiornare `kubectl`, consulta [Impostazione di `kubectl` e `eksctl`](install-kubectl.md):
+ Ti consigliamo di completare la procedura descritta in questo argomento in una shell Bash. In alternativa, puoi apportare alcune modifiche alla tua shell per alcuni comandi di script, come i caratteri di continuazione della riga, e per il modo in cui le variabili vengono impostate e utilizzate. Inoltre, le regole di escape e di utilizzo delle virgolette per la shell (interprete di comandi) potrebbero essere diverse. Per ulteriori informazioni, consulta [Uso delle virgolette con le stringhe nella AWS CLI nella Guida](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) per l'utente dell'interfaccia a riga di AWS comando.
Per questo tutorial, ti consigliamo di utilizzare i valori di esempio tranne quando è indicato di sostituirli. Puoi sostituire qualsiasi valore di esempio al completamento delle fasi dedicate alla creazione del cluster. Consigliamo di completare tutte le fasi nello stesso terminale, dato che le variabili impostate e utilizzate durante la procedura non sono presenti in terminali diversi.
I comandi in questo argomento sono formattati utilizzando le convenzioni elencate in [Utilizzo degli esempi CLI AWS](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html). Se esegui comandi dalla riga di comando su risorse che si trovano in una AWS regione diversa da quella predefinita definita nel [profilo AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles) CLI che stai utilizzando, devi aggiungerli `--region us-west-2` ai comandi, sostituendoli `us-west-2` con la tua AWS AWS regione.
Per implementare le reti personalizzate nel cluster di produzione, passa alla [Passaggio 2: configurazione del VPC](#custom-networking-configure-vpc).
## Passaggio 1: creazione di un VPC e di un cluster di test
Le procedure seguenti illustrano la creazione di un VPC e un cluster di test, oltre alla configurazione di una rete personalizzata per tale cluster. Consigliamo di non utilizzare il cluster di test per i carichi di lavoro di produzione poiché alcune funzionalità da utilizzare con il cluster di produzione non sono trattate in questo argomento. Per ulteriori informazioni, consulta [Crea un cluster Amazon EKS.](create-cluster.md).
1. Eseguire il seguente comando per definire la variabile `account_id`.
```
account_id=$(aws sts get-caller-identity --query Account --output text)
```
1. Crea un VPC.
1. Se esegui la distribuzione su un sistema di test, crea un VPC utilizzando un modello Amazon AWS CloudFormation EKS.
```
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. La AWS CloudFormation creazione dello stack richiede alcuni minuti. Utilizzare il comando seguente per verificare lo stato di implementazione dello stack.
```
aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus --output text
```
Non passare alla Passaggio successiva finché l’output del comando non è `CREATE_COMPLETE`.
1. Definisci le variabili con i valori della sottorete privata IDs creata dal modello.
```
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. Definire le variabili con le zone di disponibilità delle sottoreti recuperate nel passaggio precedente.
```
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. Crea un ruolo IAM del cluster.
1. Per creare un file JSON della policy di attendibilità IAM, esegui il comando seguente.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Crea il ruolo IAM del cluster Amazon EKS. Se necessario, inserisci il prefisso `eks-cluster-role-trust-policy.json` nel percorso del computer in cui hai eseguito la scrittura del file nella Passaggio precedente. Il comando associa il criterio di attendibilità creato nella Passaggio precedente al ruolo. Per creare un ruolo IAM, l’azione `iam:CreateRole` (autorizzazione) deve essere assegnata al [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) che sta creando il ruolo.
```
aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Allega la policy gestita di Amazon EKS denominata [Amazon EKSCluster Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) al ruolo. Per allegare una policy IAM a un [principale IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), è necessario assegnare al principale che sta allegando la policy una delle azioni IAM (autorizzazioni) seguenti: `iam:AttachUserPolicy` o `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Crea un cluster Amazon EKS e configura il dispositivo per comunicare con esso.
1. Crea un 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"
```
**Nota**
Potresti ricevere un messaggio di errore indicante che una delle zone di disponibilità nella richiesta non dispone di capacità sufficiente per creare un cluster Amazon EKS. In questo caso, l’output di errore contiene le zone di disponibilità in grado di supportare un nuovo cluster. Riprova a creare il cluster con almeno due sottoreti che si trovano nelle zone di disponibilità supportate per il tuo account. Per ulteriori informazioni, consulta [Capacità insufficiente](troubleshooting.md#ice).
1. La creazione del cluster richiede diversi minuti. Utilizzare il comando seguente per verificare lo stato di implementazione del cluster.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
```
Non passare alla Passaggio successiva finché l’output del comando non è `"ACTIVE"`.
1. Configura `kubectl` per comunicare con il cluster.
```
aws eks update-kubeconfig --name my-custom-networking-cluster
```
## Passaggio 2: configurazione del VPC
Questo tutorial richiede il VPC creato nella [Passaggio 1: creazione di un VPC e di un cluster di test](#custom-networking-create-cluster). Per un cluster di produzione, modificare i passaggi in base al VPC, sostituendo tutti i valori di esempio con i propri.
1. Accertati che la versione del plug-in CNI di Amazon VPC per Kubernetes installata sia l’ultima versione. Per determinare la versione più recente per il componente aggiuntivo del tipo Amazon EKS e aggiornarla, consulta la pagina [Aggiornamento di un componente aggiuntivo di Amazon EKS](updating-an-add-on.md). Per determinare la versione più recente per il componente aggiuntivo del tipo autogestito e aggiornarla, consulta la pagina [Assegna IPs ai pod con Amazon VPC CNI](managing-vpc-cni.md).
1. Recupera l’ID del VPC in cui si trova il cluster e memorizzarlo in una variabile per l’utilizzo nei passaggi successivi.
```
vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
```
1. Associare un intervallo di routing interdominio senza classi (CIDR) aggiuntivo al VPC del cluster. L’intervallo CIDR non può sovrapporsi agli intervalli CIDR esistenti già associati.
1. Visualizza i blocchi CIDR attualmente associati al tuo VPC.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id \
--query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Di seguito viene riportato un output di esempio:
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
+-----------------+--------------+
```
1. Associa un blocco CIDR aggiuntivo al VPC. Sostituire il valore dell’intervallo CIDR nel comando seguente. Per ulteriori informazioni, consulta [Associare blocchi IPv4 CIDR aggiuntivi al tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr) nella Amazon VPC User Guide.
```
aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
```
1. Verifica che il nuovo blocco sia associato.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Di seguito viene riportato un output di esempio.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
| 192.168.1.0/24 | associated |
+-----------------+--------------+
```
Non andare al passaggio successivo finché il nuovo `State` dell’intervallo CIDR non è `associated`.
1. Crea tutte le sottoreti che vuoi utilizzare in ogni zona di disponibilità in cui si trovano le sottoreti esistenti. Specificare un intervallo CIDR all’interno dell’intervallo CIDR associato al VPC in una Passaggio precedente.
1. Crea nuove sottoreti. Sostituire i valori dell’intervallo CIDR nel seguente comando. È necessario creare le sottoreti in un blocco CIDR VPC diverso rispetto alle sottoreti esistenti, ma all’interno delle stesse zone di disponibilità. In questo esempio si crea una sottorete nel nuovo blocco CIDR in ogni zona di disponibilità in cui esistono le sottoreti private attuali. Le IDs sottoreti create vengono memorizzate in variabili da utilizzare nelle fasi successive. I valori `Name` corrispondono a quelli assegnati alle sottoreti create utilizzando il modello Amazon EKS VPC in un passaggio precedente. I nomi non sono obbligatori. È possibile utilizzare nomi diversi.
```
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)
```
**Importante**
Per impostazione predefinita, le nuove sottoreti sono implicitamente associate alla [tabella di routing principale](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables) del VPC. Questa tabella di instradamento consente la comunicazione tra tutte le risorse implementate nel VPC, ad eccezione delle risorse con indirizzi IP esterni ai blocchi CIDR associate al VPC. Per modificare questo comportamento, associa la tabella di instradamento alle sottoreti. Per ulteriori informazioni, consulta [Tabelle di instradamento per sottoreti](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables) nella Guida per l’utente di Amazon VPC.
1. Per visualizzare le sottoreti attuali nel tuo VPC.
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
--query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
--output table
```
Di seguito viene riportato un output di esempio:
```
----------------------------------------------------------------------
| 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 |
+------------------+--------------------+----------------------------+
```
Come puoi vedere, le sottoreti create nel blocco CIDR `192.168.1.0` si trovano nelle stesse zone di disponibilità di quelle create nel blocco CIDR `192.168.0.0`.
## Passaggio 3: configurazione delle risorse Kubernetes
1. Imposta la variabile di `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` ambiente su `true` in. `aws-node` DaemonSet
```
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
```
1. Recupera l'ID del [gruppo di sicurezza del cluster](sec-group-reqs.md) e memorizzalo in una variabile da utilizzare nel passaggio successivo. Amazon EKS crea automaticamente questo gruppo di sicurezza durante la creazione del cluster.
```
cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
```
1. Creare una risorsa personalizzata `ENIConfig` per ogni sottorete in cui vuoi implementare i Pod.
1. Crea un file univoco per ogni configurazione di interfaccia di rete.
I comandi seguenti creano file `ENIConfig` separati per le due sottoreti create in una Passaggio precedente. Il valore di `name` deve essere univoco. Il nome corrisponde alla zona di disponibilità in cui si trova la sottorete. Il gruppo di sicurezza del cluster viene assegnato a `ENIConfig`.
```
cat >$az_1.yaml <$az_2.yaml <
1. Creare un ruolo IAM del nodo.
1. Per creare un file JSON della policy di attendibilità IAM, esegui il comando seguente.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Creare un ruolo IAM e memorizzare il nome della risorsa Amazon (ARN) restituito in una variabile da utilizzare in una Passaggio successiva.
```
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. Allega al ruolo IAM le tre policy gestite IAM richieste.
```
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
```
**Importante**
Per semplicità, in questo tutorial la policy [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) è allegata al ruolo IAM del nodo. Tuttavia, in un cluster di produzione, consigliamo di allegare la policy a un ruolo IAM separato da utilizzare solo con il plug-in CNI di Amazon VPC per Kubernetes. Per ulteriori informazioni, consulta [Configurare il plug-in CNI di Amazon VPC per l’utilizzo di IRSA](cni-iam-role.md).
1. Creare uno dei seguenti tipi di gruppi di nodi. Per determinare il tipo di istanza da implementare, consulta [Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale](choosing-instance-type.md). Per questo tutorial, utilizza l’opzione **Gestito**, **senza un modello di avvio o con un modello di avvio senza un ID AMI specificato**. Se prevedi di utilizzare il gruppo di nodi per i carichi di lavoro di produzione, ti consigliamo di familiarizzare con tutte le opzioni del [gruppo di nodi gestito](create-managed-node-group.md) e del [gruppo di nodi autogestito](worker.md) prima di implementare il gruppo di nodi.
+ **Gestito**: implementare il gruppo di nodi utilizzando una delle opzioni seguenti:
+ **Senza un modello di avvio o con un modello di avvio senza un ID AMI specificato**: esegui il comando seguente. Per questo tutorial, utilizza i valori di esempio. Per un gruppo di nodi di produzione, sostituire tutti i valori di esempio con i propri. Il nome del gruppo di nodi non può contenere più di 63 caratteri. Deve iniziare con una lettera o un numero, ma può anche includere trattini e caratteri di sottolineatura.
```
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
```
+ **Con un modello di avvio con un ID AMI specificato**
1. Determinare il numero massimo di Pod consigliato da Amazon EKS per i nodi. Seguire le istruzioni riportate in , aggiungendo `--cni-custom-networking-enabled` alla Passaggio 3 di questo argomento. Annota l’output restituito per l’utilizzo in un passaggio successivo.
1. Nel modello di avvio, specifica un ID AMI ottimizzato per Amazon EKS o un’AMI personalizzata sviluppata con l’AMI ottimizzato per Amazon EKS, quindi [implementa il gruppo di nodi utilizzando un modello di avvio](launch-templates.md) e fornisci i seguenti dati utente nel modello di avvio. Questi dati utente passano gli argomenti alle `NodeConfig` specifiche. Per ulteriori informazioni in merito NodeConfig, consulta il [riferimento all'NodeConfig API](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig). Puoi sostituire `20` con il valore del passaggio precedente (consigliato) o con un valore desiderato.
```
---
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
```
Se hai creato un’AMI personalizzata che non è stata sviluppata con quella ottimizzata per Amazon EKS, devi creare autonomamente la configurazione.
+ **Autogestito**
1. Determinare il numero massimo di Pod consigliato da Amazon EKS per i nodi. Seguire le istruzioni riportate in , aggiungendo `--cni-custom-networking-enabled` alla Passaggio 3 di questo argomento. Annota l’output restituito per l’utilizzo in un passaggio successivo.
1. Implementa il gruppo di nodi utilizzando le istruzioni in [Crea nodi Amazon Linux autogestiti](launch-workers.md).
**Nota**
Se vuoi che i nodi presenti in un cluster di produzione supportino un numero significativamente più elevato di Pod, esegui nuovamente lo script in . Aggiungi inoltre l’opzione `--cni-prefix-delegation-enabled` al comando. Ad esempio, per un tipo di istanza `m5.large` viene restituito `110`. Per istruzioni su come abilitare questa funzionalità, consulta [Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi](cni-increase-ip-addresses.md). Puoi utilizzare questa funzionalità con una rete personalizzata.
1. La creazione di gruppi di nodi richiede diversi minuti. Puoi verificare lo stato della creazione di un gruppo di nodi gestiti con il comando seguente.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Non andare al passaggio successivo finché l’output restituito non è `ACTIVE`.
1. Ai fini di questo tutorial, puoi ignorare questo passaggio.
Per un cluster di produzione, se è stato assegnato a `ENIConfigs` un nome diverso da quello della zona di disponibilità in cui lo stai utilizzando, devi annotare i nodi con il nome `ENIConfig` da utilizzare con il nodo. Questo passaggio non è necessario se disponi di una sola sottorete in ogni zona di disponibilità e hai assegnato a `ENIConfigs` gli stessi nomi delle zone di disponibilità. Questo perché il plug-in CNI di Amazon VPC per Kubernetes associa automaticamente il `ENIConfig` corretto al nodo se questa opzione è stata abilitata in una [Passaggio precedente](#custom-networking-automatically-apply-eniconfig).
1. Ottieni l’elenco dei nodi nel cluster.
```
kubectl get nodes
```
Di seguito viene riportato un output di esempio:
```
NAME STATUS ROLES AGE VERSION
ip-192-168-0-126.us-west-2.compute.internal Ready 8m49s v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal Ready 8m34s v1.22.9-eks-810597c
```
1. Determina in quale zona di disponibilità si trova ogni nodo. Eseguire il comando seguente per ogni nodo restituito nella Passaggio precedente, sostituendo gli indirizzi IP in base all’output precedente.
```
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}'
```
Di seguito viene riportato un output di esempio.
```
[
{
"AvailabilityZone": "us-west-2d",
"SubnetId": "subnet-Example5"
}
]
```
1. Annota ogni nodo con la risorsa `ENIConfig` creata per l’ID della sottorete e la zona di disponibilità. Puoi annotare solo un nodo con un `ENIConfig`, ma più nodi con lo stesso `ENIConfig`. Sostituire i valori di esempio con i propri valori.
```
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. Se in un cluster di produzione erano presenti nodi con Pod in esecuzione prima di passare all’utilizzo della funzionalità di rete personalizzata, completare le attività seguenti:
1. Assicurati di avere dei nodi disponibili abilitati per la funzionalità di rete personalizzata.
1. Cordonare ed espellere i nodi per interrompere normalmente i Pod. Per ulteriori informazioni, consulta [Safely Drain a Node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) (Espellere un nodo in modo sicuro) nella documentazione Kubernetes.
1. Termina i nodi. Se i nodi si trovano in un gruppo di nodi gestito esistente, puoi eliminare il gruppo di nodi. Eseguire il seguente comando seguente.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
Solo i nuovi nodi registrati con l’etichetta `k8s.amazonaws.com/eniConfig` useranno la nuova funzionalità di rete personalizzata.
1. Verificare che ai Pod venga assegnato un indirizzo IP da un intervallo CIDR associato a una delle sottoreti create in una Passaggio precedente.
```
kubectl get pods -A -o wide
```
Di seguito viene riportato un output di esempio.
```
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal
kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
```
Puoi vedere che ai coredns vengono assegnati indirizzi IP dall’intervallo CIDR `192.168.1.0` aggiunto al VPC. Senza una rete personalizzata, ai pod sarebbero stati assegnati indirizzi provenienti dall’unico blocco CIDR originariamente associato al VPC, ossia il blocco CIDR `192.168.0.0`.
Se una `spec` del Pod contiene il valore `hostNetwork=true`, viene assegnato l’indirizzo IP principale del nodo, non un indirizzo proveniente dalle sottoreti aggiunte. Per impostazione predefinita, questo valore è impostato su `false`. Questo valore è impostato su `true` per il `kube-proxy` e i pod (`aws-node`) del plug-in CNI di Amazon VPC per Kubernetes in esecuzione sul cluster. Per questo motivo al `kube-proxy` e ai pod `aws-node` del plug-in non vengono assegnati indirizzi 192.168.1.x nell’output precedente. Per ulteriori informazioni sull'`hostNetwork`impostazione di un Pod, consulta [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) nel riferimento all'API Kubernetes.
## Passaggio 5: eliminazione delle risorse del tutorial
Ti consigliamo di eliminare le risorse create dopo aver completato il tutorial. In seguito, potrai modificare i passaggi per abilitare la rete personalizzata di un cluster di produzione.
1. Se il gruppo di nodi creato era solo a scopo di test, eliminalo.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
1. Anche dopo che l'output della AWS CLI indica che il cluster è stato eliminato, il processo di eliminazione potrebbe non essere effettivamente completo. Questo processo di eliminazione richiede alcuni minuti. Verificare che il processo sia completo con il comando seguente.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
Non continuare finché l’output restituito non è simile al seguente.
```
An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
```
1. Se il gruppo di nodi creato era solo a scopo di test, elimina il ruolo IAM del nodo.
1. Scollega le policy dal ruolo.
```
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. Elimina il ruolo.
```
aws iam delete-role --role-name myCustomNetworkingNodeRole
```
1. Elimina il cluster.
```
aws eks delete-cluster --name my-custom-networking-cluster
```
Verifica l’eliminazione del cluster con il comando seguente.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
```
Quando viene restituito un output simile al seguente, il cluster è stato eliminato correttamente.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
```
1. Elimina il ruolo IAM del cluster.
1. Scollega le policy dal ruolo.
```
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
1. Elimina il ruolo.
```
aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Elimina le sottoreti create in una Passaggio precedente.
```
aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2
```
1. Elimina il VPC creato.
```
aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
```
# Assegnazione di più indirizzi IP ai nodi Amazon EKS con prefissi
**Si applica a**: nodi Linux e Windows con istanze Amazon EC2
**Si applica a**: sottoreti pubbliche e private
Ogni istanza Amazon EC2 supporta un numero massimo di interfacce di rete elastiche e un numero massimo di indirizzi IP che possono essere assegnati a ogni interfaccia di rete. Ogni nodo richiede un indirizzo IP per ogni interfaccia di rete. Tutti gli altri indirizzi IP disponibili possono essere assegnati a `Pods`. Ogni `Pod` necessita di un proprio indirizzo IP. Di conseguenza, si potrebbero avere nodi con risorse di calcolo e memoria disponibili, ma che non possono ospitare ulteriori `Pods` perché il nodo ha esaurito gli indirizzi IP a cui assegnare `Pods`.
È possibile aumentare sensibilmente il numero di indirizzi IP che i nodi possono assegnare ai `Pods` assegnando prefissi IP ai nodi, anziché assegnare singoli indirizzi IP secondari. Ogni prefisso include diversi indirizzi IP. Se non configuri il cluster per l’assegnazione del prefisso IP, il cluster deve effettuare più chiamate di interfaccia di programmazione dell’applicazione (API) di Amazon EC2 per la configurazione delle interfacce di rete e degli indirizzi IP necessari alla connettività del Pod. La frequenza di queste chiamate API, man mano che i cluster acquisiscono dimensioni maggiori, può portare a tempi di avvio di Pod e delle istanze più lunghi. Ciò si traduce in ritardi di dimensionamento per soddisfare la domanda di carichi di lavoro grandi e spigolosi e aggiunge costi generali di gestione in quanto è necessario eseguire il provisioning di cluster e VPC aggiuntivi per soddisfare i requisiti di scalabilità. Consultare [Kubernetes Scalability thresholds](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) su GitHub per ulteriori informazioni.
## Compatibilità con le funzionalità del plug-in CNI di Amazon VPC per Kubernetes
È possibile utilizzare prefissi IP con le seguenti caratteristiche:
+ Traslazione degli indirizzi di rete di origine IPv4: Per ulteriori informazioni, consulta [Abilitare l’accesso a Internet in uscita per i pod](external-snat.md).
+ Indirizzi IPv6 verso 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).
L’elenco seguente fornisce informazioni sulle impostazioni del plug-in CNI di Amazon VPC applicabili. Per maggiori informazioni su ciascuna impostazione, consultare [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) su GitHub.
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## Considerazioni
Quando si utilizza questa funzionalità, considerare i seguenti aspetti:
+ Ogni tipo di istanza Amazon EC2 supporta un numero massimo di Pod. Se il gruppo di nodi gestito è costituito da più tipi di istanza, a tutti i nodi del cluster viene applicato il numero minimo di Pod massimo per un’istanza del cluster.
+ Per impostazione predefinita, il numero massimo di `Pods` che puoi eseguire su un nodo è pari a 110, ma puoi modificare questo numero. Se cambi il numero e disponi di un gruppo di nodi gestiti, il prossimo aggiornamento dell’AMI o del modello di avvio del gruppo di nodi comporta la creazione di nuovi nodi con il valore modificato.
+ Quando passi dall’assegnazione di indirizzi IP all’assegnazione di prefissi IP, si consiglia di creare nuovi gruppi di nodi per aumentare il numero di indirizzi IP disponibili, anziché effettuare una sostituzione progressiva dei nodi esistenti. L’esecuzione di Pod su un nodo a cui sono stati assegnati sia indirizzi IP che prefissi può portare a un’incoerenza nella capacità degli indirizzi IP pubblicizzati, con un impatto sui carichi di lavoro futuri sul nodo. Per il metodo consigliato di eseguire la transizione, consulta la [modalità Prefix Delegation per Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html) in *Amazon EKS Best Practices Guide*.
+ L’ambito del gruppo di sicurezza è a livello di nodo: Per ulteriori informazioni, consulta [Gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
+ I prefissi IP assegnati a un’interfaccia di rete supportano un’elevata densità di Pod per nodo e offrono il miglior tempo di avvio.
+ I prefissi IP e gli indirizzi IP sono associati alle interfacce di rete elastiche Amazon EC2 standard. Ai pod che richiedono gruppi di sicurezza specifici viene assegnato l’indirizzo IP primario di un’interfaccia di rete di filiali. È possibile combinare i Pod ottenendo gli indirizzi IP o gli indirizzi IP dai prefissi IP con i Pod che ottengono interfacce di rete di filiali sullo stesso nodo.
+ Solo per i cluster con nodi Linux.
+ Dopo aver configurato il componente aggiuntivo per assegnare prefissi alle interfacce di rete, non è possibile eseguire il downgrade del componente aggiuntivo del plug-in CNI di Amazon VPC per Kubernetes a una versione inferiore a `1.9.0` (o `1.10.1`) senza rimuovere tutti i nodi in tutti i gruppi di nodi nel cluster.
+ Se si utilizzano anche gruppi di sicurezza per i Pod, con `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` e `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false`, quando i Pod comunicano con endpoint esterni al VPC, vengono utilizzati i gruppi di sicurezza del nodo, anziché i gruppi di sicurezza assegnati ai Pod.
Se si utilizzano anche [gruppi di sicurezza per Pod](security-groups-for-pods.md), con `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, quando i `Pods` comunicano con endpoint esterni al VPC, vengono utilizzati i gruppi di sicurezza di `Pod’s`.
# Aumentare gli indirizzi IP disponibili per il nodo Amazon EKS
Puoi aumentare sensibilmente il numero di indirizzi IP che i nodi possono assegnare ai Pod assegnando prefissi IP ai nodi, anziché assegnare singoli indirizzi IP secondari.
## Prerequisiti
+ Necessiti di un cluster esistente. Per implementarne uno, consulta [Crea un cluster Amazon EKS.](create-cluster.md).
+ Le sottoreti in cui si trovano i tuoi nodi Amazon EKS devono avere un numero sufficiente di blocchi di routing interdominio senza classi (CIDR) `/28` (per i cluster `IPv4`) o `/80` (per i cluster `IPv6`). Puoi disporre solo di nodi Linux in un cluster `IPv6`. L’uso dei prefissi IP può non riuscire se gli indirizzi IP sono sparsi nella sottorete CIDR. Consigliamo quanto segue:
+ L’utilizzo di una prenotazione di sottorete CIDR in modo che, anche se alcuni indirizzi IP all’interno dell’intervallo riservato sono ancora in uso, al momento del rilascio, gli indirizzi IP non vengano riassegnati. Ciò assicura che i prefissi siano disponibili per l’assegnazione senza segmentazione.
+ Usa nuove sottoreti utilizzate specificamente per l’esecuzione di carichi di lavoro a cui sono assegnati i prefissi IP. I carichi di lavoro sia di Windows sia di Linux possono essere eseguiti nella stessa sottorete quando si assegnano prefissi IP.
+ Per assegnare prefissi IP ai nodi, i nodi devono essere basati su Nitro. AWS Le istanze che non sono basate su Nitro continuano ad allocare singoli indirizzi IP secondari, ma hanno un numero significativamente inferiore di indirizzi IP da assegnare ai Pod rispetto alle istanze basate su Nitro.
+ **Solo per cluster con nodi Linux**`IPv4`: se il cluster è configurato per la famiglia, devi avere installata la versione `1.9.0` o una versione successiva del componente aggiuntivo del plug-in CNI di Amazon VPC per Kubernetes. Puoi controllare la versione attuale con il seguente comando.
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
Se il cluster è configurato per la famiglia `IPv6`, è necessario che sia installata la versione `1.10.1` del componente aggiuntivo. Se la versione del plugin è precedente a quelle richieste, è necessario aggiornarla. Per ulteriori informazioni, consulta le sezioni di aggiornamento di [Assign IPs to Pods con Amazon VPC CNI](managing-vpc-cni.md).
+ **Solo per i cluster con nodi Windows**
+ Per il cluster, devi abilitare il supporto Windows. Per ulteriori informazioni, consulta [Implementazione dei nodi Windows su cluster EKS](windows-support.md).
## Assegnare i prefissi degli indirizzi IP ai nodi
Configurare il cluster per assegnare i prefissi degli indirizzi IP ai nodi. Completare la procedura corrispondente al sistema operativo del nodo.
### Linux
1. Abilita il parametro per assegnare prefissi alle interfacce di rete per Amazon VPC CNI. DaemonSet Quando implementi un cluster, la versione `1.10.1` o successiva del componente aggiuntivo del plug-in CNI di Amazon VPC per Kubernetes viene implementata con esso. Se crei il cluster con la famiglia `IPv6`, questa impostazione era su `true` di default. Se crei il cluster con la famiglia `IPv4`, questa impostazione era su `false` di default.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**Importante**
Anche se la sottorete dispone di indirizzi IP disponibili, se non dispone di blocchi `/28` contigui disponibili, vedrai il seguente errore nei log del plug-in di Amazon VPC CNI per Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Ciò può verificarsi a causa della frammentazione degli indirizzi IP secondari esistenti distribuiti in una sottorete. Per risolvere questo errore, crea una nuova sottorete e avvia i Pod lì oppure utilizza una prenotazione CIDR di EC2 subnet Amazon per riservare spazio all'interno di una sottorete da utilizzare con l'assegnazione del prefisso. Per ulteriori informazioni, consulta la sezione relativa a [Prenotazioni della CIDR per la sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) nella Guida per l’utente di Amazon VPC.
1. Se intendi implementare un gruppo di nodi gestito senza un modello di avvio o con uno in cui non è specificato un ID AMI e se utilizzi una versione del componente aggiuntivo del plug-in CNI di Amazon VPC per Kubernetes corrispondente o successiva alle versioni riportate nei prerequisiti, vai al passaggio successivo. I gruppi di nodi gestiti calcolano automaticamente il numero massimo di Pod.
Se stai implementando un gruppo di nodi autogestito o un gruppo di nodi gestito con un modello di avvio in cui è specificato un ID AMI, devi determinare il numero massimo di Pod consigliati da Amazon EKS per i nodi. Segui le istruzioni riportate in , `--cni-prefix-delegation-enabled` da aggiungere al passaggio 3. Annotare l’output restituito per l’utilizzo in un passaggio successivo.
**Importante**
I gruppi di nodi gestiti applicano un numero massimo sul valore di `maxPods`. Per le istanze con meno di 30 v CPUs il numero massimo è 110 e per tutte le altre istanze il numero massimo è 250. Questo numero massimo viene applicato indipendentemente dal fatto che la delega del prefisso sia abilitata o meno.
1. Se usi un cluster configurato per `IPv6`, vai alla Passaggio successiva.
È possibile specificare i parametri una delle seguenti opzioni. Per determinare quale opzione è adatta a te e quale valore fornirti, consulta [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET e MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md) su. GitHub
Puoi sostituire i valori di esempio con un valore maggiore di zero.
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` o `MINIMUM_IP_TARGET` – Se uno dei due valori è impostato, sovrascrive qualsiasi valore impostato per `WARM_PREFIX_TARGET`.
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. Crea uno dei seguenti tipi di gruppi di nodi con almeno un tipo di istanza Amazon EC2 Nitro Amazon Linux 2023. Per un elenco dei tipi di istanze Nitro, consulta [Istanze costruite sul sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) nella Amazon EC2 User Guide. Questa funzionalità non è supportata da Windows. Per le opzioni che includono *110*, sostituirlo con il valore del passaggio 3 (consigliato) o con il proprio valore.
+ **Gestione automatica**: implementare il gruppo di nodi utilizzando le istruzioni in [Create self-managed Amazon Linux nodes](launch-workers.md). Prima di creare lo CloudFormation stack, apri il file modello e modificalo `UserData` in modo che sia `NodeLaunchTemplate` come segue
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
Se stai utilizzando `eksctl` per creare il gruppo di nodi, puoi usare il seguente comando.
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **Gestito**: implementare il gruppo di nodi utilizzando una delle opzioni seguenti:
+ **Senza un modello di avvio o con un modello di avvio senza un ID AMI specificato**: completare la procedura in [Create a managed node group for your cluster](create-managed-node-group.md). I gruppi di nodi gestiti calcolano automaticamente il valore massimo di `max-pods` consigliato da Amazon EKS.
+ **Con un modello di avvio con un ID AMI specificato** – nel modello di lancio, specificare un ID AMI ottimizzato per Amazon EKS o un’AMI personalizzata sviluppata con l’AMI ottimizzato Amazon EKS, quindi [implementare il gruppo di nodi utilizzando un modello di avvio](launch-templates.md) e fornire i seguenti dati utente nel modello di avvio. Questi dati utente passano un `NodeConfig` oggetto che deve essere letto dallo `nodeadm` strumento sul nodo. Per ulteriori informazioni in merito`nodeadm`, consulta [la documentazione di nodeadm.](https://awslabs.github.io/amazon-eks-ami/nodeadm)
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
Se stai utilizzando `eksctl` per creare il gruppo di nodi, puoi usare il seguente comando.
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Se hai creato un’AMI personalizzata che non è stata sviluppata con quella ottimizzata per Amazon EKS, devi creare autonomamente la configurazione.
**Nota**
Se desideri assegnare anche indirizzi IP ai Pod di una sottorete diversa da quella dell’istanza, devi abilitare la funzionalità in questa Passaggio. Per ulteriori informazioni, consulta [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md).
### Windows
1. Abilita l’assegnazione di prefissi IP.
1. Apri `amazon-vpc-cni` `ConfigMap` per la modifica.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Aggiungi la seguente riga al file `data`:
```
enable-windows-prefix-delegation: "true"
```
1. Salva il file e chiudi l’editor.
1. Accertati che la riga sia stata aggiunta a `ConfigMap`.
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
Se l’output restituito non è `true`, potrebbe essersi verificato un errore. Prova a completare di nuovo il passaggio.
**Importante**
Anche se la sottorete dispone di indirizzi IP disponibili, se non dispone di blocchi `/28` contigui disponibili, vedrai il seguente errore nei log del plug-in di Amazon VPC CNI per Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Ciò può verificarsi a causa della frammentazione degli indirizzi IP secondari esistenti distribuiti in una sottorete. Per risolvere questo errore, crea una nuova sottorete e avvia i Pod lì oppure utilizza una prenotazione CIDR di EC2 subnet Amazon per riservare spazio all'interno di una sottorete da utilizzare con l'assegnazione del prefisso. Per ulteriori informazioni, consulta la sezione relativa a [Prenotazioni della CIDR per la sottorete](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) nella Guida per l’utente di Amazon VPC.
1. (Facoltativo) Specifica una configurazione aggiuntiva per controllare il comportamento di prescalabilità e scalabilità dinamica del cluster. Per ulteriori informazioni, consulta [Opzioni di configurazione con](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md) la modalità di delega dei prefissi su Windows on. GitHub
1. Apri `amazon-vpc-cni` `ConfigMap` per la modifica.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Sostituite i valori di esempio con un valore maggiore di zero e aggiungete le voci necessarie alla `data` sezione di. `ConfigMap` Se imposti un valore per `warm-ip-target` o `minimum-ip-target`, il valore sostituisce qualsiasi valore impostato per `warm-prefix-target`.
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. Salva il file e chiudi l’editor.
1. Crea gruppi di nodi Windows con almeno un tipo di istanza Amazon EC2 Nitro. Per un elenco dei tipi di istanze Nitro, consulta [Istanze costruite sul sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) nella Amazon EC2 User Guide. Per impostazione predefinita, il numero massimo di Pod che è possibile distribuire su un nodo è pari a 110. Se vuoi aumentare o diminuire questo numero, specifica quanto segue nei dati utente per la configurazione di bootstrap. Sostituisci *max-pods-quantity* con il tuo valore di pod massimo.
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
Se si sta implementando gruppi di nodi gestiti, questa configurazione deve essere aggiunta nel modello di avvio. Per ulteriori informazioni, consulta [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md). Per ulteriori informazioni sui parametri di configurazione dello script bootstrap di Windows, consultare [Parametri di configurazione dello script di bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Determinare il numero massimo di pod e gli indirizzi IP disponibili
1. Dopo aver implementato i nodi, visualizzare i nodi del cluster.
```
kubectl get nodes
```
Di seguito viene riportato un output di esempio:
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. Descrivi uno dei nodi per determinare il valore di `max-pods` per il nodo e il numero di indirizzi IP disponibili. Sostituisci *192.168.30.193* con l'indirizzo `IPv4` nel nome di uno dei tuoi nodi restituiti nell'output del passaggio precedente.
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
Di seguito viene riportato un output di esempio.
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
Nell'output precedente, `110` è il numero massimo di Pod che Kubernetes distribuirà sul nodo, anche se gli indirizzi IP sono disponibili. *144*
# Assegnazione dei gruppi di sicurezza ai singoli pod
**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
È 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
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
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
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 <sample-application.yaml <
my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal
```
**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.
```
Welcome to nginx!
[...]
```
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
```
# Collegamento di interfacce di rete multiple ai pod
Per impostazione predefinita, il plugin CNI di Amazon VPC assegna un indirizzo IP a ciascun pod. Questo indirizzo IP è collegato a un’*interfaccia di rete elastica* che gestisce tutto il traffico in entrata e in uscita per il pod. Per aumentare le prestazioni della larghezza di banda e della velocità di pacchetti al secondo, è possibile utilizzare la *funzionalità Multi-NIC* di CNI di VPC per configurare un pod multi-homed. Un pod multi-homed è un singolo pod Kubernetes che utilizza più interfacce di rete (e più indirizzi IP). Eseguendo un pod multi-homed, è possibile distribuire il traffico delle applicazioni su più interfacce di rete utilizzando connessioni simultanee. Ciò è particolarmente utile per i casi d’uso di intelligenza artificiale (IA), machine learning (ML) e calcolo ad alte prestazioni (HPC).
Il diagramma seguente mostra un pod multi-homed in esecuzione su un nodo di lavoro con più schede di interfaccia di rete () in uso. NICs
![\[Un pod multi-homed con due interfacce di rete collegate, un’interfaccia di rete con ENA e un’interfaccia di rete con ENA ed EFA\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/images/multi-homed-pod.png)
## Contesto
Su Amazon EC2, un'*interfaccia di rete elastica* è un componente di rete logico in un VPC che rappresenta una scheda di rete virtuale. Per molti tipi di EC2 istanze, le interfacce di rete condividono una singola scheda di interfaccia di rete (NIC) nell'hardware. Questa singola NIC ha una larghezza di banda e una velocità massime di pacchetti al secondo.
Se la funzionalità Multi-NIC è abilitata, CNI di VPC non assegna gli indirizzi IP in blocco, come avviene per impostazione predefinita. Invece, CNI di VPC assegna un indirizzo IP a un’interfaccia di rete su ciascuna scheda di rete su richiesta all’avvio di un nuovo pod. Tale comportamento riduce la velocità di esaurimento degli indirizzi IP, che è aumentata usando pod multi-homed. Poiché la CNI di VPC assegna l’indirizzo IP su richiesta, l’avvio dei pod potrebbe richiedere più tempo sulle istanze con la funzionalità multi-NIC abilitata.
## Considerazioni
+ Assicurati che sul tuo cluster Kubernetes sia in esecuzione la versione `1.20.0` CNI di VPC e successive. La funzionalità multi-NIC è disponibile solo nella versione `1.20.0` o successiva di CNI di VPC.
+ Abilita la variabile di ambiente `ENABLE_MULTI_NIC` nel plugin CNI di VPC. È possibile eseguire il comando seguente per impostare la variabile e avviare una distribuzione di DaemonSet.
+ `kubectl set env daemonset aws-node -n kube-system ENABLE_MULTI_NIC=true`
+ Assicuratevi di creare nodi di lavoro con più schede di interfaccia di rete (NICs). Per un elenco di EC2 istanze con più schede di interfaccia di rete, consulta Schede [di rete](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) nella **Amazon EC2 User Guide**.
+ Se la funzionalità Multi-NIC è abilitata, CNI di VPC non assegna gli indirizzi IP in blocco, come avviene per impostazione predefinita. Poiché la CNI di VPC assegna l’indirizzo IP su richiesta, l’avvio dei pod potrebbe richiedere più tempo sulle istanze con la funzionalità multi-NIC abilitata. Per ulteriori informazioni, consulta la sezione [Contesto](#pod-multi-nic-background) precedente.
+ Con la funzionalità multi-NIC abilitata, per impostazione predefinita i pod non dispongono di più interfacce di rete. È necessario configurare ciascun carico di lavoro per utilizzare multi-NIC. Aggiungi l’annotazione `k8s.amazonaws.com/nicConfig: multi-nic-attachment` ai carichi di lavoro che dovrebbero avere più interfacce di rete.
### Considerazioni su `IPv6`
+ **Policy IAM personalizzata**: per i cluster `IPv6`, crea e utilizza la seguente policy IAM personalizzata per CNI di VPC. Questa policy è specifica per multi-NIC. Per informazioni più generali sull’utilizzo di CNI di VPC con i cluster `IPv6`, consulta [Scopri IPv6 gli indirizzi di cluster, pod e servizi](cni-ipv6.md).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSCNIPolicyIPv6MultiNIC",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeInstances",
"ec2:AssignIpv6Addresses",
"ec2:DetachNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstanceTypes",
"ec2:UnassignIpv6Addresses",
"ec2:AttachNetworkInterface",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSCNIPolicyENITagIPv6MultiNIC",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:network-interface/*"
}
]
}
```
+ `IPv6` **Meccanismo di transizione non disponibile**: se si utilizza la funzionalità multi-NIC, CNI di VPC non assegna un indirizzo `IPv4` ai pod di un cluster `IPv6`. Altrimenti, CNI di VPC assegna un indirizzo `IPv4` host locale a ciascun pod in modo che un pod possa comunicare con risorse esterne `IPv4` in un altro Amazon VPC o su Internet.
## Utilizzo
Dopo aver abilitato la funzionalità multi-NIC nel CNI di VPC e riavviato i pod `aws-node`, è possibile configurare ciascun carico di lavoro in modo che sia multi-homed. Il seguente esempio di una configurazione YAML con l’annotazione richiesta:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-deployment
namespace: ecommerce
labels:
app: orders
spec:
replicas: 3
selector:
matchLabels:
app: orders
template:
metadata:
annotations:
k8s.amazonaws.com/nicConfig: multi-nic-attachment
labels:
app: orders
spec:
...
```
## Domande frequenti
### **1. Cos’è una scheda di interfaccia di rete (NIC)?**
Una scheda di interfaccia di rete (NIC), chiamata anche semplicemente scheda di rete, è un dispositivo fisico che consente la connettività di rete per l’hardware di cloud computing sottostante. Nei EC2 server moderni, questo si riferisce alla scheda di rete Nitro. Un’interfaccia di rete elastica (ENI) è una rappresentazione virtuale di questa scheda di rete sottostante.
Alcuni tipi di EC2 istanza ne hanno più di uno NICs per aumentare le prestazioni in termini di larghezza di banda e velocità dei pacchetti. In questi casi, è possibile assegnare schede di rete secondarie ENIs alle schede di rete aggiuntive. Ad esempio, ENI \$11 può funzionare come interfaccia per la NIC collegata all’indice 0 della scheda di rete, mentre ENI \$12 può funzionare come interfaccia per la NIC collegata a un indice di schede di rete separato.
### **2. Cos’è un pod multi-homed?**
Un pod multi-homed è un singolo pod Kubernetes con più interfacce di rete (e per implicazione più indirizzi IP). Ogni interfaccia di rete pod è associata a un'[interfaccia di rete elastica (ENI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) e si ENIs tratta di rappresentazioni logiche di separate NICs sul nodo di lavoro sottostante. Con più interfacce di rete, un pod multi-homed ha una capacità di trasferimento dati aggiuntiva, che aumenta anche la velocità di trasferimento dei dati.
**Importante**
Il VPC CNI può configurare pod multihomed solo su tipi di istanza che ne hanno più di uno. NICs
### **3. Qual è il vantaggio di utilizzare questa funzionalità?**
Se è necessario scalare le prestazioni di rete nei carichi di lavoro basati su Kubernetes, è possibile utilizzare la funzionalità Multi-NIC per eseguire pod multihomed che si interfacciano con tutti i dispositivi sottostanti NICs a cui è collegato un dispositivo ENA. L’utilizzo di schede di rete aggiuntive aumenta la capacità di larghezza di banda e le prestazioni di velocità di pacchetti nelle applicazioni distribuendo il traffico delle applicazioni su più connessioni simultanee. Ciò è particolarmente utile per i casi d’uso di intelligenza artificiale (IA), machine learning (ML) e calcolo ad alte prestazioni (HPC).
### **4. Come posso utilizzare questa funzionalità?**
1. Innanzitutto, è necessario assicurarsi che il proprio cluster Kubernetes utilizzi versione 1.20 o successiva di CNI di VPC. Per i passaggi per aggiornare CNI di VPC come componente aggiuntivo EKS, consulta [Aggiornamento di CNI di Amazon VPC (componente aggiuntivo Amazon EKS)](vpc-add-on-update.md).
1. Quindi, è necessario abilitare il supporto multi-NIC nel CNI di VPC usando la variabile di ambiente `ENABLE_MULTI_NIC`.
1. Quindi, è necessario assicurarsi di creare e unire nodi con più schede di rete. Per un elenco di tipi di EC2 istanze con più schede di rete, consulta [Schede di rete](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) nella *Amazon EC2 User Guide*.
1. Infine, configura ciascun carico di lavoro per utilizzare più interfacce di rete (pod multi-homed) o utilizza un’unica interfaccia di rete.
### **5. Come posso configurare i miei carichi di lavoro per utilizzarne più di uno NICs su un nodo di lavoro supportato?**
Per utilizzare i pod multi-homed, è necessario aggiungere la seguente annotazione: `k8s.amazonaws.com/nicConfig: multi-nic-attachment`. Ciò collegherà un ENI da ogni NIC dell'istanza sottostante al pod (mappatura uno a più tra un pod e il NICs).
Se manca questa annotazione, CNI di VPC presuppone che il pod richieda solo 1 interfaccia di rete e gli assegna un IP da un’ENI su qualsiasi NIC disponibile.
### **6. Quali adattatori di interfaccia di rete sono supportati da questa funzionalità?**
È possibile utilizzare qualsiasi adattatore di interfaccia di rete se si dispone di almeno un ENA collegato alla scheda di rete sottostante per il traffico IP. Per ulteriori informazioni su ENA, consulta [Elastic Network Adapter (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) nella *Amazon EC2 User Guide*.
Configurazioni dei dispositivi di rete supportate:
+ Le interfacce **ENA** offrono tutte le tradizionali funzionalità di rete e routing IP necessarie per supportare la rete IP per un VPC. Per ulteriori informazioni, consulta [Abilita reti avanzate con ENA sulle tue EC2 istanze.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)
+ Le interfacce **EFA** **(EFA** **con ENA)** offrono sia il dispositivo ENA per le reti IP che il dispositivo EFA per le comunicazioni a bassa latenza e a throughput elevato.
**Importante**
Se a una scheda di rete è collegato un adattatore **solo EFA**, il CNI di VPC lo ignorerà durante il provisioning della connettività di rete per un pod multi-homed. Tuttavia, se si combina un adattatore **solo EFA** con un adattatore **ENA** su una scheda di rete, il VPC CNI ENIs gestirà anche questo dispositivo. Per utilizzare interfacce solo EFA con i cluster EKS, consulta [Esecuzione dei corsi di machine learning su Amazon EKS con Elastic Fabric Adapter](node-efa.md).
### **7. Posso vedere se un nodo del mio cluster supporta ENA?**
Sì, puoi utilizzare la AWS CLI o l' EC2 API per recuperare informazioni di rete su un' EC2 istanza nel tuo cluster. Ciò fornisce dettagli sul fatto che l’istanza disponga o meno del supporto ENA. Nell'esempio seguente, sostituiscilo `` con l'ID di EC2 istanza di un nodo.
AWS Esempio di CLI:
```
aws ec2 describe-instances --instance-ids --query "Reservations[].Instances[].EnaSupport"
```
Output di esempio:
```
[ true ]
```
### **8. Posso vedere i diversi indirizzi IP associati a un pod?**
No, non è semplice. Tuttavia, è possibile utilizzare `nsenter` dal nodo per eseguire strumenti di rete comuni come `ip route show` e visualizzare gli indirizzi IP e le interfacce aggiuntivi.
### **9. Posso controllare il numero di interfacce di rete per i miei pod?**
No. Quando il carico di lavoro è configurato per utilizzarne più di uno NICs su un'istanza supportata, un singolo pod ha automaticamente un indirizzo IP da ogni scheda di rete dell'istanza. In alternativa, i pod single-homed avranno un’interfaccia di rete collegata a una NIC sull’istanza.
**Importante**
Le schede di rete a cui è collegato *solo* un dispositivo **solo EFA** sono ignorate da CNI di VPC.
### **10. Posso configurare i miei pod per utilizzare una scheda NIC specifica?**
No, questa funzionalità non è supportata. Se un pod ha l’annotazione pertinente, CNI di VPC lo configura automaticamente per utilizzare ogni NIC con un adattatore ENA sul nodo worker.
### **11. Questa funzionalità funziona con le altre funzionalità di rete di CNI di VPC?**
Sì, la funzionalità multi-NIC di CNI di VPC funziona sia con *reti personalizzate* che con *la rilevazione avanzata delle sottoreti*. Tuttavia, i pod multi-homed non utilizzano sottoreti o gruppi di sicurezza personalizzati. Invece, CNI di VPC assegna indirizzi IP e interfacce di rete ai pod multi-homed con la stessa configurazione di sottorete e gruppo di sicurezza del nodo. Per ulteriori informazioni sulle reti personalizzate, consulta [Implementazione dei pod in sottoreti alternative con reti personalizzate](cni-custom-network.md).
La funzionalità multi-NIC di CNI di VPC non funziona e non può essere combinata *con i gruppi di sicurezza per i pod*.
### **12. Posso utilizzare le politiche di rete con questa funzionalità?**
Sì, è possibile utilizzare le policy di rete Kubernetes con multi-NIC. Le policy di rete Kubernetes limitano il traffico di rete verso e dai pod. Per ulteriori informazioni sull’applicazione delle policy di rete con CNI di VPC, consulta [Limita il traffico di Pod con le policy di rete di Kubernetes](cni-network-policy.md).
### **13. Il supporto multi-NIC è abilitato in modalità automatica EKS?**
La multi-NIC non è supportata per i cluster in modalità automatica EKS.