Requisiti e considerazioni su VPC e sottoreti di Amazon EKS

Durante la creazione di un cluster, in genere si specificano un VPC e due sottoreti che si trovano in zone di disponibilità diverse. Questo argomento offre una panoramica dei requisiti e delle considerazioni specifiche di Amazon EKS per il VPC e le sottoreti utilizzate con il cluster. Se non disponi di un VPC da utilizzare con Amazon EKS, puoi crearne uno utilizzando un modello fornito AWS CloudFormation da Amazon EKS. Se stai creando un cluster locale o esteso su AWS Outposts, consulta Requisiti e considerazioni su VPC e sottoreti del cluster locale Amazon EKS invece di questo argomento.

Considerazioni e requisiti relativi al VPC

Durante la creazione di un cluster, il VPC specificato deve soddisfare i requisiti e le considerazioni seguenti:

• 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' AWS Management Console aggiornamento dalla versione più recente di e dalla AWS CLIeksctl versione v0.164.0-rc.0 o successiva. AWS CloudFormation Potrebbe essere necessario eseguire questa operazione per fornire alle sottoreti più indirizzi IP disponibili per aggiornare in modo corretto una versione del cluster.

  Importante

  Tutte le sottoreti aggiunte devono trovarsi nello stesso insieme di AZ fornito in origine quando hai creato il cluster. Le nuove sottoreti devono soddisfare tutti gli altri requisiti, ad esempio devono disporre di sufficienti indirizzi IP.

  Supponiamo ad esempio che hai creato un cluster e specificato quattro sottoreti. Nell'ordine in cui le hai specificate, la prima sottorete si trova nella zona di disponibilità us-west-2a, la seconda e la terza si trovano nella zona di disponibilità us-west-2b e la quarta si trova nella zona di disponibilità us-west-2c. Se desideri modificare le sottoreti, devi fornire almeno una sottorete in ciascuna delle tre zone di disponibilità e le sottoreti devono trovarsi nello stesso VPC delle sottoreti originali.

  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 CIDR privati (RFC 1918) e pubblici (non RFC 1918) può avvenire prima o dopo la creazione del cluster. Il riconoscimento del blocco CIDR associato a un VPC da parte del cluster può richiedere fino a cinque ore.

  È possibile conservare l'utilizzo degli indirizzi IP tramite 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.

• Se vuoi che Kubernetes assegni indirizzi IPv6 a Pods e servizi, associa un blocco CIDR IPv6 al VPC. Per ulteriori informazioni, consulta Associazione di un blocco CIDR IPv6 al VPC nella Guida per l'utente di Amazon VPC.

• 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 l'utilizzo di endpoint VPC. AWS PrivateLink Per ulteriori informazioni, consulta Considerazioni e requisiti relativi alle sottoreti.

Se il cluster è stato creato con Kubernetes 1.14 o versioni precedenti, Amazon EKS ha aggiunto il tag seguente al VPC:

Chiave	Valore
kubernetes.io/cluster/my-cluster	owned

Questo tag è stato utilizzato solo da Amazon EKS, per cui è possibile rimuoverlo senza influire sui servizi. Non è necessario con la versione 1.15 del cluster o con versioni successive.

Considerazioni e requisiti relativi alle sottoreti

Durante la creazione di un cluster, Amazon EKS crea da 2 a 4 interfacce di rete elastiche nelle sottoreti specificate. Queste interfacce di rete consentono la comunicazione tra il cluster e il VPC. Inoltre, abilitano alcune funzionalità di Kubernetes come kubectl exec e kubectl logs. Ogni interfaccia di rete creata da Amazon EKS ha il testo Amazon EKS cluster-name nella sua descrizione.

Amazon EKS può creare le proprie interfacce di rete in qualsiasi sottorete specificata al momento della creazione di un cluster. Puoi modificare le sottoreti in cui Amazon EKS crea le interfacce di rete dopo la creazione del cluster. Quando aggiorni la versione Kubernetes di un cluster, Amazon EKS elimina le interfacce di rete originali e ne crea di nuove. Queste interfacce di rete potrebbero essere create all'interno delle stesse sottoreti o in sottoreti diverse rispetto alle interfacce di rete originali. Per verificare in quali sottoreti vengono create le interfacce di rete, puoi limitare il numero di sottoreti specificate a due quando crei un cluster o aggiornare le sottoreti dopo aver creato il cluster.

