A deep dive into Kubernetes Deployment strategies

With the use of containerized applications and microservices on the rise, there’s never been a better time to become a Kubernetes expert. Whether you’re a developer eager to learn Kubernetes or a seasoned Docker expert looking to expand your skill set, this blog will help you take the next step toward Kubernetes expertise.

We’ll start by exploring the Deployment object,  which is the key to managing ReplicaSets and enabling smooth, live system updates. Next, we’ll explore Kubernetes Deployment strategies.

Choosing the right deployment strategy can mean the difference between a seamless user experience and a disastrous outage. While Kubernetes provides several options, this blog will focus on three core strategies:

• The rolling update strategy

• The recreate update strategy

• The canary update strategy

Before we examine these strategies in detail, let’s first understand the fundamentals of Kubernetes Deployments and the vital role ReplicaSets play in maintaining application stability.

What is Kubernetes?#

While Kubernetes is incredibly powerful, it’s also notoriously difficult to learn.

What is Deployment in Kubernetes?#

A Deployment is a resource object in Kubernetes that defines the desired state for your program.

Deployments are declarative, meaning you don’t specify the exact steps to achieve the desired state. Instead, you define what you want, and the Deployment controller makes it happen efficiently. Think of it like ordering omelets at a restaurant: you simply tell the chef how many omelets you need, and they ensure you get them without worrying about how they’re cooked.

Once a Deployment is running, it continuously monitors the application’s current state and compares it to the desired state. If there’s a mismatch, the Deployment controller automatically adjusts the current state to align with the desired configuration. This automatic state maintenance is what gives Kubernetes its beloved self-healing properties.

Desired states can include the number of Pods running, the type of Pods, the container images available to the program, and the desired workload for each Pod. If any aspect of the desired state is missing, the Deployment Controller will alter the program until it is met.

Deployments are incredibly useful for automatically managing updates to the Kubernetes applications. Without Deployments, you’d have to manually end all old Pods, start new Pods, and manually check to see if any problems occurred during Pod creation.

This brings us to an important question: How does the Deployment controller maintain the application’s state? Deployments maintain a program’s desired state mainly by using ReplicaSets.

What is a ReplicaSet?#

A ReplicaSet is a core Kubernetes object that ensures that a specified number of identical Pods are running at any given time. If a user-facing Pod fails or becomes overworked, the Deployment allocates work to a Pod from the ReplicaSet to maintain responsiveness. If a Pod from the ReplicaSet fails, it automatically creates an additional Pod from the template.

It’s best practice not to manage ReplicaSets directly. You should perform all actions against the Deployment object and leave the Deployment to manage ReplicaSets.

Here’s an overview of Deployments, ReplicaSets, and Pods:

• Pods: The basic unit in Kubernetes that holds your application and its workload.

• ReplicaSets: Ensure the correct number of Pods are running and match the desired state.

• Deployments: Define the desired state of the application, manage ReplicaSets, and handle workload updates and scaling.

A Deployment manages only one type of Pod with a specific configuration, but it can create multiple copies (replicas) of that Pod.

If you need to manage Pods with different setups, you must create separate Deployments for each type. This keeps things organized and allows Kubernetes to handle each group of Pods separately for scaling and updates.

What Deployment strategies does Kubernetes provide?#

Kubernetes provides different Deployment strategies that allow you to update your applications based on the system’s specific needs. The three most common strategies are:

• Rolling update strategy: Minimizes downtime but takes longer to update.

• Recreate strategy: Causes downtime but updates quickly.

• Canary strategy: Updates a small portion of users first, with a full rollout later.

Let’s take a deeper look at each of these three strategies!

The rolling update strategy (Default)#

The rolling update strategy is a gradual process that allows you to update your system with only a minor effect on performance and no downtime.

In this strategy, instead of taking down the entire application at once, Pods are replaced incrementally, one by one, or in small batches, ensuring that some instances of the application are always running.

Pros and cons#

There is a minor performance reduction during this update process because the system consistently has one active Pod short of the desired number. This is often preferred to a full system deactivation, but this strategy isn’t suited for all situations.

Factors to consider:#

Some considerations when deciding to use a rolling update strategy are as follows:

• Question: How will my system react to momentarily duplicated Pods?

  • Answer: The rolling update strategy is suitable if your system can handle temporarily duplicated Pods without impacting performance or causing conflicts. For example, e-commerce websites.

• Question: Is the update substantial enough to malfunction with some Pods still running old specifications?

  • Answer: For updates that require all Pods to be on the same version to function correctly, avoid the rolling update strategy and consider the recreate strategy instead. For example, banking systems.

• Question: Will a minor performance reduction greatly affect my system’s usability? How finely time-sensitive is it?

  • Answer: If your system is highly sensitive to performance drops or requires real-time processing, carefully evaluate whether the rolling update strategy aligns with your requirements. For example, stock trading platforms.

For example, imagine we wanted to change the specifications for our Pods. We’d first change the Pod template to new specifications, passed from the Deployment to the ReplicaSet. The Deployment would then recognize that the current program state (Pods with old specifications) differs from the desired state (Pods with new specifications). The Deployment would create Pods and a ReplicaSet with the updated specifications and transfer workload one by one from the old Pods to the new Pods. By the end, we’ll have an entirely new set of Pods and ReplicaSet without any service downtime.

Rolling update strategy implementation#

