Ingress

A Kubernetes Ingress is an API object that manages external access to Services, typically HTTP and HTTPS traffic, providing routing, load balancing, SSL termination, and virtual hosting — all through a single external endpoint.

Think of it as the entry point to your cluster’s web traffic. 🌐

---

⚙️ Definition

An Ingress exposes HTTP(S) routes from outside the cluster to Services within the cluster, based on rules and paths you define.

Instead of exposing each Service separately using LoadBalancer or NodePort, an Ingress lets you route multiple Services through one external IP or domain.

---

🧩 Key Components

1. Ingress Resource — Defines the routing rules (e.g., paths, hostnames).
2. Ingress Controller — Implements those rules (e.g., NGINX, Traefik, HAProxy, or cloud-specific controllers).
3. Service — The backend that the Ingress routes traffic to.

---

🧾 Example YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: backend-service
                port:
                  number: 8080

What this does:

• Routes requests for myapp.example.com/ → frontend-service
• Routes requests for myapp.example.com/api → backend-service
• Both share the same public endpoint (one domain, one IP).

---

🌍 How It Works

1. Client sends a request to your cluster’s domain (e.g., myapp.example.com).
2. Ingress Controller receives the request (listening via a LoadBalancer).
3. The Controller checks the Ingress rules and routes the request to the correct Service.
4. The Service forwards it to one of its Pods.

---

🔐 TLS / HTTPS Support

Ingress can handle SSL termination, so you can secure your apps with HTTPS:

spec:
  tls:
    - hosts:
        - myapp.example.com
      secretName: myapp-tls-secret

This uses a Kubernetes Secret containing the TLS certificate and key.

---

🧠 Ingress vs Service

Concept	Purpose	Typical Use
Service (LoadBalancer)	Exposes one app to the outside world	Simple, single-service exposure
Ingress	Routes traffic to multiple Services based on host/path	Central entry point for web traffic

---

🧰 Common Ingress Controllers

You must have an Ingress Controller running in your cluster — the Ingress object alone does nothing.

Popular controllers:

• NGINX Ingress Controller (most common)
• Traefik
• HAProxy Ingress
• Kubernetes Gateway API (next-gen)
• Cloud provider-specific (GKE Ingress, AWS ALB Ingress, etc.)

---

🧱 Ingress Path Types

Path Type	Description
Prefix	Matches based on URL prefix (e.g., /api matches /api/v1)
Exact	Matches the URL path exactly (e.g., /login)

---

🚀 Use Cases

• Expose multiple microservices under a single domain.
• Host multiple apps on the same IP using virtual hosting (host rules).
• Enforce HTTPS across all apps.
• Integrate Let’s Encrypt for automatic SSL certificates.
• Apply traffic policies, rate limiting, or rewrite rules via annotations.

---

🧩 Typical Architecture

[ User / Browser ]
        │
        ▼
[ Ingress Controller (e.g., NGINX) ]
        │
 ┌──────────────┬──────────────┐
 ▼              ▼              ▼
Service A     Service B     Service C
(frontend)    (backend)     (auth)

---