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.

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
This removes the ReplicaSet and all managed Pods.

Delete Pods Independently
kubectl delete pods --selector
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

Apply the updated Pod configuration:kubectl apply -f .yaml

Scaling a ReplicaSet

1. Manual Scaling You can scale a ReplicaSet manually using:

kubectl scale rs --replicas=5

1. 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.