Rollout Canário Ponderado com Istio

Primeiro, as duas versões precisam estar rodando com labels distintos — `version: v1` nos pods estáveis e `version: v2` nos novos. Depois eu escrevo um DestinationRule que declara os dois subsets, para que o Istio saiba o que v1 e v2 significam. Em seguida, um VirtualService com uma rota ponderada: 95 para v1, 5 para v2. Para aumentar gradualmente, eu ajusto os valores de peso e reaplico. A maioria dos times automatiza isso via script ou integra com Flagger ou Argo Rollouts, para que o ramp seja automatizado com base na taxa de sucesso e nas métricas de latência vindas do Prometheus. O ponto-chave a verificar depois de cada etapa é se os labels dos subsets realmente correspondem a pods reais. Um modo de falha comum é deslocar peso para v2 quando v2 tem zero pods saudáveis porque o label do pod é `app=reviews-v2` em vez de `version: v2`. Você vai ver os erros 503 dispararem na porcentagem de tráfego que foi deslocada. Também vale lembrar que os pesos são porcentagens do tráfego que já passou pelo match, não valores absolutos. Se o seu VirtualService tem um match de header antes da rota ponderada, os pesos só se aplicam às requisições que caíram nessa regra.