In this blog, we will discuss the different deployment strategies which can be deployed using Devtron and its various use cases. But before deep diving into deployment strategies lets first discuss Deployments in K8s.
As per the official documentation of Kubernetes -
A Deployment provides declarative updates for Pods and ReplicaSets.
You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets or to remove existing Deployments and adopt all their resources with new Deployments.
A major benefit of a deployment is the ability to start and stop a set of pods predictably.
A Kubernetes deployment makes this process automated and repeatable. Deployments are entirely managed by the Kubernetes backend, and the whole update process is performed on the server-side without client interaction.
The Kubernetes deployment controller always monitors the health of pods and nodes. It replaces a failed pod or bypasses down nodes, ensuring availability of applications.
Deployment strategies are nothing but way to change or upgrade the type of deployment of an application ensuring zero downtime. There are different types of deployment strategies among which Devtron provides 4 commonly used Deployment Strategies.
We will discuss all these strategies in detail and their use cases with the help of a sample app deployed over k8s with Devtron.
Note: Devtron provides a detailed documentation on deployment strategies that it supports and parameters used.
As you can see we have already deployed a sample php application on Devtron, we can see the application details by going through the App Details Section on Devtron Dashboard.
We have 3 pods that are in the
RUNNING state, now let’s select a deployment strategy by going to
App Configuration >
Workflow Editor and Selecting the
CD Pipeline as shown in the image below.
After we click on the CD Pipeline a window will open which allows us to edit the pipeline. Under the Deployment Strategy, we can add a strategy we want to deploy with.
We can also specify multiple strategies with their configuration and define a default deployment.
Rolling is the default strategy that is selected when you add a deployment pipeline on Devtron. It works slowly, one by one, replacing pods of the previous version of your application with pods of the new version without any application downtime.
Rolling deployment typically waits for new pods to become ready via a readiness check before scaling down the old components. If a significant issue occurs, the rolling deployment can be aborted.
We have done a few changes like selected
maxSurge value as 2 and
maxUnavailable values as 0. To see these changes we need to deploy the app again and once our app is healthy we can observe these changes in the App Details Section.
As you can see 2 extra pods are running apart from the 3 old ones due to the
Now the old pods will terminate one by one and new pods will be created.
And eventually, all the old pods will be replaced by new pods.
- It is mostly used when organizations want a simple solution to update any application or roll back to previous changes without allocating any extra resources or performing any complex deployment tasks.
- It is best suited for applications that are smaller in size and can afford downtime in case of any failures.
In this type of deployment, all of the old pods are killed all at once and get replaced all at once with the new ones.
Let's change the deployment type and select the recreate strategy in our
After Clicking on
Update Pipeline and redeploying the application let’s see what kind of changes it does
As we can see it terminated the old pods at once which were previously running and deployed all 3 new pods together.
- This deployment strategy is typically only used in development environments where downtime won’t affect any production users.
- The recreate method is best used when you need to run data migrations in between terminating your old code and starting your new code, or when your deployment doesn’t support running version A and version B of your application at the same time.
In a blue/green deployment strategy (sometimes also referred to as red/black), the blue represents the current application version, and the green represents the new application version. In this, only one version is live at a time. Traffic is routed to the blue deployment while the green deployment is created and tested.
Let us change the deployment type and select Blue/Green Strategy.
We will also change some parameters to observe the results quickly.
Let’s Update and Deploy our application.
As we can see 3 new pods with the latest version have been deployed. The traffic routes to different versions by changing the service. We can observe that by having a look at the events in the Rollout object.
From the above events, we can see that it first scaled up the
replicasets and switched the
service. After that scaled down the old pods after some delay which we defined in the parameters.
- This allows you to live test the new version of your application without impacting your users. Once your testing is complete, you update the load balancer to send user traffic to the green version of your application.
- A blue/green deployment strategy works well for avoiding API versioning issues because you’re changing the entire application state in one go, but as you need to double your cloud resources to run both versions at the same time, it can be very expensive.
Canary deployment is a deployment strategy that releases an application or service incrementally to a subset of users. All infrastructure in a target environment is updated in small phases (e.g: 2%, 25%, 75%, 100%).
Let’s change the deployment type and select canary
After Updating the
CD Pipeline and redeploying our app let’s see what kind of changes are happening.
Since we selected MaxSurge as 2, two new pods are created, and after 30 sec 50 percent of pods will be moved to the next stage, and after that the remaining.
As we can see old pods are getting terminated according to our weight selection and new pods are created.
- One of the best use cases is when you need real traffic testing of your new versions and have the resources to manage the complex setup.
- It can also limit the damage caused by the release of a faulty software update and also rollback that update quickly and easily.
- It allows you to release software faster. Since it contains the damage caused by a problem to a small subset of users, canary deployments give organizations the freedom to deploy to production constantly, allowing them to remain competitive.
Hurray! You reached the end. Hope you found the blog informative and learned about how easily you can implement all these different deployment strategies using Devtron just with a few clicks. Feel free to let us know your thoughts and join our community discord-server if you have any doubts about Devtron or which strategy to choose for your organization. We would be happy enough to help you.