In this guide, we will talk about Kubernetes ReplicaSets - how they work, how to use them, how to update, delete, scale them, and much more.

replicasets, replica sets, kubernetes replicasets

Kubernetes is an open-source container orchestration platform that has revolutionized the way applications are deployed, scaled, and managed in distributed environments. 

At the heart of Kubernetes' scaling capabilities lies the ReplicaSet—an essential building block that ensures your applications are always available, resilient, and adaptable to changing demands.

In this blog post, we'll dive into the world of Kubernetes ReplicaSets, why they are important, their functionality, and the pivotal role they play within the Kubernetes ecosystem. 

Kubernetes Replicasets

A Kubernetes ReplicaSet is a resource object within the Kubernetes ecosystem that helps ensure a specified number of replicas (copies) of a pod are running at all times.

ReplicaSets work to maintain the desired state of a set of identical pods, ensuring that if the actual state deviates from the desired state (due to failures or scaling needs), the ReplicaSet takes appropriate actions to bring the system back to the desired state.

Also Read: A Complete Guide to Kubernetes Secrets

How Does a ReplicaSet Work?

A ReplicaSet in Kubernetes works by continuously monitoring the actual state of a set of pods with the desired state defined in its configuration.

 It ensures that the specified number of replica pods, which you have specified in the manifest file are running at all times and takes actions in response to changes in the cluster's state.

This basically means, suppose you have 3 replicas of your application and by mistake, if you delete one of the pods using the command kubectl delete pod <pod-name>, the pod will get deleted but instantly, another pod will be started.

This is how ReplicaSets make sure that the specified number of pods are all up and running.

Here is how a RepliaSet operates practically,

Desired State Definition: When you create a ReplicaSet, you define the desired state by specifying the number of replicas you want to maintain and a pod template that describes the characteristics of these replicas, such as the container image, resources, and configuration.

Pod Label Matching: The ReplicaSet uses a selector with label matching to identify the pods it manages.

The labels in the pod template and the selector ensure that the ReplicaSet can track and manage the right set of pods.

Monitoring: Once the initial set of pods is created, the ReplicaSet enters a monitoring and reconciliation loop. 

Changes Detection: If there are any discrepancies between the desired and actual state (e.g., due to pod failures or manual pod deletion), the ReplicaSet detects these changes during its monitoring process.

Taking Corrective Actions: When the ReplicaSet identifies a difference between the desired and actual replica count, it takes corrective actions to bring the system back to the desired state.

These actions include creating new pods to replace failed ones or terminating excess pods that exceed the desired count.

Scaling Operations: If you decide to scale the ReplicaSet, either by increasing or decreasing the replica count, the ReplicaSet adjusts the number of pods accordingly.

It will either create new pods or terminate existing ones, ensuring that the new replica count is met.

Also Read: Differences between Vertical Scaling and Horizontal Scaling

How to Create ReplicaSets in Kubernetes?

Suppose you have a basic web application that consists of a single container running a web server. You want to ensure that there are always three replicas of this web application running, providing redundancy and load distribution.

You'll start by creating a ReplicaSet manifest in YAML format. This manifest will define the desired state of the ReplicaSet, including the pod template for your application.

Here is the manifest file which will make sure that the deployment of your web application has 3 replicasets always up and running.

In this case, we are using a sample web app docker image. You can use your own.

apiVersion: apps/v1
kind: ReplicaSet
  name: webapp-replicaset
  replicas: 3
      app: webapp
        app: webapp
        - name: webapp-container
          image: appdynamics/sample-app-web
            - containerPort: 80

Let's understand this manifest file, which introduces a new Kubernetes resource.

  • kind: This specifies the Kubernetes resource type. Here, it's a ReplicaSet.
  • metadata: It contains the metadata for the ReplicaSet, such as its name.
  • replicas: It specifies the desired number of replicas (pods) to maintain. In this case, it's set to 3.
  • selector: This specifies a label selector to identify the pods managed by this ReplicaSet. The pods must have labels that match the specified labels here.
  • matchLabels: This specifies the labels used for pod selection. In this case, it's using a label app: webapp. This means the ReplicaSet will manage pods with the label app set to webapp.
  • template: template describes the pod template that ReplicaSet will use to create and manage its replicas.

