Gruppi di nodi gestiti

• I gruppi di nodi gestiti Amazon EKS creano e gestiscono le istanze Amazon EC2 per conto dell'utente.

• Ogni nodo gestito viene assegnato come parte di un gruppo Amazon EC2 Auto Scaling gestito per l'utente da Amazon EKS. Inoltre, ogni risorsa, incluse le istanze Amazon EC2 e i gruppi di Auto Scaling, viene eseguita all'interno del tuo account. AWS

• 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 il Cluster Autoscaler di Kubernetes.

  Importante

  Se esegui un'applicazione stateful in più zone di disponibilità supportate dai volumi Amazon EBS e che utilizza Scalabilità automatica di Kubernetes, devi 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 di nodi gestiti con un modello 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 verificano errori.

• Amazon EKS segue il modello di responsabilità condivisa per i CVE 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. L'utente è invece responsabile della distribuzione di queste versioni AMI con patch ai gruppi di nodi gestiti. Quando i nodi gestiti eseguono un'AMI personalizzata, l'utente è 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 di un gruppo di nodi gestiti.

• 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 assegnazione degli indirizzi IPv4 pubblici 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 Requisiti dei cluster privati.

• I gruppi di nodi gestiti non possono essere distribuiti su AWS Outpostso all'interno AWS Wavelength delle nostre 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 Amazon Linux standard ottimizzata per Amazon EKS per alcuni carichi di lavoro e un altro con la variante GPU per carichi di lavoro che richiedono il supporto GPU.

• Se il gruppo di nodi gestiti rileva un errore di controllo dello stato dell'istanza Amazon EC2, Amazon EKS restituirà un messaggio di errore che consente di diagnosticare il problema. Per ulteriori informazioni, consulta Codici di errore dei gruppi di nodi gestiti.

• Amazon EKS aggiunge le 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 Pods dal nodo. Tuttavia, se trascorrono più di 15 minuti, il nodo viene terminato a prescindere dal fatto che tutti i Pods 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 Aggiungere un hook del ciclo di vita nella Guida per l'utente di Dimensionamento automatico Amazon EC2.

• 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 Pod impostati per i Pods. Per ulteriori informazioni, consulta Comportamento dell'aggiornamento del nodo gestito.

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

Come funziona

Per impostazione predefinita, se non specifichi un Capacity Type (Tipo di capacità), il provisioning del gruppo di nodi gestiti viene eseguito con istanze on demand. Un gruppo di nodi gestiti configura un gruppo Amazon EC2 Auto Scaling per conto dell'utente 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 maggiori informazioni, consultare Gruppo Amazon EC2 Auto Scaling nella Guida per l'utente di Amazon EC2 Auto Scaling.

• Amazon EKS aggiunge l'etichetta Kubernetes seguente a tutti i nodi del gruppo di nodi gestiti 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.

Come funziona

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. Applicando le seguenti best practices Spot, un gruppo di nodi gestiti configura un gruppo Amazon EC2 Auto Scaling per conto dell'utente:

• 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 successive, 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 svuotare e bilanciare correttamente i nodi Spot per ridurre al minimo le interruzioni delle applicazioni quando un nodo Spot è a rischio elevato di interruzione. Per maggiori informazioni, consultare Rebalancing Capacity di Amazon EC2 Auto Scaling nella Guida per l'utente di Amazon EC2 Auto Scaling.

  • 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 è assicurato 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 elenco di nodi Spot sani e attivi. Lo svuotamento del nodo Spot assicura che i Pods in esecuzione vengano espulsi in modo aggraziato.

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

Considerazioni per la selezione di un tipo di capacità

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. Queste includono carichi di lavoro di formazione batch e machine learning, ETL di big data come Apache Spark, applicazioni di elaborazione delle code ed endpoint API senza stato. Poiché Spot è una capacità Amazon EC2 di riserva che può cambiare nel tempo, consigliamo di utilizzare la capacità Spot per carichi di lavoro con tolleranza di interruzione. 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 si utilizza il Cluster Autoscaler, si consiglia 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 sono necessarie quattro vCPU e otto memorie GiB, utilizzare c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.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 sono necessarie 4 vCPU e 8 memorie GiB, si consiglia di creare un gruppo di nodi gestiti con c3.xlarge, c4.xlarge, c5.xlarge, c5d.xlarge, c5a.xlarge, c5n.xlarge o altri tipi di istanza simili; e un secondo gruppo di nodi gestiti con m3.xlarge, m4.xlarge, m5.xlarge, m5d.xlarge, m5a.xlarge, m5n.xlarge o altri tipi di istanza simili.

  • Quando si implementa il gruppo di nodi con il tipo di capacità Spot che utilizza un modello di avvio personalizzato, utilizzare 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 di nodi gestiti con un modello di avvio.