Semplifica il ciclo di vita dei nodi con gruppi di nodi gestiti

I gruppi di nodi gestiti di Amazon EKS automatizzano il provisioning e la gestione del ciclo di vita dei nodi ( EC2 istanze Amazon) per i cluster Amazon EKS Kubernetes.

Con i gruppi di nodi gestiti di Amazon EKS, non è necessario effettuare il provisioning o registrare separatamente EC2 le istanze Amazon che forniscono capacità di calcolo per eseguire le applicazioni Kubernetes. È possibile creare, aggiornare o terminare automaticamente i nodi per il cluster con una singola operazione. Gli aggiornamenti e le interruzioni dei nodi svuotano automaticamente i nodi per garantire che le applicazioni rimangano disponibili.

Ogni nodo gestito viene fornito come parte di un gruppo Amazon EC2 Auto Scaling gestito per te da Amazon EKS. Ogni risorsa, incluse le istanze e i gruppi Auto Scaling, viene eseguita all'interno AWS del tuo account. Ogni gruppo di nodi viene eseguito su più zone di disponibilità definite.

I gruppi di nodi gestiti possono anche sfruttare opzionalmente la riparazione automatica, che monitora continuamente lo stato di integrità dei nodi. In pratica, reagisce automaticamente ai problemi rilevati e sostituisce i nodi quando possibile. Ciò aiuta la disponibilità complessiva del cluster con un intervento manuale minimo. Per ulteriori informazioni, consulta Enable node auto repair and investigate node health issues.

Puoi aggiungere un gruppo di nodi gestiti a cluster nuovi o esistenti utilizzando la console Amazon EKS, la AWS CLI eksctl AWS , l'API o l'infrastruttura come strumenti di codice, tra cui. AWS CloudFormation I nodi avviati come parte di un gruppo di nodi gestiti vengono automaticamente taggati per l’individuazione automatica tramite Cluster Autoscaler di Kubernetes. É possibile utilizzare il gruppo di nodi per applicare le etichette Kubernetes ai nodi e aggiornarle in qualsiasi momento.

Non ci sono costi aggiuntivi per l'utilizzo dei gruppi di nodi gestiti di Amazon EKS, paghi solo per le AWS risorse fornite. Questi includono EC2 istanze Amazon, volumi Amazon EBS, orari dei cluster Amazon EKS e qualsiasi altra AWS infrastruttura. Non sono previste tariffe minime né impegni anticipati.

Per iniziare a utilizzare un nuovo cluster Amazon EKS e un gruppo di nodi gestiti, vedi Inizia a usare Amazon EKS Console di gestione AWS e AWS CLI.

Per aggiungere un gruppo di nodi gestiti a un cluster esistente, vedi Creare un gruppo di nodi gestiti per il cluster.

Concetti sui gruppi di nodi gestiti

• I gruppi di nodi gestiti di Amazon EKS creano e gestiscono EC2 istanze Amazon per te.

• Ogni nodo gestito viene fornito come parte di un gruppo Amazon EC2 Auto Scaling gestito per te da Amazon EKS. Inoltre, tutte le risorse, incluse EC2 le istanze Amazon e i gruppi di Auto Scaling, vengono eseguite all'interno AWS del tuo account.

• Il gruppo Auto Scaling di un gruppo di nodi gestiti si estende su ogni sottorete specificata al momento della creazione del gruppo.

• Amazon EKS applica tag alle risorse del gruppo di nodi gestiti in modo che siano configurate per utilizzare Cluster Autoscaler di Kubernetes.

  Importante

  Se si esegue un’applicazione stateful in più zone di disponibilità supportate dai volumi Amazon EBS e che utilizza il Cluster Autoscaler di Kubernetes, è necessario configurare più gruppi di nodi, ognuno dei quali definito per una singola zona di disponibilità. Inoltre, è necessario abilitare la funzionalità --balance-similar-node-groups.