Requisiti relativi alla sottorete per i cluster

Le sottoreti specificate al momento della creazione o dell'aggiornamento di un cluster devono soddisfare i seguenti requisiti:

• 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 sottoreti non possono risiedere in o in AWS Outposts una zona locale. AWS Wavelength AWS Tuttavia, se presenti nel VPC, puoi implementare nodi autogestiti e risorse Kubernetes in questi tipi di sottoreti.

• 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 instradamento 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à:

  Regione AWS	Nome Regione	ID della zona di disponibilità non consentita
  us-east-1	Stati Uniti orientali (Virginia settentrionale)	use1-az3
  us-west-1	Stati Uniti occidentali (California settentrionale)	usw1-az2
  ca-central-1	Canada (Centrale)	cac1-az3

Utilizzo della famiglia di indirizzi IP per componente

La tabella seguente contiene la famiglia di indirizzi IP utilizzata da ogni componente di Amazon EKS. Puoi utilizzare un NAT (Network Address Translation) o un altro sistema di compatibilità per connetterti a questi componenti da indirizzi IP di origine in famiglie con il "No" valore per una voce di tabella.

La funzionalità può variare a seconda dell'impostazione IP family (ipFamily) del cluster. Questa impostazione modifica il tipo di indirizzi IP utilizzati per il CIDR blocco Kubernetes assegnato aServices. Un cluster con il valore di impostazione di IPv4 viene definito come unIPv4 cluster, mentre un cluster con il valore di impostazione di IPv6 viene definito come unIPv6 cluster.

Componente	IPv4solo indirizzi	IPv6solo indirizzi	indirizzi dual stack
Endpoint pubblico dell'API EKS	Sì	No	No
Endpoint VPC API EKS	Sì	No	No
Endpoint pubblico dell'API EKS Auth	Sì 1	Sì 1	Sì 1
Endpoint VPC dell'API di autenticazione EKS	Sì 1	Sì 1	Sì 1
Endpoint pubblico del cluster EKS	Sì	No	No
Endpoint privato del cluster EKS	Sì 2	Sì 2	No
Sottoreti del cluster EKS	Sì 2	No	Sì 2
Indirizzi IP primari del nodo	Sì 2	No	Sì 2
CIDRIntervallo di cluster per indirizzi Service IP	Sì 2	Sì 2	No
PodIndirizzi IP dal VPC CNI	Sì 2	Sì 2	No

Nota

¹ L'endpoint è a doppio stack con entrambi gli indirizzi. IPv4 IPv6 Le applicazioni esterne AWS, i nodi del cluster e i pod all'interno del cluster possono raggiungere questo endpoint tramite l'uno o l'altro. IPv4 IPv6

² È possibile scegliere tra un IPv4 cluster e un IPv6 cluster nell'impostazione IP family (ipFamily) del cluster quando si crea un cluster e questa impostazione non può essere modificata. È invece necessario scegliere un'impostazione diversa quando si crea un altro cluster e si migrano i carichi di lavoro.

Requisiti relativi alla sottorete per i nodi

Puoi implementare nodi e risorse Kubernetes nelle stesse sottoreti specificate al momento della creazione del cluster. Tuttavia, l'implementazione non è necessaria. Questo perché puoi implementare nodi e risorse Kubernetes anche in sottoreti che non hai specificato durante la creazione del cluster. L'implementazione di nodi in sottoreti diverse non comporta la creazione di interfacce di rete cluster in tali sottoreti da parte di Amazon EKS. Qualsiasi sottorete in cui si implementano nodi e risorse Kubernetes deve soddisfare i seguenti requisiti:

• Per implementare tutti i nodi e le risorse Kubernetes, le sottoreti devono disporre di un numero sufficiente di indirizzi IP.