You can apply the manifest file using the command

kubectl apply -f my-web-app.yaml
This is what the output of this command will look like when executed.
output kubectl apply, replicasets

Now, you can view the created ReplicaSet and its associated pods by using the following commands:

kubectl get replicasets
The above command will give you an output similar to the screenshot below.
kubectl get replicaset output, replica sets
kubectl get pods -l app=webapp

The output of kubectl get pods will look something like this.

kubectl get pods output, replicasets

After creating a replicaset, let's see how you can work with these and do operations like Deletion, Autoscaling, etc.

humalect developer platform CTA banner, kubernetes replicasets

How to Scale a ReplicaSet?

Let's say you want to scale up the number of replicas to handle increased traffic, to 5. You can use the following command to do so, where “webapp-replicaset” is the name of the replicaset in the manifest file.

kubectl scale replicaset webapp-replicaset --replicas=5

This scale command's output will be something like this.

kubectl scale replicasets, kubernetes replicaset

You can also view these replicas on minikube dashboards, by using the following command:

minikube dashboard
The minikube dashboard will look something like this.

minikube dashboard, replicasets

You can click on each ReplicaSet, for personalized data with CPU and Memory usage as well.

Also Read: How to Fix CrashLoopBackOff in Kubernetes?

How to Delete a ReplicaSet in Kubernetes?

By using the following command, where <rs name> is the name of your ReplicaSet, you can destroy ReplicaSets. After you destroy the ReplicaSet, the running Pods will also get deleted. 

kubectl delete rs <rs name>
The output of the above delete command will look something like the image shown below.
kubectl delete output, deleting a kubernetes replicaset
humalect cta banner, kubernetes replica sets

When to Use ReplicaSets?

In the following section, you will see, when and how to leverage Kubernetes ReplicaSets with real-world examples to illuminate their significance in ensuring application availability and resilience.

Basic Scaling and Redundancy

ReplicaSet excels at maintaining a consistent number of identical pod replicas. They are ideal for scenarios where you need to ensure a certain level of redundancy and scaling. 

For example, think of a web application that experiences varying traffic loads throughout the day. 

A ReplicaSet could guarantee that a set number of pods are always available to handle incoming requests, even during traffic spikes.

Also Read: Cluster Autoscaler vs Karpenter

Manual Healing and Recovery

In a disturbed environment, failures are inevitable. In such a situation, ReplicaSets comes to the rescue by automatically replacing failed pods to restore the desired replica count. 

This behavior aids in maintaining the system's health and availability.

For instance, an eCommerce platform utilizes a ReplicaSet for its checkout service. If a pod running the checkout service crashes due to some issues, the ReplicaSet quickly replaces it to continue processing customer orders seamlessly.

Stateless Applications

ReplicaSets are particularly suited for stateless applications that don't rely on maintaining specific data or states across instances. 

Since each pod is identical, they can be easily replaced or scaled without causing any data integrity concerns.

For instance, a social media platform uses a ReplicaSet to manage its user authentication service. 

As authentication processes are stateless and uniform across requests, the ReplicaSet ensures that multiple pods handle incoming authentication requests without data conflicts.

From the above section, one can get an idea of how important is ReplicaSets in the practical aspect of development and how useful it is too.

To make the best use of this extraordinary Kubernetes resource, let's see what some of the great practices of using ReplicaSets are.

Also Read: When to Use Kubectl Rollout Restart?

ReplicaSets Best Practices

Deploying and managing ReplicaSets effectively requires sticking to best practices to ensure the best performance, scalability, and reliability. 

Here are some ReplicaSet best practices in Kubernetes to consider.

Use Labels and Selectors Wisely

Labels and selectors are crucial for ReplicaSets to identify and manage pods. 

Try to use meaningful labels that represent the purpose or role of the pods. 

Ensure that the labels in the ReplicaSet's selector match the labels in the pod template.

Here's an example. Instead of a generic label like app: web, opt for something descriptive like app: ecommerce-frontend to enhance clarity when dealing with multiple components.

Define Resource Requests and Limits

Ensure each pod's resource requirements (requests) and limits are defined appropriately. This prevents resource clashes and guarantees that pods can scale effectively without impacting overall cluster performance.

Also Read: Kubeadm for Cluster Management

Plan for Scalability

