Comprendi ogni fase degli aggiornamenti dei nodi - Amazon EKS
Fase di configurazioneFase di scalabilitàFase di aggiornamentoFase di dimensionamento

Contribuisci a migliorare questa pagina

Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.

Comprendi ogni fase degli aggiornamenti dei nodi

La strategia di aggiornamento del nodo (worker) gestito di Amazon EKS ha quattro fasi diverse descritte nelle sezioni seguenti.

Fase di configurazione

La fase di configurazione prevede i seguenti passaggi:

  1. Crea una nuova versione del modello di avvio Amazon EC2 per il gruppo Auto Scaling associato al gruppo di nodi. La nuova versione del modello di avvio utilizza l’AMI di destinazione o una versione del modello di avvio personalizzata per l’aggiornamento.

  2. Il gruppo Auto Scaling viene aggiornato per utilizzare la versione più recente del modello di avvio.

  3. Determina la quantità massima di nodi da aggiornare in parallelo utilizzando la proprietà updateConfig per il gruppo di nodi. Il massimo non disponibile ha una quota di 100 nodi. Il valore di default è un nodo. Per ulteriori informazioni, consulta la proprietà updateConfig nella Documentazione di riferimento delle API di Amazon EKS.

Fase di scalabilità

Quando si aggiornano i nodi in un gruppo di nodi gestiti, i nodi aggiornati vengono avviati nella stessa zona di disponibilità di quelli in fase di aggiornamento. Per garantire questo posizionamento, utilizziamo il ribilanciamento della zona di disponibilità di Amazon EC2. Per ulteriori informazioni, consulta Availability Zone Rebalancing nella Guida per l’utente di Amazon EC2 Auto Scaling. Per soddisfare questo requisito, è possibile avviare fino a due istanze per zona di disponibilità nel gruppo di nodi gestiti.

La fase di scalabilità prevede i seguenti passaggi:

  1. Incrementa la dimensione massima e la dimensione desiderata del gruppo Auto Scaling in base alla scelta maggiore tra:

    • Fino a due volte il numero di zone di disponibilità in cui è stato implementato il gruppo Auto Scaling.

    • Il massimo non disponibile per l’aggiornamento.

      Ad esempio, se il gruppo di nodi ha cinque zone di disponibilità e maxUnavailable è uno, il processo di aggiornamento può avviare al massimo 10 nodi. Tuttavia, quando maxUnavailable è 20 (o comunque superiore a 10), il processo avvia 20 nuovi nodi.

  2. Dopo aver dimensionato il gruppo Auto Scaling, verifica se i nodi che utilizzano la configurazione più recente sono presenti nel gruppo di nodi. Questo passaggio ha esito positivo solo quando soddisfa i seguenti criteri:

    • Almeno un nuovo nodo viene avviato in ogni zona di disponibilità in cui esiste il nodo.

    • Ogni nuovo nodo deve essere nello stato Ready.

    • I nuovi nodi devono avere etichette applicate da Amazon EKS.

      Queste sono le etichette applicate da Amazon EKS sui nodi (worker) di un normale gruppo di nodi:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      Queste sono le etichette applicate da Amazon EKS sui nodi (worker) in un modello di avvio personalizzato o un gruppo di nodi AMI:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. Contrassegna i nodi come non programmabili per evitare di programmare nuovi pod. Inoltre, etichetta i nodi con node.kubernetes.io/exclude-from-external-load-balancers=true per rimuovere i vecchi nodi dai sistemi di bilanciatore del carico prima di terminare i nodi.

Di seguito sono riportati i motivi noti che portano a un errore NodeCreationFailure in questa fase:

Capacità insufficiente nella zona di disponibilità

Esiste la possibilità che la zona di disponibilità non abbia capacità disponibile per i tipi di istanza richiesti. Si consiglia di configurare più tipi di istanze durante la creazione di un gruppo di nodi gestiti.

Limiti delle istanze EC2 dell’account

Potrebbe essere necessario aumentare il numero di istanze Amazon EC2 che il l’account può eseguire contemporaneamente utilizzando Service Quotas. Per ulteriori informazioni, consulta Service Quotas di EC2 nella Guida per l’utente di Amazon Elastic Compute Cloud per le istanze Linux.

Dati utente personalizzati

I dati utente personalizzati possono talvolta interrompere il processo di bootstrap. Questo scenario può portare al mancato avvio di kubelet sul nodo o sui nodi che non ricevono le etichette Amazon EKS previste. Per ulteriori informazioni, consulta Specifica di un'AMI.

Qualsiasi modifica che renda un nodo non integro o non pronto

