Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

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.
The image illustrates a high availability setup with a user accessing a node containing a replication controller managing two pods.
  • Redundancy and load balancing across nodes:
The image illustrates a high availability setup with two nodes, each containing a replication controller and pods, indicating redundancy and load balancing.
  • Scaling across nodes to meet growing demand:
The image illustrates a load balancing and scaling concept using Kubernetes, showing multiple pods distributed across nodes with a replication controller managing them.

​
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.
FeatureReplicationController (v1)ReplicaSet (apps/v1)
API Versionv1apps/v1
Selector SupportEquality-based labels onlyEquality & set-based label match
Recommended for UsageDeprecatedYes

​
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
Using kubectl scale updates in-memory replica counts but does not modify your source YAML file.
For automatic scaling based on metrics, see the Horizontal Pod Autoscaler.

​
Command Cheat Sheet

CommandDescription
kubectl create -f <file>Create any Kubernetes object
kubectl get <resource>List resources (e.g., pods, rs)
kubectl delete <resource> <name>Delete a resource by name
kubectl replace -f <file>Update by replacing the manifest
kubectl scale —replicas=<n> -f <file>Scale replicas from the command line

Watch Video