Free sample question

How do you implement a canary deployment in Kubernetes, and how does traffic splitting actually work?

Mid-Senior · Canary · Traffic Management · Chapter 1: Deployment Strategies & Scheduling, question 2 of 6 · from Container Orchestration Journey: Docker to Kubernetes

What the interviewer is really testing

whether you understand the mechanics of traffic splitting and automated analysis, or whether you'd just deploy two Deployments and call it a canary.

The 30-second answer

I'd reach for Argo Rollouts or Flagger rather than raw Deployments, because they wire traffic control to automated metric analysis. With Argo Rollouts I define steps (say, 5% for five minutes, 25% for ten, 50% for fifteen) and attach an AnalysisTemplate that queries Prometheus error rate and p99 latency. If either threshold breaches, the Rollout aborts and shifts all traffic back to stable within about 30 seconds. Istio VirtualService or the Gateway API HTTPRoute gives me per-request weight control underneath; with ingress-nginx retired in March 2026, an HTTPRoute is also the mesh-free path.

Follow-ups the interviewer will probe

How do you handle database schema changes alongside a canary rollout?
Deploy the schema change first using the expand-contract pattern: add new columns as nullable, deploy the canary (which writes both old and new columns), verify, then drop the old column in a follow-up migration. That way stable and canary pods share the same schema throughout the rollout, and a rollback never leaves orphaned data or constraint violations.
What's the difference between canary and A/B testing in Kubernetes?
Canary is a safety gate: you're validating that a new version doesn't degrade error rates or latency before full rollout. A/B testing compares business outcomes (conversion, engagement) between feature variants at a fixed traffic split. Both use the same traffic mechanisms, but the promotion decision is technical for canary and product-driven for A/B. The two are often confused but have different owners and different success criteria.
How would you configure header-based routing so your team can test the canary before any percentage rollout?
In Argo Rollouts I'd add a canaryService and a VirtualService match rule: requests with an X-Canary: true header always hit the canary subset regardless of the weight step. Flagger supports the same via its match spec. That lets QA and on-call engineers exercise the new version in production traffic shape (real databases, real dependencies) without exposing end users to it yet.

Recall hook

“Weight the requests, not the replicas.”

Traffic splitting lives in the routing layer (service mesh, Gateway API, or ingress annotations); analysis runs against Prometheus; rollback fires automatically when a threshold breaks.

What the book adds to this question

In the ebook every question runs three pages. Between the 30-second answer and the follow-ups it adds a deep dive with a diagram, a decision framework, and a pitfalls-and-signals table. Container Orchestration Journey: Docker to Kubernetes has 52 questions across 8 chapters and includes the free Interview-Day Playbook.

Buy this ebookSee all 52 questions and prices

Want full three-page questions? Download the free 8-question PDF sample (from Cloud Interview Mastery).

Sample questions from the other books