• È possibile utilizzare un modello di avvio personalizzato per un maggiore livello di flessibilità e personalizzazione durante l’implementazione dei nodi gestiti. Ad esempio, è possibile specificare argomenti kubelet aggiuntivi e utilizzare un’AMI personalizzata. Per ulteriori informazioni, consulta Personalizzazione dei nodi gestiti con modelli di avvio. Se non si utilizza un modello di avvio personalizzato quando si crea per la prima volta un gruppo di nodi gestiti, è disponibile un modello di avvio generato automaticamente. Non modificare manualmente questo modello generato automaticamente o si verificheranno errori.

• Amazon EKS segue il modello di responsabilità condivisa CVEs e le patch di sicurezza sui gruppi di nodi gestiti. Quando i nodi gestiti eseguono un’AMI ottimizzata per Amazon EKS, Amazon EKS è responsabile della creazione di versioni con patch dell’AMI quando vengono segnalati bug o problemi. A questo scopo vengono pubblicate delle correzioni. Sei invece responsabile della distribuzione di queste versioni AMI con patch ai gruppi di nodi gestiti. Quando i nodi gestiti eseguono un’AMI personalizzata, sei responsabile della creazione di versioni con patch dell’AMI quando vengono segnalati bug o problemi, oltre che della distribuzione dell’AMI. Per ulteriori informazioni, consulta Aggiornamento del gruppo di nodi gestito per il cluster.

• I gruppi di nodi gestiti Amazon EKS possono essere avviati in sottoreti pubbliche e private. Se si avvia un gruppo di nodi gestiti in una sottorete pubblica in data 22 aprile 2020 o successiva, sarà necessario che la sottorete abbia MapPublicIpOnLaunch impostato su vero affinché le istanze possano partecipare correttamente a un cluster. Se la sottorete pubblica è stata creata utilizzando eksctl o i AWS CloudFormation modelli forniti da Amazon EKS a partire dal 26 marzo 2020, questa impostazione è già impostata su true. Se le sottoreti pubbliche sono state create prima del 26 marzo 2020 devi modificare manualmente l’impostazione. Per ulteriori informazioni, consulta Modifica dell'attributo di IPv4 indirizzamento pubblico per la sottorete.

• Quando implementi un gruppo di nodi gestito in sottoreti private, devi assicurarti che possa accedere ad Amazon ECR per estrarre le immagini dei container. È possibile farlo collegando un gateway NAT alla tabella di routing della sottorete o aggiungendo i seguenti endpoint VPC AWS PrivateLink :

  • Interfaccia endpoint dell'API di Amazon ECR: com.amazonaws.region-code.ecr.api

  • Interfaccia endpoint dell’API del registro Docker di Amazon ECR: com.amazonaws.region-code.ecr.dkr

  • Endpoint del gateway Amazon S3: com.amazonaws.region-code.s3

  Per altri servizi ed endpoint di uso comune, consulta la sezione Implementazione di cluster privati con accesso limitato a Internet.

• I gruppi di nodi gestiti non possono essere distribuiti su AWS Outposts o in AWS Wavelength. È possibile creare gruppi di nodi gestiti in AWS Local Zones. Per ulteriori informazioni, consulta Avvia cluster EKS a bassa latenza con AWS Local Zones.

• È possibile creare più gruppi di nodi gestiti all’interno di un singolo cluster. Ad esempio, puoi creare un gruppo di nodi con l’AMI Linux standard ottimizzata per Amazon EKS per alcuni carichi di lavoro e un altro gruppo con la variante GPU per i carichi di lavoro che richiedono il supporto della GPU.

• Se il tuo gruppo di nodi gestiti rileva un errore di controllo dello stato delle EC2 istanze Amazon, Amazon EKS restituisce un codice di errore per aiutarti a diagnosticare il problema. Per ulteriori informazioni, consulta Codici di errore dei gruppi di nodi gestiti.

• Amazon EKS aggiunge etichette Kubernetes alle istanze del gruppo di nodi gestiti. Queste etichette fornite da Amazon EKS hanno il prefisso eks.amazonaws.com.

