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 con scalabilità automatica 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 con scalabilità automatica 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 e la dimensione desiderata del gruppo con scalabilità automatica 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 qualcosa superiore a 10), il processo lancerebbe 20 nuovi nodi.

2. Dopo il dimensionamento del gruppo con scalabilità automatica, controlla 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 Pods. Inoltre, etichetta i nodi con node.kubernetes.io/exclude-from-external-load-balancers=true per rimuovere i nodi dai sistemi di bilanciamento 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.

Fase di aggiornamento

La fase di aggiornamento prevede i seguenti passaggi:

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

2. Svuota i Pods dal nodo. Se i Pods 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 Pods.

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 con scalabilità automatica 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

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