DEV Community

Isreal Urephu
Isreal Urephu

Posted on

Why Kubernetes Ingress Is Broken (and How Gateway API Fixes It)

The ๐—ž๐Ÿด๐˜€ ๐—œ๐—ป๐—ด๐—ฟ๐—ฒ๐˜€๐˜€ has been one of (if not the) major ways of exposing applications running in a Kubernetes cluster to external traffic. Other options include ๐—ก๐—ผ๐—ฑ๐—ฒ๐—ฃ๐—ผ๐—ฟ๐˜, ๐—Ÿ๐—ผ๐—ฎ๐—ฑ๐—•๐—ฎ๐—น๐—ฎ๐—ป๐—ฐ๐—ฒ๐—ฟ, or using a ๐˜€๐—ฒ๐—ฟ๐˜ƒ๐—ถ๐—ฐ๐—ฒ ๐—บ๐—ฒ๐˜€๐—ต. But Ingress still comes out on top and remains one of the most widely adopted ways to expose applications.

That said, Ingress has plenty of limitations that make it tricky to manage. Letโ€™s break it down:

In a typical Ingress resource, the ๐˜€๐—ฝ๐—ฒ๐—ฐ section is where you configure your host, route to the backend service, and the service itself. Thatโ€™s pretty much it. But to make an Ingress ๐™ฅ๐™ง๐™ค๐™™๐™ช๐™˜๐™ฉ๐™ž๐™ค๐™ฃ-๐™ง๐™š๐™–๐™™๐™ฎ, we usually need more: ๐˜๐—ฟ๐—ฎ๐—ณ๐—ณ๐—ถ๐—ฐ ๐˜€๐—ฝ๐—น๐—ถ๐˜๐˜๐—ถ๐—ป๐—ด, ๐—ง๐—Ÿ๐—ฆ ๐—ฐ๐—น๐—ถ๐—ฒ๐—ป๐˜ ๐—ฎ๐˜‚๐˜๐—ต๐—ฒ๐—ป๐˜๐—ถ๐—ฐ๐—ฎ๐˜๐—ถ๐—ผ๐—ป, ๐—ฟ๐—ฎ๐˜๐—ฒ ๐—น๐—ถ๐—บ๐—ถ๐˜๐—ถ๐—ป๐—ด, ๐—–๐—ข๐—ฅ๐—ฆ, ๐—ต๐—ฒ๐—ฎ๐—ฑ๐—ฒ๐—ฟ ๐—บ๐—ฎ๐—ป๐—ถ๐—ฝ๐˜‚๐—น๐—ฎ๐˜๐—ถ๐—ผ๐—ป, and so on. These canโ€™t be handled in the spec directly.

The workaround? ๐—”๐—ป๐—ป๐—ผ๐˜๐—ฎ๐˜๐—ถ๐—ผ๐—ป๐˜€.

The problem? Annotations are specific to the ๐—ถ๐—บ๐—ฝ๐—น๐—ฒ๐—บ๐—ฒ๐—ป๐˜๐—ฎ๐˜๐—ถ๐—ผ๐—ป (๐—ก๐—š๐—œ๐—ก๐—ซ, ๐—ง๐—ฟ๐—ฎ๐—ฒ๐—ณ๐—ถ๐—ธ, ๐—ž๐—ผ๐—ป๐—ด, ๐—ฒ๐˜๐—ฐ.). This becomes a mess if you ever want to migrate to a different Ingress controller, because you basically have to rewrite everything.

This is where the ๐—š๐—ฎ๐˜๐—ฒ๐˜„๐—ฎ๐˜† ๐—”๐—ฃ๐—œ comes in.

With Gateway API, everything is ๐˜€๐˜๐—ฎ๐—ป๐—ฑ๐—ฎ๐—ฟ๐—ฑ๐—ถ๐˜‡๐—ฒ๐—ฑ from traffic routing to rate limiting to advanced policies. And the best part: itโ€™s the same across implementations. So an ๐—ป๐—ด๐—ถ๐—ป๐˜…-๐—ด๐—ฎ๐˜๐—ฒ๐˜„๐—ฎ๐˜†-๐—ณ๐—ฎ๐—ฏ๐—ฟ๐—ถ๐—ฐ setup would work with ๐—ง๐—ฟ๐—ฎ๐—ฒ๐—ณ๐—ถ๐—ธ without needing to change annotations.

๐—–๐—ผ๐—ฟ๐—ฒ ๐—–๐—ผ๐—บ๐—ฝ๐—ผ๐—ป๐—ฒ๐—ป๐˜๐˜€ ๐—ผ๐—ณ ๐—š๐—ฎ๐˜๐—ฒ๐˜„๐—ฎ๐˜† ๐—”๐—ฃ๐—œ:
1๏ธโƒฃ ๐—š๐—ฎ๐˜๐—ฒ๐˜„๐—ฎ๐˜†๐—–๐—น๐—ฎ๐˜€๐˜€ โ€“ Points to the implementation (e.g., Istio, NGINX Gateway Fabric, HAProxy Ingress).
2๏ธโƒฃ ๐—š๐—ฎ๐˜๐—ฒ๐˜„๐—ฎ๐˜† โ€“ Refers to the endpoint that processes traffic (e.g., filtering, routing, load balancing). This could be a cloud load balancer, proxy, or a server with LB installed.
3๏ธโƒฃ ๐—ฅ๐—ผ๐˜‚๐˜๐—ฒ๐˜€ โ€“ Define how traffic flows from the Gateway endpoint to backend services, which then forward to the pods.

This is just a high-level overview. In my upcoming posts, Iโ€™ll share how to migrate from Ingress to Gateway API.
๐Ÿ‘‰ Consider a repost if you found this useful.

Useful links:

Top comments (0)