ReplicaSets

Controllers are the control plane components in Kubernetes that continuously reconcile cluster objects to the desired state. This guide focuses on ReplicationController and ReplicaSet — the controllers responsible for ensuring a specified number of pod replicas are running. Why replication matters

High availability: if one pod crashes, other replicas keep serving traffic.
Fault tolerance: restarts or node failures are handled by creating replacements.
Load distribution: multiple replicas share incoming load across pods and nodes.
Autoscaling compatibility: controllers enable both manual and automated scaling strategies.

A diagram titled "Load Balancing and Scaling" showing user requests being distributed to multiple containerized pods across two nodes. It illustrates a replication controller balancing traffic to identical Python-containing pods for scaling.

ReplicationController vs ReplicaSet

ReplicationController is the legacy resource. ReplicaSet (part of apps/v1) is the modern replacement and is preferred for new clusters. Both ensure a desired replica count and use a pod template, but ReplicaSet introduces a stricter selector model and aligns with current API practices.

Resource	API version	Selector required?	Notes
ReplicationController	`v1`	Not strictly required (defaults to template labels)	Legacy; maintained for backward compatibility
ReplicaSet	`apps/v1`	Yes (`selector.matchLabels`)	Preferred; works cleanly with Deployments and newer APIs

Prefer ReplicaSet (and Deployments that manage ReplicaSets) for modern Kubernetes usage. ReplicationController exists primarily for backward compatibility.

A dark blue slide showing two rounded rectangular boxes side by side labeled "Replication Controller" and "ReplicaSet." A small "© Copyright KodeKloud" label appears in the bottom-left corner.

Creating a ReplicationController

A ReplicationController YAML follows the standard structure: apiVersion, kind, metadata, and spec. The spec includes:

replicas: desired number of pod replicas
template: pod template (metadata + spec) used to create pods

Move the contents of an existing Pod spec into spec.template, ensuring the template is nested under template. Note that the controller and the pod template each have their own metadata sections. Example ReplicationController definition (rc-definition.yml):

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: front-end
spec:
  replicas: 3
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx

Create it:

$ kubectl create -f rc-definition.yml
replicationcontroller "myapp-rc" created

Verify:

$ kubectl get replicationcontrollers
NAME        DESIRED   CURRENT   READY   AGE
myapp-rc    3         3         3       19s

$ kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
myapp-rc-41vk9          1/1     Running   0          20s
myapp-rc-mc2mf          1/1     Running   0          20s
myapp-rc-px9pz          1/1     Running   0          20s

Pod names begin with the replication controller name (myapp-rc), indicating controller ownership.

ReplicaSet

ReplicaSet is conceptually similar to ReplicationController but requires an explicit selector and lives under the apps/v1 API. If you attempt to create a ReplicaSet with the wrong API version, kubectl will return:

error: unable to recognize "replicaset-definition.yml": no matches for /, Kind=ReplicaSet

Minimal ReplicaSet example (replicaset-definition.yml):

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end
spec:
  replicas: 3
  selector:
    matchLabels:
      type: front-end
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx

Create and verify:

$ kubectl create -f replicaset-definition.yml
replicaset "myapp-replicaset" created

$ kubectl get replicasets
NAME                DESIRED   CURRENT   READY   AGE
myapp-replicaset    3         3         3       19s

$ kubectl get pods
# lists the pods that match the selector and are managed by the replicaset

Selectors and labels

Labels let you tag objects for selection and grouping. A ReplicaSet uses a selector to determine which pods to manage. matchLabels is the common form:

selector:
  matchLabels:
    tier: front-end

# Pod template labels
metadata:
  name: myapp-pod
  labels:
    tier: front-end

Because ReplicaSet can adopt existing pods that match its selector, providing a proper selector is essential. ReplicationController would implicitly default to the template labels, but ReplicaSet requires the selector explicitly.

The ReplicaSet selector.matchLabels must match the labels in template.metadata.labels. A mismatch produces a validation error when creating the ReplicaSet.

Why include the pod template if pods already exist?

The ReplicaSet needs the template for future replacement pods: if a pod fails later, the controller uses the template to recreate matching pods with the desired configuration.

Scaling a ReplicaSet

You can scale a ReplicaSet manually either by editing YAML or with kubectl commands.

Update the YAML and run replace:

# Edit replicaset-definition.yml to set replicas: 6
$ kubectl replace -f replicaset-definition.yml

Use kubectl scale (no file edit required):

# Scale by providing the file
$ kubectl scale --replicas=6 -f replicaset-definition.yml

# Or scale by resource type/name
$ kubectl scale --replicas=6 replicaset myapp-replicaset

Note: scaling with kubectl scale -f updates the live object in the cluster but does not change the replica count in the static file on disk. For automated scaling based on metrics, use the Horizontal Pod Autoscaler (HPA).

Quick command reference

Action	Command
Create from file	`kubectl create -f replicaset-definition.yml`
List ReplicaSets	`kubectl get replicasets`
Delete a ReplicaSet	`kubectl delete replicaset myapp-replicaset`
Update from file	`kubectl replace -f replicaset-definition.yml`
Scale from file	`kubectl scale --replicas=6 -f replicaset-definition.yml`
Scale by name	`kubectl scale --replicas=6 replicaset myapp-replicaset`

Summary

ReplicationController and ReplicaSet ensure a desired number of pod replicas are running.
ReplicaSet (apps/v1) is the modern replacement and should be used with Deployments for most production scenarios.
ReplicaSets require an explicit selector (usually matchLabels) and a pod template.
Use labels and selectors to define which pods controllers manage.
Scale manually with kubectl or automatically with higher-level controllers (Deployments) and autoscalers (HPA).

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

ReplicationController vs ReplicaSet

Creating a ReplicationController

ReplicaSet

Selectors and labels

Scaling a ReplicaSet

Quick command reference

Summary

Links and references

Watch Video

Practice Lab

​ReplicationController vs ReplicaSet

​Creating a ReplicationController

​ReplicaSet

​Selectors and labels

​Scaling a ReplicaSet

​Quick command reference

​Summary

​Links and references

Watch Video

Practice Lab

ReplicationController vs ReplicaSet

Creating a ReplicationController

ReplicaSet

Selectors and labels

Scaling a ReplicaSet

Quick command reference

Summary

Links and references