La pressione del disco del nodo, la pressione della memoria e condizioni simili possono far sì che un nodo non assuma lo stato Ready.

Ogni nodo si avvia al massimo entro 15 minuti

Se un nodo impiega più di 15 minuti per avviarsi e unirsi al cluster, si verificherà il timeout dell’aggiornamento. Questo è il runtime totale per il bootstrap di un nuovo nodo misurato dal momento in cui è necessario un nuovo nodo al momento in cui si unisce al cluster. Quando si aggiorna un gruppo di nodi gestito, il contatore temporale si avvia non appena la dimensione del gruppo Auto Scaling aumenta.

Fase di aggiornamento

La fase di aggiornamento si comporta in due modi diversi, a seconda della strategia di aggiornamento. Esistono due strategie di aggiornamento: predefinita e minimale.

Consigliamo una strategia predefinita nella maggior parte degli scenari. Infatti, questa crea nuovi nodi prima di terminare quelli vecchi, in modo da mantenere la capacità disponibile durante la fase di aggiornamento. La strategia minimale è utile in scenari in cui si è limitati per quanto riguarda risorse o costi, ad esempio con acceleratori hardware come le GPU. Infatti, termina i vecchi nodi prima di creare quelli nuovi, in modo che la capacità totale non aumenti mai oltre la quantità configurata.

La strategia di aggiornamento predefinita prevede i seguenti passaggi:

  1. Aumenta la quantità di nodi (numero desiderato) nel gruppo Auto Scaling, facendo sì che il gruppo di nodi crei nodi aggiuntivi.

  2. Seleziona casualmente un nodo che deve essere aggiornato, fino al massimo non disponibile configurato per il gruppo di nodi.

  3. Svuota i pod dal nodo. Se i pod non lasciano il nodo entro 15 minuti e non c’è un flag di forzatura, la fase di aggiornamento non riesce con errore PodEvictionFailure. Per questo scenario, è possibile applicare il flag di forzatura con la richiesta update-nodegroup-version di eliminare i pod.

  4. Isola il nodo dopo che ogni pod è stato espulso e aspetta 60 secondi. Ciò consente al controller di servizio di non inviare nuove richieste a questo nodo, e lo rimuove dall’elenco di nodi attivi.

  5. Invia una richiesta di interruzione al gruppo con scalabilità automatica per il nodo isolato.

  6. Ripete i passaggi di aggiornamento precedenti fino a quando non vi sono nodi nel gruppo implementato con la versione precedente del modello di avvio.

La strategia di aggiornamento minimale prevede i seguenti passaggi:

  1. All’inizio isola tutti i nodi del gruppo di nodi, in modo che il controller di servizio non invii nuove richieste a questi nodi.

  2. Seleziona casualmente un nodo che deve essere aggiornato, fino al massimo non disponibile configurato per il gruppo di nodi.

  3. Drena i Pod dai nodi selezionati. Se i pod non lasciano il nodo entro 15 minuti e non c’è un flag di forzatura, la fase di aggiornamento non riesce con errore PodEvictionFailure. Per questo scenario, puoi applicare il flag di forzatura con la richiesta update-nodegroup-version di eliminare i pod.

  4. Dopo che ogni pod è stato rimosso e ha atteso 60 secondi, invia una richiesta di interruzione al gruppo Auto Scaling per i nodi selezionati. Il gruppo Auto Scaling crea nuovi nodi (lo stesso numero di nodi selezionati) per sostituire la capacità mancante.

  5. Ripete i passaggi di aggiornamento precedenti fino a quando non vi sono nodi nel gruppo implementato con la versione precedente del modello di avvio.

Errori PodEvictionFailure durante la fase di aggiornamento

Di seguito sono riportati i motivi noti che portano a un errore PodEvictionFailure in questa fase:

PDB aggressivo

Sul pod è definito un PDB aggressivo oppure sono presenti più PDB che puntano allo stesso pod.

Implementazione che tollera tutti i taint

Una volta espulso ogni pod, il nodo dovrebbe essere vuoto in quanto oggetto di taint nei passaggi precedenti. Tuttavia, se l’implementazione tollera ogni taint, è più probabile che il nodo non sia vuoto, causando un errore di espulsione dal pod.

Fase di dimensionamento

La fase di dimensionamento diminuisce di uno la dimensione massima del gruppo Auto Scaling e la dimensione desiderata per tornare ai valori prima dell’avvio dell’aggiornamento.

Se il flusso di lavoro di aggiornamento determina che il Cluster Autoscaler stia dimensionando il gruppo di nodi durante la fase di dimensionamento del flusso di lavoro, esce immediatamente senza riportare il gruppo di nodi alle dimensioni originali.