Interview › Istio & Service Mesh
How do you upgrade Istio safely (canary control plane, revision tags)?
Istio & Service Mesh · Intermediate level
Answer
I upgrade Istio safely by installing the new control plane as a canary revision, moving a small set of workloads to that revision, validating telemetry and traffic, then promoting the revision tag and rolling the rest gradually. I avoid in-place upgrades that change every workload at once.
Technical explanation
Revision-based upgrades let old and new control planes coexist during validation.
Workload migration requires restart because sidecar injection happens at pod creation.
Rollback is moving the namespace revision tag back and restarting affected workloads, assuming CRDs and APIs remain compatible.
Hands-on example
Upgrade example:
$ istioctl install --set revision=1-28 -y
$ kubectl label namespace canary istio.io/rev=1-28 --overwrite
$ kubectl rollout restart deploy -n canary
$ istioctl proxy-status
After validation:
$ istioctl tag set stable --revision 1-28
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?