Kubernetes ReplicaSet: Overview & How It Works

When it comes to planning a pregnancy, you rarely get to decide in advance if you’re going to end up with twins or not. If you're a Kubernetes admin, however, you can decide how many Pods you want to run, thanks to ReplicaSets. ReplicaSets allow you to tell Kubernetes to create multiple copies of the same Pod – which is kind of like having a pair of human babies, minus the sleep deprivation.

Here's a breakdown of everything Kubernetes admins should know about what ReplicaSets are, how they work, and how to use them effectively.

What is a Kubernetes ReplicaSet?

In Kubernetes, a ReplicaSet is a group of multiple instances of the same Pod. In other words, when you create a ReplicaSet, Kubernetes runs a set of replicas (hence the name) of the same Pod.

The Kubernetes ReplicaSet feature allows you to run multiple Pod instances (based on a Pod template defined within the ReplicaSet) without having to deploy each one separately. This is convenient in situations where you want to ensure that you have more than one copy of a Pod running at any given time.

ReplicaSet vs. ReplicationController vs. Kubernetes Deployments

Creating a ReplicaSet isn't the only way to run multiple copies of the same Pod. You can also use a ReplicationController and a standard Deployment to achieve something similar – although these alternatives to ReplicaSets work a bit differently in some respects.

ReplicationController also lets you configure a set of Pod replicas, but it does so using selectors that are equality-based, whereas ReplicaSets use set-based selectors. A detailed explanation of the difference in these types of selectors is beyond the scope of this article, but suffice it to say that set-based selectors are typically more flexible. Mainly for that reason, ReplicaSet (which is a new feature) has become the preferred approach for running multiple Pod instances in most cases. ReplicationContollers are still supported in Kubernetes for now, but a lot of admins treat them as a more or less deprecated feature.

As for ReplicaSets vs. Deployments, these are not alternative solutions as much as they're complementary ones that can – but don't have to be – used together. You can create a ReplicaSet as part of a Kubernetes Deployment, or you can create a standalone K8s ReplicaSet. Typically, creating a ReplicaSet as part of a Deployment is the preferred approach because a Kubernetes Deployment also allows you to configure other aspects of Pod behavior that you can't manage through a ReplicaSet. That said, if your only goal is to ensure that Kubernetes runs multiple replicas of the same Pod, a ReplicaSet is the most straightforward way to do that.

How does a ReplicaSet work?

ReplicaSets work in a pretty straightforward way: You write a manifest containing a Pod template and other code that tells Kubernetes which Pod to run and how many replicas of the Pod should be present. Then, you deploy the ReplicaSet, and Kubernetes automatically enforces the desired state by running the number of replicas you've specified (assuming that's possible, which it should be unless your Kubernetes cluster has major issues like lack of available Kubernetes nodes to support the requested number of Pod replicas).

For example, here's a ReplicaSet that runs 3 replicas of an NGINX Pod:

(For details on what this code does, scroll down to the "Writing a ReplicaSet manifest" section later in this article.)

You can deploy this ReplicaSet by saving the code to a file with a name like nginx-replicaset.yaml, then deploying it with:

When to use ReplicaSets in Kubernetes

The main use case for a ReplicaSet is ensuring that multiple copies of the same Pod run at any given time. This helps ensure the availability of applications because if one Pod fails for some reason (such as its host node crashing or being drained), other copies of the Pod remain available (and Kubernetes will automatically work to restart the failed Pod in order to restore the desired number of Pod replicas).

Of course, if you ran just a single Pod instance, Kubernetes would try to restart the Pod in the event it failed. In that sense, ReplicaSets are not the only way to try to achieve application stability.

However, the major advantage of Kubernetes ReplicaSets is that you always have multiple Pod replicas running, so there is no downtime in Pod availability while you wait for Kubernetes to restart a failed Pod. (Well, there would be downtime if all of your replicas were to crash at the same time, but that should almost never happen unless you are exceedingly unlucky or your Kubernetes cluster has serious performance issues.)

The downside, of course, is that running multiple Pod replicas consumes more resources because you have more Pods running. But that's almost always the tradeoff for increased availability and stability.

Benefits of Kubernetes ReplicaSets

As we mentioned above, increased availability is the main overall advantage of using a ReplicaSet. But to be more specific, ReplicaSets also provide Kubernetes benefits such as:

• Load balancing: By running multiple copies of a Pod through a ReplicaSet, you can distribute load across them. This helps prevent any one Pod from becoming overwhelmed with requests while other Pods sit idle or under-utilized.
• High availability: As we mentioned, ReplicaSets help maximize application availability because you (should) always have more than one copy of a Pod running.
• Reliability: Along similar lines, ReplicaSets increase the reliability of apps and services hosted on Kubernetes.
• Scaling: Once you create a ReplicaSet, you can increase or decrease the number of replicas within it using the kubectl autoscale rs command. This makes ReplicaSets a convenient way to scale application capacity up or down based on how many Pod instances you need to support application demand at any given point in time.

Writing a ReplicaSet manifestAs we noted above, creating a K8s ReplicaSet requires writing a manifest. The manifest contains code that tells Kubernetes how to run the ReplicaSet.To revisit the example we used previously, here's a manifest that creates a ReplicaSet with three copies of an NGINX Pod:

This manifest does a few key things:

