Kubernetes Ingress: Routing HTTP traffic into the cluster

In short: A set of rules that determines which web addresses from outside lead to which services in the Kubernetes cluster.

In more detail: Pods in Kubernetes are not directly reachable from outside. A service makes them discoverable within the cluster. For a web request from the internet to arrive, you additionally need an ingress: it describes rules such as “shop.example.com goes to the service shop”. An ingress controller (for example nginx or Traefik) implements the rules.

In Depth

Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
spec:
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: shop, port: { number: 80 } }

Here the host shop.example.com with a TLS certificate is routed to the service shop.

Tasks of the controller

The controller runs as a pod in the cluster and reads the ingress resources. It works as a reverse proxy: accepts connections, terminates TLS, selects the service by host and path and distributes to its pods. Additional functions such as redirecting HTTP to HTTPS, timeouts or rate limits are controlled via annotations.

Automatic certificates

With cert-manager, certificates (for example from Let’s Encrypt) can be requested and renewed automatically. The ingress then only refers to the name of the secret.

Gateway API

The Gateway API is regarded as the successor. It separates roles more precisely (the infrastructure operator provides a gateway, application teams create routes) and supports more than HTTP. The classic ingress is still widespread, though.

See also: Kubernetes basics, nginx and reverse proxy, Let’s Encrypt and TLS certificates, Load balancer