“Should we cluster swap?”
Jenkins is waiting. The new version is beside the old one and its rollout has finished. Now somebody can decide whether it should get the traffic.
I'm back with countries and airports from zimb means Zimbabwe. I'm learning about deployment this time. How do I put out a new version while people keep using it?
Work supplies two ready-made Java jars, one for countries and one for airports. They run on my laptop behind a common entry point. Airports must go from version 1.0.1 to 1.1.0 without interrupting service.
Kubernetes runs the applications and arranges their traffic, Jenkins handles deployment, and Jenkins integration earns bonus points, so there's more to this version of the exercise than the country lookup.
And now my laptop has an approval ceremony.
The prompt gives someone fifteen minutes. Abort it or let it time out and the traffic switch won't run. The old selection stays put, and the new deployment remains available to inspect, so I can look at what I declined without putting it in front of everyone using the application.
Cluster swap, well, that sounds rather grand for changing one selector. The wording suggests two entire clusters. I do like the ceremony it gets.
Blue and green are colours for two copies of the application. A colour is a pod label. They're ordinary Kubernetes objects with labels that let me address the copies separately.
The pipeline reads the live Service's colour. If blue is live, it targets green. Otherwise, it chooses blue, so even a deployment without a previous release has somewhere to begin. It applies that colour's Deployment and Service and waits for kubectl rollout status to finish.
Is it ready to take traffic?
A running process can still be initialising. Both supplied applications have a liveness endpoint to say whether the server is alive and a readiness endpoint to say whether it has finished initialising and can take traffic. Those are separate questions.
Ready gives me something useful to wait for. Meanwhile, green can be inspected while blue serves everyone else. If green looks wrong, I can leave it there to inspect (no elaborate cluster swapping required). My laptop's approval ceremony is starting to make sense.
Give the new version the traffic
The Ingress still points at the shared Service. Clicking Proceed reapplies that Service with a new colour selector:
# Illustrative fragment of the live Service
spec:
selector:
colour: green
Green is already running. The selector changes which pods the Service chooses as backends while the cluster updates its routing. After switching, I scale the old colour to zero. There may be no old colour on an initial deployment, so that command tolerates failure. A missing previous release shouldn't ruin the first one. The cost of tolerating failure is that an unexpected scale-down failure can pass too, and I still have to notice it rather than assume the old copy went away.
There's also a milestone after the prompt. Think of two pipeline runs waiting for approval. The newer one proceeds. Someone then approves the older candidate. Which version gets the traffic? The milestone helps prevent the older run proceeding after a newer run has passed that point, so clicking Proceed shouldn't unknowingly put the older candidate back in front.
Old requests are another job. Kubernetes has to spread the routing change and blue may still be answering somebody when green becomes ready. Scaling it to zero immediately could cut that request off. Is the application still answering? Is it allowed time to finish? Before I can call this smooth, its shutdown and the time for draining have to work together.
The other pipeline replaces pods gradually. Airports has two replicas and Kubernetes works through the old pods progressively, using readiness to decide when a new pod can join the Service's backends. Blue/green gives me a separate candidate and a switch to make. With rolling replacement, I leave the sequence to the Deployment controller.
Readiness still has to mean the application can serve a request.
First there's a malformed rollingUpdate line to fix.
Then I can use the Service to make requests while the pods change, watching readiness alongside them. A port-forward to one pod would be easier to follow, but it skips the traffic switch I'm trying to learn about.
For blue/green, I most want to watch a request already using blue when green takes new traffic. Can it finish while I retire blue? That's the part of “without downtime” I still have to demonstrate.