Ingress and the Gateway API

Kubernetes · Practical · 12 min

One entry point with TLS and routing rules is how web apps are exposed, not a load balancer per Service.

An Ingress describes HTTP routing: hosts, paths, and the backend Service for each, plus TLS certificates from Secrets. It does nothing on its own: an ingress controller (Traefik, HAProxy, a cloud load balancer controller, ingress-nginx...) watches Ingress objects and configures a proxy. ingressClassName picks the controller. Many features (rewrites, timeouts) live in controller-specific annotations, which is the Ingress API's weakness. The once-default community ingress-nginx controller has been retired, so check what your platform supports.

The Gateway API is the newer, more expressive standard, now the recommended direction:

  • GatewayClass: a kind of load balancer, provided by an implementation (Envoy Gateway, Istio, Cilium, cloud controllers).
  • Gateway: an instance with listeners (ports, protocols, TLS), usually owned by the platform team.
  • HTTPRoute (also GRPCRoute and others): routing rules owned by app teams, attached to a Gateway, with header matching, traffic splitting by weight, redirects and rewrites built in.

The role split (infrastructure vs routes) and the portable features are why new setups tend to choose it. Gateway API CRDs are installed separately from Kubernetes itself.

For certificates, cert-manager can issue and renew Let's Encrypt certificates for both Ingress and Gateway resources.

Example

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
spec:
  parentRefs:
    - name: public-gw          # a Gateway run by the platform team
      namespace: infra
  hostnames: ["shop.example.com"]
  rules:
    - matches: [{path: {type: PathPrefix, value: /api}}]
      backendRefs:
        - {name: api, port: 80, weight: 90}
        - {name: api-canary, port: 80, weight: 10}   # 10% canary
    - backendRefs:
        - {name: web, port: 80}
# kubectl get httproute shop -o yaml   # status.parents shows Accepted / ResolvedRefs

Remember

  • Ingress and Gateway need a controller/implementation to do anything
  • Gateway API splits Gateway (infra) from routes (apps)
  • Weighted backends make canaries possible without extra tools

Watch out for

  • Creating an Ingress in a cluster with no ingress controller and wondering why nothing listens.

Check yourself

  1. You applied an Ingress but nothing serves traffic, and its ADDRESS stays empty. Most likely cause?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: kubernetes.io/docs/concepts/services-networking/gateway/

Builds on

Unlocks

Nothing builds on this yet.