Visualizzazione di requisiti di rete di Amazon EKS per VPC e sottoreti

Il VPC deve disporre di un numero sufficiente di indirizzi IP da mettere a disposizione per il cluster, i nodi e le altre risorse Kubernetes da creare. In caso contrario, è possibile provare ad aumentare il numero di indirizzi IP disponibili.

È possibile farlo aggiornando la configurazione del cluster per modificare le sottoreti e i gruppi di sicurezza utilizzati dal cluster. Puoi eseguire l’aggiornamento da Console di gestione AWS, dalla versione più recente di AWS CLI, da CloudFormation AWS e da eksctl versione v0.164.0-rc.0 o successiva. Potrebbe essere necessario eseguire questa operazione per fornire alle sottoreti più indirizzi IP disponibili per aggiornare in modo corretto una versione del cluster.

Se hai bisogno di più indirizzi IP rispetto ai blocchi CIDR nel VPC, puoi aggiungere altri blocchi CIDR associando ulteriori blocchi di routing interdominio senza classi (CIDR) al VPC. L'associazione di blocchi di CIDR privati (RFC 1918) e pubblici (non RFC 1918) può avvenire prima o dopo la creazione del cluster.

È possibile aggiungere nodi che utilizzano il nuovo intervallo CIDR subito dopo averlo aggiunto. Tuttavia, poiché il piano di controllo riconosce il nuovo intervallo CIDR solo dopo il completamento della riconciliazione, il riconoscimento dell’intervallo CIDR associato a un VPC da parte del cluster può richiedere fino a un’ora. Quindi, è possibile eseguire i comandi kubectl cp, kubectl exec, kubectl logs e kubectl port-forward (questi comandi utilizzano kubelet API) per nodi e pod nel nuovo intervallo CIDR. Inoltre, se si dispone di pod che funzionano come backend webhook, devi attendere il completamento della riconciliazione del piano di controllo.

Evita le sovrapposizioni degli intervalli di indirizzi IP quando connetti il tuo cluster EKS ad altri VPC tramite Transit Gateway, peering di VPC o altre configurazioni di rete. I conflitti di CIDR si verificano quando il servizio CIDR del cluster EKS si sovrappone al CIDR di un VPC connesso. In questi scenari, gli indirizzi ServiceIP hanno la priorità sulle risorse nei VPC connessi con lo stesso indirizzo IP, sebbene il routing del traffico possa diventare imprevedibile e le applicazioni potrebbero non riuscire a connettersi alle risorse previste.

Per evitare conflitti CIDR, assicurati che il tuo servizio CIDR di EKS non si sovrapponga a nessun CIDR di VPC connesso e mantieni un registro centralizzato di tutte le assegnazioni CIDR. Se si riscontrano sovrapposizioni di CIDR, è possibile utilizzare un gateway di transito con un VPC di servizi condivisi. Per ulteriori informazioni, consulta VPC isolati con servizi condivisi e Modelli di conservazione degli indirizzi IP instradabili di Amazon EKS VPC in una rete ibrida. Inoltre, consulta la sezione Comunicazione tra le sezioni di VPC della pagina Considerazioni su VPC e sottorete nella guida alle best practice di EKS.

Se vuoi che Kubernetes assegni indirizzi IPv6 a pod e servizi, associa un intervallo CIDR IPv6 al tuo VPC. Per ulteriori informazioni, consultare Associazione di un blocco CIDR IPv6 al VPC nella Guida per l'utente di Amazon VPC. Non è possibile utilizzare indirizzi IPv6 con pod e servizi in esecuzione su nodi ibridi e non è possibile utilizzare nodi ibridi con cluster configurati con la famiglia di indirizzi IP IPv6.

Il VPC deve supportare il nome host DNS e la risoluzione DNS. In caso contrario, i nodi non possono registrarsi al cluster. Per ulteriori informazioni, consulta Attributi DNS nel VPC nella Guida per l'utente di Amazon VPC.

