(Day 29) Task : Scaling and Replication in Kubernetes:-

Introduction :

As applications scale and user demand grows, maintaining availability and performance becomes critical. Kubernetes offers built-in mechanisms for scaling and replication, ensuring high availability, load distribution, and fault tolerance. In this blog, we'll explore:

• Why we need scaling and replication

• How Kubernetes handles this (or doesn't, by default)

• The role of ReplicationController and ReplicaSet

• How to write YAML configurations to manage replicas effectively

Why Do We Need Scaling and Replication?

Let’s start by understanding the core motivations.

Replication:

Replication means running multiple instances (Pods) of the same application.

• High Availability – If one pod fails, others are still running.

• Fault Tolerance – Resilience in case of node or pod failures.

• Load Distribution – Multiple pods can serve traffic behind a load balancer.

Scaling:

Scaling is the process of increasing or decreasing the number of pods.

• Horizontal Scaling: More pods (replica-based).

• Vertical Scaling: More CPU/Memory to a single pod (less common in K8s).

Why Kubernetes Does NOT Replicate by Default :

By default, when you create a Pod using a basic Pod object, Kubernetes only runs a single instance of that pod. This is intentional because:

• Pods are meant to be ephemeral and replaced by controllers.

• Kubernetes encourages declarative replication using higher-level abstractions like:

  • ReplicaSet

  • Deployment

  • StatefulSet

  • DaemonSet

Thus, Kubernetes leaves replication responsibility to controllers.

Replication Using Kubernetes Objects :

To achieve replication, Kubernetes provides two key objects:

1. ReplicationController (Legacy) :

• Ensures the specified number of pod replicas are running at all times.

• If a pod dies, it creates a new one.

• Deprecated in favor of ReplicaSet, but still used in legacy clusters.

2. ReplicaSet (Modern Replacement) :

• More powerful and supports label selectors more flexibly.

• Manages the lifecycle and count of Pods.

• Best practice: Use Deployment, which internally uses ReplicaSet.

YAML Example for Replication :

kind: ReplicationController
apiVersion: v1
metadata:
  name: MyReplica
spec:
  replicas: 2
  selector:
    MyName: Aditya
  template:
    metadata:
      name: TestPod
      labels:
        MyName: Adi
    spec:
      containers:
      - name: C00
        image: ubuntu
        command: ["/bin/bash", "-c", "while true; do echo hello adi; sleep 5; done"]

YAML Manifest:

apiVersion: v1

• Specifies the API version used for the object.

• v1 is the core API group version used for basic objects like Pod, Service, ReplicationController.

kind: ReplicationController

• Defines the type of Kubernetes object.

• Here, it's a ReplicationController, which ensures a specified number of pod replicas are always running.

metadata:
  name: MyReplica

• Metadata provides information about the object.

• name: MyReplica sets the name of the ReplicationController, which must be unique within the namespace.

spec:

• Specification of the desired state for the ReplicationController.

replicas: 2

• Indicates the desired number of pod replicas.

• Kubernetes ensures that 2 pods matching the template are always running.

 selector:
    MyName: Aditya

• The selector is used to match existing pods that this ReplicationController should manage.

• Here, it selects pods with the label MyName: Aditya.

• Note : The selector must match the labels in the pod template to function correctly.

 template:

• The pod template that defines how the replicated pods should be created.

metadata:
      name: TestPod

• Sets metadata inside the pod template.

• name: TestPod is the name of the pod (optional, often auto-generated by controllers).

  • This name may not be used when using ReplicaSet or Deployment because they generate unique names automatically.

labels:
        MyName: Adi

• These labels are assigned to each pod created.

• Labels are key-value pairs used by selectors and service discovery.

• this label should match the selector's label (MyName: Aditya) for the ReplicationController to manage these pods correctly.

  • So technically, either selector or template label needs to be corrected for this to work. (More on that below.)

spec:
      containers:

• The spec for the pod itself, defining what container(s) should run inside the pod.

 - name: C00

• The name of the container inside the pod.

• Helps in identifying and logging container-specific messages.

image: ubuntu

• The Docker image to be used for the container.

• ubuntu is the official Ubuntu base image from Docker Hub.

command: ["/bin/bash", "-c", "while true; do echo hello adi; sleep 5; done"]

• Overrides the default command (ENTRYPOINT) of the image.

• Runs a shell loop that infinitely prints hello adi every 5 seconds.