**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à.
# 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, questi 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, creare una nuova sottorete e avviare i Pod lì oppure utilizzare una prenotazione CIDR sottorete Amazon EC2 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 gestiti con un modello di avvio in cui hai specificato un ID AMI, devi impostare il numero massimo di Pod per i tuoi nodi. Per ulteriori informazioni su come determinare il valore appropriato, consulta. [Come viene determinato MaxPods](choosing-instance-type.md#max-pods-precedence)
**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 [Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) nella Guida per l’utente di Amazon EC2. 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, creare una nuova sottorete e avviare i Pod lì oppure utilizzare una prenotazione CIDR sottorete Amazon EC2 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 la modalità di delega dei prefissi in Windows on](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md). 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. Creare gruppi di nodi di Windows con almeno un tipo di istanza Amazon EC2 Nitro. Per un elenco dei tipi di istanze Nitro, consultare [Instances built on the Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) nella Guida per l’utente di Amazon EC2. 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 *144* gli indirizzi IP sono disponibili.