Ingress vs Gateway API

The same carlo-nginx pod in namespace carlo on dev-01, reachable through two different entry points.

This request was served via ingress-nginx Host: nginx-ingress.carlo.pub.dev-01.kvant.cloud

You are here

Ingress + ingress-nginx

RetiredIngress API frozen

Clientnginx-ingress.carlo.pub.dev-01.kvant.cloud

HTTPS

MetalLB LoadBalancer192.135.63.138 · shared by every Ingress

TCP 443

ingress-nginx controllernginx · ns ingress-nginx
TLS termination, host/path match

ConfigIngress carlo-nginx + annotations → controller renders nginx.conf and reloads (same pod)

HTTP · adds X-Scheme

Pod carlo-nginxendpoints of Service carlo-nginx:80

The original Kubernetes way to expose HTTP: one Ingress object per app, served by a shared controller. The API only covers host and path routing, so anything more (headers, redirects, timeouts) means controller-specific annotations or raw nginx snippets.

The community ingress-nginx project has been retired and no longer receives releases or security fixes, and the Ingress API itself is feature-frozen. New work should target Gateway API.

You are here

Gateway API

Current standard

Clientgateway-api.carlo.pub.dev-01.kvant.cloud

HTTPS

MetalLB LoadBalancer192.135.63.143 · dedicated to carlo-gateway

TCP 443

Envoy · Gateway carlo-gatewayns openshift-ingress · class openshift-default
TLS *.carlo.pub, host match

ConfigGateway + HTTPRoute → istiod (OSSM 3) → pushed live to Envoy over xDS, no reloads

HTTP · HTTPRoute sets X-Served-Via

Pod carlo-nginxendpoints of Service carlo-nginx:80

The successor to Ingress, maintained by Kubernetes SIG Network and implemented by many vendors; on OpenShift it is built in, backed by Envoy. Headers, redirects, traffic splitting and TLS are typed, portable fields instead of annotations.

Roles are split: the platform team owns the GatewayClass and Gateway (IP, ports, certificates, which namespaces may attach), while app teams own their HTTPRoutes.