Routing Traffic with Ingress

An Ingress (networking.k8s.io/v1) describes HTTP(S) routing rules — host and path combinations mapped to backend Services — but on its own it's just data, the same way a CRD is inert without a controller. Nothing in the core API server actually routes traffic for it. An Ingress Controller (nginx, and many others) has to be running in the cluster, watching Ingress objects and provisioning the real reverse proxy or load balancer that does the routing. An IngressClass names which controller a given Ingress should be handled by.

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

pathType has three values, since Kubernetes v1.18. Prefix matches a path segment by segment. Exact matches the request path exactly, case-sensitively, with nothing appended. ImplementationSpecific is the default if pathType is left unset — its actual matching behavior depends entirely on whichever controller is running, not on a fixed Kubernetes-wide rule.

One Ingress, behind one controller, can route many different hostnames and paths to many different backend Services — the usual reason to use Ingress at all instead of a separate LoadBalancer Service per application. A tls section can also list which Secret holds the certificate for a given host, so the controller terminates HTTPS at the edge before forwarding plain HTTP internally, and a defaultBackend can catch any request that matches none of the declared rules.