• Se desideri che Kubernetes assegni indirizzi IPv6 a Pods e servizi, dovrai disporre di un blocco CIDR IPv6 e di un blocco CIDR IPv4 associati alla sottorete. Per ulteriori informazioni, consulta Associazione di un blocco 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 Pods un accesso in entrata da Internet, assicurati di disporre di almeno una sottorete pubblica con un numero sufficiente di indirizzi IP disponibili su cui implementare i load balancer e gli ingressi. Puoi implementare sistemi di bilanciamento del carico nelle sottoreti pubbliche. I sistemi di bilanciamento del carico possono bilanciare il carico sui Pods in 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 AWS CloudFormation modello Amazon EKS per distribuire il tuo 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 ulteriori informazioni, consulta Modifica dell'attributo di assegnazione degli indirizzi IPv4 pubblici per la sottorete e Modifica dell'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 instradamento non include un instradamento verso un dispositivo Network address translation (NAT) (IPv4) o un gateway egress-only (IPv6), aggiungere endpoint VPC utilizzando AWS PrivateLink al VPC. Gli endpoint VPC sono necessari per tutti i Servizi AWS nodi con Pods cui devono comunicare. Alcuni esempi includono Amazon ECR, Elastic Load Balancing, Amazon e CloudWatch Amazon AWS Security Token Service Simple Storage Service (Amazon S3). L'endpoint deve includere la sottorete in cui si trovano i nodi. Non tutti Servizi AWS supportano gli endpoint VPC. Per ulteriori informazioni, consulta Cos'è? AWS PrivateLink e AWS servizi che si integrano con AWS PrivateLink. Per un elenco di altri requisiti Amazon EKS, consulta Requisiti dei cluster privati.

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

  • Sottoreti private

    Chiave	Valore
    kubernetes.io/role/internal-elb	1

  • Sottoreti pubbliche

    Chiave	Valore
    kubernetes.io/role/elb	1

In passato, quando si creava un cluster Kubernetes versione 1.18 e precedenti, Amazon EKS aggiungeva il seguente tag a tutte le sottoreti specificate.

Chiave	Valore
kubernetes.io/cluster/my-cluster	shared

Adesso, se crei un nuovo cluster Kubernetes, Amazon EKS non aggiunge alcun tag alle sottoreti. Se il tag era applicato a sottoreti utilizzate da un cluster che in precedenza era una versione precedente a 1.19, il tag non veniva rimosso automaticamente dalle sottoreti quando il cluster veniva aggiornato a una versione più recente. La versione 2.1.1 o precedenti di AWS Load Balancer Controller richiede questo tag. Se si utilizza una versione più recente di Load Balancer Controller, è possibile rimuovere il tag senza interrompere i servizi.

Se hai distribuito un VPC eksctlutilizzando o uno qualsiasi dei modelli AWS CloudFormation VPC di Amazon EKS, si applica quanto segue:

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

Questa modifica influisce sui nuovi gruppi di nodi implementati nelle sottoreti pubbliche nei modi seguenti:

• 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 per la sottorete.

• Gruppi di nodi autogestiti Linux, Windows o Arm: se il gruppo di nodi viene implementato in una sottorete pubblica dal 26 marzo 2020 in poi, la sottorete pubblica dovà disporre dell'assegnazione automatica degli indirizzi IP pubblici. Altrimenti, i nodi devono essere avviati con un indirizzo IP pubblico. Per ulteriori informazioni, consulta Modifica dell'attributo di assegnazione degli indirizzi IPv4 pubblici per la sottorete o Assegnazione di un indirizzo IPv4 pubblico durante l'avvio dell'istanza.

Considerazioni e requisiti relativi alle sottoreti condivisi

È possibile utilizzare la Condivisione VPC per condividere sottoreti con altri account AWS all'interno della stessa AWS Organizations. È possibile creare cluster Amazon EKS in sottoreti condivise, tenendo a mente le seguenti considerazioni:

• 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 ruolo IAM del cluster e i ruoli IAM del nodo devono essere creati in quell'account. Per ulteriori informazioni, consulta Ruolo IAM del cluster Amazon EKS e Ruolo IAM del nodo Amazon EKS.

  • Tutti i nodi devono essere creati dallo stesso partecipante, inclusi i gruppi di nodi gestiti.

• 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 Amazon VPC CNI plugin for Kubernetes, è necessario utilizzare le mappature degli ID delle zone di disponibilità elencate nell'account del proprietario per creare ciascuna ENIConfig. Per ulteriori informazioni, consulta Rete personalizzata per i pod.

Per ulteriori informazioni sulla condivisione delle sottoreti VPC, consulta la pagina Condivisione del VPC con altri account nella Guida per l'utente di Amazon VPC.