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

Considerazioni su VPC e sottorete

La gestione di un cluster EKS richiede la conoscenza della rete AWS VPC, oltre alla rete Kubernetes.

Ti consigliamo di comprendere i meccanismi di comunicazione del piano di controllo EKS prima di iniziare a progettare il tuo VPC o implementare i cluster in VPC esistenti.

Fai riferimento alle considerazioni su Cluster VPC e alle considerazioni sul gruppo di sicurezza Amazon EKS quando progetti un VPC e delle sottoreti da utilizzare con EKS.

Panoramica di

Architettura del cluster EKS

Un cluster EKS è composto da due VPC:

I nodi del VPC del cliente necessitano della possibilità di connettersi all'endpoint del server API gestito nel VPC AWS. Ciò consente ai nodi di registrarsi nel piano di controllo di Kubernetes e ricevere richieste per eseguire i Pod delle applicazioni.

I nodi si connettono al piano di controllo EKS tramite (a) un endpoint pubblico EKS o (b) un'interfaccia di rete Cross-Account elastica () gestita da EKS. X-ENI Quando viene creato un cluster, è necessario specificare almeno due sottoreti VPC. EKS inserisce un X-ENI in ogni sottorete specificata durante la creazione del cluster (chiamate anche sottoreti del cluster). Il server API Kubernetes utilizza questi Cross-Account ENI per comunicare con i nodi distribuiti nelle sottoreti VPC del cluster gestite dal cliente.

All'avvio del nodo, viene eseguito lo script di bootstrap EKS e vengono installati i file di configurazione del nodo Kubernetes. Come parte del processo di avvio su ogni istanza, vengono avviati gli agenti di runtime del contenitore, gli agenti kubelet e i nodi Kubernetes.

Per registrare un nodo, Kubelet contatta l'endpoint del cluster Kubernetes. Stabilisce una connessione con l'endpoint pubblico esterno al VPC o con l'endpoint privato all'interno del VPC. Kubelet riceve istruzioni API e fornisce regolarmente aggiornamenti di stato e battiti cardiaci all'endpoint.

Comunicazione EKS Control Plane

