Zero-downtime migration to Kubernetes with multi-cloud ingress
A team moving from hand-managed VMs to Kubernetes needed it done without an outage. A staged, GitOps-driven migration with weighted ingress shifted traffic gradually and reversibly, with zero downtime.
The problem
A company on hand-managed VMs wanted Kubernetes for scaling and reproducibility but had a hard no-downtime constraint and a team nervous about a big-bang migration after past failed attempts.
The approach
- ▸Codified the target cluster and networking in Terraform so the whole environment was reproducible and reviewable instead of clicked together by hand.
- ▸Adopted GitOps with Argo CD so cluster state always matched git and any change went through a reviewable, revertible merge.
- ▸Ran the old VMs and the new cluster in parallel behind weighted ingress, shifting traffic in small increments while watching error rates and latency.
- ▸Kept every step reversible. A bad signal meant shifting weight back in seconds, not a panicked rollback at 2am.
The result
- ✓Full cutover completed with zero customer-facing downtime
- ✓Infrastructure fully reproducible from Terraform afterward
- ✓Deploys became git merges through GitOps, not manual SSH rituals
- ✓The team came away with a migration pattern they can reuse on the next service
stack: Kubernetes · Terraform · Argo CD · Envoy
Why the earlier attempts failed
The earlier attempts failed because they flipped everything at once and hoped. Running both environments in parallel behind weighted ingress turns a terrifying cutover into a dial you turn slowly while watching the graphs, and turn back the instant anything looks off. The GitOps foundation meant every change was reviewable and revertible, and that was what finally made a nervous team comfortable enough to go.
Done by Harshit Luthra, an independent infrastructure and AI engineering consultant. Bring me a similar problem →
further reading
The method behind this
EKS vs GKE vs Self-Managed Kubernetes: Where the Cost Actually Goes
A cost comparison that starts from the actual bill instead of the pricing page. What EKS, GKE and self-managed Kubernetes really charge for, which line items dominate, the surprises that show up in month three, and a model you can fill in with your own numbers.
12 min readKarpenter vs Cluster Autoscaler: Which One Should Be Scaling Your Nodes?
A practical comparison of the two Kubernetes node autoscalers, from someone who has migrated production clusters between them. What each actually does, where consolidation earns its keep, and the operational cost nobody mentions.
12 min readIngress vs Gateway API: Planning the Move Now That ingress-nginx Is Retired
What Gateway API actually gives you over Ingress, what the ingress-nginx retirement means if you are still running it, and a migration path that moves route by route instead of all at once.
12 min readDebugging Kubernetes Ingress: What 502, 503, and 504 Are Actually Telling You
A request-path playbook for Kubernetes ingress errors — how to read 502 vs 503 vs 504, walk ingress to Service to endpoint to pod, and find the layer that is actually broken.
13 min readA Zero-Downtime Kubernetes Migration Runbook That Survives Contact With Production
The runbook I use to move production onto Kubernetes without an outage window: parallel environments, weighted ingress, session and state handling, the rollback triggers agreed in advance, and the order that keeps every step reversible.
Questions about this work
How do you migrate to Kubernetes with zero downtime?+
Run the old and new environments in parallel behind weighted ingress and shift traffic in small increments while watching error rates and latency. A bad signal means shifting weight back in seconds, not a panicked 2am rollback. The earlier failed attempts here flipped everything at once and hoped, which is what made them fail.
Why use GitOps for the migration?+
So every change is reviewable and revertible. With Argo CD the running cluster always matches git, and a deploy becomes a merge. That auditability is what finally made a team burned by past migrations comfortable enough to go.
What if something breaks mid-cutover?+
Every step was reversible by design. Because traffic shifted gradually behind weighted ingress, rolling back was turning the dial down, not an emergency. Nothing customer-facing went down across the whole cutover.