Day 27 - Kubernetes Ingress

1. Why People Find Kubernetes Ingress Difficult

Two reasons:

1. They don’t understand why Ingress is required.

2. Practical setup fails on Minikube or local clusters because Ingress controller is missing.

---

2. Before Ingress (Before Kubernetes v1.1)

People used Kubernetes with:

• Deployment → creates Pods

• Service → exposes Pods, provides internal/external LB using kube-proxy

Everything worked fine until real production needs appeared.

---

3. Problems People Faced With ONLY Services

Problem 1 — Missing Enterprise Load Balancing Features

Traditional VM-based environments had powerful load balancers like:

• Nginx (as LB)

• F5

• HAProxy

• Traefik

These offered advanced features:

• Path-based routing /a → service1, /b → service2

• Host-based routing app.example.com → service1

• Sticky sessions

• Weighted/rationed load balancing (70/30)

• Whitelisting / blacklisting

• TLS/HTTPS termination

• WAF
  ...and many more

Kubernetes Services DID NOT support these.
Service only does simple round-robin load balancing using kube-proxy.

This made enterprises unhappy.

---

Problem 2 — Huge Cost with LoadBalancer Services

When using:

type: LoadBalancer

Every Service gets a public static IP.

In large companies:

• 1000 services = 1000 load balancers = huge cloud cost
  Cloud providers charge for every static LB IP.

In VMs earlier:

• They used one load balancer for all apps.

• Routing done by path/host rules.

So Kubernetes LoadBalancer type became too expensive.

---

4. Kubernetes Adds a New Concept → INGRESS

To solve above two problems.

Kubernetes said:

• “We will let users create a Ingress resource”

• But Kubernetes will not implement LB logic for all vendors.

• Instead, LB companies must create Ingress Controllers.

---

5. What is an Ingress Controller?

A load balancer implementation inside Kubernetes.

Examples:

• NGINX Ingress Controller

• HAProxy Ingress Controller

• Traefik

• F5 BIG-IP Ingress

• Ambassador

• Apache APISIX

Workflow:

1. User creates Ingress resource (rules like path/host/TLS).

2. Ingress controller reads those rules.

3. Ingress controller configures the load balancer inside the cluster.

Without an Ingress controller:

• Ingress does nothing.

---

6. Practical Understanding (Extremely Important)

Just like:

• Pods → handled by Kubelet

• Services → handled by kube-proxy

• Deployments → handled by deployment-controller

Ingress → MUST be handled by Ingress Controller.

So:
✔ You can create 100 Ingress YAML files
✖ Nothing will work
❗ Unless the Ingress controller is installed.

---

7. Common Ingress Controller Installation (Minikube Example)

On Minikube, installation is simple:

minikube addons enable ingress

This deploys:

• nginx-ingress-controller Pod

• In namespace ingress-nginx

After this:

• Ingress controller starts watching your Ingress rules

• Updates routing internally

---

8. Example of the Ingress Resource in Your Content

You created:

• Deployment → Pod

• Service → NodePort

• Ingress → Host-based routing (foo.bar.com)

Ingress YAML points to:

serviceName: my-service
servicePort: 80
path: /bar
host: foo.bar.com

---

9. After Ingress Controller Installs

• Ingress now gets an Address (IP).

• Ingress controller logs show:

    Successfully synced ingress: Ingress example
  

This means:

• Controller picked up your Ingress rule

• Updated its internal Nginx config

---

10. Accessing Ingress on Local Machine

Because DNS is not real on local environment:

• You MUST update /etc/hosts file

• Map your domain (foo.bar.com) to Ingress IP

Example:

192.168.64.11 foo.bar.com

Then you can access:

http://foo.bar.com/bar

---

11. Summary — What You Should Remember

Ingress solves two major problems

1. Missing enterprise-grade LB features

2. High cost of cloud LB for each service

Ingress requires Ingress Controller

Without it → Ingress does nothing.

Ingress Controller = Load Balancer + API Gateway inside Kubernetes

One Ingress can route traffic to MANY services

Using host/path rules.