Ingress and Gateway API

🚪 Services and Networking: Ingress and Gateway API

The Hotel Lobby Story 🏨

Imagine a giant hotel with hundreds of rooms. Each room is a different service (like a website, an API, or an app). Guests (internet traffic) arrive at the front door every second.

The problem? You can’t just let everyone wander around. You need:

• A receptionist to greet them
• Signs pointing to the right rooms
• Security badges to keep things safe
• Rules about who goes where

In Kubernetes, Ingress is like the hotel’s reception desk. And Gateway API is the newer, fancier lobby with more features!

🎯 What You’ll Learn

1. Ingress fundamentals
2. Ingress controllers
3. Ingress rules and paths
4. Ingress TLS configuration
5. Ingress annotations
6. Gateway API overview
7. Gateway API resources
8. Gateway API routes
9. Gateway API vs Ingress

Part 1: Ingress Fundamentals

What is Ingress? 🚪

Ingress = The front door manager of your Kubernetes cluster.

Think of it this way:

• Your apps run inside Kubernetes (the hotel)
• People outside want to visit (web traffic)
• Ingress decides WHO gets in and WHERE they go

Simple Example

Without Ingress:

Internet → ❓ → Your App
(Where do I go?)

With Ingress:

Internet → 🚪 Ingress → ✅ Your App
(Follow the signs!)

The Magic of Ingress

graph TD
    A["👤 User visits myapp.com"] --> B["🚪 Ingress"]
    B --> C{Check the rules}
    C -->|/shop| D["🛒 Shop Service"]
    C -->|/blog| E["📝 Blog Service"]
    C -->|/api| F["⚙️ API Service"]

Real-life example:

• User types myshop.com/products
• Ingress sees /products path
• Sends them to the Products service
• User gets what they need!

Basic Ingress YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

What this does:

• Listens for myapp.com
• Sends ALL traffic (/) to my-service
• Uses port 80

Part 2: Ingress Controllers

The Receptionist Behind the Desk 👩‍💼

Here’s a secret: Ingress by itself does nothing!

It’s like writing rules on paper but having no one to read them. You need an Ingress Controller — the actual worker who makes things happen.

Popular Ingress Controllers

How Controllers Work

graph TD
    A["📝 You write Ingress rules"] --> B["🤖 Controller watches"]
    B --> C["⚙️ Controller configures itself"]
    C --> D["🚀 Traffic flows correctly"]

Installing NGINX Ingress Controller

# Using Helm (package manager)
helm install ingress-nginx \
  ingress-nginx/ingress-nginx

What happens:

1. Controller pod starts running
2. It watches for Ingress resources
3. When you create Ingress, it automatically configures routing!

Example: Controller in Action

# Your Ingress rule
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: blog-ingress
spec:
  ingressClassName: nginx  # 👈 Uses NGINX
  rules:
  - host: blog.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: blog-service
            port:
              number: 3000

The ingressClassName: nginx tells Kubernetes: “Hey NGINX controller, this one’s for you!”

Part 3: Ingress Rules and Paths

The Signpost System 🪧

Rules and paths are the directions inside your hotel. They tell traffic exactly where to go.

Two Types of Routing

1. Host-based routing (Different buildings)

shop.mysite.com → Shop Service
blog.mysite.com → Blog Service

2. Path-based routing (Different floors)

mysite.com/shop → Shop Service
mysite.com/blog → Blog Service

Path Types Explained

Multi-Path Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-path-ingress
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 3000
      - path: /
        pathType: Prefix
        backend:
          service:
            name: home-service
            port:
              number: 80