• Amazon EKS svuota automaticamente i nodi utilizzando l’API Kubernetes durante le interruzioni o gli aggiornamenti.

• I budget di interruzione del pod non vengono rispettati quando si termina un nodo con AZRebalance o si riduce il numero di nodi desiderato. Queste operazioni cercano di espellere pod dal nodo. Tuttavia, se trascorrono più di 15 minuti, il nodo viene terminato a prescindere dal fatto che tutti i pod sul nodo siano stati terminati. Per prolungare il periodo fino alla terminazione del nodo, aggiungi un hook del ciclo di vita al gruppo con scalabilità automatica. Per ulteriori informazioni, consulta Add lifecycle hook nella Amazon EC2 Auto Scaling User Guide.

• Per eseguire correttamente il processo di scarico dopo aver ricevuto una notifica di interruzione spot o una notifica di ribilanciamento della capacità, CapacityRebalance deve essere impostato su true.

• L’aggiornamento di gruppi di nodi gestiti rispettano i budget di interruzione dei pod impostati per i pod. Per ulteriori informazioni, consulta Comprendi ogni fase degli aggiornamenti dei nodi.

• I gruppi di nodi gestiti Amazon EKS non prevedono costi aggiuntivi. Paghi solo per le AWS risorse che fornisci.

• Se si desidera crittografare i volumi Amazon EBS per i nodi, è possibile implementare i nodi utilizzando un modello di avvio. Per implementare nodi gestiti con volumi Amazon EBS crittografati senza utilizzare un modello di avvio, crittografare tutti i nuovi volumi Amazon EBS creati nell’account. Per ulteriori informazioni, consulta Encryption by default nella Amazon EC2 User Guide.

Tipi di capacità del gruppo di nodi gestiti

Quando si crea un gruppo di nodi gestito, è possibile scegliere il tipo di capacità su on demand o Spot. Amazon EKS implementa un gruppo di nodi gestiti con un gruppo Amazon EC2 Auto Scaling che contiene solo istanze On-Demand o solo istanze Amazon EC2 Spot. All’interno di un singolo cluster Kubernetes, è possibile pianificare i pod per le applicazioni tolleranti ai guasti sia per i gruppi di nodi gestiti Spot che per i gruppi di nodi on-demand. Per impostazione predefinita, un gruppo di nodi gestiti distribuisce istanze Amazon EC2 On-Demand.

On demand

Con Istanze on demand, sono previsti costi per la capacità di calcolo entro la seconda ora senza impegni a lungo termine.

Per impostazione predefinita, se non specifichi un Tipo capacità, per il gruppo di nodi gestiti viene eseguito il provisioning con Istanze on demand. Un gruppo di nodi gestito configura un gruppo Amazon EC2 Auto Scaling per tuo conto con le seguenti impostazioni applicate:

• La strategia di allocazione per il provisioning della capacità On-Demand è impostata su prioritized. Il gruppo di nodi gestiti utilizza l’ordine dei tipi di istanze approvata dall’API per determinare quale tipo di istanza utilizzare prima per soddisfare la capacità on demand. Ad esempio, è possibile specificare tre tipi di istanza nell’ordine seguente: c5.large, c4.large, e c3.large. Quando le istanze on demand vengono avviate, il gruppo di nodi gestiti soddisfa la capacità on demand a partire da c5.large, quindi c4.large, e infine c3.large. Per ulteriori informazioni, consulta il gruppo Amazon EC2 Auto Scaling nella Amazon Auto EC2 Scaling User Guide.

• Amazon EKS aggiunge la seguente etichetta Kubernetes a tutti i nodi del gruppo di nodi gestito che specifica il tipo di capacità: eks.amazonaws.com/capacityType: ON_DEMAND. È possibile utilizzare questa etichetta sui nodi on demand per pianificare applicazioni con stato o fault intolerant.

Spot

