Blue-green vs canary deployments in Kubernetes: How do they shift traffic?

Your users never talk to pods directly. They talk to the shop Service, and the Service decides which version they get. Right now, v1 gets everything, while v2 sits there, unconnected. That's why a careless rollout can put a broken v2 in front of real users.

In blue-green, blue is v1, and it keeps serving all shop traffic through the Service. Beside it, we run a complete copy of v2, called green. Only QA smoke tests reach it, so real users never touch it. The catch is cost: during the release, you're paying for double capacity.

The Service finds its pods through the selector. Our pods carry a version label, blue or green. Change that one value from blue to green, and the Service repoints to v2 right away. The catch is that every user moves at once, so a bad v2 hits everyone.

Now the Service sends all requests to green v2. Blue v1 is still running, just idle, so it's your rollback path. Flip the selector back and traffic returns to blue. Once you're confident in v2, you can retire blue and free up that spare capacity.

After switching the shop Service to green, v2 starts throwing errors. What is the fastest way to roll back?

Point the Service selector back to blue. Blue v1 is still running, so the only change needed is the selector label. Rebuilding v1 wastes minutes users spend on a broken release, and deleting the Service causes an outage. Keeping the old version alive is what makes rollback instant.

Canary takes a different route with the same shop app. Users still hit the Service, but now v1 and v2 both serve real traffic at once. About 90 percent goes to stable v1, and about 10 percent reaches the v2 canary. If v2 breaks, only that small slice feels it.

The Service selects only app: shop, so it matches pods from both Deployments. Nine v1 pods and one v2 pod means roughly ten percent of requests reach v2. It's approximate, since it's just pod counts. For precise weights, you'd use an ingress controller or a service mesh.

A canary rollout grows in steps. Here it's illustrative: ten percent, then twenty-five, fifty, and finally one hundred percent on v2. At each step, you check error rate and latency. Healthy, you increase. Unhealthy, you send traffic back to v1. It's slower, but measured.

Say v2 has the same bug in both strategies. In blue-green, everyone moves at once, so every user hits the bug until you flip the Service selector back, which is instant. In canary, only the small slice sees it, but you need metrics and patience to catch it.

Pick blue-green when spare capacity is cheap and you need an instant rollback. Pick canary when you want real traffic to validate v2 before everyone sees it. Either way, both versions run together, so your database changes must work for v1 and v2.

Both strategies keep the old version running, and they differ in how traffic moves. Blue-green flips everything at once. Canary shifts a slice at a time. Either way, the Service routing is your safety lever, so keep v1 alive and control the switch.