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à.
# Esecuzione di cluster EKS IPv6
EKS in modalità IPv6 risolve il problema dell'esaurimento dell'IPv4 che spesso si manifesta nei cluster EKS su larga scala. Il supporto di EKS per IPv6 è focalizzato sulla risoluzione del problema dell'esaurimento dell'IPv4, che deriva dalla dimensione limitata dello spazio degli indirizzi IPv4. Si tratta di una preoccupazione significativa sollevata da alcuni dei nostri clienti ed è distinta da Kubernetes [IPv4/IPv6 dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) caratteristica. EKS/IPv6 fornirà inoltre la flessibilità necessaria per interconnettere i confini della rete utilizzando CIDR IPv6, riducendo così al minimo le possibilità di sovrapposizione dei CIDR e risolvendo così un duplice problema (In-Cluster, Cross-Cluster). Quando si distribuiscono cluster EKS in modalità IPv6 (--ip-family ipv6), l'azione non è reversibile. In parole semplici, il supporto EKS IPv6 è abilitato per l'intera durata del cluster.
[](https://www.youtube.com/watch?v=zdXpTT0bZXo?rel=0)
In un cluster EKS IPv6, Pods and Services riceveranno indirizzi IPv6 mantenendo la compatibilità con gli endpoint IPv4 precedenti. Ciò include la possibilità per gli endpoint IPv4 esterni di accedere ai servizi del cluster e per i Pods di accedere agli endpoint IPv4 esterni.
Il supporto IPv6 di Amazon EKS sfrutta le funzionalità IPv6 native di VPC. Ogni VPC è allocato con un prefisso di indirizzo IPv4 (la dimensione del blocco CIDR può essere compresa tra /16 e /28) e un prefisso di indirizzo IPv6 /56 univoco (fisso) all'interno del GUA (Global Unicast Address) di Amazon; puoi assegnare un prefisso di indirizzo /64 a ciascuna sottorete del tuo VPC. Le funzionalità IPv4, come le tabelle di routing, gli elenchi di controllo degli accessi alla rete, il peering e la risoluzione DNS, funzionano allo stesso modo in un VPC abilitato per IPv6. Il VPC viene quindi definito VPC dual-stack, seguendo le sottoreti dual-stack. Il diagramma seguente illustra il modello di base del VPC IPv4/IPv6 che supporta EKS/IPv6 cluster basati:
Nel mondo IPv6, ogni indirizzo è instradabile su Internet. Per impostazione predefinita, VPC alloca il CIDR IPv6 dall'intervallo GUA pubblico. Tuttavia, dal momento che [agosto 2024](https://aws.amazon.com/about-aws/whats-new/2024/08/aws-private-ipv6-addressing-vpcs-subnets/) puoi anche utilizzare un indirizzamento IPv6 privato per VPC e sottoreti con Amazon VPC IP Address Manager (IPAM). Consulta il [questo post sul blog di AWS Networking](https://aws.amazon.com/blogs/networking-and-content-delivery/understanding-ipv6-addressing-on-aws-and-designing-a-scalable-addressing-plan) e [documentazione VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#vpc-ipv6-addresses) per ulteriori informazioni.
Il diagramma seguente illustra un flusso di uscita Internet IPv6 di un Pod all'interno di un EKS/IPv6 cluster:
Le migliori pratiche per l'implementazione delle sottoreti IPv6 sono disponibili in [Guida per l'utente di VPC](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/IPv6-on-AWS.html).
In un cluster EKS IPv6, nodi e pod ricevono indirizzi IPv6 pubblici. EKS assegna gli indirizzi IPv6 ai servizi in base agli indirizzi Unique Local IPv6 Unique Local Unique Unicast Address (ULA). Il CIDR del servizio ULA per un cluster IPv6 viene assegnato automaticamente durante la fase di creazione del cluster e non può essere specificato, a differenza di IPv4. Il diagramma seguente illustra un EKS/IPv6 modello di base del piano dati basato sul piano di controllo del cluster:
## Panoramica di
EKS/IPv6 è supportato solo in modalità prefisso (VPC-CNI Plug-in modalità di assegnazione IP ENI). Scopri di più su [Modalità prefisso](prefix-mode-linux.md).
L'assegnazione del prefisso funziona solo su Nitro-based Istanze EC2, quindi EKS/IPv6 è supportato solo quando il piano dati del cluster utilizza EC2 Nitro-based istanze.
In parole semplici un prefisso IPv6 di /80 (per nodo di lavoro) produrrà \~10^14 indirizzi IPv6, il fattore limitante non sarà più gli IP ma la densità dei Pod (dal punto di vista delle risorse).
L'assegnazione del prefisso IPv6 avviene solo al momento del bootstrap del nodo di lavoro EKS. Questo comportamento è noto per mitigare gli scenari in cui un elevato tasso di abbandono dei Pod EKS/IPv4 i cluster sono spesso ritardati nella pianificazione dei Pod a causa della limitazione delle chiamate API generate dal plug-in VPC CNI (ipamd) volto ad allocare indirizzi IPv4 privati in modo tempestivo. È anche noto per creare VPC-CNI ottimizzazione avanzata delle manopole tramite plug-in [WARM\_IP/ENI*, MINIMUM\_IP*](https://github.com/aws/amazon-vpc-cni-k8s#warm_ip_target) inutilmente.
Il diagramma seguente ingrandisce un'interfaccia di rete elastica (ENI) con nodo di lavoro IPv6:
A ogni nodo di lavoro EKS vengono assegnati indirizzi IPv4 e IPv6, insieme alle corrispondenti voci DNS. Per un determinato nodo di lavoro, viene utilizzato un solo indirizzo IPv4 dalla sottorete dual-stack. Il supporto EKS per IPv6 consente di comunicare con gli endpoint IPv4 (AWS, on-premise, Internet) attraverso un modello IPv4 solo in uscita molto avanzato. EKS implementa un plug-in CNI locale sull'host, secondario al plug-in VPC CNI, che alloca e configura un indirizzo IPv4 per un Pod. Il plugin CNI configura un indirizzo IPv4 non instradabile specifico dell'host per un Pod a partire dal 169.254.172.0/22 intervallo. L'indirizzo IPv4 assegnato al Pod è *univoco per il worker-node* ed è *non pubblicizzato oltre il worker-node*. 169.254.172.0/22 fornisce fino a 1024 indirizzi IPv4 univoci in grado di supportare tipi di istanze di grandi dimensioni.
Il diagramma seguente illustra il flusso di un Pod IPv6 che si connette a un endpoint IPv4 al di fuori dei confini del cluster (non Internet):
Nel diagramma sopra riportato, Pods eseguirà una ricerca DNS per l'endpoint e, dopo aver ricevuto una risposta IPv4 «A», l'indirizzo IPv4 univoco di Pod (solo nodo) viene tradotto tramite la traduzione degli indirizzi di rete di origine (SNAT) nell'indirizzo IPv4 privato (VPC) dell'interfaccia di rete primaria collegata all'EC2 Worker-node.
**Nota**
Lo schema precedente richiede che DNS64 sia disabilitato nelle sottoreti in cui EKS/IPv6 I pod sono in esecuzione. Quando DNS64 è abilitato, il resolver DNS restituisce un indirizzo IPv6 sintetizzato per IPv4-only endpoint insieme a un indirizzo IPv4. Di conseguenza, il traffico viene indirizzato attraverso la funzionalità NAT64 del NAT Gateway (se inclusa nell'architettura) invece di rimanere all'interno del VPC come mostrato nello schema precedente. Ciò può comportare un utilizzo imprevisto del NAT Gateway e i relativi costi.
EKS/IPv6 I pod dovranno inoltre connettersi agli endpoint IPv4 su Internet utilizzando indirizzi IPv4 pubblici, per ottenere un flusso simile. Il diagramma seguente illustra il flusso di un pod IPv6 che si connette a un endpoint IPv4 al di fuori dei confini del cluster (instradabile via Internet):
Nel diagramma sopra riportato, Pods eseguirà una ricerca DNS per l'endpoint e, dopo aver ricevuto una risposta IPv4 «A», l'indirizzo IPv4 univoco di Pod (solo nodo) viene tradotto tramite la traduzione degli indirizzi di rete di origine (SNAT) nell'indirizzo IPv4 privato (VPC) dell'interfaccia di rete primaria collegata all'EC2 Worker-node. L'indirizzo IPv4 del pod (IPv4 di origine: IP primario EC2) viene quindi indirizzato al gateway NAT IPv4 dove l'IP primario EC2 viene tradotto (SNAT) in un indirizzo IP pubblico IPv4 instradabile su Internet valido (IP pubblico assegnato dal gateway NAT).
Qualsiasi Pod-to-Pod la comunicazione tra i nodi utilizza sempre un indirizzo IPv6. VPC CNI configura iptables per gestire IPv6 bloccando qualsiasi connessione IPv4.
I servizi Kubernetes riceveranno solo indirizzi IPv6 (ClusterIP) da Unique [Indirizzi Unicast IPv6 locali (ULA)](https://datatracker.ietf.org/doc/html/rfc4193). Il CIDR del servizio ULA per un cluster IPv6 viene assegnato automaticamente durante la fase di creazione del cluster EKS e non può essere modificato. Il diagramma seguente illustra il flusso da Pod a Kubernetes Service:
I servizi sono esposti a Internet utilizzando un sistema di bilanciamento del carico AWS. Il load balancer riceve indirizzi IPv4 e IPv6 pubblici, noti anche come load balancer dual-stack. Per i client IPv4 che accedono ai servizi kubernetes del cluster IPv6, il load balancer esegue la conversione da IPv4 a IPv6.
Amazon EKS consiglia di eseguire nodi di lavoro e pod in sottoreti private. Puoi creare sistemi di bilanciamento del carico pubblici nelle sottoreti pubbliche che bilanciano il traffico verso i Pods in esecuzione su nodi che si trovano in sottoreti private. Il diagramma seguente illustra un utente Internet IPv4 che accede a un EKS/IPv6 Servizio basato su Ingress:
**Nota**
Il modello precedente richiede l'implementazione di [versione più recente](https://kubernetes-sigs.github.io/aws-load-balancer-controller) del controller di bilanciamento del carico AWS
### Comunicazione EKS Control Plane Data Plane
EKS provvederà Cross-Account ENI (X-ENIs) in modalità dual stack (IPv4/IPv6). I componenti dei nodi Kubernetes come kubelet e kube-proxy sono configurati per supportare il dual stack. Kubelet e kube-proxy vengono eseguiti in modalità HostNetwork e si collegano agli indirizzi IPv4 e IPv6 collegati all'interfaccia di rete primaria di un nodo. L'api-server Kubernetes comunica con i Pods e i componenti del nodo tramite X-ENIs è basato su IPv6. I pod comunicano con gli api-server tramite X-ENIse la comunicazione da pod a api-server utilizza sempre la modalità IPv6.
## Raccomandazioni
### Pianificazione basata sulle risorse di calcolo
Un singolo prefisso IPv6 è sufficiente per eseguire più pod su un singolo nodo. Ciò rimuove efficacemente anche le limitazioni ENI e IP sul numero massimo di Pod su un nodo. Sebbene l'IPv6 elimini la dipendenza diretta dai Max-pods, quando si utilizzano allegati di prefisso con tipi di istanza più piccoli come m5.large, è probabile che si esauriscano le risorse di CPU e memoria dell'istanza molto prima di esaurirne gli indirizzi IP. È necessario impostare manualmente il valore Pod massimo consigliato da EKS se si utilizzano gruppi di nodi autogestiti o un gruppo di nodi gestiti con un ID AMI personalizzato.
È possibile utilizzare la seguente formula per determinare il numero massimo di Pod che è possibile distribuire su un nodo per un cluster EKS IPv6.
```
((Number of network interfaces for instance type (number of prefixes per network interface-1)* 16) + 2
```
```
((3 ENIs)_((10 secondary IPs per ENI-1)_ 16)) + 2 = 460 (real)
```
I gruppi di nodi gestiti calcolano automaticamente il numero massimo di Pod per te. Evita di modificare il valore consigliato da EKS per il numero massimo di Pod per evitare errori di pianificazione dei Pod dovuti alla limitazione delle risorse.
### Valuta lo scopo della rete personalizzata esistente
Se [rete personalizzata](https://docs.aws.amazon.com/eks/latest/best-practices/custom-networking.html) è attualmente abilitato, Amazon EKS consiglia di rivalutarne le necessità con IPv6. Se hai scelto di utilizzare una rete personalizzata per risolvere il problema dell'esaurimento dell'IPv4, con IPv6 non è più necessario. Se si utilizza una rete personalizzata per soddisfare un requisito di sicurezza, ad esempio una rete separata per nodi e pod, si consiglia di inviare un [Richiesta di roadmap EKS](https://github.com/aws/containers-roadmap/issues).
### Fargate Pods in EKS/IPv6 Grappolo
EKS supporta l'IPv6 per i Pods in esecuzione su Fargate. I pod in esecuzione su Fargate consumeranno indirizzi IPv6 e VPC Routable Private IPv4 ricavati dagli intervalli VPC CIDR (IPv4IPv6). In parole semplici, il tuo EKS/Fargate L'ampia densità del cluster Pods sarà limitata agli indirizzi IPv4 e IPv6 disponibili. Si consiglia di dimensionare il dual-stack subnets/VPC CIDR per la crescita futura. Non sarà possibile pianificare nuovi Fargate Pod se la sottorete sottostante non contiene un indirizzo IPv4 disponibile, indipendentemente dagli indirizzi IPv6 disponibili.
### Distribuisci AWS Load Balancer Controller (LBC)
**Il controller di servizio Kubernetes in-tree upstream non supporta IPv6**. Si consiglia di utilizzare [versione più recente](https://kubernetes-sigs.github.io/aws-load-balancer-controller) del componente aggiuntivo AWS Load Balancer Controller. L'LBC distribuirà un NLB dual-stack o un ALB dual-stack solo dopo aver utilizzato i corrispondenti kubernetes service/ingress definizione annotata con: `"alb.ingress.kubernetes.io/ip-address-type: dualstack"` e `"alb.ingress.kubernetes.io/target-type: ip"`