Wait, what? Doesn’t everyone have this already? While various deployment methodologies including blue/green, A/B, Canary etc etc are fairly prevalent outside of containers, its been quite a different story in the container world and in particular Kubernetes. Now before you go all crazy on me. I’m not saying there aren’t ways by which to do this, there are tons of them but none of them I could consider elegant. We in fact use a combination of multiple replication controllers with labels and updates to the Kubernetes service to accomplish this.
Unless of course you are on OpenShift. In which case you have had these capabilities built-in for a little while now. Props to the OpenShift team.
I’ve also seen some very creative ways of accomplishing blue/green deploys from the guys at Citrix and Zcentric.
But as with many things in Kubernetes, Blue/Green deploys just got the easy button.
Enter Kubernetes Deployment Resource which is currently in v1beta and is better describe as a DeploymentController.
Depending on your deployment strategy the actual process differs.
Currently there are two options:
Recreate: Destroy the existing RC(s) and replace with a new one.
RollingUpgrade: Launch New RC(s) along side the existing ones. Ramp up the new and ramp down the old.
So how does this work? I’m going to try and give the short version without over simplifying to much.
1) The DeploymentController initiates a search for ReplicationControllers using labelSelector:myapp
2) Add a unique label to every RC and Pod based on the PodTemplateSpec which is guaranteed to be unique per version of app being deployed. label: deployment.kubernetes.io/uniqueHashperPodTemplateSpec. So basically the RC and its respective pods will have a label by which the DeploymentController can identify them. The existing RC will get updated with the label (if using RollingUpgrade Strategy), the new RC will automatically be deployed with it. The ReplicationControllers also get an updated labelSelector: so they rely on this label to determine state of the pods.
3) DeploymentController will use these hashes to determine which to ramp up and which to ramp down.
All in all, an excellent way of performing deployments in the future. Until that day comes, we’ll be stuck with our hacks. But awesome to know I won’t have to manage it relatively soon.
Also in the future, alternate deployment strategies and desirable options will be included like A/B deploys, Canary deploys and automated Rollback in case of failure.
For considerably more information on the topic you can go here.
Thanks for this, Michael! Kubernetes benefits a good deal from OpenShift. It’s good to see Deployment Resources are on their way. Automated rollback on failure sounds nice. Having this will likely mean developers will need to or operators will needs to tether their applications a bit more closely to Kubernetes as they’ll need to define rollback criteria. Granted the deployment tests (rollback criteria) doesn’t need to be Kubernetes-Specipic, but the implementation (perhaps, simply defined in a .spec) does.
Excellent point Lee. We aren’t quite there yet around automated Rollback in the face of failures. I think you would be quite keen to hear more about our Build Pipelines and CI process. In the end, some of this may be managed by event driven automation. Based on Application log events. We intend to standardize our log events across all applications to enable a rollback function. Not just for containers but across a disperse stack of hardware, VMs and containers as well. This is very much far into the future but absolutely something we are accounting for in our design process.