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

VPCe considerazioni sulla sottorete

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

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

Fai riferimento alle VPCconsiderazioni sui cluster e sulle considerazioni sui gruppi EKS di sicurezza di Amazon per l'architettura delle sottoreti VPC e delle sottoreti da utilizzare. EKS

Panoramica

EKSArchitettura del cluster

Un EKS cluster è composto da dueVPCs:

I nodi del cliente VPC devono poter connettersi all'endpoint del API server gestito in. AWS VPC 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 EKS controllo tramite (a) un endpoint EKS pubblico o (b) un'interfaccia di rete elastica Cross-Account (X-) gestita da. ENI EKS Quando viene creato un cluster, è necessario specificare almeno due sottoreti. VPC EKSinserisce una X- ENI in ogni sottorete specificata durante la creazione del cluster (denominate anche sottoreti del cluster). Il API server Kubernetes utilizza questi Cross-Account ENIs per comunicare con i nodi distribuiti nelle sottoreti del cluster gestite dal cliente. VPC

All'avvio del nodo, viene eseguito lo script di EKS bootstrap 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 a o con l'endpoint privato all'interno di. VPC VPC Kubelet riceve API istruzioni e fornisce regolarmente aggiornamenti di stato e battiti cardiaci all'endpoint.

EKSComunicazione sul piano di controllo

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

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

Endpoint pubblico

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

Endpoint pubblico e privato

Quando sono abilitati sia gli endpoint pubblici che quelli privati, le API richieste di Kubernetes dall'interno VPC comunicano al piano di controllo tramite l'X- all'interno dell'utente. ENIs VPC Il API server del cluster è accessibile da Internet.

Endpoint privato

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

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

VPCconfigurazioni

VPCSupporto IPv4 e IPv6 indirizzamento di Amazon. Amazon EKS supporta IPv4 per impostazione predefinita. A VPC deve essere associato un IPv4 CIDR blocco. Facoltativamente, puoi associare più blocchi IPv4 Classless Inter-Domain Routing (CIDR) e più blocchi al tuo. IPv6 CIDR VPC Quando crei unVPC, devi specificare un IPv4 CIDR blocco per gli intervalli VPC di IPv4 indirizzi privati come specificato in 1918. RFC La dimensione del blocco consentita è compresa tra un /16 prefisso (65.536 indirizzi IP) e un /28 prefisso (16 indirizzi IP).

Quando ne crei uno nuovoVPC, puoi allegare un singolo IPv6 CIDR blocco e fino a cinque quando ne modifichi uno esistente. VPC La lunghezza del prefisso della dimensione del IPv6 CIDR blocco può essere compresa tra /44 e /60 e per le IPv6 sottoreti può essere compresa tra /44/ e /64. Puoi richiedere un IPv6 CIDR blocco dal pool di IPv6 indirizzi gestito da Amazon. Per ulteriori informazioni, consulta la sezione dedicata ai VPCCIDRblocchi della Guida per VPC l'utente.

EKSI cluster Amazon supportano entrambi IPv4 eIPv6. Per impostazione predefinita, EKS i cluster utilizzano l'IPv4IP. La specificazione IPv6 al momento della creazione del cluster abiliterà l'uso IPv6 dei cluster. IPv6i cluster richiedono dual-stack e sottoretiVPCs.

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 account incrociati (x-account o x-ENIs) ENIs nelle sottoreti specificate. Gli x- ENIs vengono sempre distribuiti e utilizzati per il traffico di amministrazione del cluster, ad esempio per la consegna dei log, l'esecuzione e il proxy. Consulta la guida per l'EKSutente per i dettagli completi VPCe sui requisiti delle sottoreti.

I nodi di lavoro Kubernetes possono essere eseguiti nelle sottoreti del cluster, ma non è consigliato. Durante gli upgrade dei cluster, Amazon fornisce EKS ulteriori componenti ENIs nelle sottoreti del cluster. Quando il cluster si ridimensiona orizzontalmente, i nodi di lavoro e i pod possono consumare quanto disponibile IPs nella sottorete del cluster. Quindi, per assicurarti che ci sia abbastanza spazio disponibile, IPs 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 (EIPs) all'interno di una sottorete configurata con un gateway Internet consentono l'ingresso dall'esterno di. VPC Le sottoreti private di solito hanno un routing verso un NATgateway, che non consente il traffico in ingresso ai nodi delle sottoreti dall'esterno, ma consente VPC comunque al traffico proveniente dai nodi di uscire dal (uscita). VPC

Nel IPv6 mondo, ogni indirizzo è instradabile su Internet. Gli IPv6 indirizzi associati ai nodi e ai pod sono pubblici. Le sottoreti private sono supportate implementando un gateway Internet solo in uscita (EIGW) in aVPC, che consente il traffico in uscita e blocca tutto il traffico in entrata. Le migliori pratiche per l'implementazione delle IPv6 sottoreti sono disponibili nella guida per l'utente. VPC

È possibile configurare VPC le sottoreti in tre modi diversi:

