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

2. Advanced routing

Ingress supports:

• Host-based routing (foo.example.com)

• Path-based routing (/checkout, /pay)

• Wildcards (*.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

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

Path-based routing

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

Wildcard host (*)

*.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

---

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.