• kind defines a ReplicaSet as the type of object we're creating.
• name specifies a name for the ReplicaSet (nginx-replicaset in this example).
• replicas specifies how many copies of the Pod to create.
• The containers spec section defines which container image to use and which port to run on.

After creating this manifest, you'd apply it using the kubectl apply -f manifest-name.yaml command.

Working with ReplicaSets

Here's a look at important actions you can take to work with ReplicaSets once you've created one.

List ReplicaSets

This command will show which ReplicaSets you currently have deployed:

Deleting a ReplicaSet and its Pods

To delete a ReplicaSet and its associated entirely, use this command:

This removes the ReplicaSet and any Pods that were running as part of it. Thus, you'd want to use this command if your goal is to shut down the application entirely.

Delete a ReplicaSet without removing Pods

It's also possible to delete a ReplicaSet but keep its Pods in operation using this command:

After running this command, the kubectl get rs command should show that your ReplicaSet no longer exists, but kubectl get pods will display the ReplicaSet's Pod as active.

Remove Pods from a ReplicaSet

You can remove Pods from a ReplicaSet if you want them to keep running, but not as part of the ReplicaSet. To do this, you edit the Pod's label.

To change a Pod's label, open its configuration using a command like:

Then, modify the role= value to anything other than its current value.

A few seconds after making this change, kubectl get pods will show that the Pod is still running but is no longer part of the ReplicaSet.

Note, however, that this change will automatically trigger the creation of a new Pod as part of the ReplicaSet to replace the one you removed – so effectively, removing a Pod from a ReplicaSet adds a new Pod instance (in other words, the total number of Pods increases), although the number of Pods inside the ReplicaSet remains the same.

If you want to remove a Pod from a ReplicaSet without having Kubernetes replace it, you'd need to scale the ReplicaSet down.

Scale a ReplicaSet

There are two ways to scale a ReplicaSet.

One is to define a fixed number of replicas using a command like the following:

This tells Kubernetes to create the number of replicas you define, regardless of the value configured in the original manifest file.

The other way to scale a ReplicaSet is autoscaling, which you can configure using a command like the following:

This tells Kubernetes to use the Horizontal Pod Autoscaler to increase the number of replicas automatically (up to the maximum you defined) as CPU load increases. Thus, you won't necessarily always have the maximum number of replicas running, but you should automatically see an increase if application demand increases. This is a handy way to manage application scale automatically, without waiting to depend on Kubernetes alerting to notify you when you should scale your app.

Alternatives to ReplicaSet

Again, a ReplicaSet is not the only way to run multiple copies of the same Pod. You can do the same thing in various other ways – although each comes with different pros and cons.

Here's a look at the main alternatives to ReplicaSets.

Deployments

You can specify replicas as part of a Pod template when creating a Deployment – another way to create Pod replicas.

In general, this approach is preferable to creating a standalone ReplicaSet because a Deployment also allows you to define additional configuration values that aren't supported by ReplicaSets. In addition, you can scale replicas based on a Deployment in a similar way to scaling those inside a ReplicaSet.

That said, if your only goal is to deploy multiple copies of a Pod, and none of the other options that come with a Deployment is important, it makes sense to create a ReplicaSet instead of a Deployment.

ReplicationController

As we noted, ReplicationController is an older Kubernetes feature that is very similar to ReplicaSets, with the main difference being that ReplicaSets use set-based selectors instead of equality-based ones.

There are very few situations today where you'd want to use a ReplicationController instead of a ReplicaSet. The only real example is scenarios where you already have manifests written to support a ReplicationController and you don't want to bother with converting them to work with a ReplicaSet.

DaemonSet

A DaemonSet allows you to run a copy of a Pod on multiple nodes, achieving a similar outcome as ReplicaSets. However, the main purpose of a DaemonSet is to ensure that copies of a Pod run on certain nodes. This is often done to support Kubernetes monitoring and logging agents. In contrast, a ReplicaSet doesn't guarantee that Pods will be distributed across nodes; it could result in multiple copies of a Pod running on the same node.

So, use a ReplicaSet if you want to run a certain number of copies of a Pod but don't care about exactly where they run. Use a DaemonSet if you want to distribute copies of a Pod across multiple nodes.

Running bare Pods manually

Another way to run multiple copies of a Pod using a Pod template without creating a ReplicaSet is simply to run the same Pod multiple times using manual kubectl run commands.

If you do this, each Pod will run independently of the others. You won't be able to delete or scale the Pods using a single command because they won't be part of a ReplicaSet.

Running individual Pods based on a separate Pod template for each one entails more manual effort. Generally, it only makes sense if you’re running multiple Pod instances for testing purposes, not in production.

Jobs

A final method for running multiple Pods without using a ReplicaSet is to use the Kubernetes Jobs controller. The Jobs controller supports a parallelism parameter (spec.parallelism) where you can configure multiple copies of the same Pod and have them run when a Job runs.

That said, you should only do this if you need to run multiple Pods as part of a Job (which might be necessary if, for example, the Job workload needs to be distributed across multiple Pods for some reason). If your only goal is to run multiple copies of a Pod as part of a standard application deployment, this is a clunky way to do it.

Getting more from Kubernetes with ReplicaSets

From increasing application availability, to balancing load, to scaling Pods and more, ReplicaSets bring a variety of benefits to Kubernetes. Understanding when and how to take advantage of ReplicaSets is a crucial part of operating Kubernetes effectively at scale.