When defining the initial number of replicas, consider the expected load and resource availability. Also, set up alerts or automation to scale the ReplicaSet based on observed metrics, such as CPU utilization or traffic.

Design for High Availability

Spread your ReplicaSet pods across multiple nodes and availability zones to enhance redundancy and resilience. This ensures that a single point of failure doesn't affect the entire ReplicaSet.

Also Read: Why Application Performance Monitoring is Important?

Keep an Eye on Events and Logs

Monitor events and logs from your ReplicaSet to detect errors or resource shortages. This proactive approach helps you identify and address issues before they escalate.

Regularly review Kubernetes events and pod logs. If a ReplicaSet is repeatedly creating pods due to errors, investigate and rectify the underlying cause.

A ReplicaSet is the core building block for maintaining a specified number of identical pod replicas, ensuring high availability and resilience. Its excellence is at handling straightforward scaling needs and guarantees a consistent number of pods at all times.

Also Read: The Only Guide to Kubernetes Port Forwarding You'll Ever Need

ReplicaSets Vs Deployments

Consider this scenario. Imagine a content management system that receives regular feature updates. 

By creating a Deployment, you can easily manage updates, ensuring zero downtime rollouts. In case an update causes unforeseen issues, you can promptly revert to the previous version without service disruptions.

Deployments build upon the foundation of ReplicaSets and introduce version control and declarative update strategies. 

They focus on ensuring seamless application updates and enabling rollbacks in case issues arise during the update process.



It ensures a consistent number of replicas at all times.

It can maintain a specific number of replicas but primarily focuses on updates.

It doesn't directly handle updates or version control.

It facilitates controlled, zero-downtime updates and rollbacks.

It doesn't support rolling updates natively.

It supports rolling updates, allowing gradual replacements of old pods with new ones.

After knowing the basic definitions and some differences, you can understand when to choose which from the following section.

When to Choose ReplicaSets?

You need to maintain a consistent number of replicas to ensure redundancy and availability. For stateless applications and straightforward scaling needs, ReplicaSets are a suitable choice.

When to Choose Deployments?

You need to manage application updates and version control effectively. Deployments are the preferred option for orchestrating rolling updates, enabling rollbacks, and maintaining different versions of your application.

Let's go through some more Kubernetes resources and compare them with ReplicaSets.

Also Read: Kubernetes imagePullPolicy

ReplicaSet vs. StatefulSet vs. DaemonSet


Kubernetes StatefulSets introduce order and consistency to stateful applications, such as databases, by assigning unique identities and persistent storage to each pod. 

They enable stable, ordered scaling and updates while preserving the state.

Imagine that you have a database scenario, a StatefulSet assigns unique hostnames and persistent storage to each replica. This facilitates reliable scaling and enables seamless, ordered updates without data loss.


DaemonSets in Kubernetes guarantees a copy of a pod runs on every node within a cluster. They're designed for system-level tasks, like logging agents or monitoring tools, that require continuous coverage across nodes.

Consider a security monitoring agent that must be present on every node for comprehensive coverage. 

A DaemonSet automatically deploys and maintains the agent on each node, ensuring full visibility into cluster activities.




Provides redundancy and scalability for stateless applications.

Offers ordered scaling for stateful applications.

Ensures a pod's presence on every node, regardless of state.

Doesn't manage state, suitable for stateless applications.

Manages stateful applications, preserving unique identities and data.

Primarily focuses on system-level tasks, not state management.

Distributes pods across nodes based on resource availability.

Ensures stable pod identities and placement.

Places pods on all nodes for system-level coverage.

With this, we have reached the end of the blog. Here is a brief summary of what we have achieved in the blog.

humalect developer platform, kubernetes replicasets

Final Words: Kubernetes ReplicaSets

In this blog, we explored the fundamentals, diving into what ReplicaSets are and how they work, ensuring a solid foundation.

From creating and working with ReplicaSets to understanding their optimal use cases and best practices, we've navigated the path to mastering their capabilities. 

We also delved into comparing ReplicaSets with Deployments, StatefulSets, and DaemonSets. 

By covering these essential topics, you've been equipped with the insights to harness the power of ReplicaSets effectively, enriching your understanding of Kubernetes orchestration and enabling you to elevate your application's scalability and resilience.