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 un problema significativo sollevato da alcuni nostri clienti e si distingue 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 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 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, da agosto 2024
Il diagramma seguente illustra un flusso di uscita Internet IPv6 Pod all'interno di un cluster: EKS/IPv6
Le migliori pratiche per l'implementazione delle sottoreti IPv6 sono disponibili nella 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, i nodi e i 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 modello di base del piano EKS/IPv6 dati basato sul piano di controllo del cluster:
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 nodo di lavoro) produrrà ~10^14 indirizzi IPv6, il fattore limitante non sarà più gli IP ma la densità dei Pod (per quanto riguarda le 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 EKS/IPv4 i cluster Pod churn elevati sono spesso ritardati nella pianificazione dei Pod a causa di chiamate API limitate generate dal plug-in VPC CNI (ipamd) finalizzato all'allocazione tempestiva di indirizzi IPv4 privati. È anche noto che ottimizza inutilmente le manopole avanzate del plug-in, MINIMUM_IP. VPC-CNI WARM_IP/ENI
Il diagramma seguente ingrandisce una Elastic Network Interface (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 nodo di lavoro e non viene pubblicizzato oltre il nodo di lavoro. 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 EKS/IPv6 il DNS64 sia disabilitato sulle sottoreti in cui sono in esecuzione i Pods. 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 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 Internet valido (IP pubblico assegnato dal 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). https://datatracker.ietf.org/doc/html/rfc4193
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 mostra un utente Internet IPv4 che accede a un servizio basato su Ingress: EKS/IPv6
Nota
Il modello precedente richiede la distribuzione della versione più recente del controller di
Comunicazione EKS Control Plane Data Plane
EKS fornirà 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 IPv6. X-ENIs I pod comunicano con gli api-server tramite e la comunicazione da pod a api-server utilizza sempre la modalità IPv6. X-ENIs
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 la rete personalizzata è attualmente abilitata, 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 una richiesta di roadmap EKS. https://github.com/aws/containers-roadmap/issues
Pods Fargate in Cluster EKS/IPv6
EKS supporta IPv6 per i pod 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, l'ampia densità del cluster di EKS/Fargate Pods sarà limitata agli indirizzi IPv4 e IPv6 disponibili. Si consiglia di dimensionare i CIDR dual-stack per la crescita futura subnets/VPC . 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. Consigliamo di utilizzare la versione più recente del componente aggiuntivo AWS Load Balancer "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
