Considerazioni su cluster VPC e sottoreti - Amazon EKS

Considerazioni su cluster VPC e sottoreti

Amazon EKS consiglia di eseguire un cluster su un VPC con sottoreti pubbliche e private, in modo che Kubernetes possa creare bilanciatori del carico pubblici nelle sottoreti pubbliche, che bilancino il carico del traffico ai pod in esecuzione su nodi che si trovano in sottoreti private. Tuttavia, questa configurazione non è necessaria. È possibile eseguire un cluster in un VPC solo con sottoreti private o pubbliche, a seconda dei requisiti di rete e di sicurezza. Per ulteriori informazioni sui cluster distribuiti in un VPC con sottoreti private, consultare Cluster privati.

Quando si crea un cluster Amazon EKS, specificare le sottoreti VPC in cui Amazon EKS può posizionare le interfacce di rete elastiche. Amazon EKS richiede sottoreti in almeno due zone di disponibilità e crea fino a quattro interfacce di rete tra queste sottoreti per facilitare la comunicazione del piano di controllo con i nodi. Questo canale di comunicazione supporta funzionalità Kubernetes come kubectl exec e kubectl logs. Amazon EKS crea un Gruppo di sicurezza del cluster e ogni gruppo di sicurezza aggiuntivo specificati al momento della creazione del cluster, i quali vengono applicati a queste interfacce di rete. Ogni interfaccia di rete creata da Amazon EKS presenta il cluster name di Amazon EKS nella sua descrizione.

Assicurati che le sottoreti specificate durante la creazione del cluster dispongano di un numero sufficiente di indirizzi IP per le interfacce di rete create da Amazon EKS. Se si sta per implementare un cluster che utilizza la famiglia IPv4, consigliamo di creare piccole (/28) sottoreti dedicate per le interfacce di rete create da Amazon EKS e specificare solo queste sottoreti come parte della creazione del cluster. Altre risorse, ad esempio nodi e bilanciatori del carico, devono essere avviate in sottoreti separate dalle sottoreti specificate durante la creazione del cluster.

Importante
  • I nodi e i bilanciatori del carico possono essere avviati in qualsiasi sottorete del VPC del cluster, incluse le sottoreti non registrate con Amazon EKS durante la creazione del cluster. Le sottoreti non richiedono alcun tag per i nodi. Affinché il rilevamento automatico del bilanciamento del carico di Kubernetes funzioni, le sottoreti devono essere taggate come descritto in Assegnazione di tag alle sottoreti.

  • Le sottoreti associate al cluster non possono essere modificate dopo la creazione del cluster. Se è necessario controllare esattamente in quali sottoreti vengono inserite le interfacce di rete create da Amazon EKS. Specificare solo due sottorete durante la creazione del cluster, ognuna in una zona di disponibilità diversa.

  • Non selezionare una sottorete in AWS Outposts, AWS Wavelength, o una Local Zone AWS durante la creazione del cluster.

  • I cluster creati con v1.14 o versioni precedenti contengono un tag kubernetes.io/cluster/cluster-name sul VPC. Questo tag è stato utilizzato solo da Amazon EKS e può essere rimosso in modo sicuro.

  • La visualizzazione di un intervallo aggiornato causato dall'aggiunta di blocchi CIDR a un cluster esistente può richiedere fino a 5 ore.

  • Se si desidera che Kubernetes assegni indirizzi IPv6 a pod e servizi, è necessario che i blocchi CIDR IPv4 e IPv6 siano assegnati al VPC e alle sottoreti. Per ulteriori informazioni, consultare Associazione di un blocco CIDR IPv6 al VPC nella Guida per l'utente di Amazon VPC. Le tabelle di routing e i gruppi di sicurezza devono includere anche indirizzi IPv6. Per ulteriori informazioni, consultare Migrazione a IPv6 nella Guida per l'utente di Amazon VPC.

  • I nodi devono essere in grado di comunicare con il piano di controllo e altri AWS servizi. Se i nodi vengono distribuiti in una sottorete privata e si desidera che i pod abbiano accesso in uscita a Internet, allora la sottorete privata deve soddisfare uno dei requisiti seguenti:

    • Le sottoreti con solo blocchi CIDR IPv4 devono avere un routing predefinito verso il gateway NAT. Al gateway NAT deve essere assegnato un indirizzo IPv4 pubblico per fornire ai nodi l'accesso a Internet.

      Le sottoreti con solo blocchi CIDR IPv6 devono avere un routing predefinito verso il gateway Internet egress-only.

    • È configurata con le impostazioni e i requisiti necessari in Cluster privati.

