Skip to main content
< All Topics

Kubernetes ReplicaSet

Posted
Updated
Author -Rajkumar Aute
Views9

The Guardian of Your Pods

Think of a ReplicaSet as a “Guarantee Manager.” Its only job is to make sure that a specific number of identical Pods (copies of your application) are running at all times. If you ask for 3 copies, it ensures there are exactly 3. If one crashes, it creates a new one immediately. If you accidentally start a 4th one, it deletes the extra one. It is the self-healing mechanism that keeps your app available.

Key Characteristics to Remember
  • ReplicaSet replaces the older “ReplicationController.”
  • Help Deployment to rollout and rollback using history.
  • Load balancing: traffic will be shared actress multiple pods using labels and selectors
  • Scaling: increase / decrease the number of pods
  • It ensures the “Desired State” (number of pods) matches the “Current State.”
  • It uses Labels and Selectors to track which Pods belong to it.
  • It does not support Rolling Updates (you need a Deployment for that).
FeatureDescription
Primary GoalMaintain a stable set of replica Pods running at any given time.
Key Field.spec.replicas (How many do you want?)
IdentificationUses matchLabels to find its Pods.
Self-HealingYes. Restarts Pods if they fail or are deleted.
UpdatesNo. Cannot change the image version smoothly (no rolling update).
Recommended WrapperDeployment. (Always use Deployment to manage ReplicaSets).

Kubernetes ReplicaSet is a workload API object used to ensure high availability. While Pods in Kubernetes are “ephemeral” (they can die and won’t restart themselves), a ReplicaSet adds stability. It runs a continuous loop that checks: “Do I have X number of pods with label Y?” If the answer is No, it takes action to fix it.

It is rarely created directly by users anymore. Instead, we create a Deployment, and the Deployment automatically creates and manages the ReplicaSet for us. However, understanding ReplicaSet is critical because it is the underlying machinery that makes scaling and self-healing possible.

When you apply a ReplicaSet, the Kubernetes Controller Manager picks it up. It doesn’t just create pods blindly; it looks for existing pods that match the labels.

Label Selector Logic:

  • ReplicaSet uses matchLabels in the selector. This is an “Equality-based” requirement.
  • Example: If the selector says env: prod, it will claim ANY pod in the namespace with that label, even if you created that pod manually hours ago! This is called “Pod Adoption.”

This is where things get interesting for production design.

The “Adoption” and “Orphaning” Concept:

  • Adoption: If you create a “naked” Pod (a pod without a controller) that matches a ReplicaSet’s selector, the ReplicaSet will effectively “kidnap” (adopt) it and count it towards its total.
  • Orphaning (Cascading Deletes): By default, if you delete a ReplicaSet, it deletes all its Pods. However, you can delete only the ReplicaSet and leave the Pods running using the --cascade=orphan flag. This is useful for migrating zero-downtime applications to a new controller.

Why Deployments are Superior:

  • A ReplicaSet cannot do a “Rolling Update.” If you change the image in a ReplicaSet YAML and apply it, nothing happens to the existing pods. You have to manually kill them for new ones to spawn with the new image.
  • A Deployment manages ReplicaSets. When you update a Deployment, it creates a new ReplicaSet, slowly scales it up, and scales down the old ReplicaSet. This is why Architects always ban raw ReplicaSets in production manifests.

Benefits:

  • High Availability: If a node dies, pods are rescheduled elsewhere.
  • Load Balancing: Services distribute traffic to all pods managed by the ReplicaSet.
  • Scalability: Changing the count from 3 to 30 takes milliseconds.

Limitations:

  • No support for canary deployments or blue/green deployments natively (requires Deployment).
  • No rollback history.

https://kubernetes.io/docs/concepts/workloads/controllers/replicaset

Create ReplicaSet by Commands

Bash
kubectl create deployment my-web-app-replicaset \
  --image=nginx:latest \
  --replicas=3 \
  --port=80

