Ingress and the Gateway API

Ingress is HTTP routing into the cluster: one external entry point that sends requests to different Services by hostname and path, terminating TLS along the way. It exists so you do not provision a separate cloud load balancer for every service.

Ingress is also showing its age. The Gateway API is its successor — a richer, role-oriented model that is now the recommended direction for new routing. This topic covers both, and when to use which.

The Ingress Object

An Ingress is a set of HTTP routing rules: for this host and this path prefix, send traffic to that Service. One Ingress can front many Services behind a single external IP, which is the whole point — host- and path-based virtual hosting without a load balancer per service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: site
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: orders
                port:
                  number: 80

Ingress Controllers

The Ingress object is just data; nothing happens until an Ingress controller is running to read it and configure an actual proxy. NGINX, HAProxy, Traefik, and cloud-native controllers are common choices. The ingressClassName field picks which controller handles a given Ingress, so multiple controllers can coexist. Forgetting to install a controller is the classic "my Ingress does nothing" mistake.

TLS termination is configured on the Ingress by referencing a Secret that holds the certificate and key. The controller terminates HTTPS at the edge and forwards plain HTTP to the backend Services — though most setups pair this with cert-manager to issue and renew certificates automatically.

The Limits of Ingress

Ingress was scoped narrowly to HTTP host/path routing, so anything beyond that — header-based routing, traffic splitting for canaries, gRPC, TCP/UDP — was bolted on through controller-specific annotations. Those annotations are not portable: an Ingress tuned for NGINX does not behave the same on another controller. The model also blurs roles, mixing infrastructure concerns and application routing in one object owned by one team.

The Gateway API

The Gateway API replaces annotation-soup with first-class, portable resources and a clean separation of roles. A GatewayClass and Gateway are owned by the platform or infrastructure team (the listeners, IPs, and TLS), while HTTPRoute (and TCPRoute, gRPCRoute) are owned by application teams and attach to a Gateway. Header matching, traffic splitting, and cross-namespace routing are built in, not annotations.

For new clusters the Gateway API is the recommended path; Ingress remains widely deployed and fully supported, so you will meet both for years. The practical guidance: learn Ingress because it is everywhere, and prefer the Gateway API for anything new that needs more than basic host/path routing.