Kubernetes – Creating a ReplicaSet

A ReplicaSet is a core Kubernetes controller designed to ensure that a specified number of identical Pods, called replicas, are running at all times. It serves as a self-healing mechanism — if any Pod fails, crashes, or is accidentally deleted, the ReplicaSet automatically creates a replacement to maintain the desired count. This guarantees high availability, scalability, and reliability for applications running in Kubernetes.

Purpose of a ReplicaSet

The main objectives of a ReplicaSet are to maintain application stability, availability, and scalability.

High Availability:
A ReplicaSet maintains a consistent number of running Pods. Even if a node or Pod fails, others remain available to serve traffic, ensuring zero downtime.
Load Balancing:
When used with a Kubernetes Service, a ReplicaSet distributes traffic evenly across all its Pods. As replicas scale up or down, the Service dynamically adjusts to maintain balanced traffic distribution.
Scalability:
You can easily adjust the number of replicas by modifying the replicas field in the ReplicaSet specification. The controller automatically creates or removes Pods to match the updated count.

How ReplicaSets Improved Over Replication Controllers

ReplicaSets are the modern replacement for the older Replication Controller. The key improvement lies in label selectors:

Replication Controller:
Uses equality-based selectors, matching Pods with exact key-value label pairs (e.g., app: frontend). This is quite restrictive.
ReplicaSet:
Uses set-based selectors, allowing more expressive selection logic. For example, it can select Pods where a label value exists or belongs to a specific set of values.

Example:
```
matchExpressions:
- key: environment
  operator: In
  values:
  - production
  - qa
```
This allows a ReplicaSet to manage Pods with labels environment=production or environment=qa.

Example: ReplicaSet Manifest


apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-rs-pod
    matchExpressions:
    - key: env
      operator: In
      values:
      - dev
  template:
    metadata:
      labels:
        app: nginx-rs-pod
        env: dev
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Non-Template Pod Acquisition

A ReplicaSet can also adopt existing Pods that match its selectors, even if it didn’t originally create them. This process is called non-template Pod acquisition.

Example:


apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: first-replicaset
spec:
  selector:
    matchLabels:
      app: web-app
  replicas: 5

Any Pod with the label app: web-app will be managed by this ReplicaSet.

Note: Always ensure that your ReplicaSet selectors don’t unintentionally match other Pods, as this can lead to unwanted acquisitions.

Working with ReplicaSets

Step 1: Create the YAML File

Define your ReplicaSet with desired configurations such as the number of replicas, labels, and container specifications.

Example:


apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-app:latest
        ports:
        - containerPort: 80

Step 2: Create the ReplicaSet


kubectl create -f replicaset.yaml

Step 3: Verify Creation


kubectl get replicasets

Step 4: View Details


kubectl describe replicaset my-replicaset

Deleting ReplicaSets and Pods

Delete a ReplicaSet


kubectl delete rs <replicaset-name>

This removes the ReplicaSet and all managed Pods.

Delete Pods Independently


kubectl delete pods --selector <key=value>

You can delete specific Pods without deleting the ReplicaSet. The ReplicaSet will recreate them to maintain the replica count.

Isolating Pods from a ReplicaSet

To exclude a Pod from ReplicaSet management, change its label so it no longer matches the ReplicaSet’s selector.

Steps:

List Pods:
```
kubectl get pods
```
Edit Pod labels:
```
kubectl edit pod <pod-name>
```
Apply the updated Pod configuration:
```
kubectl apply -f <pod-definition>.yaml
```

Scaling a ReplicaSet

1. Manual Scaling

You can scale a ReplicaSet manually using:


kubectl scale rs <replicaset-name> --replicas=5

2. Automatic Scaling with HPA

You can attach a Horizontal Pod Autoscaler (HPA) to automatically adjust replicas based on metrics like CPU utilization.

Example:


apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: mavenwebapprc
  namespace: test-ns
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mavenwebapp
  template:
    metadata:
      labels:
        app: mavenwebapp
    spec:
      containers:
      - name: mavenwebapp
        image: dockerhandson/maven-web-application:1
        ports:
        - containerPort: 8080
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 80

When CPU utilization reaches 80%, the HPA scales the replicas up to the configured maximum limit (for example, four Pods).

Difference Between ReplicaSet and ReplicationController

Feature	ReplicaSet	ReplicationController
Purpose	Modern controller ensuring desired number of Pods are running	Older mechanism managing Pod lifecycles
Selector Type	Supports set-based selectors	Supports only equality-based selectors
Flexibility	More expressive and powerful matching logic	Limited matching capabilities
Status	Successor to ReplicationController	Deprecated for most use cases

Difference Between ReplicaSet and DaemonSet

Feature	ReplicaSet	DaemonSet
Pod Distribution	Ensures a fixed number of Pods run across the cluster	Ensures one Pod runs on each node
Use Case	Best for stateless applications like web servers	Ideal for stateful or system-level apps like log collectors or monitoring agents
Pod Replacement	Recreates a Pod when one is deleted	Automatically deploys a Pod to every new node in the cluster
Scaling	Manually or automatically scaled	One Pod per node by design

Summary

A ReplicaSet is the foundation of Kubernetes scalability and reliability. It ensures your applications stay highly available by maintaining the right number of Pods. While Deployments are typically used to manage ReplicaSets (for rolling updates and version control), understanding ReplicaSets helps you grasp how Kubernetes ensures continuous and consistent application availability.

Search This Blog

AskTech