Si esegue un Deployment con 5 repliche per un'API critica su AKS. È necessario garantire che almeno 4 repliche rimangano disponibili durante interruzioni pianificate come gli aggiornamenti del sistema operativo dei nodi e durante gli aggiornamenti progressivi del Deployment. Cosa si dovrebbe configurare?

La configurazione corretta per garantire la disponibilità dell'API è combinare un PodDisruptionBudget (PDB) e una strategia di rolling update del Deployment. Il PDB con minAvailable: 4 assicura che almeno 4 delle 5 repliche siano sempre disponibili durante le interruzioni volontarie, come gli aggiornamenti dei nodi. La strategia di rolling update del Deployment con maxUnavailable: 1 e maxSurge: 1 consente di aggiornare un pod alla volta, mantenendo sempre almeno 4 pod attivi (5 - 1 = 4) e aggiungendo al massimo un pod temporaneo durante l'aggiornamento. Le altre opzioni sono errate perché: Un PDB con maxUnavailable: 2 permetterebbe a soli 3 pod di rimanere attivi, violando il requisito di 4. maxSurge: 0 rallenterebbe l'aggiornamento senza beneficio. Non configurare un PDB non proteggerebbe l'applicazione durante gli aggiornamenti dei nodi. maxUnavailable: 0 e maxSurge: 2 causerebbe un aggiornamento molto lento e un consumo maggiore di risorse. La strategia Recreate causerebbe un downtime completo dell'applicazione, terminando tutti i pod prima di crearne di nuovi, il che è inaccettabile per un'API critica.