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
Suggerimento
Esplora le
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 a distribuire cluster in VPC esistenti.
Fai riferimento alle considerazioni sul cluster VPC e alle considerazioni sui gruppi di sicurezza di Amazon EKS per la progettazione di un VPC e delle sottoreti da utilizzare con EKS.
Panoramica di
Architettura del cluster EKS
Un cluster EKS è costituito da due VPC:
-
Un AWS-managed VPC che ospita il piano di controllo di Kubernetes. Questo VPC non appare nell'account del cliente.
-
Un VPC gestito dal cliente che ospita i nodi Kubernetes. È qui che vengono eseguiti i container e altre infrastrutture AWS gestite dal cliente, come i sistemi di bilanciamento del carico utilizzati dal cluster. Questo VPC viene visualizzato nell'account del cliente. È necessario creare un VPC gestito dal cliente prima di creare un cluster. L'eksctl crea un VPC se non ne fornisci uno.
I nodi del VPC del cliente devono essere in grado di connettersi all'endpoint del server API gestito nell'AWS VPC. Ciò consente ai nodi di registrarsi sul 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 (denominata anche sottoreti del cluster). Il server API Kubernetes utilizza questi ENI per comunicare con i nodi distribuiti nelle Cross-Account sottoreti VPC del cluster gestite dal cliente.
All'avvio del nodo, viene eseguito lo script bootstrap EKS e vengono installati i file di configurazione del nodo Kubernetes. Come parte del processo di avvio di ogni istanza, vengono lanciati gli agenti di runtime del contenitore, kubelet e gli agenti del nodo 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 sul piano di controllo EKS
EKS ha 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 (predefinito), l'endpoint privato o entrambi contemporaneamente.
La configurazione dell'endpoint dell'API del cluster determina il percorso che i nodi intraprendono per comunicare con il piano di controllo. Tieni presente che queste impostazioni degli endpoint possono essere modificate in qualsiasi momento tramite la console o l'API EKS.
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 (come il nodo di lavoro per la comunicazione del piano di controllo) escono dal VPC, ma non dalla rete di Amazon. Affinché i nodi possano connettersi al piano di controllo, devono avere un indirizzo IP pubblico e un percorso verso un gateway Internet o un percorso verso un gateway NAT in cui 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 l'interno del VPC. X-ENIs Il server API del cluster è accessibile da Internet.
Endpoint privato
Non c'è accesso pubblico al tuo server API da Internet quando è abilitato solo l'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 tramite il X-ENIs tuo VPC. Tieni presente che gli strumenti di gestione dei cluster devono avere accesso all'endpoint privato. Scopri di più su come connetterti 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 del 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 (/16 prefisso (65.536 indirizzi IP) e un prefisso (16 indirizzi IP). /28
Quando si crea un nuovo VPC, è possibile allegare 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 sui blocchi CIDR VPC della Guida per l'utente di VPC.
I cluster Amazon EKS supportano sia IPv4 che IPv6. Per impostazione predefinita, i cluster EKS utilizzano IP IPv4. La specificazione dell'IPv6 al momento della creazione del cluster consentirà l'uso dei cluster IPv6. I cluster IPv6 richiedono VPC e sottoreti dual-stack.
Amazon EKS richiede di specificare almeno due sottoreti in due diverse zone di disponibilità quando si crea un cluster. Le sottoreti specificate sono note come sottoreti di cluster. Amazon EKS effettua il provisioning di due ENI tra account (x-ENI) in diverse zone di disponibilità per consentire la comunicazione con i nodi di lavoro. Quando crei un cluster, Amazon EKS crea 2-4 X-ENI nelle sottoreti specificate. Amazon EKS distribuisce sempre gli x-ENIS e li utilizza per il traffico di amministrazione dei cluster, ad esempio per la distribuzione dei log, l'exec e il proxy. Per ulteriori informazioni sui requisiti di VPC e sottorete, consulta i requisiti di VPC e sottorete nella Amazon EKS User Guide.
I nodi di lavoro Kubernetes possono essere eseguiti nelle sottoreti del cluster, ma non è consigliato. Durante gli aggiornamenti del cluster, Amazon EKS fornisce ENI aggiuntivi nelle sottoreti del cluster. Quando il cluster si espande, i nodi e i pod di lavoro 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 cluster dedicate con maschera di rete /28.
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. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html Le sottoreti pubbliche dispongono di una tabella di instradamento verso Internet tramite il gateway Internet, mentre le sottoreti private no.
Il traffico che proviene da qualche altra parte e raggiunge i tuoi nodi si chiama ingresso. Il traffico che proviene dai nodi e lascia la rete si chiama 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 il traffico in ingresso verso i nodi delle sottoreti dall'esterno del VPC, pur consentendo al traffico dai nodi di lasciare il 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 per l'utente di VPC. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html
È possibile configurare VPC e sottoreti in tre modi diversi:
Utilizzando solo sottoreti pubbliche
Nelle stesse sottoreti pubbliche, vengono creati sia i nodi che le risorse di ingresso (come i sistemi di bilanciamento del carico). Contrassegna la sottorete pubblica con cui creare sistemi di bilanciamento del carico kubernetes.io/role/elb che si affacciano su Internet. In questa configurazione, l'endpoint del cluster può essere configurato per essere 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-elb subnet per creare sistemi di bilanciamento del carico interni. L'accesso all'endpoint del cluster richiederà una connessione VPN. Devi attivare AWS PrivateLink per EC2 e tutti i repository Amazon ECR e S3. Deve essere abilitato solo l'endpoint privato del cluster. Suggeriamo di esaminare i requisiti dei cluster privati EKS prima di eseguire il provisioning dei cluster privati.
Comunicazione tra VPC
Esistono molti scenari in cui è necessario distribuire più VPC e cluster EKS separati su questi VPC.
Puoi usare Amazon VPC Lattice
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 distribuire 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. Consigliamo Private NAT Gateway o VPC CNI in modalità di rete personalizzata in combinazione con il gateway di transito per integrare i carichi di lavoro su EKS e risolvere i problemi CIDR sovrapposti 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 tuo cliente in account separati.
Condivisione di VPC su più account
Molte aziende hanno adottato Amazon VPC condivisi come mezzo per semplificare l'amministrazione della 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 organizzazione AWS.
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 AWS RAM. La figura seguente illustra un esempio di architettura di alto livello. Ciò consente ai team di rete centralizzati di controllare i costrutti di rete come VPC, sottoreti, ecc., mentre consente ai team di applicazioni o piattaforme di distribuire cluster Amazon EKS nei rispettivi account AWS. Una panoramica completa di questo scenario è disponibile in questo repository github. https://github.com/aws-samples/eks-shared-subnets
Considerazioni sull'utilizzo di sottoreti condivise
-
I cluster e i nodi di lavoro Amazon EKS possono essere creati all'interno di sottoreti condivise che fanno tutte parte dello stesso VPC. Amazon EKS non supporta la creazione di cluster su più VPC.
-
Amazon EKS utilizza AWS VPC Security Groups (SG) per controllare il traffico tra il piano di controllo di Kubernetes e i nodi di lavoro del cluster. I gruppi di sicurezza vengono utilizzati anche per controllare il traffico tra i nodi di lavoro e altre risorse VPC e indirizzi IP esterni. È necessario creare questi gruppi di sicurezza nell' application/participant account. Assicurati che i gruppi di sicurezza che intendi utilizzare per i tuoi pod si trovino anche nell'account del partecipante. Puoi configurare le regole in entrata e in uscita all'interno dei tuoi gruppi di sicurezza per consentire il traffico necessario da e verso i gruppi di sicurezza situati nell'account Central VPC.
-
Crea ruoli IAM e politiche associate all'interno dell'account partecipante in cui risiede il tuo cluster Amazon EKS. Questi ruoli e politiche IAM sono essenziali per concedere le autorizzazioni necessarie ai cluster Kubernetes gestiti da Amazon EKS, nonché ai nodi e ai pod in esecuzione su Fargate. Le autorizzazioni consentono ad Amazon EKS di effettuare chiamate ad altri servizi AWS per tuo conto.
-
Puoi seguire i seguenti approcci per consentire l'accesso tra account a risorse AWS come bucket Amazon S3, tabelle Dynamodb, ecc., dai pod k8s:
-
Approccio basato sulle risorse: se il servizio AWS supporta le policy relative alle risorse, puoi aggiungere una policy basata sulle risorse appropriata per consentire l'accesso tra account ai ruoli IAM assegnati ai pod kubernetes. In questo scenario, il provider OIDC, i ruoli IAM e le politiche di autorizzazione sono presenti nell'account dell'applicazione. Per trovare i servizi AWS che supportano le policy basate sulle risorse, consulta i servizi AWS che funzionano con IAM e cerca i servizi che hanno Sì nella colonna Resource Based.
-
Approccio ai provider OIDC: le risorse IAM come OIDC Provider, IAM Roles, Permission e Trust policy verranno create negli altri account AWS dei partecipanti laddove esistano le risorse. Questi ruoli verranno assegnati ai pod Kubernetes nell'account dell'applicazione, in modo che possano accedere alle risorse di più account. Per una panoramica completa di questo approccio, consulta il blog
Cross account IAM roles for Kubernetes Service Accounts.
-
-
Puoi distribuire le risorse Amazon Elastic Loadbalancer (ELB) (ALB o NLB) per indirizzare il traffico verso i pod k8s nell'applicazione o negli account di rete centrale. Fai riferimento alla procedura dettagliata di Expose Amazon EKS Pods Through Cross-Account Load Balancer
per istruzioni dettagliate sulla distribuzione delle risorse ELB in un account di rete centrale. Questa opzione offre una maggiore flessibilità, in quanto garantisce all'account Central Networking il pieno controllo sulla configurazione di sicurezza delle risorse Load Balancer. -
Quando si utilizza
custom networking featureAmazon VPC CNI, è necessario utilizzare le mappature degli ID della zona di disponibilità (AZ) elencate nell'account di rete centrale per crearle ciascuna.ENIConfigCiò è dovuto alla mappatura casuale delle AZ fisiche ai nomi AZ in ciascun account AWS.
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 la distribuzione
Le regioni AWS forniscono più zone di disponibilità (AZ) fisicamente separate e isolate, collegate a reti a bassa latenza, alta produttività e altamente ridondanti. 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à. Considera 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
Puoi definire le sottoreti o le zone di disponibilità quando crei i nodi. I nodi vengono inseriti nelle sottoreti del cluster se nessuna subnet è configurata. Il supporto EKS per i gruppi di nodi gestiti distribuisce automaticamente i nodi su più zone di disponibilità in base alla capacità disponibile. Karpenter
Gli AWS Elastic Load Balancer sono gestiti da AWS Load Balancer Controller per un cluster Kubernetes. Fornisce un Application Load Balancer (ALB) per le risorse di ingresso Kubernetes e un Network Load Balancer (NLB) per i servizi Kubernetes di tipo Loadbalancer. Il controller https://aws.amazon.com/premiumsupport/knowledge-center/eks-vpc-subnet-discovery/
Distribuisci i nodi su sottoreti private
Un VPC che include sottoreti private e pubbliche è il metodo ideale per distribuire carichi di lavoro Kubernetes su EKS. Valuta la possibilità di impostare almeno 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 solo in uscita nell'ambiente IPv6 (EIGW).
L'istanziazione dei 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 (ad esempio come sistemi di bilanciamento del carico) vengono istanziate in sottoreti pubbliche e indirizzano il traffico verso i Pod che operano su sottoreti private.
Prendi in considerazione la modalità privata solo se richiedi una sicurezza rigorosa e un isolamento della rete. 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é l'applicazione Kubernetes possa accedere ad altri servizi AWS, è necessario configurare gli endpoint gateway delle interfacce. PrivateLink and/or Puoi configurare sistemi di bilanciamento del carico interni per reindirizzare il traffico verso Pods utilizzando AWS Load Balancer Controller. Le sottoreti private devono essere contrassegnate (kubernetes.io/role/internal-elb: 1) affinché il controller possa fornire i servizi di bilanciamento del carico. Affinché i nodi possano registrarsi nel cluster, l'endpoint del cluster deve essere impostato in modalità privata. Consulta la guida privata al cluster per requisiti e considerazioni completi.
Prendi in considerazione la modalità pubblica e privata per Cluster Endpoint
Amazon EKS offre modalità di 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 (ad esempio la comunicazione da nodo a piano di controllo) di utilizzare l'endpoint VPC privato e di mantenere il traffico 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 pubblico e privato agli endpoint, inclusa la limitazione dei blocchi CIDR.
Suggeriamo un endpoint esclusivamente privato quando hai bisogno di sicurezza e isolamento della rete. Consigliamo di utilizzare una delle opzioni elencate nella guida per l'utente EKS per connettersi privatamente a un server API.
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 di Kubernetes. Controlla i requisiti delle porte e configura le regole manualmente quando la tua organizzazione non consente la 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
Consigliamo vivamente di creare un gruppo di sicurezza per consentire tutto il traffico di comunicazione tra i nodi. Durante il processo di bootstrap, i nodi richiedono una connettività Internet in uscita per accedere all'endpoint del cluster. Valuta i requisiti di accesso verso l'esterno, come la connessione in sede e l'accesso al registro dei container, e imposta le regole in modo appropriato. Prima di mettere in produzione le modifiche, ti consigliamo vivamente di controllare attentamente le connessioni nel tuo ambiente di sviluppo.
Implementa i gateway NAT in ciascuna zona di disponibilità
Se distribuisci nodi in sottoreti private (IPv4 e IPv6), valuta la possibilità di creare un gateway NAT in ciascuna zona di disponibilità (AZ) per garantire un'architettura indipendente dalla zona e ridurre le spese incrociate. Ogni gateway NAT in una AZ è implementato con ridondanza.
