Replication Controllers and ReplicaSets

Kubernetes controllers act as the control plane’s “brain,” continuously observing cluster objects and reconciling the current state with your declared desired state. In this lesson, we’ll deep dive into two controllers that manage Pod replicas: ReplicationController and ReplicaSet.

Why Use Replication Controllers?

Running a single Pod is risky—if it crashes, your application goes offline. A ReplicationController (RC) maintains a specified number of identical Pods, ensuring high availability and load distribution.

• High availability: If one Pod fails, others continue serving traffic.
  

• Redundancy and load balancing across nodes:
  

• Scaling across nodes to meet growing demand:
  

ReplicationController vs. ReplicaSet

While both controllers maintain a set of Pod replicas, ReplicaSet (RS) is the modern API (apps/v1) and supports set-based label selectors. ReplicationController (v1) is older and has fewer selector capabilities. We recommend using ReplicaSets for new deployments.

Creating a ReplicationController

1. Define rc-definition.yaml:

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

2. Apply the manifest and verify:

   kubectl create -f rc-definition.yaml
   kubectl get replicationcontroller
   

   Example output:

   NAME       DESIRED   CURRENT   READY   AGE
   myapp-rc   3         3         3       19s
   

3. List Pods managed by the RC:

   kubectl get pods
   

   NAME            READY   STATUS    RESTARTS   AGE
   myapp-rc-4lvk9  1/1     Running   0          20s
   myapp-rc-mc2mf  1/1     Running   0          20s
   myapp-rc-px9pz  1/1     Running   0          20s
   

Introducing ReplicaSets

A ReplicaSet manifest closely mirrors an RC, with two key differences:

• apiVersion: apps/v1
• selector: Required to match Pods

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

Apply and verify:

kubectl create -f replicaset-definition.yaml
kubectl get replicaset
kubectl get pods

Labels and Selectors

Labels are key/value pairs attached to objects. A ReplicaSet’s spec.selector.matchLabels determines which Pods it manages—even pre-existing ones.

Example Pod with labels:

metadata:
  name: myapp-pod
  labels:
    tier: front-end

Matching selector in a ReplicaSet:

selector:
  matchLabels:
    tier: front-end

Scaling a ReplicaSet

You can adjust replica counts by editing the YAML or using kubectl scale:

Option 1: Update replicas in replicaset-definition.yaml and apply:

kubectl replace -f replicaset-definition.yaml

Option 2: Scale on the fly:

kubectl scale --replicas=6 -f replicaset-definition.yaml

Command Cheat Sheet

Links and References

• Kubernetes Controllers
• ReplicationController API
• ReplicaSet API
• Horizontal Pod Autoscaler