Le istanze Amazon EC2 Spot sono una EC2 capacità Amazon inutilizzata che offre forti sconti sui prezzi On-Demand. Le istanze Amazon EC2 Spot possono essere interrotte con un avviso di interruzione di due minuti quando è EC2 necessario ripristinare la capacità. Per ulteriori informazioni, consulta le istanze Spot nella Amazon EC2 User Guide. Puoi configurare un gruppo di nodi gestiti con Amazon EC2 Spot Instances per ottimizzare i costi per i nodi di calcolo in esecuzione nel tuo cluster Amazon EKS.

Per utilizzare istanze spot all’interno di un gruppo di nodi gestiti, creare un gruppo di nodi gestiti impostando il tipo di capacità come spot. Un gruppo di nodi gestito configura un gruppo Amazon EC2 Auto Scaling per tuo conto applicando le seguenti best practice Spot:

• Per garantire che il provisioning dei nodi Spot venga eseguito nei pool di capacità Spot ottimali, la strategia di allocazione è impostata su uno dei seguenti valori:

  • price-capacity-optimized (PCO): quando si creano nuovi gruppi di nodi in un cluster con Kubernetes versione 1.28 o successive, la strategia di allocazione è impostata su price-capacity-optimized. Tuttavia, la strategia di allocazione non viene modificata per i gruppi di nodi già creati con capacity-optimized prima che i gruppi di nodi gestiti da Amazon EKS inizino a supportare PCO.

  • capacity-optimized (CO): quando si creano nuovi gruppi di nodi in un cluster con Kubernetes versione 1.27 o precedenti, la strategia di allocazione è impostata su capacity-optimized.

  Per aumentare il numero di pool di capacità Spot disponibili da cui allocare le capacità, configurare un gruppo di nodi gestiti per l’utilizzo di più tipi di istanza.

• Amazon EC2 Spot Capacity Rebalancing è abilitato in modo che Amazon EKS possa drenare e ribilanciare in modo corretto i nodi Spot per ridurre al minimo l'interruzione delle applicazioni quando un nodo Spot è a elevato rischio di interruzione. Per ulteriori informazioni, consulta Amazon EC2 Auto Scaling Capacity Rebalancing nella Amazon Auto Scaling EC2 User Guide.

  • Quando un nodo Spot riceve un consiglio di ribilanciamento, Amazon EKS tenta automaticamente di avviare un nuovo nodo Spot sostitutivo.

  • Se un avviso di interruzione Spot di due minuti arriva prima che il nodo Spot sostitutivo si trovi in uno stato Ready, Amazon EKS inizia a svuotare il nodo Spot che ha ricevuto il suggerimento di ribilanciamento. Amazon EKS svuota il nodo nel modo migliore possibile. Di conseguenza, non c’è alcuna garanzia che Amazon EKS attenda che il nodo sostitutivo si unisca al cluster prima di svuotare il nodo esistente.

  • Quando un nodo Spot sostitutivo viene avviato ed è allo stato Ready su Kubernetes, Amazon EKS isola e svuota il nodo Spot che ha ricevuto il suggerimento di ribilanciamento. L’isolamento del nodo Spot assicura che il controller di servizio non invii nuove richieste a questo nodo Spot. Il nodo viene rimosso anche dall’elenco di nodi Spot sani e attivi. Lo svuotamento del nodo Spot assicura che i pod in esecuzione vengano espulsi in modo corretto.

