🚀 Why Do We Need a Service in Kubernetes?

In real production environments:

• We don’t deploy pods directly.

• We deploy deployments, which internally create a ReplicaSet, which finally creates pods.

Assume we have a deployment with 3 pods (replicas).

These replicas are required because:

• One pod cannot handle many concurrent users.

• For example: if 1 pod handles 10 users and you have 100 users → you need ~10 pods.

---

⚠️ Problem: What if There Is No Service in Kubernetes?

Pods get dynamic IP addresses.

Example:

• Pod 1 → 172.16.3.4

• Pod 2 → 172.16.3.5

• Pod 3 → 172.16.3.6

If a pod crashes, Kubernetes auto-heals and creates a new pod → new IP address.

Example:

• Pod 1 dies

• New Pod 1 → 172.16.3.8 (IP changed)

Now the users/testers/other internal teams who were using 172.16.3.4 cannot access the application anymore.

So even though Kubernetes healed the pod correctly → application becomes unreachable due to changed IP.

This is the core reason Kubernetes Services are required.

---

🟦 How a Service Solves This Problem

Instead of giving direct pod IPs to users, DevOps creates a Service on top of the Deployment.

Users will now access the application using:

payment.default.svc

The service:

1. Acts as a load balancer

2. Performs service discovery

3. Can expose applications externally

---

1️⃣ Load Balancing

The service receives traffic and distributes it across all pods.

Example:

• 10 requests → Pod1

• 10 requests → Pod2

• 10 requests → Pod3

So all pods handle load evenly.

---

2️⃣ Service Discovery (VERY IMPORTANT)

A service does NOT track pod IPs.

Instead, it uses:

✔️ Labels

✔️ Selectors

Example label on pods:

app: payment

If pods die and new ones are created:

• IP address changes

• Label remains the same

• Service always finds the correct pods because it filters by labels.

This solves the problem of constantly changing IPs.

---

3️⃣ Exposing Applications Externally

Services can expose your app inside or outside the cluster depending on the service type.

There are 3 main service types:

---

🔹 Type 1 — ClusterIP (default)

• Application accessible only inside the Kubernetes cluster

• Provides load balancing + service discovery

• Not accessible from outside

---

🔹 Type 2 — NodePort

• Application accessible inside your organization / VPC

• Anyone who can reach Worker Node IP can access the app

• Useful for internal company apps

---

🔹 Type 3 — LoadBalancer

• Application accessible from the internet (publicly)

• Creates a Cloud Load Balancer (ELB on AWS)

• Best for apps like:

  • amazon.com

  • Any public website

Note:

• LoadBalancer works only on cloud providers (AWS, GCP, Azure)

• Does NOT work by default on Minikube (needs addons/metallb)

---

🌐 Example Summary (From Your Content)

---

🧠 Final Summary of Your Content

Kubernetes Services provide:

✔️ Load Balancing

✔️ Service Discovery (through labels & selectors)

✔️ External Exposure (depending on type)

Without a Service:

• Pods get new IPs when recreated

• Users cannot access the application

• Auto-healing breaks connectivity

With a Service:

• Users access via a single stable address

• Traffic is distributed

• IP changes of pods don’t matter