EKS offre due modi per controllare l'accesso all'endpoint del cluster. Il controllo degli accessi agli endpoint ti consente di scegliere se l'endpoint può essere raggiunto dalla rete Internet pubblica o solo tramite il tuo VPC. Puoi attivare l'endpoint pubblico (che è l'impostazione predefinita), l'endpoint privato o entrambi contemporaneamente.

La configurazione dell'endpoint dell'API del cluster determina il percorso utilizzato dai nodi per comunicare con il piano di controllo. Tieni presente che queste impostazioni degli endpoint possono essere modificate in qualsiasi momento tramite la console EKS o l'API.

Endpoint pubblico

Questo è il comportamento di default per nuovi cluster Amazon EKS. Quando è abilitato solo l'endpoint pubblico per il cluster, le richieste API Kubernetes che provengono dal VPC del cluster (ad esempio dal nodo di lavoro al piano di controllo della comunicazione) escono dal VPC, ma non dalla rete di Amazon. Affinché i nodi possano connettersi al piano di controllo, devono disporre di un indirizzo IP pubblico e un percorso verso un gateway Internet o un percorso verso un gateway NAT dove possono utilizzare l'indirizzo IP pubblico del gateway NAT.

Endpoint pubblico e privato

Quando gli endpoint pubblici e privati sono abilitati, le richieste API Kubernetes dall'interno del VPC comunicano al piano di controllo tramite il tuo VPC. X-ENIs Il server API del cluster è accessibile da Internet.

Endpoint privato

Non c'è accesso pubblico al server API da Internet quando è abilitato solo un endpoint privato. Tutto il traffico verso il server API del cluster deve provenire dal VPC del cluster o da una rete connessa. I nodi comunicano con il server API all' X-ENIs interno del tuo VPC. Tieni presente che gli strumenti di gestione del cluster devono avere accesso all'endpoint privato. Scopri di più su come connettersi a un endpoint privato del cluster Amazon EKS dall'esterno di Amazon VPC.

Tieni presente che l'endpoint del server API del cluster viene risolto dai server DNS pubblici in un indirizzo IP privato dal VPC. In passato, l'endpoint poteva essere risolto solo dall'interno del VPC.

Configurazioni VPC

Amazon VPC supporta l'indirizzamento IPv4 e IPv6. Amazon EKS supporta IPv4 per impostazione predefinita. Un VPC deve avere un blocco CIDR IPv4 associato. Facoltativamente, puoi associare più blocchi CIDR (Classless Inter-Domain Routing) IPv4 e più blocchi CIDR IPv6 al tuo VPC. Quando si crea un VPC, è necessario specificare un blocco CIDR IPv4 per il VPC dagli intervalli di indirizzi IPv4 privati come specificato in RFC 1918. La dimensione del blocco consentita è compresa tra un /16 prefisso (65.536 indirizzi IP) e un prefisso (16 indirizzi IP). /28

Quando si crea un nuovo VPC, è possibile collegare un singolo blocco CIDR IPv6 e fino a cinque quando si modifica un VPC esistente. La lunghezza del prefisso della dimensione del blocco CIDR IPv6 può essere compresa tra /44 e /60 e per le sottoreti IPv6 può essere compresa tra /44/ e /64. Puoi richiedere un blocco CIDR IPv6 dal pool di indirizzi IPv6 gestito da Amazon. Per ulteriori informazioni, consulta la sezione VPC CIDR block della VPC User Guide.

I cluster Amazon EKS supportano sia IPv4 che IPv6. Per impostazione predefinita, i cluster EKS utilizzano l'IP IPv4. Specificando IPv6 al momento della creazione del cluster, sarà possibile utilizzare i cluster IPv6. I cluster IPv6 richiedono VPC e sottoreti dual-stack.

Amazon EKS consiglia di utilizzare almeno due sottoreti che si trovano in zone di disponibilità diverse durante la creazione del cluster. Le sottoreti che trasmetti durante la creazione del cluster sono note come sottoreti del cluster. Quando crei un cluster, Amazon EKS crea fino a 4 ENI tra account (x-account o x-ENIS) nelle sottoreti specificate. Gli X-eni vengono sempre implementati e utilizzati per il traffico di amministrazione del cluster, ad esempio log delivery, exec e proxy. Consulta la guida per l'utente EKS per i dettagli completi sui requisiti relativi a VPC e sottorete.

I nodi di lavoro Kubernetes possono essere eseguiti nelle sottoreti del cluster, ma non è consigliato. Durante gli upgrade dei cluster, Amazon EKS fornisce ENI aggiuntivi nelle sottoreti del cluster. Quando il cluster si ridimensiona orizzontalmente, i nodi di lavoro e i pod possono consumare gli IP disponibili nella sottorete del cluster. Quindi, per assicurarti che ci siano abbastanza IP disponibili, potresti prendere in considerazione l'utilizzo di sottoreti di cluster dedicate con /28 netmask.

I nodi di lavoro Kubernetes possono essere eseguiti in una sottorete pubblica o privata. Il fatto che una sottorete sia pubblica o privata si riferisce al fatto che il traffico all'interno della sottorete venga instradato attraverso un gateway Internet. Le sottoreti pubbliche dispongono di una tabella di routing per accedere a Internet tramite il gateway Internet, a differenza delle sottoreti private.

Il traffico che ha origine da qualche altra parte e raggiunge i nodi si chiama ingresso. Il traffico che proviene dai nodi e esce dalla rete viene chiamato in uscita. I nodi con indirizzi IP pubblici o elastici (EIP) all'interno di una sottorete configurata con un gateway Internet consentono l'ingresso dall'esterno del VPC. Le sottoreti private di solito hanno un routing verso un gateway NAT, che non consente al traffico in ingresso ai nodi delle sottoreti dall'esterno del VPC, pur consentendo al traffico proveniente dai nodi di uscire dal VPC (uscita).

Nel mondo IPv6, ogni indirizzo è instradabile su Internet. Gli indirizzi IPv6 associati ai nodi e ai pod sono pubblici. Le sottoreti private sono supportate 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. Le migliori pratiche per l'implementazione delle sottoreti IPv6 sono disponibili nella guida utente VPC.

Puoi configurare VPC e sottoreti in tre modi diversi:

Utilizzando solo sottoreti pubbliche

Nelle stesse sottoreti pubbliche, vengono creati sia i nodi che le risorse in ingresso (come i sistemi di bilanciamento del carico). Etichetta la sottorete pubblica con kubernetes.io/role/elbper creare sistemi di bilanciamento del carico che si affacciano su Internet. In questa configurazione, l'endpoint del cluster può essere configurato come pubblico, privato o entrambi (pubblico e privato).

Utilizzo di sottoreti private e pubbliche

I nodi vengono creati su sottoreti private, mentre le risorse Ingress vengono istanziate in sottoreti pubbliche. È possibile abilitare l'accesso pubblico, privato o entrambi (pubblico e privato) all'endpoint del cluster. A seconda della configurazione dell'endpoint del cluster, il traffico del nodo entrerà tramite il gateway NAT o l'ENI.

Utilizzo solo di sottoreti private

Sia i nodi che l'ingresso vengono creati in sottoreti private. Utilizzo del tag kubernetes.io/role/internal-elbsubnet per costruire bilanciatori di carico interni. L'accesso all'endpoint del cluster richiederà una connessione VPN. È necessario attivare AWS PrivateLink for EC2 e tutti i repository Amazon ECR e S3. Deve essere abilitato solo l'endpoint privato del cluster. Suggeriamo di esaminare i requisiti del cluster privato EKS prima di effettuare il provisioning dei cluster privati.

Comunicazione tra VPC

Esistono molti scenari in cui sono necessari più VPC e cluster EKS separati distribuiti su questi VPC.

Puoi utilizzare Amazon VPC Lattice per connettere in modo coerente e sicuro i servizi su più VPC e account (senza richiedere connettività aggiuntiva fornita da servizi come il peering VPC, AWS o AWS Transit Gateway). PrivateLink Scopri di più qui.

Amazon VPC Lattice opera nello spazio degli indirizzi locali del collegamento in IPv4 e IPv6, fornendo connettività tra servizi che possono avere indirizzi IPv4 sovrapposti. Per l'efficienza operativa, consigliamo vivamente di implementare cluster e nodi EKS su intervalli IP che non si sovrappongano. Nel caso in cui l'infrastruttura includa VPC con intervalli IP sovrapposti, è necessario progettare la rete di conseguenza. Suggeriamo Private NAT Gateway o VPC CNI in modalità di rete personalizzata insieme al gateway di transito per integrare i carichi di lavoro su EKS per risolvere le sfide CIDR sovrapposte preservando gli indirizzi IP RFC1918 instradabili.

Prendi in considerazione l'utilizzo di AWS PrivateLink, noto anche come servizio endpoint, se sei il fornitore di servizi e desideri condividere il servizio e l'ingresso Kubernetes (ALB o NLB) con il VPC del cliente in account separati.

Condivisione del VPC su più account

Molte aziende hanno adottato Amazon VPC condivisi come mezzo per semplificare l'amministrazione di rete, ridurre i costi e migliorare la sicurezza su più account AWS in un'organizzazione AWS. Utilizzano AWS Resource Access Manager (RAM) per condividere in modo sicuro le risorse AWS supportate con singoli account AWS, unità organizzative (OU) o l'intera AWS Organization.

Puoi distribuire cluster Amazon EKS, gruppi di nodi gestiti e altre risorse AWS di supporto (come gruppi di sicurezza LoadBalancers, endpoint, ecc.) in sottoreti VPC condivise da un altro account AWS utilizzando la RAM AWS. La figura seguente mostra un esempio di architettura di alto livello. Ciò consente ai team di rete centrali di controllare i costrutti di rete come VPC, sottoreti e così via, mentre consente ai team di applicazioni o piattaforme di distribuire i cluster Amazon EKS nei rispettivi account AWS. Una panoramica completa di questo scenario è disponibile in questo repository github.

Considerazioni sull'utilizzo di sottoreti condivise

Gruppi di sicurezza

Un gruppo di sicurezza controlla il traffico consentito per raggiungere e lasciare le risorse a cui è associato. Amazon EKS utilizza gruppi di sicurezza per gestire la comunicazione tra il piano di controllo e i nodi. Quando crei un cluster, Amazon EKS crea un gruppo di sicurezza denominato eks-cluster-sg-my-cluster-uniqueID. EKS associa questi gruppi di sicurezza agli ENI e ai nodi gestiti. Le regole predefinite consentono il flusso del traffico tra il cluster e i nodi e il traffico in uscita verso qualsiasi destinazione.

Quando si crea un cluster, è possibile specificare i propri gruppi di sicurezza. Consulta i consigli per i gruppi di sicurezza quando specifichi i propri gruppi di sicurezza.

Raccomandazioni

Prendi in considerazione Multi-AZ l'implementazione

Le regioni AWS forniscono più zone di disponibilità (AZ) fisicamente separate e isolate, collegate con reti a bassa latenza, alto throughput e altamente ridondante. Con le zone di disponibilità, puoi progettare e gestire applicazioni che eseguono automaticamente il failover tra le zone di disponibilità senza interruzioni. Amazon EKS consiglia vivamente di distribuire i cluster EKS in più zone di disponibilità. Prendi in considerazione la possibilità di specificare le sottoreti in almeno due zone di disponibilità quando crei il cluster.

Kubelet in esecuzione sui nodi aggiunge automaticamente etichette all'oggetto nodo, ad esempio. topology.kubernetes.io/region=us-west-2 Consigliamo di utilizzare le etichette dei nodi insieme ai vincoli di diffusione della topologia Pod per controllare la distribuzione dei Pod tra le zone. Questi suggerimenti consentono allo scheduler Kubernetes di posizionare i Pod per una migliore disponibilità prevista, riducendo il rischio che un errore correlato influisca sull'intero carico di lavoro. Consulta Assegnazione di nodi ai pod per vedere esempi di vincoli relativi al selettore di nodi e allo spread AZ.

È possibile definire le sottoreti o le zone di disponibilità quando si creano nodi. I nodi vengono inseriti nelle sottoreti del cluster se non è configurata alcuna sottorete. Il supporto EKS per i gruppi di nodi gestiti distribuisce automaticamente i nodi su più zone di disponibilità in base alla capacità disponibile. Karpenter rispetterà il posizionamento dello spread AZ scalando i nodi su AZ specifici se i carichi di lavoro definiscono i limiti di diffusione della topologia.

Gli AWS Elastic Load Balancer sono gestiti dal controller AWS Load Balancer per un cluster Kubernetes. Fornisce un Application Load Balancer (ALB) per le risorse in ingresso di Kubernetes e un Network Load Balancer (NLB) per i servizi Kubernetes di tipo Loadbalancer. Il controller Elastic Load Balancer utilizza i tag per individuare le sottoreti. Il controller ELB richiede un minimo di due zone di disponibilità (AZ) per fornire correttamente le risorse in ingresso. Valuta la possibilità di impostare sottoreti in almeno due AZ per sfruttare la sicurezza e l'affidabilità della ridondanza geografica.

Distribuisci i nodi in sottoreti private

Un VPC che include sottoreti private e pubbliche è il metodo ideale per implementare carichi di lavoro Kubernetes su EKS. Prendi in considerazione l'impostazione di un minimo di due sottoreti pubbliche e due sottoreti private in due zone di disponibilità distinte. La tabella di routing correlata di una sottorete pubblica contiene un percorso verso un gateway Internet. I pod sono in grado di interagire con Internet tramite un gateway NAT. Le sottoreti private sono supportate da gateway Internet di sola uscita in ambiente IPv6 (EIGW).

L'istanziazione di nodi in sottoreti private offre il massimo controllo sul traffico verso i nodi ed è efficace per la maggior parte delle applicazioni Kubernetes. Le risorse in ingresso (come i sistemi di bilanciamento del carico) vengono istanziate nelle sottoreti pubbliche e indirizzano il traffico verso i Pod che operano su sottoreti private.

Prendi in considerazione la modalità solo privata se richiedi sicurezza e isolamento della rete rigorosi. In questa configurazione, tre sottoreti private vengono distribuite in zone di disponibilità distinte all'interno del VPC della regione AWS. Le risorse distribuite nelle sottoreti non possono accedere a Internet, né Internet può accedere alle risorse nelle sottoreti. Affinché la tua applicazione Kubernetes possa accedere ad altri servizi AWS, devi configurare gli endpoint gateway delle PrivateLink interfacce and/or . Puoi configurare sistemi di bilanciamento del carico interni per reindirizzare il traffico verso i Pods utilizzando AWS Load Balancer Controller. Le sottoreti private devono essere contrassegnate con tag (kubernetes.io/role/internal-elb: 1) affinché il controller fornisca i bilanciatori del carico. Affinché i nodi possano registrarsi nel cluster, l'endpoint del cluster deve essere impostato sulla modalità privata. Consulta la guida ai cluster privati per conoscere i requisiti e le considerazioni completi.

Prendi in considerazione la modalità pubblica e privata per Cluster Endpoint

Amazon EKS offre modalità endpoint cluster solo pubbliche, pubbliche e private e solo private. La modalità predefinita è solo pubblica, tuttavia consigliamo di configurare gli endpoint del cluster in modalità pubblica e privata. Questa opzione consente alle chiamate API Kubernetes all'interno del VPC del cluster (come la comunicazione da nodo a piano di controllo) di utilizzare l'endpoint e il traffico VPC privati per rimanere all'interno del VPC del cluster. Il server API del cluster, invece, può essere raggiunto da Internet. Tuttavia, consigliamo vivamente di limitare i blocchi CIDR che possono utilizzare l'endpoint pubblico. Scopri come configurare l'accesso agli endpoint pubblici e privati, inclusa la limitazione dei blocchi CIDR.

Ti suggeriamo un endpoint solo privato quando hai bisogno di sicurezza e isolamento della rete. Ti consigliamo di utilizzare una delle opzioni elencate nella guida per l'utente di EKS per connetterti a un server API in modo privato.

Configura attentamente i gruppi di sicurezza

Amazon EKS supporta l'utilizzo di gruppi di sicurezza personalizzati. Qualsiasi gruppo di sicurezza personalizzato deve consentire la comunicazione tra i nodi e il piano di controllo Kubernetes. Controlla i requisiti delle porte e configura le regole manualmente quando la tua organizzazione non consente una comunicazione aperta.

EKS applica i gruppi di sicurezza personalizzati forniti durante la creazione del cluster alle interfacce gestite (X-ENIs). Tuttavia, non li associa immediatamente ai nodi. Durante la creazione di gruppi di nodi, si consiglia vivamente di associare manualmente i gruppi di sicurezza personalizzati. Valuta la possibilità di abilitare la sicurezza GroupSelectorTerms per consentire ai modelli di nodi Karpenter di rilevare gruppi di sicurezza personalizzati durante la scalabilità automatica dei nodi.

Consigliamo vivamente di creare un gruppo di sicurezza per consentire tutto il traffico di comunicazione tra nodi. Durante il processo di bootstrap, i nodi richiedono la connettività Internet in uscita per accedere all'endpoint del cluster. Valuta i requisiti di accesso verso l'esterno, come la connessione locale e l'accesso al registro dei contenitori, e imposta le regole in modo appropriato. Prima di apportare modifiche alla produzione, ti consigliamo vivamente di controllare attentamente le connessioni nel tuo ambiente di sviluppo.

Implementa i gateway NAT in ogni zona di disponibilità

Se distribuisci nodi in sottoreti private (IPv4 e IPv6), prendi in considerazione la creazione di un gateway NAT in ciascuna zona di disponibilità (AZ) per garantire un'architettura indipendente dalla zona e ridurre le spese tra le aree di disponibilità. Ogni gateway NAT in una zona AZ è implementato con ridondanza.