The Kladde runs in the cluster. Its service kladde-web is of type ClusterIP (lesson W1.2) and therefore unreachable from outside: it has an address that only pods in the cluster know. This lesson answers the question that comes next: How does a call to https://kladde.example.com get from the internet to a pod, and who decides along the way about names, paths, TLS and the distribution across versions?

The classic answer is ingress. It has recently stopped being a good answer, and that is why this lesson starts with the Gateway API and treats ingress only as a reason and as a migration note.

From the outside in

A service of type ClusterIP is reachable only inside the cluster. For traffic from outside to get in, the cluster needs two things: an address that is reachable from outside (on AKS an Azure load balancer with a public IP, in the cluster a service of type LoadBalancer), and a proxy behind it that distributes requests to the services by host and path. Who runs the proxy and how it is configured is the real question:

  • Ingress is a Kubernetes object that describes rules (host, path, service, TLS). On its own it does nothing: an ingress controller in the cluster has to read the rules and set up a proxy accordingly. The Kubernetes project itself now says that it recommends the Gateway API instead of ingress, and that the ingress API is frozen: it stays generally available but is no longer developed further.
  • Gateway API is the successor: several objects instead of one, with clear responsibilities, with more capabilities in the standard and fewer vendor switches.

Why Ingress-NGINX is being retired

The most widespread ingress controller project, Ingress-NGINX, is no longer maintained upstream. The Kubernetes project has announced the retirement of the project and ended maintenance. The AKS add-on "Application Routing" with NGINX builds on it: Microsoft delivers only critical security updates for it, until a cutoff date that the migration page on Microsoft Learn names (read it there; this lesson does not change it), and asks users to switch by then. Whoever uses the NGINX add-on has to move to the add-on's Gateway API implementation or to another supported solution. New AKS Automatic clusters use the Gateway API through the application routing add-on by default from AKS 1.36.

Ingress already had weaknesses before, which the Gateway API project names:

  • Few capabilities in the standard. The ingress API knows only TLS termination and simple routing by content. Everything else (redirects, rewrites, weights) lives in a vendor's annotations.
  • Annotations are not portable. If you change the controller, you lose the configuration that lived in the annotations.
  • The permission model doesn't fit several teams. One object contains decisions of operations (port, TLS) and of development (paths) together.