A deployment strategy defines how to create, upgrade, or downgrade different versions of Kubernetes applications. There are several strategies available for Kubernetes deployment that you can choose depending on your business requirements, resources, and infrastructure.
Here, we’ll discuss these six major Kubernetes deployment strategies that include,
- Recreate Deployment
- Ramped/Rolling Deployment
- Blue/Green Deployment in Kubernetes
- Canary Deployment
- Kubernetes A/B Testing
- Shadow/Mirrored Deployment
As you can see, there are different ways to release an application but it is necessary to choose the right strategy to keep your infrastructure secured and reliable during an application update. But, how to select these strategies?
Here are different criteria based on which teams can choose the appropriate strategy that would fit the best for deploying business applications. Here’s the list!
- Zero Runtime
- Real Traffic Testing
- Targeted Users
- Cloud Cost
- Rollback Duration
- Negative Impact on User
- Complexity of Setup
There are different ways to deploy an application. Discussed here are different business scenarios apt for each strategy. Take a look!
B.1 When to Use Recreate Deployment?
- When you need to run migrations or other data transformations before your new code starts.
- When your application does not support having new and old versions of the application code running simultaneously.
- When you want to use an RWO(Read Write Once) volume, which is not being supported when shared between multiple replicas.
- When you’re releasing to development/staging environments.
Click here to know more about Recreate Deployment!
B.2 When to use Ramped/Rolling Deployment?
- When you want to take zero downtime during an application update.
- When your application supports having old code and new code running at the same time.
- When you’re releasing to development/staging/ production environments.
Click here to know more about Rolling Deployment and how it is enabled by BuildPiper!
B.3 When to use Blue/Green Deployment in Kubernetes?
- When you want to test a new release with a production-quality environment before the application is made public.
- When the team's budget is huge enough to accommodate infrastructure requirements as this strategy requires IT organisations to maintain two identical hosting environments.
- When it comes to releasing the application to the production environment.
Click here to know more about Blue-Green Deployment!
B.4 When to use Canary Deployment?
- If you are not confident with the stability of the platform and what could be the impact of releasing a new software version, then a canary release is the best way to go for.
- When you want the consumer to test the application and its integration to the platform.
- When you want to be sure that any bugs or bad deployments are relatively limited in scope and are easy to fix with a little negative impact on your users.
Click here to know more about Canary Deployment and how it is enabled by BuildPiper!
B.5 When to use Kubernetes A/B Testing?
- When your business requires testing of a new feature amongst a specific pool of users.
Click here to know more about Kubernetes A/B Testing!
B.6 When to use Shadow/Mirrored Deployment?
- When there is a need to test production traffic loads.
- When want a low negative impact of the new update on the end users.
Click here to know more about Shadow/Mirrored Deployment!
Based on different factors, here’s a brief table that will help you decide which strategy to go for.
- Recreate: This terminates the old version and releases the new one.
- Ramped/Rolling: This releases a new version in a rolling update fashion, one after the other.
- Blue/Green: This releases a new version alongside the old version and then switches the traffic.
- Canary: This releases a new version to a subset of users and then proceeds to a full rollout.
- Kubernetes A/B Testing: This releases a new version to a subset of users in a precise manner to test the conversion of a specific feature. ._
- Shadow/Mirrored: The new version is available with the old version, but a copy or forked version of traffic to the older version is sent to the new version for production testing.