Devi distribuire un'applicazione a microservizi esposta su internet su GKE ed eseguire test A/B senza tempi di inattività, inviando un sottoinsieme del traffico di produzione alle nuove release. Quale approccio di deployment soddisfa questi requisiti?

L'opzione corretta descrive un deployment canary utilizzando Anthos Service Mesh (basato su Istio). Istio consente un controllo granulare del traffico, permettendo di instradare una piccola percentuale di traffico alla nuova versione dell'applicazione (deployment canary) per test A/B senza tempi di inattività. Questo soddisfa i requisiti di invio di un sottoinsieme del traffico di produzione alle nuove release. Le altre opzioni sono meno efficaci: La prima opzione descrive un aggiornamento "in-place" che non supporta test A/B o l'invio di un sottoinsieme di traffico. La seconda opzione descrive un deployment blu/verde ma l'aggiornamento della configurazione Ingress indirizzerebbe tutto il traffico alla nuova versione, non un sottoinsieme. La quarta opzione descrive un rolling update standard di Kubernetes, che sostituisce gradualmente i Pod ma non offre il controllo del traffico necessario per test A/B con una percentuale specifica.