Background
Nowadays modern cloud-native applications are developed and deployed at a rapid scale and pace. The legacy techniques used for upgrading applications and services are no longer relevant. We want to give the best user experience to end users. One of the things which are gaining popularity and is already a mainstream technique is progressive delivery. This allows us to upgrade the application version in a progressive manner by reducing the blast radius. In this post, we will look at how to achieve zero downtime deployment using the Rolling Update strategy with Kubernetes.
Quick overview of the rolling update strategy
The rolling update strategy allows applications with multiple instances or replicas to upgrade from one version to another in a controlled manner. Instead of upgrading all the replicas together, this strategy applies changes in batches and replaces the older version with a new one. As a result of this, the application can continue to run with the reduced number of instances while the upgrade is progressing.
One of the pre-requisite for implementing a rolling update strategy is that the application needs to have multiple replicas or instances running. If there is only a single instance of the application, there will be a slight downtime. Kubernetes supports the rolling update strategy natively. We do not need any additional things to implement it with Kubernetes. When we use Kubernetes Deployment to deploy our pods, the rolling update is the default strategy.
If you have been using Kubernetes deployments, you would have unknowingly used the rolling update strategy when upgrading the application version.
Use the Rolling update strategy for zero downtime deployment
If we don't override any settings related to rolling updates, by default Kubernetes will apply 25% MaxSurge and 25% MaxUnavailable settings. What this means is that at the time of the upgrade maximum of 25% of the replicas will be added. Same way, when the old version of the replica is replaced with the new one, a maximum of 25% would be replaced at a time.
By doing this, it ensures that there are 80% of replicas in working condition during the upgrade process and the end users are not impacted. If we have exposed the deployment outside of the Kubernetes cluster using a Service, then the LoadBalancer will route the traffic accordingly between the new and older versions.
Youtube video demo
Refer to the YouTube video to see this in action.
Other alternatives to Rolling Update Strategy
There are other alternatives to the rolling update strategy. Modern-day cloud-native applications support advanced deployment strategies or techniques such as Blue-Green deployment or Canary deployment which also allow zero downtime deployment with progressive delivery. Refer to the links to watch YouTube videos on my channel to understand how these can be applied to your Kubernetes applications.
Conclusion
Gone are the days of bringing down servers and applications to upgrade them. With the cloud, we can easily upgrade applications and services with minimal impact on end users. Use modern techniques such as rolling update, Blue Green deployment or Canary deployment to achieve 100% availability for your application.
Until next time, Code with Passion and Strive for Excellence.
No comments:
Post a Comment