Kubernetes IngressClass: Den Ingress-Controller wählen – einfach erklärt

Die Kubernetes IngressClass (API-Gruppe networking.k8s.io/v1) bestimmt, welcher Ingress-Controller die Regeln eines Ingress-Objekts umsetzt. Ein Cluster kann mehrere Ingress-Controller betreiben (etwa NGINX, Traefik und HAProxy) – die IngressClass wählt pro Ingress aus, wer zuständig ist. Sie funktioniert damit wie die StorageClass für Speicher: eine Ressource, die auf eine konkrete Implementierung verweist.

Aufbau

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/ingress-nginx

Das Feld spec.controller enthält den Controller-Namen, den die Implementierung registriert (z.B. k8s.io/ingress-nginx oder traefik.io/ingress-controller). Optional verweist spec.parameters auf eine controller-spezifische Parameter-Ressource wie eine IngressClassParameters.

Auswahl und Default

Ein Ingress-Objekt wählt seine Klasse über spec.ingressClassName. Ohne Angabe greift die als Standard markierte IngressClass – dafür setzt man die Annotation ingressclass.kubernetes.io/is-default-class: "true". Es darf höchstens eine Standard-Klasse geben; sind mehrere markiert, lehnt der Admission-Controller neue Ingress-Objekte ohne explizite Klasse ab. Die frühere Auswahl per Annotation kubernetes.io/ingress.class ist veraltet.

Abgrenzung

Das Ingress-Objekt selbst (siehe Kubernetes Ingress) definiert Host- und Pfad-Regeln. Die IngressClass entscheidet nur, welcher Controller diese Regeln in die Proxy-Konfiguration übersetzt. Der Controller lenkt den Verkehr anschließend auf Services, deren Ziel-Pods über EndpointSlices aktuell gehalten werden. Wer Sticky Sessions auf HTTP-Ebene braucht, aktiviert sie meist am Controller – die Service-Ebene bietet mit der Session Affinity nur die Client-IP-Variante.

Verwandte Grundlagen: Kubernetes Ingress, Gateway API, StorageClass, Kubernetes Service.