Kubernetes Day-4: Replication Controller, Pods, Labels & Networking Basics

In today’s session, we’ll cover one of the core building blocks of Kubernetes — the Replication Controller (RC).
This topic plays a crucial role in high availability, self-healing, and scalability, which are key reasons why Kubernetes is so powerful in real-world production environments.

Along the way, we’ll also strengthen our understanding of:

• Pods and why Kubernetes needs them

• Docker networking limitations

• Port Address Translation (PAT)

• Labels and selectors

• How Kubernetes monitors and recreates containers automatically

Let’s get started

Cluster Setup Recap

We are currently working with Minikube, which is a single-node Kubernetes cluster where:

• Master node

• Worker node

both run inside a single virtual machine.

In upcoming sessions, we’ll move to multi-node clusters, but the concepts, commands, and YAML files remain exactly the same.

Quick Docker Networking Revision

When Docker launches containers:

• Each container gets a private IP

• Containers can communicate internally

• These IPs are dynamic

Challenges in Docker Networking

1. Dynamic IP Problem
   If a container stops and restarts, its IP address changes.

2. No External Access by Default
   Containers live in a private network, so users outside cannot access applications directly.

Docker solves this using Port Address Translation (PAT).

Understanding Port Address Translation (PAT)

Suppose:

• Your web app runs on port 80 inside the container

• You map host port 1234 to container port 80

docker run -it --name os4 -p 1234:80 vimal13/apache-webserver-php

Now the application becomes accessible using:

http://<host-ip>:1234

Docker uses NAT + port mapping to route traffic from host → container.

Kubernetes Networking Reality

Behind the scenes:

• Kubernetes uses a container runtime (Docker, CRI-O, Podman)

• Pods and containers still live in a private network

• Container IPs are not accessible from outside

So Kubernetes also needs exposing mechanisms, similar to Docker.

Hands-On: Creating a Pod

Let’s create a pod:

kubectl run webos1 --image=vimal13/apache-webserver-php

Check pod details:

kubectl describe pod webos1

You’ll notice:

• Pod has an internal IP (e.g., 172.17.0.5)

• This IP is not reachable from your system

Exposing the Pod (NodePort)

To make the application accessible:

kubectl expose pod webos1 --port=80 --type=NodePort

Check assigned port:

kubectl get services

Now users can access the application using:

http://<worker-node-ip>:<node-port>

We’ll discuss NodePort, ClusterIP, and LoadBalancer services in detail later.

Why Replication Controller Is Needed

If you launch a container directly using Docker:

• No continuous monitoring

• Manual restarts required

• High downtime risk

Kubernetes solves this using controllers.

What Is a Replication Controller?

A Replication Controller (RC):

• Continuously monitors pods

• Ensures the desired number of replicas are running

• Automatically recreates pods if they crash or are deleted

Without RC:

• If a pod is deleted → it’s gone forever

The IP Address Problem in Monitoring

Containers get dynamic IPs.

If Kubernetes monitors containers using IPs:

• Restart → new IP

• Controller thinks old container is dead

• Unnecessary replicas get created

Solution: Labels

Kubernetes uses labels, not IPs.

Example:

labels:
  app: web

Labels are:

• Key-value pairs

• Stable identifiers

• Used by all Kubernetes controllers

Creating a Labeled Pod

apiVersion: v1
kind: Pod
metadata:
  name: mypod1
  labels:
    app: web
spec:
  containers:
  - name: myc1
    image: vimal13/apache-webserver-php

Create the pod:

kubectl create -f pod.yaml

View labels:

kubectl get pods -L app

Creating a Replication Controller

Now let’s create rc.yaml.

What This RC Does

• Monitors pods with label app=web

• Recreates pods if they are deleted

• Uses a pod template for consistency

apiVersion: v1
kind: ReplicationController
metadata:
  name: myrc1
spec:
  replicas: 3
  selector:
    app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: myc1
        image: vimal13/apache-webserver-php

Apply the RC:

kubectl create -f rc.yaml

RC Takes Ownership Automatically

If a pod already exists with matching labels:

• RC automatically adopts it

• No duplicate pods are created

Delete the pod:

kubectl delete pod mypod1

👉 Kubernetes instantly recreates it.

Verifying Replication Controller

kubectl get rc
kubectl describe rc myrc1

The Events section helps in troubleshooting.

Exposing the Replication Controller

Instead of exposing individual pods:

kubectl expose rc myrc1 --port=80 --type=NodePort
kubectl get services

Now:

• Traffic goes to the service

• Service routes traffic to pods

• Pods can change, service stays stable

Replicas and Load Handling

What Is a Replica?

A replica is:

• An identical copy of a pod

• Running the same application

• Used for scalability and fault tolerance

If:

• Desired replicas = 3

• One pod crashes

Kubernetes immediately creates a new one.

Observing Load Balancing in Action

Access the application multiple times:

• You’ll see different container IPs

• Traffic is distributed randomly

• Application stays available

This is Kubernetes Service-based load balancing, which works like a reverse proxy.

Key Takeaways from Day-4

• Containers have dynamic IPs → labels solve this

• Replication Controller ensures self-healing

• Pods are recreated automatically

• Services handle load balancing

• Desired state is always maintained

• Kubernetes eliminates manual intervention

With this session, we’ve taken a solid step forward in understanding how Kubernetes ensures reliability, self-healing, and scalability through Replication Controllers. These concepts form the foundation of production-grade Kubernetes workloads. As we move ahead, we’ll build on this knowledge to explore more advanced controllers and traffic management strategies that power real-world systems.

Stay curious, keep experimenting, and see you in the next part of this Kubernetes journey