Deployment Strategies in Kubernetes.

In this blog we will see the different deployment strategies in kubernetes.

Nowadays when an application goes down for a few minutes we lose our business or we lose our clients. So making the application always available is a prime thing in the organisation. Nowadays we are (most of the development ) following the agile methodology. where the team will give releases every week. Generally we do updates during the mid night because we will get less traffic at that time.

Let us assume, if we need 5 mins time to update our application here we need 5 mins downtime every week. If we do so for one month our app will go down for 20 mins. In the development process it is a very big number and the ops team will work at night to make the application work properly.

So to solve all these kinds of issues we follow deployment strategies where we achieve a lesser impact on customers / clients.

we choose any of the below deployment strategie to make our application available all the time.

1. Recreate Deployment

The recreate strategy kills the currently running pod instances and creates new instances running the latest version. Recreating pods completely updates the state of the pods and applications. This is often used in development environments where users are not actively working on the instances and downtime is acceptable.So this deployment strategy results in downtime and can interrupt current operations for users, meaning it is not recommended for production environments.

2. Rolling Update Deployment

In this deployment, a new version of a ReplicaSet is started alongside the existing ReplicaSet with the old version. The Deployment object launches new pods using the new version of the pod specification, and when the new pods start successfully, shuts down the old pods. Rolling updates allow you to migrate between versions in a safe and controlled manner, but the transition to the new version can take time. Also, it can be difficult to roll back or interrupt the deployment in the middle if something goes wrong.

3. Blue/Green Deployment

Also Known as Red/Black Deployment.The blue/green strategy allows for a quick transition from the old application version to the new version, and enables testing of the new version in production. A blue/green deployment is a deployment strategy in which you create two separate, but identical environments. One environment (blue) is running the current application version and one environment (green) is running the new application version. Using a blue/green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails. Once testing has been completed on the green environment, live application traffic is directed to the green environment and the blue environment is deprecated.After switching over traffic, you should carefully monitor the new version, and if you see major issues, switch traffic back to the “blue” version. Otherwise, users continue to use the “green” version, which becomes the new “blue” version.The downside of a blue/green deployment is that it requires twice the resource utilisation, at least during the staging and cut-off period.

4. Canary Deployment

In a canary deployment, a small number of users are routed to the new version of the application. The application runs on a small set of pods to test new functionality in production. If there are no major issues and users are satisfied with the change, the canary version is expanded to more users, until eventually, it completely replaces the old version.Canary deployments are great for testing new features with small groups of users and can be rolled back easily. Therefore, canary deployment is a good way to determine how new code will affect the system as a whole and whether it will have a positive or negative impact on user experience. The purpose of a canary deployment is to reduce the risk of deploying a new version that impacts the workload. The method will incrementally deploy the new version, making it visible to new users in a slow fashion.

If you want to do canary deployments with load balancers, you’ll start by having two of them. Load balancer A will receive 95 percent of the traffic, and load balancer B will get the remaining five percent. We’ll use load balancer B for canary deployments, which means we’ll update the servers behind it first. It doesn’t really matter how many servers are behind each load balancer — the important thing is that traffic is split between the load balancers, not the servers.When you’re done updating the servers, you monitor and test for a while. If you don’t like the results in load balancer B, you can roll back and finish the release. But if the new changes are good to go, you can proceed to update the servers that are behind load balancer A.

In AWS we can achieve this using weighted routing in Route 53 or with load balancers and auto scaling

A downside of canary deployment is that the application must be able to run two versions at the same time, which is not supported by many legacy applications. In addition, for an effective canary strategy, you also need a service mesh or network gateway to split traffic between current and canary versions.

5. A/B Testing

A/B testing (also known as split testing or bucket testing) is a methodology for comparing two versions of a web page or app against each other to determine which one performs better.A/B testing is a deployment strategy used to test a specific version of an application by routing a subset (usually defined in percentages) of users to a newer version of said application. This is extremely useful when rolling out a new feature and you are unsure of how it might affect existing users.

in simple words.,A/B testing refers to a deployment in which traffic is distributed between different versions of an application based on certain parameters.

6. Shadow Deployment

A shadow deployment lets you test production loads on a new version of the application, without users being aware of the change. The shadow deployment never gets user traffic — it is a clone of prod which is not visible to users.A shadow deployment releases a new version alongside an existing version, allowing for testing in a realistic production environment. When the stability and performance of the new version meets the defined requirements, the new version is rolled out to users.

Thanks for reading the blog. See you in next blog.

DO FOLLOW ME ON INSTAGRAM :- learn_with_praveen

— — — — — — — — — — — — — — — Praveen Writings