Comportamento dell'aggiornamento del nodo gestito - Amazon EKS

Comportamento dell'aggiornamento del nodo gestito

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 la versione del modello di avvio fornita dal cliente 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, consultare 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 Availability Zone Rebalancing di Amazon EC2. Per ulteriori informazioni, consultare 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 del gruppo Auto Scaling e la dimensione desiderata secondo l'opzione 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 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. Applica un taint eks.amazonaws.com/nodegroup=unschedulable:NoSchedule su ogni nodo del gruppo di nodi senza le etichette più recenti. Ciò impedisce il taint dei nodi già aggiornati da un precedente aggiornamento non riuscito.

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 la capacità dei tipi di istanza richiesti. Si consiglia di configurare più tipi di istanze durante la creazione di un gruppo di nodi gestiti.

  • Clienti che raggiungono i limiti di istanza EC2 nel proprio account – Potrebbe essere necessario aumentare il numero di istanze Amazon EC2 che il tuo account può eseguire contemporaneamente utilizzando Service Quotas. Per ulteriori informazioni, consultare 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 sulla gestione di AMI/LT personalizzate, vedere Specifica di un'AMI.

  • Eventuali modifiche che rendono un nodo non integro o non pronto – La pressione del disco del nodo, la pressione della memoria e condizioni simili possono portare al mancato passaggio di un nodo allo stato Ready.

Fase di aggiornamento

La fase di aggiornamento prevede i seguenti passaggi:

  1. Seleziona casualmente un nodo, fino al massimo non disponibile configurato per il gruppo di nodi.

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

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

  4. Invia una richiesta di interruzione al gruppo Auto Scaling per il nodo isolato.

  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.

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

  • PDB aggressivo – Il PDB aggressivo è definito sul pod o ci sono 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 escluso 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.