Rolling update
La strategia predefinita per aggiornare un deployment Kubernetes: i vecchi pod vengono sostituiti gradualmente, pochi alla volta, da quelli nuovi, invece di spegnere tutto e riavviare; si ottiene un aggiornamento senza downtime senza bisogno di un ambiente parallelo completo.
Il funzionamento: Kubernetes avvia uno o pochi pod nuovi, attende che siano pronti (readiness probe), poi rimuove un numero uguale di pod vecchi e ripete finché l'intero deployment non è stato sostituito. Il ritmo dipende da due parametri: maxSurge (quanti pod IN PIÙ possono esistere temporaneamente rispetto al numero desiderato) e maxUnavailable (quanti possono mancare durante la transizione). Vantaggi: il servizio resta attivo per tutto il tempo (ci sono sempre pod pronti a ricevere traffico) e non servono ambienti completi aggiuntivi (a differenza del blue-green). Rollback: basta tornare alla versione precedente e Kubernetes procede allo stesso modo. Compromesso: durante il rilascio girano due versioni insieme (devono essere compatibili) e una nuova versione difettosa emerge gradualmente, non subito come con uno switch blue-green; per questo lo si affianca spesso a canary e progressive delivery. Imparentato con il blue-green deployment e la progressive delivery.