This post will present the various Kubernetes deployment strategies available.
One of the many benefits to a Kubernetes platform that hosts your applications is its ability to orchestrate deployments in an automated fashion. With businesses looking to deploy changes more frequently to continue innovating and stay ahead of their competition – there is usually a trade-off in terms of maintaining service availability and great customer experience.
If a business can adopt cloud-native strategies and implement automated CICD pipelines, then the risk to service availability is vastly reduced. Coupling strong DevOps practices with a clearly defined deployment strategy will ensure services remain highly available and new features are deployed frequently.
There are six different kubernetes deployment strategies that engineers can utilise to roll out the latest version of their application. Let’s have a look at them below…
Recreate
This is the simplest type of Kubernetes deployment and just involves the termination of old versions and then deployment of new versions. This strategy has the highest impact on users and will cause an outage. It also takes the longest to roll back to a previous version if needed but requires no setup or expertise from engineers.
Ramped/Rolling
As the name suggests, this strategy involves slowly rolling out the new version of the application before removing the old version. The old version is only removed once the new version has been rolled out and successfully tested using the Kubernetes readiness probe. This strategy ensures there is zero-downtime for customers but can take some time if a rollback to a previous version is required.
Blue/Green
A blue/green kubernetes deployment (sometimes referred to as red/black) involves deploying your new version alongside the old version. An internal QA team can then test the new version (blue), whilst the customer is still accessing the old version (green). Once the release has been tested and approved, traffic can be redirected to the new version (blue) by changing the Kubernetes service. Afterwards, when engineers are confident in the release, the old version (green) can be scaled down to zero.
This strategy also ensures there is zero downtime to customers during a deployment, it also gives a business an extra level of confidence in their new service (from QA testing). Blue/Green strategies involve a little more engineering work and are the costliest type of strategy in terms of resourcing (doubling application resources), however old versions can be immediately rolled back if needed.
Canary
Canary deployments are a little like blue/green deployments, with the difference being that a new version of the application is released to a small subset of customers. This pattern directs a small percentage of application traffic to the new version so that engineers can monitor the deployment whilst it is tested by real customers. Once engineers are happy with the new version, they can begin gradually increasing the amount of traffic directed to the new version until all traffic is directed at the new version. Afterwards, the old version is scaled down to zero.
Canary deployments also offer zero downtime for customers but have the added benefit of having your customers test the new release. The setup involved is similar to blue/green and involves a little more effort than a traditional deployment. This procedure can be completely automated with the likes of a service mesh like Istio.
A/B Testing
A/B testing is similar to canary deployments, with the main difference being engineers can specifically target certain types of users. For example, if a business wanted to test a new set of features to customers within a specific geographical market then A/B testing can apply rules to enforce this.
A/B testing is a complex deployment strategy to establish but includes the most benefits.
Shadow
A shadow strategy involves rolling out the new version alongside the old version and then forking real customer traffic from the old version into the new version. This allows businesses to test the new version using real customer traffic without affecting the customer. A full rollout of the new version is triggered when stability and performance meet the requirements.
This is the most complex deployment strategy and involves establishing mock services to interact with the new version of the deployment.
Which Kubernetes deployment strategy is right for me?
If downtime is not an issue, then recreate is the easiest deployment strategy to implement.
If downtime is an issue, ramped or blue/green deployments are generally a good fit, with blue/green deployments being more expensive and slightly more complicated to setup.
Canary and A/B Testing should be used if there is little confidence in the quality of the release. These strategies along with shadow will require extra cluster components such as service meshes, increasing cost and complexity.
For more information please see the CNCF source material by Etienne Tremmel and Container Solutions:
https://www.cncf.io/wp-content/uploads/2018/03/CNCF-Presentation-Template-K8s-Deployment.pdf