Il VPC potrebbe richiedere endpoint VPC che usano PrivateLink AWS. Per ulteriori informazioni, consulta Considerazioni e requisiti relativi alle sottoreti.

Ciascuna sottorete deve disporre di almeno sei indirizzi IP  per l'uso da parte di Amazon EKS. Tuttavia, consigliamo di utilizzare almeno 16 indirizzi IP.

Le due sottoreti devono trovarsi in almeno due zone di disponibilità diverse.

Le sottoreti non possono risiedere in AWS Outposts o in lunghezza d’onda AWS. Tuttavia, se sono presenti nel VPC, puoi implementare nodi autogestiti e risorse Kubernetes per questi tipi di sottoreti. Per ulteriori informazioni sulla gestione dei nodi, consulta Gestione autonoma dei nodi con nodi autogestiti.

Le sottoreti possono essere pubbliche o private. Tuttavia, si consiglia di specificare sottoreti private, se possibile. Una sottorete pubblica è una sottorete con una tabella di routing che include un instradamento a un gateway Internet, mentre la sottorete privata non comprende tale instradamento.

Le sottoreti non possono risiedere nelle seguenti zone di disponibilità:

Le sottoreti devono mettere a disposizione un numero sufficiente di indirizzi IP per implementare tutti i nodi e le risorse Kubernetes.

Se si desidera che Kubernetes assegni indirizzi IPv6 a pod e servizi, è necessario disporre di un intervallo CIDR IPv6 e un intervallo CIDR IPv4 associati alla sottorete. Per ulteriori informazioni, consulta Associare un intervallo CIDR IPv6 alla sottorete nella guida per l’utente di Amazon VPC. Le tabelle di instradamento associate alle sottoreti devono includere instradamenti a indirizzi IPv4 e IPv6. Per maggiori informazioni, consulta Routes (Instradamenti) nella Guida dell'utente di Amazon VPC. Ai pod viene assegnato solo un indirizzo IPv6, mentre alle interfacce di rete create da Amazon EKS per il cluster e ai nodi vengono assegnati un indirizzo IPv4 e uno IPv6.

Se è necessario garantire ai pod un accesso in entrata da Internet, assicurarsi di disporre di almeno una sottorete pubblica con un numero sufficiente di indirizzi IP disponibili su cui implementare i bilanciatori di carico e gli ingressi. È possibile implementare i load balancer nelle sottoreti pubbliche. I bilanciatori di carico possono bilanciare il carico sui pod di sottoreti private o pubbliche. Consigliamo di implementare i nodi su sottoreti private, se possibile.

Se si prevede di implementare i nodi in una sottorete pubblica, quest'ultima deve essere configurata per assegnare automaticamente indirizzi IPv4 pubblici o indirizzi IPv6. Se si implementano nodi in una sottorete privata a cui è associato un blocco CIDR IPv6, anche questa sottorete deve essere configurata per assegnare automaticamente indirizzi IPv6. Se hai utilizzato un modello CloudFormation AWS di Amazon EKS per implementare il VPC dopo il 26 marzo 2020, questa impostazione è abilitata. Se hai utilizzato i modelli per implementare il VPC prima di tale data o utilizzi un VPC personale, devi abilitare questa impostazione manualmente. Per il modello, consulta Creazione di un Amazon VPC per il cluster Amazon EKS.. Per ulteriori informazioni, consulta Modifica l’attributo di assegnazione degli indirizzi IPv4 pubblici per la sottorete e Modifica l’attributo di assegnazione degli indirizzi IPv6 per la sottorete nella guida per l’utente di Amazon VPC.

