Ingress and ingress controllers

Ingress routes HTTP/HTTPS from outside to many Services through one entry point by host and path; it needs an ingress controller to work.

flowchart LR
  U["Client"] --> LB["One load balancer / IP"]
  LB --> IC["Ingress controller<br/>(ingress-nginx)"]
  IC -- "grafana.example.com" --> S1["svc grafana"]
  IC -- "web.example.com/api" --> S2["svc api"]
  IC -- "web.example.com/" --> S3["svc web"]

An Ingress is an API object describing how HTTP/HTTPS from outside reaches Services: load balancing, TLS termination, virtual hosting by name and path. One Ingress replaces many LoadBalancer Services, saving IPs and money.

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

Three styles: default backend (no rules), simple fanout (one host, several paths → several Services), name-based virtual hosting (several hostnames on one IP).

What it needs

The cluster needs an ingress controller (ingress-nginx, AWS Load Balancer Controller, Traefik…). Controllers do not ship with the cluster like those in kube-controller-manager; without one, an Ingress never gets an ADDRESS.
Pick the controller with spec.ingressClassName (the kubernetes.io/ingress.class annotation is deprecated).
Backend Services must be in the same namespace as the Ingress.
Ingress only handles HTTP/HTTPS; other TCP/UDP (PostgreSQL, MQTT…) uses LoadBalancer/NodePort Services.
extensions/v1beta1 with serviceName/servicePort was removed in 1.22.

Command	Meaning
`kubectl get ingress`	CLASS, HOSTS, ADDRESS
`kubectl describe ingress web`	Rules, backends, events
`kubectl create ingress web --class=nginx --rule="web.example.com/*=web:80"`	Create an Ingress quickly

TLS on an Ingress

spec:
  tls:
  - hosts: [web.example.com]
    secretName: web-tls

The Secret (type kubernetes.io/tls) holds the certificate and key. cert-manager can create and renew it automatically from Let's Encrypt or an internal CA when you add an annotation such as cert-manager.io/cluster-issuer: letsencrypt, so certificates never expire unnoticed.

Path types

`pathType`	Matching
`Prefix`	Matches by path segments: `/api` matches `/api` and `/api/users`, not `/apis`
`Exact`	Only the exact path
`ImplementationSpecific`	Up to the controller

When several rules match, the longest path wins.

Controller-specific features

Behaviour such as rewrites, rate limits, body size, or authentication is set with annotations that differ between controllers (nginx.ingress.kubernetes.io/... for ingress-nginx, alb.ingress.kubernetes.io/... for the AWS controller). Moving to another controller therefore means rewriting annotations. Note that the community ingress-nginx project has announced its retirement, so new clusters often choose another controller or the Gateway API.

The Gateway API

The Gateway API is the newer standard for traffic into the cluster. It splits responsibilities: a platform team manages a GatewayClass and Gateway (listeners, TLS), while app teams attach HTTPRoute objects with path, header, and weight-based rules, including traffic splitting for canaries. It also covers TCP, UDP, and gRPC routes, which Ingress cannot. Most major controllers and service meshes support it.

Debugging an Ingress

kubectl get ingress shows an ADDRESS? If not, the controller is missing or the class name is wrong.
curl -H "Host: web.example.com" http://<address>/ tests the rule without DNS.
Check that the backend Service has endpoints and that the controller's logs (kubectl logs -n ingress-nginx deploy/ingress-nginx-controller) show no errors.