Recreate, canary, and blue/green Kubernetes deployment strategies balance speed, performance, and resource use differently
In the era of cloud development and delivery, containerization is more important than ever. Applications need to remain stable regardless of how they're used, and containers help minimize app downtime without sacrificing performance. But containerization also brings new and unique challenges. Kubernetes arose from the need to orchestrate containers so that they worked in harmony, automatically deploying or recalling resources as necessary. It also plays a major role when it comes time to update containers.
There are several approaches to Kubernetes deployment, each with its own advantages and disadvantages. Some are simple and cost-effective but can negatively affect the end-user experience. Others require more resources but can ensure safe and stable deployments. Understanding them all gives your development team the tools to pick the best option for your app.
Jump to a section…
Basic Kubernetes Deployment Strategies
Advanced Kubernetes Deployment Strategies
Accelerating Kubernetes Configuration with DuploCloud
Basic Kubernetes Deployment Strategies
Recreate Deployment
Two ways to deploy to Kubernetes are available right out of the box. The first is recreate deployment, and it’s the simplest option in the bunch. It works by terminating all existing pods and replacing them with new versions. This K8s deployment strategy offers a compelling mix of simplicity and cost-effectiveness, requiring no extra work to configure. It’s also relatively fast and consistent.
The main problem with deploying to Kubernetes via recreate deployment is that it causes unavoidable downtime. Any user who tries to access your service during the deployment will hit an error wall. The bigger your update, the longer the downtime and increased user pain. In addition, if you complete the deployment and find you need to perform a rollback, that process can force another long period of downtime.
That doesn’t mean recreate isn’t a valuable strategy. It’s generally best used in development environments, and it’s essential whenever running two versions of the same app at once would be impossible. It can also be useful for applications with predictable use times, as that can make it easier to minimize downtime for end users.
Ramped Deployment
The second Kubernetes deployment strategy available out of the box is ramped deployment, also known as rolling deployment. In this model, each node in the target environment updates incrementally according to batches developers set before the update. A readiness probe checks each new instance to make sure it’s ready to go live, then deactivates the old instance and activates the new one.
Deploying Kubernetes in this way provides several advantages. For one, like recreation deployment, ramped deployment is very easy to set up. That means low costs. A ramped deployment can also be aborted midway through without bringing down the whole cluster, which makes it safer and more reliable than other deployment strategies.
On the other hand, it requires running multiple versions of the application in parallel, which can cause problems for legacy applications that lead to end-user bugs. It’s also slower to roll out and even slower to roll back. It’s best suited to stateful applications and other cases where performance impact on end users must be minimized without paying for additional resources.
One way to accelerate ramped deployment without sacrificing security is to use a DevOps automation platform like DuploCloud. Our low-code/no-code automation tools can accelerate deployment by a factor of 10, and we designed our solution with strict compliance standards in mind. To learn more about how DuploCloud can speed up your Kubernetes deployment, click here.
Advanced Kubernetes Deployment Strategies
The complexity of cloud deployment can sometimes call for more advanced approaches when deploying to Kubernetes. Although these strategies aren’t available out-of-box, the flexibility they provide is often worth the extra time they require.
Blue/Green Deployment
In blue/green deployment (also known as red/black deployment), blue represents the current version of the app, and green represents the new version. Using a Kubernetes service object, blue/green deployment routes all your traffic to a blue deployment while your team creates and tests a green deployment. That ensures all users are on a stable version of the app while you work. Then, once you’ve finished testing, you can update the service object to route all the traffic to the green deployment. When all your users have left the blue deployment, you can either keep it for a potential rollback or decommission it.
In many ways, blue/green is the ultimate Kubernetes deployment strategy. It allows for instant rollout with zero downtime. It carries no risk because users stay on the stable version of your app until you’re sure the new one is ready for them. And it avoids version mismatches because the entire app state changes in a single deployment.
Unfortunately, that level of control carries a financial cost. Blue/green requires double the resources of running your app under normal circumstances, as it has to maintain two full versions at once. That can drive up your infrastructure spending. The deployment also needs to be designed and implemented by your team, and it can struggle with stateful applications. As a result, it’s best for apps with a lot of resources to spare.
Canary Deployment
Canary deployment gets its name by nature of its focus on cautious deployment. In this K8s deployment model, new app versions gradually ship out to portions of the cluster. This allows developers to test the new version on a small amount of live traffic. If the test goes well, the rollout can gradually expand to the rest of the containers.
With canary deployment, developers can put new app versions, including new features or major upgrades, in the hands of actual users without committing to a full rollout. That enables them to perform rapid rollback if necessary, contain the fallout of a premature deployment, and monitor app performance all the while.
Where canary deployment falters is in its complexity. Using a ReplicaSet can help you create the number of app instances you need to get the right percentage of traffic on the canary versions. However, because canary deployment requires so many instances, many developers use a load balancer or service mesh to manage traffic. It also requires the infrastructure to run multiple versions of the app at once. These drawbacks make canary deployment more expensive than some other methods. It’s most often used when live user data is critical for one reason or another. For example, testing your app for accessibility requires putting it in the hands of disabled users, and you may not have any on your team.
A/B Deployment
A/B deployment is a type of canary deployment that distributes user traffic based on certain parameters. Where canary deployment essentially chooses users at random to send to the new version of the app, A/B deployment chooses them based on cookies, user agents, or other parameters. If your app needs the feedback of a specific subset of users, A/B deployment makes that possible. But it suffers from all the same shortcomings as canary deployment.
Accelerating Kubernetes Configuration with DuploCloud
No matter how you deploy, Kubernetes allows cloud-native apps to reach enormous scale. But manually configuring all of the necessary containers can eat away at productivity, especially when human error inevitably causes problems that need fixing. DuploCloud's no-code/low-code DevOps Automation Platform addresses both issues at once. Container configuration is just one of many DevOps processes it can streamline, leading to 10x reductions in deployment times. Curious to learn more? Get in touch today for a free demo.
