kubernetes rolling updates

in Architetture Software, Informatica

Rolling Updates in Kubernetes

Reading Time: 2 minutes

All’interno di Kubernetes i deployments consentono di gestire in maniera dettagliata i pods che compongono l’applicazione. Attraverso gli yaml file è possibile stabilire come dovranno essere eseguiti pods, il loro numero, quando dovranno essere terminati e la loro configurazione. I Replicaset sono un elemento fondamentale per la configurazione del numero di pods che devono essere eseguiti contemporaneamente e soprattutto le modalità di aggiornamento che dovranno seguire.

I deployments vengono spesso considerati come un meccanismo per poter pilotare il Replicaset, che a sua volta gestirà il numero di pods contemporanei. Gestendo il deployment, viene gestito anche il Replicaset in maniera del tutto trasparente per l’utente. L’introduzione di un ulteriore strato tra deployment e pods consente, ad esempio, di controllare le modalità di aggiornamento dei pods stessi. In particolare le modalità di update Recreate e RollingUpdate.

Strategie di update

Una delle attività ricorrenti che deve essere effettuata all’interno di un cluster è l’aggiornamento dei servizi che compongono le applicazioni. K8s prevede la possibilità di effettuare l’aggiornamento dei pods seguendo differenti strategie:

  • Recreate: il metodo piu’ semplice che termina tutti i pods precedentemente in esecuzione e successivamente ne aggiunge di nuovi. Può essere usata, ad esempio, quando non è possibile avere contemporaneamente due pods uguali nello stato di running.
  • RollingUpdate: un metodo piu’ soft rispetto al precedente e che consente di terminare in maniera graduale i pods in running creando contestualmente quelli nuovi.

La scelta del tipo di strategia da utilizzare è dettata dall’architettura dell’ applicazione. Durante l’aggiornamento potrebbe non essere possibile avere due pods con versioni differenti perchè potrebbero verificarsi problemi nella gestione delle richieste. In questo, si potrebbe pensare di non utilizzare il RollingUpdate ma di passare direttamente a Recreate (anche se sarebbe comunque da gestire un minimo downtime).

La strategia RollingUpdate, di fatto un aggiornamento incrementale o sequenziale, permette di avere sempre disponibili un numero di pods fisso, garantendo di fatto l’affidabilità.

Opzioni disponibili

Per impostazione predefinita, il deployment controlla che la percentuale di pods non disponibili, in qualsiasi momento, sia al massimo del 25% e che non venga eseguito l’over provisioning di una percentuale superiore al 25% del numero dei pod previsti nello stato desiderato. 

I pods obsoleti non vengono eliminati fino a quando è disponibile un numero sufficiente di nuovi pod per mantenere la soglia di disponibilità, e non crea nuovi pod fino a quando non viene rimosso il numero sufficiente di pod obsoleti.

RollingUpdate consente di definire le soglie di “intervento” tramite le opzioni maxSurge e maxUnavailable. Queste due opzioni possono essere specificate sia come un numero intero, ma anche come percentuale (il numero di pods viene sempre calcolato come arrotondato per difetto).

  • MaxSurge è il numero massimo di pods che verranno creati in una singola volta
  • MaxUnavaible è il numero massimo di pods che verranno tolti dall’esecuzione in una singola volta

Supponiamo ad esempio di avere un applicazione composta da 8 pods. Per impostazione predefinita il valore di maxSurge e maxUnavailable è impostato a 25%. Questo significa che numericamente maxSurge corrisponde a 2 pods cosi come maxUnavailable corrisponde a 2 pods. Durante l’aggiornamento, ci troveremo quindi nella situazione di avere al massimo 10 pods pronti per l’aggiornamento (8 pods + 2 pods maxSurge) e almeno 6 pod sempre pronti durante l’aggiornamento (8 pods – 2 pods maxUnavailable).

E’ importante notare che quando viene considerato il numero di pods che devono essere nello stato di running durante l’aggiornamento, viene utilizzato il numero di replica all’interno della versione aggiornata e non in quella esistente.

In un prossimo post verrà analizzato il concetto di ready pods di k8s.