• Amazon EKS aggiunge la seguente etichetta Kubernetes a tutti i nodi del gruppo di nodi gestito che specifica il tipo di capacità: eks.amazonaws.com/capacityType: SPOT. È possibile utilizzare questa etichetta per pianificare applicazioni fault tolerant sui nodi Spot.

  Importante

  EC2 emette un avviso di interruzione Spot due minuti prima della chiusura dell'istanza Spot. Tuttavia, i Pod sui nodi Spot potrebbero non ricevere l'intera finestra di 2 minuti necessaria per uno spegnimento regolare. Quando EC2 emette l'avviso, c'è un ritardo prima che Amazon EKS inizi a sfrattare i Pods. Gli sfratti avvengono in sequenza per proteggere il server dell'API Kubernetes, quindi durante più reclami Spot simultanei, alcuni Pod potrebbero ricevere avvisi di sfratto ritardato. I Pod possono essere chiusi forzatamente senza ricevere segnali di terminazione, in particolare su nodi ad alta densità di Pod, durante reclami simultanei o quando si utilizzano periodi di tolleranza di terminazione prolungati. Per i carichi di lavoro Spot, consigliamo di progettare le applicazioni in modo da tollerare le interruzioni, utilizzando periodi di tolleranza di terminazione pari o inferiori a 30 secondi, evitando agganci PreStop di lunga durata e monitorando le metriche di sfratto dei Pod per comprendere i periodi di tolleranza effettivi nei cluster. Per i carichi di lavoro che richiedono una terminazione corretta e garantita, consigliamo invece di utilizzare la capacità On-Demand.

Quando si decide se implementare un gruppo di nodi con capacità On-Demand o Spot, è necessario considerare le seguenti condizioni:

• Le istanze Spot sono consigliate per applicazioni senza stato, fault tolerant e flessibili. Questi includono carichi di lavoro di formazione in batch e machine learning, big data ETLs come Apache Spark, applicazioni di elaborazione delle code ed endpoint API stateless. Poiché Spot è una EC2 capacità Amazon inutilizzata, che può cambiare nel tempo, ti consigliamo di utilizzare la capacità Spot per carichi di lavoro tolleranti alle interruzioni. Più specificamente, la capacità Spot è adatta per carichi di lavoro in grado di tollerare periodi in cui la capacità richiesta non è disponibile.

• Consigliamo di utilizzare On-demand per le applicazioni che sono fault intolerant. Ciò include strumenti di gestione dei cluster come strumenti di monitoraggio e operativi, implementazioni che richiedono StatefulSets e applicazioni con stato, come database.

• Per ottimizzare la disponibilità delle applicazioni durante l’utilizzo di istanze Spot, è consigliabile configurare un gruppo di nodi gestiti Spot per l’utilizzo di più tipi di istanza. Quando si utilizzano più tipi di istanza, si consiglia di applicare le seguenti regole:

  • All’interno di un gruppo di nodi gestiti, se utilizzi Cluster Autoscaler, ti consigliamo di utilizzare un set flessibile di tipi di istanza con la stessa quantità di vCPU e risorse di memoria. Questo per garantire che i nodi del cluster vengano dimensionati come previsto. Ad esempio, se hai bisogno di quattro v CPUs e otto GiB di memoria,,c3.xlarge,c4.xlarge, c5.xlarge c5d.xlarge c5a.xlargec5n.xlarge, o altri tipi di istanza simili.

  • Per migliorare la disponibilità delle applicazioni, si consiglia di implementare più gruppi di nodi gestiti Spot. Per questo, ogni gruppo dovrebbe utilizzare un set flessibile di tipi di istanza con le stesse risorse vCPU e memoria. Ad esempio, se hai bisogno di memoria 4 v CPUs e 8 GiB, ti consigliamo di creare un gruppo di nodi gestiti conc3.xlarge,,,c4.xlarge, c5.xlarge c5d.xlarge c5a.xlargec5n.xlarge, o altri tipi di istanze simili e un secondo gruppo di nodi gestiti conm3.xlarge,,, m4.xlarge m5.xlarge m5d.xlargem5a.xlarge, m5n.xlarge o altri tipi di istanze simili.

  • Quando si implementa il gruppo di nodi con il tipo di capacità Spot che utilizza un modello di avvio personalizzato, utilizza l’API per passare più tipi di istanza. Non passare un singolo tipo di istanza tramite il modello di avvio. Per ulteriori informazioni sull’implementazione di un gruppo di nodi tramite un modello di avvio, vedere Personalizzazione dei nodi gestiti con modelli di avvio.