To illustrate the rolling update strategy, let’s examine the following YAML file. This file creates 10 replicas of an application. Notice that the value of the spec.strategy.type is RollingUpdate.

Finally, we can create the Deployment with the following command:

If we want to change some configuration, let’s say, change the number of replicas to 5, we’d change the value of spec.replicas to 5 and then use the kubectl apply command again. As the value of spec.strategy is RollingUpdate, the number of replicas would gradually decrease.

The recreate update strategy#

The recreate update strategy is an all-or-nothing process that allows you to update all aspects of the system at once with a brief downtime period.

In this strategy, the Deployment selects all outdated Pods and deactivates them simultaneously. Once all old Pods are deactivated, the Deployment creates updated Pods for the entire system. The system is inoperable during this process.

The recreate strategy is used for systems that cannot function in a partially updated state or if you would rather have downtime than provide users with a lesser experience.

Factors to consider:#

Here are some factors to consider when choosing a recreate update strategy for your system:

• Question: Would the users have a better experience with downtime or temporarily reduced performance?

  • Answer: Consider the recreate strategy if a brief downtime provides a better user experience than a degraded performance. For example, banking systems during maintenance windows.

• Question: Could the system function during a recreate update?

  • Answer: The recreate strategy can be considered if the system can tolerate temporary downtime without impacting critical operations. For example, internal tools or non-urgent services.

• Question: Is there a time we could update the system without affecting a significant number of users?

  • Answer: If updates can be scheduled during periods of low user activity, downtime caused by the recreate strategy can be minimized. For example, e-commerce or banking websites during late-night hours.

Recreate update strategy implementation#

Let’s look at the following YAML file to see how the recreate update strategy is implemented. The Deployment is identical to the above file except that the value of spec.strategy.type is now Recreate instead of RollingUpdate.

Just as last time, we can create the Deployment using the following command:

If we want to make any changes to the configuration, we’ll edit the YAML file and then use the kubectl apply command to apply those changes. When the deployment controller detects a difference between the desired and the current configuration, it will delete all the current (running Pods) and create new Pods with the new configuration until the desired configuration is achieved.

The canary update strategy#

A canary update Deployment is a gradual rollout strategy in which updates are introduced to a small subset of users first. This allows you to monitor the changes in a controlled environment before rolling them out to everyone. This approach minimizes risks by testing the update’s impact on a smaller scale.

In this strategy, the Deployment creates a few new Pods while keeping most Pods on the previous version. The ratio can vary based on the desired rollout speed and risk tolerance. Most users still use the previous version, but a small subset unknowingly uses the new version to act as testers.

If we don’t detect bugs from this subset, we can scale up the updated ReplicaSet to produce a full rollout. If we find a bug, we can easily roll back the few updated Pods until we’ve fixed the bug.

Pros and cons#

The advantage of the canary update strategy is it allows you to test a new version without the risk of a full system failure. In the worst-case scenario, all users from the test subset experience critical errors while 75% or more of the user base continues without interruption.

The rollback process is also much quicker than the rolling update strategy because you only have to roll back a portion of the Pods rather than the entire system.

The downside is that the updated Pods will require a separate Deployment, which can be hard to manage at scale. Also, the canary update strategy results in a slower rollout due to the waiting period between rolling out to our initial subset and completing a full rollout.

Factors to consider:#

When considering the canary strategy, some key considerations are:

• Question: What’s the worst-case scenario if this update fails?

  • Answer: If the potential impact of a failure is severe (e.g., financial losses, user dissatisfaction), the canary strategy is ideal as it limits the exposure of the new release to a small group, allowing quick rollback if issues arise. For example, e-commerce checkout systems.

• Question: How soon do I need to finish the full rollout?

  • Answer: If a rapid rollout is necessary, the canary strategy may not be suitable due to the monitoring period required. In such cases, prioritize thorough internal testing before deployment. For example, critical updates during a high-traffic event.

• Question: How much internal testing have I done?

  • Answer: If extensive internal testing has been conducted, the canary strategy can serve as a final safeguard to verify changes in a real-world environment before full deployment, such as feature updates for a mobile app.

Canary update strategy implementation#

Let’s look at the following two YAML files to understand how the canary update strategy is implemented. We’ll need to create two different versions of a Deployment with some changes to the application. We can use different values of the same label to differentiate between two different releases. In our case, we’re using the label track.

First version (Outdated)#

Our first file, k8s-deployment.yaml, will be our outdated version that most of our Pods will run.

This will create 3 Pods of our application using the educative/helloworld:1.0 image and keeping the value of the label track as stable, meaning that these Pods will be based on the old Pod specifications.

Second version (Updated)#

Now, let’s look at the following snippet containing our updated configuration. Here, the value of the track label is canary, and we’re also using a different version of the image. We’re also creating only a single Pod to maintain the 75:25 ratio. This ensures that most users will interact with the old configuration.

Also, notice that both Deployments have a common label with a common value, i.e., app: helloworld. The Service will use this label to identify that both sets of Pods belong to the same application, and the traffic will be redirected to both versions.

Once you’re satisfied that the updated release works as intended, we can replace the image in our first release (stable) and remove the second one (canary). We can use the kubectl delete command to remove the canary Deployment.

All of our Pods will now have the updated configuration with minor chances of any bugs.

To summarize the deployment strategies, let’s have a look at the following table:

By now, you probably have a good grasp of the deployment strategies. For a much deeper dive into Kubernetes and deployment strategies, explore the following courses: