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à.

IPv6 Esecuzione di cluster EKS

EKS in IPv6 mode risolve il problema dell' IPv4 esaurimento che si manifesta spesso nei cluster EKS su larga scala. Il supporto di EKS IPv6 si concentra sulla risoluzione del problema dell' IPv4 esaurimento, che deriva dalle dimensioni limitate dello spazio degli indirizzi. IPv4 Questa è una preoccupazione importante sollevata da alcuni dei nostri clienti ed è distinta dalla funzionalità IPv4 Kubernetes/dual-stack. IPv6 EKS/ IPv6 fornirà anche la flessibilità necessaria per interconnettere i confini di rete, riducendo così al minimo le possibilità di sovrapposizione CIDR e risolvendo IPv6 CIDRs così un problema duplice (In-Cluster, Cross-Cluster). Quando si distribuiscono i cluster EKS in modalità (--ip-family ipv6), l'azione non è reversibile. IPv6 In parole semplici, il IPv6 supporto EKS è abilitato per l'intera durata del cluster.

In un cluster IPv6 EKS, Pods and Services riceveranno IPv6 gli indirizzi mantenendo la compatibilità con gli IPv4 endpoint legacy. Ciò include la possibilità per gli IPv4 endpoint esterni di accedere ai servizi all'interno del cluster e i Pod di accedere agli endpoint esterni. IPv4

Il IPv6 supporto di Amazon EKS sfrutta le funzionalità IPv6 VPC native. A ogni VPC viene assegnato un prefisso di IPv4 indirizzo (la dimensione del blocco CIDR può essere compresa tra /16 e /28) e un prefisso di indirizzo /56 univoco (fisso) dall'interno del GUA (Global Unicast IPv6 Address) di Amazon; puoi assegnare un prefisso di indirizzo /64 a ciascuna sottorete del tuo VPC. IPv4 le funzionalità, 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 IPv6 VPC abilitato. Il VPC viene quindi denominato VPC dual-stack, seguendo le sottoreti dual-stack, il diagramma seguente illustra il modello di base VPC che supporta i cluster basati su EKS/: IPV4 IPv6 IPv6

Nel IPv6 mondo, ogni indirizzo è instradabile su Internet. Per impostazione predefinita, VPC alloca IPv6 CIDR dall'intervallo GUA pubblico. VPCs non supportano l'assegnazione di IPv6 indirizzi privati dall'intervallo di indirizzi locali univoci (ULA) come definito da RFC 4193 (fd00: :/8 o fc00: :/8). Questo è vero anche quando desideri assegnare un CIDR di tua proprietà. IPv6 L'uscita verso Internet dalle sottoreti private è supportata dall'implementazione di un gateway Internet di sola uscita (EIGW) in un VPC, che consente il traffico in uscita e blocca tutto il traffico in entrata. Il diagramma seguente mostra un flusso di uscita Internet Pod all'interno di un cluster EKS/: IPv6 IPv6

Le migliori pratiche per l'implementazione delle IPv6 sottoreti sono disponibili nella guida per l'utente di VPC.

In un cluster IPv6 EKS, i nodi e i Pod ricevono indirizzi pubblici. IPv6 EKS assegna IPv6 gli indirizzi ai servizi in base agli indirizzi Unicast Local IPv6 Unicast Unicast Unicast (ULA) unici. Il CIDR del servizio ULA per un IPv6 cluster viene assegnato automaticamente durante la fase di creazione del cluster e non può essere specificato, a differenza di. IPv4 Il diagramma seguente illustra un modello di base del piano dati del piano di controllo del cluster IPv6 basato su EKS/:

Panoramica

EKS/ IPv6 è supportato solo in modalità prefisso (modalità di assegnazione IP ENI del plug-in VPC-CNI). Scopri di più sulla modalità Prefix.

L'assegnazione del prefisso funziona solo su EC2 istanze basate su Nitro, quindi EKS/ IPv6 è supportato solo quando il piano dati del cluster utilizza istanze basate su Nitro. EC2

In parole semplici, un IPv6 prefisso di /80 (per worker-node) produrrà ~10^14 IPv6 indirizzi, il fattore limitante non sarà più che la densità dei pod (per quanto riguarda le risorse). IPs

IPv6 l'assegnazione del prefisso avviene solo al momento del bootstrap del nodo di lavoro EKS. È noto che questo comportamento mitiga gli scenari in cui i IPv4 cluster EKS/ EKS/ ad alto tasso di abbandono dei Pod subiscono spesso ritardi nella pianificazione dei Pod a causa delle chiamate API limitate generate dal plug-in VPC CNI (ipamd) volto ad allocare indirizzi privati in modo tempestivo. IPv4 È noto anche che le manopole avanzate del plug-in VPC-CNI regolano inutilmente WARM_IP/ENI, MINIMUM_IP.

Il diagramma seguente ingrandisce un'interfaccia di rete elastica (ENI) a nodi di lavoro: IPv6

A ogni nodo di lavoro EKS vengono assegnati IPv6 indirizzi IPv4 e voci DNS corrispondenti. Per un determinato nodo di lavoro, viene utilizzato un solo IPv4 indirizzo dalla sottorete dual-stack. Il supporto EKS per IPv6 consente di comunicare con gli IPv4 endpoint (AWS, on-premise, Internet) attraverso un modello di sola uscita molto apprezzato. IPv4 EKS implementa un plug-in CNI locale dell'host, secondario al plug-in VPC CNI, che alloca e configura un indirizzo per un Pod. IPv4 Il plugin CNI configura un indirizzo non routabile specifico dell'host per un Pod dell'intervallo 169.254.172.0/22. IPv4 L' IPv4 indirizzo 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 unici che possono supportare tipi di istanze di grandi dimensioni. IPv4

