Interview › Istio & Service Mesh
How do you roll back a bad VirtualService change quickly?
Istio & Service Mesh · Advanced level
Answer
To roll back a bad VirtualService quickly, I keep mesh config in Git, apply changes through CI/CD, and revert to the last known-good manifest. Operationally, the fastest rollback is usually setting weights back to the stable subset or reapplying the previous VirtualService revision.
Technical explanation
Bad VirtualService changes can cause no-route errors, wrong host matches, canary overload, or broken gateway routes.
A rollback should be a small config change, not a redeploy of every service.
I validate rollback by checking proxy routes and live error-rate recovery.
Hands-on example
Rollback commands:
$ git revert <bad-commit>
$ kubectl apply -f virtualservice.yaml
Fast emergency patch:
$ kubectl patch virtualservice checkout -n app --type merge -p '<known-good-json>'
Validate:
$ istioctl proxy-config route deploy/ingressgateway -n istio-system | grep checkout
$ kubectl logs deploy/ingressgateway -c istio-proxy -n istio-system --tail=100
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Istio & Service Mesh interview questions
- What is Istio, and what are the core capabilities it provides?
- What is the difference between the Istio control plane and data plane?
- What is istiod, and what does it do?
- What is Envoy, and what role does it play in Istio?
- What is the sidecar pattern, and how does Istio inject the proxy?
- How does automatic sidecar injection work (namespace label, webhook)?
- What is the Istio ambient (sidecarless) mode, and how does it differ from sidecar mode?
- What is the difference between ztunnel and a waypoint proxy in ambient mode?