Se la sottorete in cui si implementa un nodo è privata e la relativa tabella di routing non include un instradamento verso un dispositivo Network address translation (NAT) (IPv4) o un gateway di sola uscita (IPv6), aggiungere endpoint VPC utilizzando PrivateLink AWS al VPC. Gli endpoint VPC sono necessari per tutti i servizi AWS con cui i nodi e i pod devono comunicare. A titolo esemplificativo si possono menzionare Amazon ECR, bilanciamento del carico elastico, Amazon CloudWatch, servizio di tokenizzazione di sicurezza AWS e Amazon Simple Storage Service (Amazon S3). L'endpoint deve includere la sottorete in cui si trovano i nodi. Non tutti i servizi AWS supportano gli endpoint VPC. Per ulteriori informazioni, consulta Cos’è PrivateLink AWS? e Servizi AWS che si integrano con AWS PrivateLink. Per un elenco di altri requisiti Amazon EKS, consulta Implementazione di cluster privati con accesso limitato a Internet.

Se si desidera implementare i load balancer in una sottorete, quest'ultima deve presentare il tag seguente:

In data 26 marzo 2020 o successiva. Gli indirizzi IPv4 pubblici vengono assegnati automaticamente dalle sottoreti pubbliche ai nuovi nodi implementati nelle sottoreti pubbliche.

Prima del 26 marzo 2020: gli indirizzi IPv4 pubblici non vengono assegnati automaticamente dalle sottoreti pubbliche ai nuovi nodi implementati nelle sottoreti pubbliche.

Gruppi di nodi gestiti : se il gruppo di nodi viene implementato in una sottorete pubblica in data 22 aprile 2020 o successiva, la sottorete pubblica deve disporre dell’assegnazione automatica degli indirizzi IP pubblici abilitati. Per ulteriori informazioni, consulta Modifica dell'attributo di assegnazione degli indirizzi IPv4 pubblici della sottorete.

Gruppi di nodi autogestiti Linux, Windows o Arm: se il gruppo di nodi viene implementato in una sottorete pubblica in data 26 marzo 2020 o successiva, la sottorete pubblica deve disporre dell’assegnazione automatica degli indirizzi IP pubblici abilitati. Altrimenti, i nodi devono essere avviati con un indirizzo IP pubblico. Per ulteriori informazioni, consultare Modifica dell'attributo di assegnazione degli indirizzi IPv4 pubblici della sottorete o Assegnare un indirizzo IPv4 pubblico durante l'avvio dell'istanza.

Il proprietario della sottorete VPC deve condividere una sottorete con un account partecipante prima che tale account possa creare un cluster Amazon EKS al suo interno.

Non è possibile avviare le risorse utilizzando il gruppo di sicurezza predefinito per il VPC, in quanto questo appartiene al proprietario. Inoltre, i partecipanti non possono avviare le risorse utilizzando i gruppi di sicurezza di proprietà di altri partecipanti o del proprietario.

In una sottorete condivisa, il partecipante e il proprietario controllano separatamente i gruppi di sicurezza all'interno di ciascun account. Il proprietario della sottorete può visualizzare i gruppi di sicurezza che sono stati creati dai partecipanti, ma non può eseguire operazioni sugli stessi. Se il proprietario della sottorete desidera rimuovere o modificare questi gruppi di sicurezza, è il partecipante che ha creato il gruppo di sicurezza che deve eseguire l'operazione.

Se un cluster viene creato da un partecipante, valgono le seguenti considerazioni:

Il proprietario del VPC condiviso non può visualizzare, aggiornare o eliminare un cluster creato da un partecipante nella sottorete condivisa. Ciò si aggiunge alle risorse VPC alle quali ogni account ha un accesso diverso. Per ulteriori informazioni, consulta la sezione Responsabilità e autorizzazioni per proprietari e partecipanti nella Guida per l'utente di Amazon VPC.

Se si utilizza la funzionalità rete personalizzata del plugin CNI di Amazon VPC, è necessario utilizzare le mappature degli ID delle zone di disponibilità elencate nell’account del proprietario per creare ciascun ENIConfig. Per ulteriori informazioni, consulta Implementazione dei pod in sottoreti alternative con reti personalizzate.