Exploring Kubernetes traffic management? Let’s break down Ingress Controllers vs. Gateway API.

Below is a sample architecture comparing Ingress Controller and Gateway API in a Kubernetes environment. I’ll describe a simple e-commerce application with two setups: one using an Ingress Controller and another using Gateway API. Each architecture handles traffic routing to a frontend and backend service.

Scenario

- Application: E-commerce platform

- Components:

- Frontend: A React-based UI (running on port 80)

- Backend: A Node.js API (running on port 3000)

- Requirements: Route traffic to / for the frontend and /api for the backend, with TLS termination.

---

1. Architecture with Ingress Controller

Overview

Uses an NGINX Ingress Controller to route HTTP traffic to the frontend and backend services.

Sample Configuration

# Service for Frontend

apiVersion: v1

kind: Service

metadata:

  name: frontend-service

spec:

  ports:

    - port: 80

      targetPort: 80

  selector:

    app: frontend

# Service for Backend

apiVersion: v1

kind: Service

metadata:

  name: backend-service

spec:

  ports:

    - port: 3000

      targetPort: 3000

  selector:

    app: backend

# Ingress Resource

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: ecommerce-ingress

  annotations:

    nginx.ingress.kubernetes.io/rewrite-target: /

    kubernetes.io/ingress.class: nginx

spec:

  rules:

  - host: "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: 3000

  tls:

  - hosts:

    - "example.com"

    secretName: tls-secret
        

#### Key Points

- Pros: Simple setup, widely supported, good for HTTP-only traffic.

- Cons: Limited to HTTP/HTTPS, relies on annotations for advanced features (e.g., rate limiting), less portable across controllers.

---

2. Architecture with Gateway API

Overview

Uses Gateway API (e.g., with an Envoy-based Gateway implementation) for more flexible, protocol-agnostic routing.

Sample Configuration

# GatewayClass (defined by the provider)

apiVersion: gateway.networking.k8s.io/v1

kind: GatewayClass

metadata:

  name: envoy-gateway-class

spec:

  controllerName: "example.com/envoy-gateway-controller"

# Gateway Resource

apiVersion: gateway.networking.k8s.io/v1

kind: Gateway

metadata:

  name: ecommerce-gateway

spec:

  gatewayClassName: envoy-gateway-class

  listeners:

  - name: http

    protocol: HTTP

    port: 80

  - name: https

    protocol: HTTPS

    port: 443

    tls:

      certificateRefs:

      - name: tls-secret

# HTTPRoute Resource

apiVersion: gateway.networking.k8s.io/v1

kind: HTTPRoute

metadata:

  name: ecommerce-route

spec:

  parentRefs:

  - name: ecommerce-gateway

  hostnames:

  - "example.com"

  rules:

  - matches:

    - path:

        type: PathPrefix

        value: /

    backendRefs:

    - name: frontend-service

      port: 80

  - matches:

    - path:

        type: PathPrefix

        value: /api

    backendRefs:

    - name: backend-service

      port: 3000        

Key Points

- Pros: Protocol-agnostic (HTTP, TCP, gRPC), portable across implementations, supports advanced routing (e.g., traffic splitting), separates infra and app logic.

- Cons: Newer standard, requires Gateway API support in your cluster, steeper learning curve.

---

Comparison

When to Use

- Ingress Controller: Small-scale apps, HTTP-only traffic, teams new to Kubernetes.

- Gateway API: Multi-protocol apps, advanced routing needs, hybrid or multi-cluster setups.

Let me know if you’d like me to refine this further or add deployment steps!