Kubernetes ReplicaSet: Overview & How It Works

Last updated: May 24, 2026

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, which is a kubernetes object used to manage pods through ReplicaSets, or you can create a standalone K8s ReplicaSet. Typically, creating a ReplicaSet as part of a Deployment is the preferred approach in a broader kubernetes environment because it can also automate application lifecycle management and lets you 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: A ReplicaSet ensures a specific replica count by keeping identical pods running from the Pod template in your manifest. Then, you deploy the ReplicaSet, and Kubernetes automatically enforces the desired state by running the number of replicas you’ve specified, and it may create pods or replace failed ones to maintain that desired number (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, creating three nginx pods:

(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 by maintaining replicated pods, so additional pods can be started when needed to preserve availability. 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 the ReplicaSet to create new pods after a failure. (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, as part of Kubernetes application lifecycle management, 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: You can also use kubectl get deployments when you want to review related Deployment resources before working with ReplicaSets.

Deleting a ReplicaSet and its Pods

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

This removes the ReplicaSet and handles deleting 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

Whether a pod belongs to the ReplicaSet depends on its labels matching the selector, so you can remove Pods from a ReplicaSet if you want them to keep running, but not as part of the ReplicaSet, by editing 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 Kubernetes to create a replacement in the ReplicaSet, so replica pods outside and inside the set are reconciled back to the desired count, even though the original Pod keeps running.

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 by setting an explicit replica count so you can manually scale, 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, adding additional pods instead of requiring you to manually scale each change. 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

A Deployment is one of the Kubernetes API objects, and it defines replicas in its own spec while managing ReplicaSets underneath. Its deployment metadata includes identifying fields such as the name and labels. You can specify replicas as part of a Pod template when creating a Deployment, because a deployment creates and updates ReplicaSets to manage 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. The deployment's pod template defines the Pods, and changing it causes the Deployment to create a new ReplicaSet. In addition, you can scale replicas based on a Deployment in a similar way to scaling those inside a ReplicaSet. A deployment controller also handles rollout behavior and deployment status as changes are applied, gradually replacing existing Pods so multiple versions can coexist temporarily during an update. Deployments support declarative, zero-downtime updates, and you can check rollout status with kubectl rollout status, while ReplicaSets do not support native update strategies such as rolling updates or rollback workflows. For example, an nginx deployment can be a deployment named nginx deployment with nginx deployment labels set to app nginx in both the deployment metadata and the template, plus an nginx image in the spec. This makes Deployments a better fit when you need rolling update support.

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, including machine monitoring and machine 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, especially for maintaining a target number of Pods. For rollout, rollback, and versioned updates, rely on Kubernetes documentation and Deployment workflows to return to a previous version rather than standalone ReplicaSets. Understanding when and how to take advantage of ReplicaSets is a crucial part of operating Kubernetes effectively at scale.