Una nuova versione di container per GKE non è stata sottoposta a test di carico completi. È necessario un deployment automatizzato che riduca al minimo il rischio per le prestazioni in produzione. Cosa si dovrebbe fare?

La risposta corretta è implementare un deployment canary tramite una pipeline di continuous delivery, monitorando le prestazioni con Cloud Monitoring. Questo approccio invia una piccola percentuale di traffico alla nuova versione, permettendo di rilevare problemi di performance o errori in un ambiente di produzione controllato prima di esporre tutti gli utenti. Se le metriche sono positive, il traffico viene gradualmente aumentato. Le altre opzioni sono meno adatte: Utilizzare solo Cloud Load Balancing per aumentare lentamente il traffico non è sufficiente senza una strategia di deployment specifica come il canary, e non include il feedback automatico per l'aumento del traffico. Il deployment blue/green sposta tutto il traffico in una volta sulla nuova versione dopo i test, il che non minimizza il rischio di performance in produzione come richiesto, poiché un problema potrebbe influenzare tutti gli utenti immediatamente. Un RollingUpdate con kubectl sposta il traffico gradualmente, ma non offre il controllo granulare e la capacità di rollback automatico basato su metriche che un deployment canary in una pipeline CI/CD fornisce per minimizzare il rischio.