Q: Your microservices communicate over an Istio service mesh with mutual TLS (mTLS). You need to roll out new backend versions using A/B testing (routing internal employee requests with header 'X-Canary: always' to the new version) before gradually shifting 10% -> 50% -> 100% of public traffic. How do you implement Flagger with Istio VirtualServices to automate this progressive rollout?

Establish the automated delivery controller and target deployment spec:

• Flagger Installation: Deployed Flagger controller with Istio provider enabled in istio-system.
• Canary Custom Resource: Created Canary CR targeting order-service deployment with provider: istio, progressDeadlineSeconds: 60, and interval: 1m.

Direct specific users or QA testers to canary pods before public release:

• A/B Testing Match Rule: Configured Flagger route: { match: [ { headers: { 'x-canary': { exact: 'always' } } } ] }.
• Internal Validation: Internal employees and automated E2E test suites pass X-Canary: always, testing the live canary pods in production with zero risk to general customers.

Shift public traffic in controlled increments while measuring telemetry:

• Traffic Shifting: Configured stepWeight: 10, maxWeight: 50, shifting traffic 10% -> 20% -> 30% -> 40% -> 50%.
• Istio Metrics: Flagger queries Istio Prometheus telemetry: istio_requests_total and istio_request_duration_milliseconds_bucket, validating error rate < 1% and p99 latency < 500ms.

Execute automated smoke tests before promoting canary to primary:

• Pre-Rollout Webhook: Flagger calls a test runner pod executing k6 integration tests against order-service-canary:8080.
• Final Promotion: When 50% step succeeds with zero errors, Flagger scales the primary deployment to the new image version, points 100% traffic to primary, and scales canary pods down.