Utilizzo solo di 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 NAT gateway o il. ENI

Utilizzando solo 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 eseguire l'attivazione AWS PrivateLinkper EC2 tutti i repository Amazon ECR e S3. Deve essere abilitato solo l'endpoint privato del cluster. Suggeriamo di esaminare i requisiti del cluster EKS privato prima di effettuare il provisioning dei cluster privati.

Comunicazione attraverso VPCs

Esistono molti scenari in cui è necessario distribuire EKS cluster multipli VPCs e separati su questi. VPCs

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

Amazon VPC Lattice opera nello spazio degli indirizzi locali del collegamento in IPv4 eIPv6, fornendo connettività tra servizi che possono avere indirizzi sovrapposti. IPv4 Per l'efficienza operativa, consigliamo vivamente di distribuire EKS cluster e nodi su intervalli IP che non si sovrappongano. Nel caso in cui l'infrastruttura VPCs includa 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 per risolvere i CIDR problemi di sovrapposizione preservando EKS gli indirizzi IP instradabili. RFC1918

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

Condivisione tra più account VPC

Molte aziende hanno adottato Amazon condiviso VPCs come mezzo per semplificare l'amministrazione della rete, ridurre i costi e migliorare la sicurezza tra più AWS account di un'AWSorganizzazione. Utilizzano AWS Resource Access Manager (RAM) per condividere in modo sicuro AWSle risorse supportate con singoli AWS account, unità organizzative (OUs) o l'intera AWS organizzazione.

Puoi distribuire EKS cluster Amazon, gruppi di nodi gestiti e altre AWS risorse di supporto (come gruppi di sicurezza LoadBalancers, endpoint, ecc.) in VPC sottoreti condivise da un altro account utilizzando. AWS AWS RAM 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 VPCs le sottoreti, ecc., mentre consente ai team delle applicazioni o della piattaforma di distribuire EKS i cluster Amazon 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 denominatoeks-cluster-sg-my-cluster-uniqueID. EKSassocia questi gruppi di sicurezza ai nodi ENIs e 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 l'implementazione Multi-AZ

AWSLe regioni offrono più zone di disponibilità (AZ) fisicamente separate e isolate, collegate tramite reti a bassa latenza, ad alto throughput e altamente ridondanti. Con le zone di disponibilità, è possibile progettare e utilizzare applicazioni che eseguono automaticamente il failover tra le zone di disponibilità senza interruzioni. Amazon consiglia EKS vivamente di distribuire EKS i cluster 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. EKSil supporto 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 in modo da specificare AZs se i carichi di lavoro definiscono i limiti di diffusione della topologia.

AWSGli Elastic Load Balancer sono gestiti dal Load AWS Balancer Controller 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. ELBil controller richiede un minimo di due zone di disponibilità (AZs) per fornire correttamente le risorse in ingresso. Valuta la possibilità di impostare almeno due sottoreti AZs per sfruttare la sicurezza e l'affidabilità della ridondanza geografica.

Distribuisci i nodi in sottoreti private

L'VPCinclusione di sottoreti pubbliche e private è il metodo ideale per distribuire 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 NAT gateway. Le sottoreti private sono supportate dai gateway Internet di sola uscita presenti nell'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 della AWS regione. VPC 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 AWS servizi, è necessario configurare interfacce e/o endpoint gateway. PrivateLink È possibile configurare sistemi di bilanciamento del carico interni per reindirizzare il traffico verso i Pods utilizzando Load AWS Balancer Controller. Le sottoreti private devono essere contrassegnate con il tag (kubernetes.io/role/internal-elb: 1) affinché il controller possa fornire i bilanciatori del carico. Affinché i nodi possano registrarsi nel cluster, l'endpoint del cluster deve essere impostato in 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 public-and-private solo pubbliche e private. La modalità predefinita è solo pubblica, tuttavia consigliamo di configurare l'endpoint del cluster in modalità pubblica e privata. Questa opzione consente alle API chiamate Kubernetes all'interno del cluster VPC (come le node-to-control-plane comunicazioni) di utilizzare l'VPCendpoint privato e il traffico per rimanere all'interno del cluster. VPC Il API server del cluster, invece, può essere raggiunto da Internet. Tuttavia, consigliamo vivamente di limitare i CIDR blocchi che possono utilizzare l'endpoint pubblico. Scopri come configurare l'accesso pubblico e privato agli endpoint, 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'EKSutente per connetterti a un API server 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.

EKSapplica 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 securityGroupSelectori Termini per consentire ai modelli di nodi Karpenter di individuare i 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 NAT i gateway in ogni zona di disponibilità

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

Usa Cloud9 per accedere ai cluster privati

AWSCloud9 è una soluzione IDE basata sul Web che può essere eseguita in modo sicuro in sottoreti private senza accesso in ingresso, utilizzando Systems Manager. AWS L'uscita può anche essere disabilitata sull'istanza Cloud9. Scopri di più sull'utilizzo di Cloud9 per accedere a cluster e sottoreti privati.

📝 Modifica questa pagina su GitHub