Kubernetes offers several deployment strategies to manage the rollout and updates of applications running in a cluster.
-
Recreate
- This strategy involves creating a new set of pods with the updated application version while deleting the old ones.
- It provides a simple rollback mechanism by switching back to the old version if the new version has issues.
- However, it can cause downtime during the switch.
- The application experiences downtime from when the old version goes down until the new pods start successfully and serve user requests.
- It is impossible to have 2 versions of the same app running simultaneously. A recreate deployment lets you shut down the previous version and only then start the new one.
Downtime: Minimal
-
Rolling Update
- This deployment strategy updates a running instance of an application to a new version.
- This strategy ensures that there is always a certain number of pods available, minimizing downtime.
- The advantages of a rolling deployment are that it is relatively easy to roll back, is less risky than a recreate deployment, and is easier to implement.
- The downsides are that it can be slow, and there is no easy way to roll back to the previous version if something goes wrong.
- In an application, there might be multiple versions running at the same time in parallel. This might be problematic for legacy applications, which might force you to use a recreate strategy.
Downtime: Minimal
-
Shadow
- Shadow deployment tests a new release on production workloads. It sends a copy of production traffic to the new version without affecting the real user traffic.
- This is useful for monitoring and collecting metrics on how the new version performs under realistic conditions.
- This deployment splits traffic between a current and a new version, without end users noticing the difference. When the stability and performance of the new version meet predefined requirements, operators trigger a full rollout.
- The advantage of shadow deployments is that they can help test the performance and stability.
Downtime: None
-
Canary
- A canary deployment strategy enables to test of a new application version to a small group of users or traffic. Monitor its performance; if all's well, roll it out to everyone.
- It enables testing a major upgrade or experimental feature on a subset of live users while providing all other users with the previous version.
- This deployment requires using two almost identical ReplicaSets – one for all active users and another for rolling out new features to a small subset of users.
- It allows testing the new version's performance and reliability in a controlled environment before rolling it out to everyone. If issues are detected, only a portion of users is affected.
-
Blue-Green
- Blue-Green deployments involve running two separate environments, one with the current version (blue) and one with the new version (green). Traffic is switched from blue to green when the new version is ready.
- It involves routing traffic to a blue deployment while creating and testing a green deployment.
- This deployment eliminates downtime and reduces risk because you can immediately roll back to the previous version if something occurs while deploying the new version.
- This strategy requires double resources for both deployments and can incur high costs. Furthermore, it requires a way to switch over traffic rapidly from blue to green version and back.
-
A/B Testing
- A/B testing is similar to canary deployments but involves testing multiple versions concurrently. Different sets of users or traffic are routed to different versions to compare performance, usability, or other metrics.
- This testing can target specific users based on cookies, user agents, or other parameters.
- A/B testing in Kubernetes is testing a few options of a new feature, identifying which one users prefer, and then rolling out that version to all users.
- This helps in making data-driven decisions about which version to promote.