Kubernetes: Der Weg von der Ingress API zur Gateway API
Mit der Gateway-API gibt es einen Nachfolger der Ingress-API, der diese sowohl bei Funktionstiefe, Komplexität und Enterprise-Tauglichkeit übertrifft.
- Erkan Yanar
Im November 2025 sorgte die Nachricht vom Ende des Community-NGINX-Ingress-Controllers für Unruhe innerhalb der Kubernetes-Community. Schnell machte die Einschätzung die Runde, das Ende des Controllers bedeute auch das Ende der Ingress API selbst und erfordere innerhalb weniger Monate den Umstieg auf die im Post erwähnte Kubernetes Gateway API. Nachdem sich der aufgewirbelte Staub gelegt hat, ist es Zeit, sich die Fakten anzusehen und sich der Gateway API als Nachfolgerin der Ingress API zu widmen.
Das angebliche Ende der Ingress API war eine Fehleinschätzung, hier wurde sprichwörtlich das Kind mit dem Bade ausgeschüttet. Der Community-NGINX-Ingress-Controller ist lediglich eine von vielen Implementierungen der stabilen und eben nicht abgekündigten Ingress API. Damit lässt er sich ohne Funktionsverlust durch jeden anderen Ingress-Controller ersetzen, ohne die Ingress API aufzugeben. Letztere ist sehr einfach aufgebaut. Oft benötigte Funktionen sind nicht Teil der Ingress API, werden aber durch Ingress-Controller bereitgestellt. Der Zugriff auf diese Funktionen erfolgt an der Ingress API vorbei.
- Die AbkĂĽndigung des Community-NGINX-Controllers fĂĽhrte zu BefĂĽrchtungen, innerhalb weniger Wochen auf die Kubernetes Gateway API umsteigen zu mĂĽssen.
- Trotz anders lautender Einschätzungen hat die Einstellung des verbreiteten Community-Controllers keinen Einfluss auf die Ingress API in Kubernetes.
- Mit der Gateway API gibt es einen Nachfolger der Ingress API, der diese sowohl bei der Funktionstiefe als auch bei der Komplexität und Enterprise-Tauglichkeit übertrifft.
- Wer noch nicht auf die Gateway API wechseln möchte, kann mit dem Ingress-NGINX-Fork von Chainguard Zeit gewinnen und sein bisheriges Set-up weiter nutzen.
In Kubernetes hat sich historisch ein Pattern etabliert, controllerspezifische Konfigurationen in den Annotationen des entsprechenden Kubernetes-Objekts abzulegen. Die Konvention fĂĽr Annotation Keys ist: <Controller-Domain>/<Konfigurationsoption>, also beispielsweise:
