There are several ways to release an application in Kubernetes. You need to choose the right strategy to make your infrastructure reliable when doing application updates. Your choice will largely depend on your needs. Here are some of the strategies you can adopt.
The recreate Kubernetes deployment strategy is a dummy deployment that involves shutting down version A of your app and deploying version B. There’s usually a downtime associated with it. It depends on how long it takes to shut down one and boot up the other. Your old code and new code don’t run at the same time.
When to Use Recreate Deployment
- When you’re running migrations and other data transformations before starting your new code.
- When your deployment doesn’t support having an old version (A) and a new version (B) of your application running at the same time.
- When you are using a ReadWriteOnce (RWO) volume that doesn’t support sharing between multiple replicas.
- Easy setup
- Completely renewed state of applications
This strategy involves rolling out a version of an application slowly by replacing one instance at a time. This is what that looks like:
- You have a pool of version A running behind a load balancer.
- Deploy one instance of B. You add this to the pool when the service is ready to accept traffic.
- It shuts down one instance of version A.
- Easy setup
- Version releases take place slowly across instances.
- Convenient for stateful applications
- Hard to support multiple APIs
- Zero control over traffic
- Low rollout/rollback
This Kubernetes deployment strategy involves deploying version A and version B alongside each other. They have the same number of instances. You only switch off version A after making sure version B meets all the requirements.
- Fast rollout/rollback
- No versioning issues
- Can be expensive because of the resource demands of running two versions simultaneously.
- You must do proper tests of the entire platform.
- Difficult to deal with stateful applications
This deployment involves gradually shifting production traffic from version A to version B. You’ll split traffic bad on weight. For instance, 80 percent of the requests go to version A while 20 percent go to version B. This is the perfect strategy when tests are unreliable or lacking, and you can’t vouch for the stability of version B.
- Fast rollback
- Perfect for performance and error rate monitoring
- Rollout is slow
A/B Testing Deployment
This Kubernetes deployment strategy involves routing some users to a new functionality under specific conditions. The strategy is perfect for testing new features. Only roll out those that perform as desired.
- Several app versions run in parallel
- You retain full control over the distribution of traffic.
- Need an intelligent load balancer
- Difficult to troubleshoot errors
This type of deployment involves releasing version B alongside version A. Incoming requests go to both A and B. It’s a great strategy for testing production load on new features. You only perform a rollout after the performance and stability meet your expectations.
- Tests take place with production traffic.
- It doesn’t affect the user.
- You only do the rollout when the application is stable.
- It’s expensive because of the resource demands.
- Tests can be misleading
- Complex setup
You have several options when you want to deploy an application. The choice largely depends on your budget and goals.