Il VPC deve supportare il nome host DNS e la risoluzione DNS oppure i nodi non possono registrarsi con il cluster. Per ulteriori informazioni, consultare l'articolo sull'utilizzo del DNS nei VPC nella Guida per l'utente di Amazon VPC.

Assegnazione degli indirizzi IP VPC

Se si desidera che i pod implementati sui nodi nelle sottoreti pubbliche abbiano accesso a Internet in uscita, le sottoreti pubbliche devono essere configurate per assegnare automaticamente indirizzi IPv4 pubblici o indirizzi IPv6. Determinare se le sottoreti pubbliche sono configurate per l'assegnazione automatica degli indirizzi IPv4 pubblici o IPv6 con il comando seguente. Sostituisci example values con i valori in tuo possesso.

IPv4
aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=VPC-ID" | grep 'SubnetId\|MapPublicIpOnLaunch'
IPv6
aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=VPC-ID" | grep 'SubnetId\|AssignIpv6AddressOnCreation'

Output

IPv4
"MapPublicIpOnLaunch": true, "SubnetId": "subnet-ID1", "MapPublicIpOnLaunch": false, "SubnetId": "subnet-ID2", ...
IPv6
"SubnetId": "subnet-ID1", "AssignIpv6AddressOnCreation": true, "SubnetId": "subnet-ID2", "AssignIpv6AddressOnCreation": false, ...

Per le sottoreti che hanno MapPublicIpOnLaunch o AssignIpv6AddressOnCreation impostato su false, modificare l'impostazione su true.

IPv4
aws ec2 modify-subnet-attribute --subnet-id subnet-ID2 --map-public-ip-on-launch
IPv6
aws ec2 modify-subnet-attribute --subnet-id subnet-ID2 --assign-ipv6-address-on-creation
Importante

Se hai utilizzato un modello AWS CloudFormation di Amazon EKS per implementare il VPC prima del 26 marzo 2020, è necessario cambiare l'impostazione per le sottoreti pubbliche.

È possibile definire sia intervalli IPv4 (CIDR) con routing tra domini classless privati (RFC 1918) che pubblici (non-RFC 1918) all'interno del VPC utilizzato per il cluster Amazon EKS. Per ulteriori informazioni, consultare l'articolo relativo all'aggiunta di blocchi CIDR IPv4 a un VPC nella Guida per l'utente di Amazon VPC. Quando si scelgono i blocchi CIDR per il VPC e per le sottoreti, assicurarsi che i blocchi contengano un numero di indirizzi IPv4 sufficiente per tutti i nodi e i pod Amazon EC2 che si intende implementare. Dovrebbe esserci almeno un indirizzo IP per ciascuno dei pod. È possibile conservare l'utilizzo degli indirizzi IP implementando un gateway di transito con un VPC di servizi condivisi. Per ulteriori informazioni, consultare VPC isolati con servizi condivisi e Modelli di conservazione degli indirizzi IP instradabili di Amazon EKS VPC in una rete ibrida.

Assegnazione di tag alle sottoreti

Per i cluster versione 1.18 e precedenti, Amazon EKS aggiunge il seguente tag a tutte le sottoreti passate durante la creazione del cluster. Amazon EKS non aggiunge il tag alle sottoreti passate durante la creazione di cluster 1.19. Se il tag esiste nelle sottoreti utilizzate da un cluster creato in una versione precedente alla 1.19, e si aggiorna il cluster alla versione 1.19, il tag non viene rimosso dalle sottoreti.

  • Chiavekubernetes.io/cluster/cluster-name

  • Valoreshared

È possibile utilizzare questo tag facoltativamente per controllare dove viene eseguito il provisioning degli Elastic Load Balancers (Bilanciatori del Carico Elastico), oltre ai tag delle sottoreti necessari per l'utilizzo degli Elastic Load Balancer con provisioning automatico. Per ulteriori informazioni relative all'assegnazione di tag alle sottoreti del sistema di bilanciamento del carico, consultare Bilanciamento del carico di applicazione su Amazon EKS e Bilanciamento del carico di rete su Amazon EKS.

Aumento degli indirizzi IPv4 disponibili per il VPC

Se il proprio Amazon VPC sta esaurendo gli indirizzi IPv4, è possibile associare un CIDR secondario a un VPC esistente. Per ulteriori informazioni, consultare l'articolo relativo all'aggiunta di blocchi CIDR IPv4 a un VPC nella Guida per l'utente di Amazon VPC. Con il nuovo CIDR associato, è possibile creare sottoreti utilizzando un sottoinsieme del CIDR appena associato. Dopo aver creato la nuova sottorete o le nuove sottoreti, è possibile creare gruppi di nodi aggiuntivi, gestiti o autogestiti, che utilizzano il CIDR e le sottoreti appena associate.