Create basic replicaset.yaml via kubectl command
Bash
kubectl create deployment my-web-app-replicaset \
  --image=nginx:latest \
  --replicas=3 \
  --port=80 \
  --dry-run=client -o yaml > replicaset.yaml

Note By adding --dry-run=client -o yaml > replicaset.yaml it will generate yaml.

Create ReplicaSet by Yaml file

1: Create replicaset.yaml with below code.

Kubernetes ReplicaSet YAML 
# -------------------------------------------------------------------
# 1. API Version & Kind
# -------------------------------------------------------------------
# "apps/v1" is the stable API group for workloads like ReplicaSets.
apiVersion: apps/v1 
# "kind" tells Kubernetes what type of object we are creating.
kind: ReplicaSet

# -------------------------------------------------------------------
# 2. Metadata (About the ReplicaSet itself)
# -------------------------------------------------------------------
metadata:
  # The unique name of your ReplicaSet object.
  name: my-web-app-replicaset
  # Labels help you organize and filter your resources (e.g., kubectl get rs -l env=prod).
  labels:
    app: my-web-app
    env: production
    tier: frontend

# -------------------------------------------------------------------
# 3. Specification (The Desired State)
# -------------------------------------------------------------------
spec:
  # "replicas" is the MOST vital field. 
  # It tells K8s: "Ensure exactly 3 copies of this pod are running at all times."
  replicas: 3 # If you didn't specify this, it would default to 1 replica.

  # "selector" is how the ReplicaSet finds which Pods belong to it.
  # CRITICAL RULE: This MUST match the labels in the "template" below.
  selector:
    matchLabels:
      app: my-web-app
      env: production

  # ----------------------------------------------------------------
  # 4. Pod Template ( The Blueprint)
  # ----------------------------------------------------------------
  # If a Pod dies (or doesn't exist yet), the ReplicaSet uses this 
  # template to create a new one.
  template:
    metadata:
      # These labels are applied to the ACTUAL Pods created.
      # They allow the "selector" (above) to find these pods.
      labels:
        app: my-web-app
        env: production
    
    spec:
      containers:
      # ------------------------------------------------------------
      # Container Details
      # ------------------------------------------------------------
      - name: nginx-container
        # The Docker image to use. "latest" is okay for labs, but avoid in production.
        image: nginx:latest
        
        # "Always" = Check registry for new image every time.
        # "IfNotPresent" = Use local cache if available (faster).
        imagePullPolicy: IfNotPresent
        
        # Open port 80 on the container so traffic can enter.
        ports:
        - containerPort: 80
          name: http-web
          protocol: TCP
        
        # ------------------------------------------------------------
        # Resources (Best Practice for DevSecOps)
        # ------------------------------------------------------------
        # Always define limits to prevent a pod from eating all node memory/CPU.
        resources:
          requests:
            memory: "64Mi"  # Minimum guaranteed
            cpu: "250m"     # 1/4th of a core guaranteed
          limits:
            memory: "128Mi" # Maximum allowed before OOMKilled
            cpu: "500m"     # Maximum allowed
        
        # ------------------------------------------------------------
        # Health Checks (Liveness & Readiness)
        # ------------------------------------------------------------
        # Checks if the app is alive. If this fails, K8s restarts the pod.
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5  # Wait 5s before first check
          periodSeconds: 10       # Check every 10s

2: Apply it: Run the following command in your terminal:

Bash
kubectl apply -f replicaset.yaml

3: Verify it:

Bash
# Show existing replicaset in default # to list from specific namespace add flag --namespace <namespace-name>
kubectl get rs
#or
kubectl get replicaset

# show pods with labels
kubectl get pods --show-labels

# show more details of replicaset
kubectl describe replicaset <REPLICASET_NAME>

# We can expose replicaset pods and access using local host / or node IP
kubectl expose replicaset <replicaset-name> - -type=NodePort - -port=<port-number> - -target-port=<container-port> - -name=<service-name>

Practice lab yet to be added.

Contents
Scroll to Top