Table of Contents
In the cloud computing world, cloud providers offer various ways to deploy containerized applications. Kubernetes is a widely used platform in the modern landscape which enables enterprises to deploy and manage applications with flexibility, agility, and scalability. The container orchestration is beneficial in streamlining provisioning of infrastructure for microservices based cloud native applications which support efficient workload management via modularity. Kubernetes enables various resources deployment but production deployments require understanding and selection of the right kind of deployment strategy.
Today we look more in detail about strategies widely or commonly adopted for Kubernetes deployment, Pros, and cons of each strategy and how each strategy functions.
What is Kubernetes Deployment?
Deployment is the process of installing a new version of an application or workload on Kubernetes Pods/ Nodes. A ‘Deployment’ having capital ‘D’ is Kubernetes object with its own YAML configuration, which lets define how deployment will happen, what needs to be deployed exactly, and how requests shall be routed to applications which are deployed recently. The deployment strategy is the way by which Kubernetes Pods will be updated with newer versions of the application.
Kubernetes Deployment Strategies
Lets look at Kubernetes deployment strategies more in detail:
1. Deployment – Recreate
This strategy means scrap and setup new and it lets you update applications with some downtime. The current pods are terminated and new versions of Pods are brought up. There is a downtime between the old version being taken down and the new version becomes available. A recreate strategy is ideal for environments used for development work or when users prefer a brief downtime with some glitches like poor performance or faults for a limited time period. Such kind of deployments are application in scenarios where:
- Due to technological constraints, it is not possible to run two versions of same application.
- Possible to plan downtime during off-peak hours.
PROS
- Ease of setup.
- Totally renewed applicate state is achieved.
CONS
High impact on availability, downtime during shutdown and booting process.
2. Deployment – Rolling / Ramped
It happens in batches. Upgrade of application instances happens to a new version incrementally in pre-specified batches. These deployments call two versions of a service – an old version of Kubernetes application and newer version. It is a slow process and if something goes wrong, reverting back to previous state is complex process.
PROS
- Ease of setup.
- Slow release of new version across instances.
- Ideal for stateful applications which handle rebalancing of the data.
CONS
- Rollout and backups are time consuming.
- Support to multiple APIs is tough.
- No control can be imposed on traffic.
3. Deployment – Blue/Green
New version can be deployed without downtime. The newer version is Green and the previous version is Blue. One version is always active as when the green version is tested for deployment traffic is routed to the blue version. The blue version is retained for future reversal or decommissioned once the green version is available and traffic is routed to the newer version.
With this strategy rollback is easier if error is encountered during deployment of a newer version.
PROS
- Instant rollback possible.
- Entire application state changes in one go hence avoids versioning issue.
CONS
- Expensive as both versions required to be maintained.
- Testing of entire platform is required before production release.
- Stateful applications are hard to handle in this strategy.
4. Deployment – Shadow
In this strategy new release is tested using workloads from production systems. In shadow deployment traffic is divided into old version and newer version. A comprehensive deployment starts as soon as performance and stability standards of new applications are met. This kind of strategy is useful to test load but technique is complex especially with egress traffic.
PROS
- Testing application performance in production.
- User is not aware of the impact.
- No rollout is done until performance and stability of new version is not established or met.
CONS
- Expensive to maintain dual resources.
- Complex in setup.
- Mocking services required for some use cases.
5. Deployment – Canary
In this strategy a new version is tested out with users before going for a full rollout. A phased deployment applies a progressive approach to delivery. A/B testing, dark launches are some techniques deployed by Canary. Deployment of a new application to Kubernetes autoscaling cluster happens in incremental manner along with testing it using a limited amount of actual traffic.
Canary deployment requires two identical ReplicaSets one to roll out new features to a small group of users and another for all active users. Progressively the new version is pushed to the entire infrastructure and until canary version becomes the new version all live traffic is directed to canaries.
PROS
- Version is released for a group of users.
- Ideal for performance monitoring and load.
- Rollback is fast.
CONS
Rollout is slow.
6. Deployment – A/B testing
It is a type of canary development which routes traffic to various versions of application based on specific conditions or criteria. It can be target specific based on cookies, user agents, or other parameters. This kind of testing helps Kubernetes to determine which version of an application customer would have preference before it gets distributed to all users.
PROS
- Parallel running of several versions.
- Traffic distribution is fully controlled.
CONS
- Intelligent load balancer is required.
- Tough to troubleshoot errors in session, distributed tracing is required.