# Day 25 - Kubernetes Services

# 🚀 **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:

```plaintext
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:

```plaintext
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`](http://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)

| Service Type | Who Can Access | Purpose |
| --- | --- | --- |
| ClusterIP | Only inside Kubernetes | Internal services |
| NodePort | Anyone with access to Node IP | Internal org access |
| LoadBalancer | Anyone on the internet | Public access |

---

# 🧠 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