Il diagramma seguente mostra il flusso di un Pod che si connette a un endpoint esterno al confine del cluster (non Internet): IPv6 IPv4

Nel diagramma precedente Pods eseguirà una ricerca DNS per l'endpoint e, dopo aver ricevuto una risposta IPv4 «A», l' IPv4 indirizzo univoco del solo nodo di Pod viene tradotto tramite la traduzione degli indirizzi di rete di origine (SNAT) all'indirizzo privato IPv4 (VPC) dell'interfaccia di rete principale collegata al Worker-node. EC2

EKS/ IPv6 Pods dovrà inoltre connettersi agli IPv4 endpoint su Internet utilizzando indirizzi pubblici, per ottenere un flusso simile. IPv4 Il diagramma seguente illustra il flusso di un IPv6 Pod che si connette a un IPv4 endpoint esterno ai 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' IPv4 indirizzo univoco del solo nodo di Pod viene tradotto tramite la traduzione degli indirizzi di rete di origine (SNAT) all'indirizzo privato IPv4 (VPC) dell'interfaccia di rete principale collegata al Worker-node. EC2 L' IPv4 indirizzo Pod (origine IPv4: IP EC2 primario) viene quindi indirizzato IPv4 al gateway NAT dove l'IP EC2 primario viene tradotto (SNAT) in un indirizzo IP IPv4 pubblico instradabile su Internet valido (IP pubblico assegnato al gateway NAT).

Qualsiasi Pod-to-Pod comunicazione attraverso i nodi utilizza sempre un indirizzo. IPv6 VPC CNI configura iptables per gestire IPv6 mentre blocca qualsiasi connessione. IPv4

I servizi Kubernetes riceveranno solo indirizzi IPv6 (ClusterIP) da Unique Local Unicast Addresses (ULA). IPv6 Il CIDR del servizio ULA per un IPv6 cluster 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 IPv6 indirizzi IPv4 e indirizzi pubblici, ovvero un sistema di bilanciamento del carico dual-stack. Per IPv4 i client che accedono ai servizi IPv6 Kubernetes del cluster, il load balancer esegue la traduzione. IPv4 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 di Internet che accede a un servizio basato su EKS/ Ingress: IPv4 IPv6

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 entrambi gli indirizzi collegati all'interfaccia di rete principale di un nodo. IPv4 IPv6 L'api-server Kubernetes comunica con i Pod e i componenti del nodo tramite la base X-. ENIs IPv6 I pod comunicano con gli api-server tramite X- ENIs e la comunicazione tra Pod e api-server utilizza sempre la modalità. IPv6

Raccomandazioni

Mantieni l'accesso a IPv4 EKS APIs

Gli EKS APIs sono accessibili IPv4 solo da. Ciò include anche l'endpoint dell'API Cluster. Non sarà possibile accedere agli endpoint del cluster e APIs da un' IPv6 unica rete. È necessario che la rete supporti (1) un meccanismo di IPv6 transizione come NAT64/DNS64 che facilita la comunicazione tra IPv4 gli host IPv6 e (2) un servizio DNS che supporti le traduzioni degli endpoint. IPv4

Pianificazione basata sulle risorse di calcolo

Un singolo IPv6 prefisso è 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 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 IPv6 cluster EKS.

((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 la necessità con. IPv6 Se hai scelto di utilizzare reti personalizzate per risolvere il problema dell' IPv4 esaurimento, non è più necessario con. IPv6 Se utilizzate una rete personalizzata per soddisfare un requisito di sicurezza, ad esempio una rete separata per nodi e pod, vi consigliamo di inviare una richiesta di roadmap EKS.

Pod Fargate in EKS/ Cluster IPv6

Supporti EKS IPv6 per i Pod che funzionano su Fargate. I pod in esecuzione su Fargate consumeranno IPv4 indirizzi IPv6 privati routabili VPC ricavati dagli intervalli CIDR del VPC (). IPv4 IPv6 In parole semplici, sei EKS/Fargate Pods cluster wide density will be limited to the available IPv4 and IPv6 addresses. It is recommended to size your dual-stack subnets/VPC CIDRs destinato alla crescita futura. Non sarà possibile pianificare nuovi Fargate Pod se la sottorete sottostante non contiene un indirizzo disponibile, indipendentemente dagli IPv4 indirizzi disponibili. IPv6

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 aggiuntivo AWS Load Balancer Controller. LBC implementerà un NLB dual-stack o un ALB dual-stack solo dopo aver utilizzato la corrispondente definizione di servizio/ingresso Kubernetes annotata con: e "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"

AWS Network Load Balancer non supporta tipi di indirizzi di protocollo UDP dual-stack. Se hai requisiti rigorosi per lo streaming in tempo reale, i giochi online e l'IoT a bassa latenza, ti consigliamo di utilizzare i cluster IPv4 . Per ulteriori informazioni sulla gestione dei controlli di integrità per i servizi UDP, consulta «Come indirizzare il traffico UDP verso Kubernetes».