graph TD
    A["myapp.com"] --> B{Path?}
    B -->|/api/*| C["api-service:8080"]
    B -->|/web/*| D["web-service:3000"]
    B -->|everything else| E["home-service:80"]

Multi-Host Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-host-ingress
spec:
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: shop-service
            port:
              number: 80
  - host: blog.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: blog-service
            port:
              number: 80

Part 4: Ingress TLS Configuration

The Security Guard 🔒

TLS = The padlock on your website (HTTPS).

Without TLS:

🔓 http://mysite.com
(Anyone can see your data!)

With TLS:

🔒 https://mysite.com
(Your data is encrypted!)

How TLS Works in Ingress

graph TD
    A["👤 User"] -->|🔒 HTTPS| B["🚪 Ingress"]
    B -->|🔓 HTTP| C["🖥️ Your Service"]
    style B fill:#4CAF50

The Ingress handles encryption so your services don’t have to!

Step 1: Create a Secret

apiVersion: v1
kind: Secret
metadata:
  name: my-tls-secret
type: kubernetes.io/tls
data:
  tls.crt: BASE64_ENCODED_CERT
  tls.key: BASE64_ENCODED_KEY

Or use kubectl:

kubectl create secret tls my-tls \
  --cert=path/to/cert.crt \
  --key=path/to/key.key

Step 2: Add TLS to Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
spec:
  tls:
  - hosts:
    - secure.example.com
    secretName: my-tls-secret
  rules:
  - host: secure.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: secure-service
            port:
              number: 443

What happens:

1. User visits https://secure.example.com
2. Ingress uses my-tls-secret for encryption
3. Connection is secure! 🔒

Auto-TLS with Cert-Manager

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auto-tls-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt"
spec:
  tls:
  - hosts:
    - auto.example.com
    secretName: auto-tls-secret
  rules:
  - host: auto.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Cert-Manager automatically gets and renews certificates!

Part 5: Ingress Annotations

The Special Instructions 📝

Annotations are like sticky notes on your Ingress. They add extra features specific to your controller.

Common NGINX Annotations

Example: URL Rewriting

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Magic explained:

• User visits: myapp.com/api/users
• Service receives: /users
• The /api part is stripped!

Example: Force HTTPS

metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

Now HTTP automatically becomes HTTPS!

Example: Rate Limiting

metadata:
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "10"
    nginx.ingress.kubernetes.io/limit-connections: "5"

Prevents one user from overwhelming your service!

Part 6: Gateway API Overview

The Upgraded Hotel Lobby 🏢✨

Gateway API is the next generation of Ingress. Same job, more power!

Why Gateway API?

The Big Picture

graph TD
    A["🏗️ Platform Team"] --> B["GatewayClass"]
    B --> C["Gateway"]
    D["👨‍💻 App Team"] --> E["HTTPRoute"]
    E --> C
    C --> F["🖥️ Services"]

Separation of concerns:

• Platform team: Sets up infrastructure (Gateway)
• App team: Defines routing (Routes)

Core Concepts

Think of it like this:

• GatewayClass = The type of door (wooden, glass, automatic)
• Gateway = The actual door installed
• Routes = Signs pointing where to go

Part 7: Gateway API Resources

The Building Blocks 🧱

1. GatewayClass

The blueprint for your gateways.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-gateway-class
spec:
  controllerName: example.com/gateway

Like choosing: “We use automatic sliding doors in this building”

2. Gateway

The actual entry point.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: http
    port: 80
    protocol: HTTP
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-cert

Like saying: “Install a door at entrance A, listening on ports 80 and 443”

3. HTTPRoute

The routing rules.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "app.example.com"
  rules:
  - matches:
    - path:
        value: /api
    backendRefs:
    - name: api-service
      port: 8080

4. Other Route Types

Part 8: Gateway API Routes

The Navigation System 🗺️

HTTPRoute Deep Dive

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: complex-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "shop.example.com"
  rules:
  # Rule 1: API traffic
  - matches:
    - path:
        type: PathPrefix
        value: /api
      headers:
      - name: version
        value: v2
    backendRefs:
    - name: api-v2
      port: 8080
  # Rule 2: Default
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: frontend
      port: 3000

Matching Options

graph TD
    A["HTTPRoute Matching"] --> B["Path"]
    A --> C["Headers"]
    A --> D["Query Params"]
    A --> E["Method"]

    B --> B1["Exact: /users"]
    B --> B2["Prefix: /api"]
    B --> B3["Regex: /user/.*"]

Traffic Splitting

Send traffic to multiple services:

rules:
- backendRefs:
  - name: service-v1
    port: 80
    weight: 90    # 90% of traffic
  - name: service-v2
    port: 80
    weight: 10    # 10% of traffic

Perfect for canary deployments!

Request Modification

rules:
- matches:
  - path:
      value: /old-path
  filters:
  - type: URLRewrite
    urlRewrite:
      path:
        type: ReplacePrefixMatch
        replacePrefixMatch: /new-path
  backendRefs:
  - name: my-service
    port: 80

Part 9: Gateway API vs Ingress

The Comparison 🆚

Side-by-Side

Visual Comparison

graph LR
    subgraph Ingress
        A["Single Resource"] --> B["Service"]
    end

    subgraph Gateway API
        C["GatewayClass"] --> D["Gateway"]
        D --> E["HTTPRoute"]
        E --> F["Service"]
    end

When to Use What?

Use Ingress when:

• ✅ Simple HTTP routing
• ✅ Already working setup
• ✅ Basic needs only

Use Gateway API when:

• ✅ Need advanced features
• ✅ Multiple protocols (TCP, gRPC)
• ✅ Team separation needed
• ✅ Starting fresh

Migration Path

Good news! You can run both at the same time.

graph TD
    A["Start with Ingress"] --> B["Add Gateway API"]
    B --> C["Migrate routes gradually"]
    C --> D["Remove old Ingress"]

🎉 Summary

You just learned how to be the ultimate traffic controller for Kubernetes!

Remember the hotel analogy:

• Ingress = Reception desk
• Gateway API = Modern automated lobby
• Controllers = Staff who do the work
• Rules = Signs pointing guests to rooms
• TLS = Security badges

You’re now ready to route traffic like a pro! 🚀