# Day 28 - Kubernetes Service, Ingress, TLS & Ingress Controllers

# 1\. Why Kubernetes Services Are Needed

When a Pod is created in Kubernetes, it receives a **dynamic IP address**.  
If the Pod dies and restarts, its IP changes.  
So other Pods (like *checkout → payments*) cannot rely on Pod IP because it changes, creating issues like **404 Not Found** when trying to call the old IP.

### Solution → **Kubernetes Service**

A Service gives a **stable virtual IP** (ClusterIP) that stays constant even if Pods change.

---

# 2\. Types of Kubernetes Services

### **(1) ClusterIP (default)**

* Only accessible **inside the cluster**
    
* Used for internal communication (e.g., checkout → payments)
    

### **(2) NodePort**

* Exposes service on each node via a port between **30000–32767**
    
* Access: `NodeIP:NodePort`
    
* Problems:
    
    * Random high port → cannot open all ports in firewall
        
    * Nodes might not be accessible from outside
        
    * Not secure for production
        

### **(3) LoadBalancer**

* Cloud provider provisions an **external IP**
    
* Works well on AWS, Azure, GCP
    
* Drawbacks:
    
    * One LoadBalancer = one external IP
        
    * Expensive when you have many services (100+ services = 100+ LoadBalancers)
        

### LoadBalancer on bare metal?

Yes. Use **MetalLB** (CNCF project) to simulate LoadBalancer in on-prem or home labs.

---

# 3\. Why We Need Ingress

LoadBalancer works but becomes **expensive** and **hard to manage** if you have many services.

### Ingress solves 2 big problems:

### **1\. Reduce cost**

One public IP → route traffic to many services  
[`example.com/login`  
`example.com/checkout`  
`example.com/payments`](http://example.com/loginexample.com/checkoutexample.com/payments)

### **2\. Advanced routing**

Ingress supports:

* Host-based routing ([foo.example.com](http://foo.example.com))
    
* Path-based routing (/checkout, /pay)
    
* Wildcards (`*.`[`example.com`](http://example.com))
    
* Authentication (BasicAuth)
    
* Web Application Firewall (in some controllers)
    
* TLS/SSL termination
    

---

# 4\. What Is an Ingress?

An **Ingress** is a Kubernetes object containing traffic-routing rules:

* Which host goes to which service
    
* Which path goes where
    
* TLS settings
    

But **Ingress alone does nothing**.

---

# 5\. What Is an Ingress Controller?

It is a **software component** that:

1. Watches Ingress resources
    
2. Reads routing rules
    
3. Updates its internal load balancer (e.g., nginx.conf)
    

Examples:

* **NGINX Ingress Controller**
    
* **HAProxy Ingress**
    
* **Traefik**
    
* **Istio Gateway**
    
* **F5**
    
* **ALB Ingress (AWS)**
    
* **Contour**
    
* ~30+ others
    

### How it works:

* You install the ingress controller
    
* It runs inside the cluster (except big enterprise LBs)
    
* It watches all Ingress objects
    
* It writes config (e.g., `/etc/nginx/nginx.conf`)
    
* It handles client traffic and routes correctly
    

---

# 6\. Path-Based & Host-Based Routing (Concept)

### **Host-based routing**

```plaintext
foo.example.com → service A
bar.example.com → service B
```

### **Path-based routing**

```plaintext
example.com/checkout → checkout-service
example.com/payments → payments-service
```

### Wildcard host (\*)

```plaintext
*.bar.com → same service
```

Wildcards are commonly used with TLS (wildcard certificates).

---

# 7\. TLS / SSL in Ingress

There are **3 ways** to handle HTTPS in Ingress:

---

# 7.1 SSL Passthrough

### How it works:

* Load balancer **does not decrypt**
    
* Traffic passes encrypted directly to the backend
    
* Backend Pod decrypts the request
    

### Pros:

* End-to-end encryption
    
* Maximum privacy (LB can’t see traffic)
    

### Cons:

* Load balancer cannot:
    
    * inspect packets
        
    * block attacks
        
    * do routing based on URL path
        
* Backend service handles expensive SSL decryption → **higher CPU usage**
    
* LB acts only as TCP forwarder → fewer features
    

---

# 7.2 SSL Offloading (SSL Termination)

### How it works:

* Load balancer **decrypts traffic**
    
* Sends **HTTP (unencrypted)** traffic to backend services
    

### Pros:

* Fastest (backend does not decrypt)
    
* LB can inspect, filter, apply WAF rules, routing, etc.
    
* Good for high traffic loads
    

### Cons:

* Traffic between LB → Pod is **not encrypted**
    
* Vulnerable to man-in-the-middle inside the cluster
    
* Not ideal for high-security environments
    

---

# 7.3 SSL Bridging (Re-Encryption)

Also called **Re-Encrypt** in OpenShift.

### How it works:

1. Load balancer **decrypts** request
    
2. Inspects / applies routing
    
3. Load balancer **re-encrypts**
    
4. Sends encrypted traffic to backend Pod
    

### Pros:

* LB can inspect traffic
    
* Keeps encryption between LB ↔ Pod
    
* Most secure option with advanced LB features
    

### Cons:

* Backend still decrypts → same CPU cost as passthrough
    
* Load balancer also decrypts → more LB CPU usage
    

---

# 8\. Comparison Summary

| Feature | Passthrough | Offloading | Bridging |
| --- | --- | --- | --- |
| LB decrypts traffic | ❌ No | ✅ Yes | ✅ Yes |
| LB inspects packets | ❌ No | ✅ Yes | ✅ Yes |
| LB→backend encrypted | ❌ No | ❌ No | ✅ Yes |
| Backend decrypts | ✅ Yes | ❌ No | ✅ Yes |
| Best performance | ❌ | ⭐ **Best** | ❌ |
| Best security | ❌ | ❌ | ⭐ **Best** |
| Best LB features | ❌ | ⭐ | ⭐ |

---

# 9\. Which One Should You Use?

### If you want **maximum performance** → **SSL Offloading**

Backend stays free from decryption load.

### If you want **maximum security** → **SSL Bridging**

Everything encrypted end-to-end + LB security features.

### If you want **zero LB involvement** → **SSL Passthrough**

Not recommended unless required.