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 si manifesta spesso nei cluster EKS su larga scala. Il supporto di EKS per IPv6 è incentrato sulla risoluzione del problema dell'esaurimento dell'IPv4, che deriva dalle dimensioni limitate dello spazio degli indirizzi IPv4. Questa è una preoccupazione importante sollevata da alcuni nostri clienti ed è distinta dalla funzionalità dual-stack di Kubernetes. IPv4/IPv6
In un cluster EKS IPv6, Pods and Services riceveranno indirizzi IPv6 mantenendo la compatibilità con gli endpoint IPv4 legacy. Ciò include la possibilità per gli endpoint IPv4 esterni di accedere ai servizi all'interno del cluster e i Pod di accedere agli endpoint IPv4 esterni.
Il supporto IPv6 di Amazon EKS sfrutta le funzionalità VPC IPv6 native. 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) dall'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 denominato VPC dual-stack, seguendo le sottoreti dual-stack, il diagramma seguente illustra il modello di base VPC IPv4IPv6 che supporta i cluster basati: EKS/IPv6
Nel mondo IPv6, ogni indirizzo è instradabile su Internet. Per impostazione predefinita, VPC alloca il CIDR IPv6 dall'intervallo GUA pubblico. Tuttavia, dall'agosto 2024
Il diagramma seguente mostra un flusso di uscita Internet Pod IPv6 all'interno di un cluster: EKS/IPv6
In un cluster EKS IPv6, i nodi e i Pod ricevono indirizzi IPv6 pubblici. EKS assegna gli indirizzi IPv6 ai servizi basati su indirizzi unicast IPv6 locali univoci (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 uno schema di base del piano dati del piano di controllo del cluster basato sul piano di controllo del cluster EKS/IPv6 :
Panoramica di
EKS/IPv6 è supportato solo in modalità prefisso (modalità VPC-CNI Plug-in ENI IP assign). Scopri di più sulla modalità Prefisso.
L'assegnazione del prefisso funziona solo sulle istanze Nitro-based EC2, quindi EKS/IPv6 è supportata solo quando il piano dati del cluster utilizza istanze EC2. Nitro-based
In parole semplici, un prefisso IPv6 di /80 (per worker-node) produrrà ~10^14 indirizzi IPv6, il fattore limitante non sarà più costituito dagli IP ma dalla densità dei pod (per quanto riguarda le risorse).
L'assegnazione del prefisso IPv6 avviene solo al momento del bootstrap del nodo di lavoro EKS. È noto che questo comportamento mitiga gli scenari in cui EKS/IPv4 i cluster high Pod churn subiscono spesso ritardi nella pianificazione dei Pod a causa delle chiamate API limitate generate dal plug-in VPC CNI (ipamd) volto ad allocare indirizzi IPv4 privati in modo tempestivo. È noto anche che il plug-in ottimizza inutilmente le manopole avanzate, MINIMUM_IP. VPC-CNI WARM_IP/ENI
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 voci DNS corrispondenti. Per un determinato nodo di lavoro, viene utilizzato solo un singolo indirizzo IPv4 dalla sottorete dual-stack. Il supporto EKS per IPv6 consente di comunicare con gli endpoint IPv4 (AWS, on-premise, Internet) tramite un modello IPv4 di sola uscita molto apprezzato. EKS implementa un plug-in CNI locale dell'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 routabile specifico dell'host per un Pod dal 169.254.172. 0/22 intervallo. L'indirizzo IPv4 assegnato al Pod è unico per il worker-node e non viene pubblicizzato oltre il worker-node. 169.254.172. 0/22 fornisce fino a 1024 indirizzi IPv4 unici 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 precedente Pods eseguirà una ricerca DNS per l'endpoint e, dopo aver ricevuto una risposta IPv4 «A», l'indirizzo IPv4 univoco di Pod solo per i nodi viene tradotto tramite la traduzione degli indirizzi di rete di origine (SNAT) all'indirizzo IPv4 privato (VPC) dell'interfaccia di rete principale collegata all'EC2. Worker-node
Nota
Lo schema precedente richiede che DNS64 sia disabilitato EKS/IPv6 nelle sottoreti in cui sono in esecuzione i Pod. Quando DNS64 è abilitato, il resolver DNS restituisce un indirizzo IPv6 sintetizzato per gli endpoint insieme a un indirizzo IPv4. IPv4-only Di conseguenza, il traffico passa attraverso la funzionalità NAT64 del gateway NAT (se inclusa nell'architettura) anziché rimanere all'interno del VPC come mostrato nello schema precedente. Ciò può comportare un utilizzo imprevisto del gateway NAT e i costi associati.
EKS/IPv6 I pod dovranno inoltre connettersi agli endpoint IPv4 su Internet utilizzando indirizzi IPv4 pubblici, per far sì che esista un flusso simile. Il diagramma seguente illustra il flusso di un Pod IPv6 che si connette a un endpoint IPv4 all'esterno dei confini del cluster (instradabile su Internet):
Nel diagramma precedente Pods eseguirà una ricerca DNS per l'endpoint e, dopo aver ricevuto una risposta IPv4 «A», l'indirizzo IPv4 univoco di Pod solo per i nodi viene tradotto tramite la traduzione degli indirizzi di rete di origine (SNAT) all'indirizzo IPv4 privato (VPC) dell'interfaccia di rete principale collegata all'EC2. Worker-node L'indirizzo IPv4 del pod (origine IPv4: 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 al gateway NAT).
Qualsiasi comunicazione tra i Pod-to-Pod 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 indirizzi Unicast IPv6 locali univoci (ULA).
I servizi sono esposti a Internet utilizzando un sistema di bilanciamento del carico AWS. Il load balancer riceve indirizzi IPv4 e IPv6 pubblici, ovvero un sistema di bilanciamento del carico dual-stack. Per i client IPv4 che accedono ai servizi Kubernetes del cluster IPv6, il sistema di bilanciamento del carico esegue la traduzione da IPv4 a IPv6.
Amazon EKS consiglia di eseguire nodi di lavoro e pod in sottoreti private. Puoi creare bilanciatori di carico pubblici nelle sottoreti pubbliche che bilanciano il carico del traffico verso i Pod in esecuzione su nodi che si trovano in sottoreti private. Il diagramma seguente mostra un utente Internet IPv4 che accede a un servizio basato su Ingress: EKS/IPv6
Nota
Lo schema sopra riportato richiede la distribuzione della versione più recente
EKS Control Plane (comunicazione Data Plane)
EKS fornirà Cross-Account eNIS (X-ENIs) in modalità dual stack (IPv4/IPv6). I componenti del nodo 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 a indirizzi IPv4 e IPv6 collegati all'interfaccia di rete principale di un nodo. L'api-server Kubernetes comunica con i Pod e i componenti del nodo tramite IPv6. X-ENIs I pod comunicano con i server API tramite e la comunicazione tra Pod e server API utilizza sempre la modalità IPv6. X-ENIs
Raccomandazioni
Pianificazione basata sulle risorse di calcolo
Un singolo prefisso IPv6 è sufficiente per eseguire molti Pod su un singolo nodo. Ciò rimuove efficacemente anche le limitazioni ENI e IP sul numero massimo di Pod su un nodo. Sebbene IPv6 rimuova la dipendenza diretta dai Max-Pods, quando si utilizzano allegati di prefisso con tipi di istanze 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. 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 la rete personalizzata è attualmente abilitata, Amazon EKS consiglia di rivalutarne le esigenze con IPv6. Se hai scelto di utilizzare reti personalizzate per risolvere il problema dell'esaurimento dell'IPv4, non è più necessario con IPv6. Se utilizzate reti personalizzate per soddisfare un requisito di sicurezza, ad esempio una rete separata per nodi e pod, vi consigliamo di inviare una richiesta di roadmap EKS.
Cialde Fargate a grappolo EKS/IPv6
EKS supporta IPv6 per Pod in esecuzione su Fargate. I pod in esecuzione su Fargate utilizzeranno indirizzi IPv6 e VPC Routable Private IPv4 ricavati dagli intervalli CIDR VPC (). IPv4IPv6 In parole semplici, l'ampia densità del cluster EKS/Fargate Pods sarà limitata agli indirizzi IPv4 e IPv6 disponibili. Si consiglia di dimensionare i CIDR dual-stack per una subnets/VPC crescita futura. Non sarà possibile pianificare nuovi Fargate Pod se la sottorete sottostante non contiene un indirizzo IPv4 disponibile, indipendentemente dagli indirizzi IPv6 disponibili.
Implementa l'AWS Load Balancer Controller (LBC)
Il controller di servizio Kubernetes integrato a monte non supporta IPv6. Consigliamo di utilizzare la versione più recente del componente"alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
